Hello,

i hope this is the correct place for my problem.

I used the OGCServer as a CGI Script (your wms.py) and i think the paths are set correctly. But when i want to run the Server i have several Problems.

• When I start a GetMap Request in version 1.1.1, i get a blank Map. The Requestparameter that i used will work without problems with the UMN Mapserver. So i think the BBox and the projection are correctly set. My XML File from that i read will also be found form the OGCServer and shows Map with nik2img.py.

What do i wrong to show a map in the Browser.

• When I start a GetMap Request in Version 1.3.0 i get an internal ServerError. And the Apache Log shows the following:

Traceback (most recent call last):
File "/usr/lib/cgi-bin/wms.py", line 29, in <module>
fcgi.Server({fcgi.FCGI_RESPONDER: OGCServerHandler}).run()
File "/usr/local/lib/python2.6/dist-packages/jon/fcgi.py", line 514, in run
self.handler_types[FCGI_RESPONDER]).process()
File "/usr/local/lib/python2.6/dist-packages/jon/cgi.py", line 476, in process
handler.traceback(self)
File "/usr/local/lib/python2.6/dist-packages/ogcserver/cgiserver.py", line 87, in traceback
eh = ExceptionHandler130(self.debug)
TypeError: __init__() takes at least 3 arguments (2 given)

• When I start the wms.py from console i get nearly the same error with a diffrent Version:

Traceback (most recent call last):
File "/usr/lib/cgi-bin/wms.py", line 29, in <module>
fcgi.Server({fcgi.FCGI_RESPONDER: OGCServerHandler}).run()
File "/usr/local/lib/python2.6/dist-packages/jon/fcgi.py", line 514, in run
self.handler_types[FCGI_RESPONDER]).process()
File "/usr/local/lib/python2.6/dist-packages/jon/cgi.py", line 476, in process
handler.traceback(self)
File "/usr/local/lib/python2.6/dist-packages/ogcserver/cgiserver.py", line 87, in traceback
eh = ExceptionHandler111(self.debug)
TypeError: __init__() takes at least 3 arguments (2 given)

Could you help me to solve these Problems?

(Sorry for my bad English)

There's something kind of odd with styles in OGCServer. In loadXML in BaseWMSFactory you have an if / else branch on style_count, the number of styles for a layer in the xml file. Zero raises an error; after that you distinct between style_count == 1 and style_count > 1.

Ignoring meta styles for now, if a layer has 1 style only, you add this style to both props layer.wmsdefaultstyle and layer.wmsextrastyles, by calling register_layer as follows:

self.register_layer(lyr_, style_name, extrastyles=(style_name,))

When requesting a map, a style must be contained in layer.wmsextrastyles to be a valid candidate for the STYLE WMS parameter (if not, you raise an exception). Since the layer's style has been added to both layer.wmsdefaultstyle and layer.wmsextrastyles, you can add this style to your request's STYLE parameter or not - you always get the same result and no exception.

The problem with these single-style layers comes with the GetCapabilities request. You advertise styles for a layer only, if there are extra styles present. However, you write out the default style and all extra styles. As a result, for single-style layers, the layer's default style occurs twice in the capabilities document. According to OGC, default styles may be omitted from the capabilities response.

With multi-style layers, things go different. You create an xxx_aggregates style, that is used as the layer's default style. The actual styles go into extra styles. As with all layers, both default and extra styles are published in the capabilities document. However, since the advertised xxx_aggregates default style is not part of extra styles, you'll get an exception, if you actually include it in you STYLES parameter.

IMO, only extra styles should be advertised in the capabilities document. Single-style layers should not add their style name to layer.wmsextrastyles. Then, these problems could be fixed with only two modifications: (actually three, since there is wms111 and wms130)

First, change WMS.py, line 128 from

self.register_layer(lyr_, style_name, extrastyles=(style_name,))

to

self.register_layer(lyr_, style_name, extrastyles=())

Then, change in both wms111.py, line 211 and wms130.py, line 234 from

for extrastyle in [layer.wmsdefaultstyle] + list(layer.wmsextrastyles):

to

for extrastyle in list(layer.wmsextrastyles):

However, after that, it is no longer possible to explicitly request the default style through the STYLE parameter for any layer (currently it's possible for single-style layers).

Carsten

Hi, This pull request adds possibility to load mapnik XML configuration from string using load_map_from_string function. There is a check if 'xmlfile' is existing file (os.path.isfile) - if not 'load_map_from_string' will be used. This is second pull request after #26 - earlier I've add wrong checkig - sorry for that.

Regards Piotr Pociask

When using the wms service in ArcMap, the layers will be requested top-down (first in xml is drawn last). Reversing the layer list in the GetCapabilities response could be a quick way of solving this.

'HTTP_USER_AGENT': 'ArcGIS Client Using WinInet'

Adds a LatLonBoundingBox element to the root layer in the GetCapabilities response for WMS 1.1.1, and an equivalent EX_GeographicBoundingBox element for WMS 1.3.0.

According to the WMS 1.1.1 (section 7.1.4.5.6) specification:

"Every Layer shall have exactly one element that is either stated explicitly or inherited from a parent Layer."

The 1.3.0 spec contains a similar section (7.2.4.6.6).

We have a customer with a WMS client (DigPro) that is kind of picky and apparently refuses to work correctly if this element is missing.

OGCserver does not work properly through a reverse proxy in WSGI mode as it binds SERVER_NAME, SERVER_PORT and PATH_INFO. There should be 'onlineresource' parameter in ogcserver.conf in '[server]' group.

patch available: http://trac.mapnik.org/ticket/316

Hi there,

currently there may be two concurrent names that designate 'getting all layers' from OGCServer; one is 'all' and the other one may be what was configured for wms_name under the [map] section in the config file. The latter defaults to 'all', so if no other name was specified, the root layer node in the capabilities document, which actually is a group in WMS terms, is named 'all'. According to WMS specs, requesting a named group layer should actually return all its child layers in the order as they appear in the caps document. So, if wms_name is left to its default name 'all' (the name of the root layer node), everything works as expected and satisfies WMS standards and also allows clients to get the whole map "as seen by Mapnik", that is something like the "real" Mapnik map.

However, since in _buildMap the token 'all' is still hard-coded, things get odd if someone configures a different name for wms_name. The configured name is not valid in the LAYERS parameter and throws a 'LayerNotDefined' exception. Still one has to request for 'all'.

One obvious solution is to replace the hard-coded 'all' token in _buildMap with the name configured for wms_name. Easy as that. However, since this is closely related to WMS groups, things may be more complicated.

In code, the comments at the 'all' branch in _buildMap state, that this is intended to provide a map like plain Mapnik does. Call it the "real" Mapnik map. Since all layers under the root layer node (group) are actually in Mapnik order, this "real" Mapnik view of the map exactly matches the root layer group according to WMS. However, I we add support for additional WMS groups, these two maps may be different.

Also the currently implemented meta layers, that expose all named rules of a style as separate layers in the form <layer_name>:<named_rule_1>-<named_rule_2> breaks this concept and makes the WMS root layer group define a map different from the "real" Mapnik map.

BTW, the meta layers based on named rules feature is poorly implemented; since a layer's abstract text is preferred over its name (which is mostly an empty string), most of these meta layers are actually named :<named_rule_1>-<named_rule_2> (with no layer name). Is this a permanent feature or is it just a quick hack like the Haiti stuff?

So, how to deal with the problems of wms_name and 'all' highly depends on what other WMS features we plan to implement, notably meta layers for named rules and WMS groups.

If we agree to guarantee, that there will always be only one root layer group that only contains the "real" Mapnik layers (that is, no WMS groups and removing the mete layers based on named rules), we should actually replace the hard-coded 'all' in _buildMap with wms_name. Additionally, we should provide a better integration of this single (and only) root layer group. Notably we should support requests like LAYERS=buildings,streets,all,rivers etc. That's easy to achieve.

If we agree to support arbitrary WMS layer groups and like to keep the meta layers based to named rules, we must keep wms_name and 'all' separated. We'll likely need a new configuration file type for WMS groups. Most suitable will be a hierarchical format, like XML or JSON. Maybe we still keep a key/value base config file and go for an additional hierarchical groups.conf file. Then, we should treat the root layer group as a regular group and so replace wms_name by the new regular group definition syntax. However, since I want to get rid of the term 'all' (some commercial clients have problems with these double underscores), I'd like to make this extra non-WMS backdoor for getting plain Mapnik maps configurable as well.

Carsten

When making a GetMap request without explicitly specifying the bgcolor parameter, it appears my map always get a white background, although my mapnik XML specifies a background-color attribute.

This is an example URL I use: http://myhost/?service=WMS&version=1.1.0&request=GetMap&layers=__all__&bbox=-195609.547531264,5911221.52277581,1130387.38250057,7988952.8814813&width=326&height=512&srs=EPSG:3006&format=image/png&styles=

While trying to debug this by emulating what OGCServer does, I have a bit of a hard time actually finding where the problem lies, since the configuration seems to load the background color setting properly:

from ogcserver.WMS import BaseWMSFactory
from ogcserver.common import WMSBaseServiceHandler
from ogcserver.wms111 import ServiceHandler
from ogcserver.configparser import SafeConfigParser

conf = SafeConfigParser()
conf.readfp(open('../../conf/ogcserver.conf'))

f = BaseWMSFactory()
f.loadXML("lmv-bright.xml")

wms = ServiceHandler(conf, f, "")

m = wms._buildMap({"crs":"epsg:3006", "bbox":[-195609.547531264,5911221.52277581,1130387.38250057,7988952.8814813], "width":326, "height":512, "layers":["__all__"]})

m.background
>>> Color(R=167,G=207,B=242,A=255)   # <--- expected, and not white

Is this a OGCServer issue, or is it something with my setup/request that would trigger this behaviour?

QGIS trunk says: r13995 Advertised GetMap URL

http://tile2.dbsgeo.com:80/?

is different from GetCapabilities URL

http://tile2.dbsgeo.com/?

This might be an server configuration error. Should the URL be used

I've been trying to setup OGCServer on Ubuntu 12.014 and I seem to be having issues integrating WSGI.

I installed Mapnik 2.2.0 & python-mapnik packages. Then installed PIL & jonpy based on the doc here: https://github.com/mapnik/OGCServer/tree/master/docs

I setup OGCServer from the main branch as described in the readme. The test server works correctly for the demo.xml & I'm able to see the map.

I'm running into an error on:

from mapnik import ogcserver Traceback (most recent call last): File "", line 1, in ImportError: cannot import name ogcserver

Because of this i'm not able to proceed setting up WSGI integration. Can anyone let me know where I went wrong ? or any further guide to setup WSGI ?

Thank You

The default for Mapnik 2.3 is to return png8 when calling im.tostring('png'). Needs a way to define format returned (png8, png24 or png32)

https://github.com/mapnik/mapnik/issues/2110

ubuntu20.04 python3.8

There are some errors when I run ogcserver...

Traceback (most recent call last): File "/usr/local/bin/ogcserver", line 4, in import('pkg_resources').run_script('ogcserver==0.1.1', 'ogcserver') File "/usr/local/lib/python3.8/dist-packages/pkg_resources/init.py", line 666, in run_script self.require(requires)[0].run_script(script_name, ns) File "/usr/local/lib/python3.8/dist-packages/pkg_resources/init.py", line 1469, in run_script script_code = compile(script_text, script_filename, 'exec') File "/usr/local/lib/python3.8/dist-packages/ogcserver-0.1.1-py3.8.egg/EGG-INFO/scripts/ogcserver", line 48 print "Listening at %s:%s...." % (host,port) ^ SyntaxError: invalid syntax

_This comment is not yet complete. It covers a complex topic and I try to be very clear and correct, which takes some time. I will continue writing on it as time permits. This remark will be removed upon completion._

Introduction

There are some ideas of extending the features of OGCServer. Notably, these features are configurable named layer groups published through the capabilities documents, providing much more map and layer specific meta-information in the capabilities documents as well as support for providing external layers. The latter may come from other WMS servers, so this will make OGCServer a cascading WMS server. This also includes introducing a new, maybe additional, configuration file with a hierarchical structure, most likely in JSON format.

Let me first please define some basic specifications for supporting layer groups and other layer meta-information and for having a new, maybe JSON style, configuration file.

Configuration Files

After thinking about it, I do not recommend to completely replace the current configuration file ogcserver.conf with the new hierarchical wms.json or layers.json file. There are many plain (non hierarchical) and mostly internal or technical configuration options, that are not suitable for being stored in a JSON file. At current, this only applies to the module and to the maxage option. However, some of my next PRs will introduce some more of these basic configuration options.

Most of these basic options are OGCServer and implementation specific, so these need additional documentation (in contrast to WMS layer meta-information for example, which are explained by WMS specs). Since JSON basically has no support for inline comments, storing these in a file with a plain old configuration file format (like of the current ogcserver.conf file) is preferred.

Furthermore, for my understanding, all these new features, like layer groups, layer meta-information and external layers, shall be optional. That is, the server must also work without these configurations, by using proper default values. So, moving these into one ore more separate configuration file(s), which must not be present, is probably a good idea.

In all request entry functions, notably 'call' in wsgi.py and modserver.py and 'process' in cgiserver.py, you delete 'service' and 'version' parameters from reqparams. However, in the exception handler you get the version from reqparams in order to determine whether to create a 1.1.1 or a 1.3.0 exception. Since 'version' has been deleted, you end up constantly returning 1.1.1 exceptions even if VERSION=1.3.0 was specified on the request.

Since I do not see any problems with having both 'service' and 'version' in reqparams around, I recommend NOT deleting these entries after the service handler was setup. If you agree, I will include this in one of my upcoming pull requests (likely in the XML-prettifying PR).

Hi there,

All types of exception reports currently are returned with a HTTP status code of 404 Not Found. Actually, that's not ideal, since in case of an error ("Oh, I'm getting no map images...!"), most people will likely issue some test requests in a web browser. Since most modern browsers just do not show the response for a 404, you need Wireshark (or similar) to actually read the service exception.

You could either constantly use status code 200 OK for all responses (that's what GeoServer does, for example) or try using the codes recommended by OGC's 'Web Services Common Standard', which basically are 400 Bad Request and 501 Not Implemented.

For the latter solution, obviously there is more work to be done. You could probably pass the HTTP status code as a (new) last parameter to OGCException and use it in the handler accordingly. If you actually go that far, you could also add support for the 'locator' attribute for version 1.3.0 exception reports (also with an additional argument to ctor of OGCException).

At least for the self.debug == true case, in which you switch to the HTML handler, returning 200 OK would be helpful; the same seems to be true for IN_IMAGE and BLANK handlers. So, using different status codes for different exceptions, actually only applies to XML and - maybe - HTML formats.

Although not that familiar with Python (coming form Java, C++, VB etc.), I could likely implement these changes if you like (and one or two more, see upcoming issues). I need to use OGCServer in a production environment (Apache httpd, mod_wsgi etc.), but I'm really not a fan of creating my personal local branches.

However, I've read Dane Springmeyer's post "Inventory and evaluate merge of refactoring done for haiti instance", so I'm not quite sure whether the latest version is the one to implement these changes on. Maybe you should first clean up the code? Oh, the ticket is from 2010... As far as I've seen, the Haiti stuff is still there... Are still movong on with this?

Thanks in advance for any helpful reply, Carsten

When serving WMS for stylesheets with many layers, and layers with long names, its easy to hit the limit for length of GET requests for a given browser.

A "meta layers" hack was added to work around this problem for a haiti deployment of the ogcserver: https://github.com/mapnik/OGCServer/blob/master/ogcserver/common.py#L384 and this needs to be removed and proper support added.