1. MapServer generates poor URL in the GET request

MapServer, while making the GetFeature request, does not specify

• SRSNAME parameter – name of SRS, in which the resulting data should be
• BBOX parameter leaks on SRS specification – server can not be sure, in which SRS given coordinates are

Those are crucial parameters, when requesting data from WFS 1.1.0 in non-default coordinate reference system.

2. MapServer does not respect coordinates order in the GET request

For some SRSs, coordinates order should respect the order in the SRS, e.g. WGS84, declared as urn:ogc:epsg::4326 should be given in north, east order. This should be applied in the BBOX parameter of the GetFeature type of request.

3. MapServer is not aware of coordinates order of returned data

When formulating proper request (with proper coordinates order in the BBOX request and propper SRSNAME parameter), for some coordiante systems, data are returned from the server with north,east axis order. MapServer can not handle this, it does not recognize, that the data are “somewhere else”.

Those three problems, I have hopefully solved. However, it was not enough. Following two issues are not solvable for now, I have no idea how to approach:

4. MapServer is not able to respect SRS encoding in the request

According to WFS specification, there are three ways of SRS encoding specification:

• EPSG: EPSG_code — coordinates are NOT “swaped”
• http://www.opengis.net/gml/srs/epsg.xml#EPSG_code — no idea, weather the coordinates should or should not be swapped
• urn:EPSG:geographicCRC:epsg_code — coordinates should be swaped

MapServer uses the last form – always, but some servers are using the first form of SRS encoding. Currently, it is not possible to force MapServer, to give propper SRS encoding to the server and expect propper coordinate order. As said, I have no idea, how to make things working here – I know, where it should go, but dunno how to do that.

5. GDAL seems to be unable to handle some coordinate systems

Reading GML data, we can pass GML_INVERT_AXIS_ORDER_IF_LAT_LONG and GML_CONSIDER_EPSG_AS_URN configuration options, which will make GDAL (or OGR) know, that it should consider axis order of the data based on their SRS. This works well for EPSG:4326, but does not for other coordinate systems, such as EPSG:3035. Reason is EPSGTreatAsLatLong() function, which is not suitable for this purpose. There is already motion in GDAL about this issue, and patch available, but still, it is not at least in trunk.

Result is: propper data will come to MapServer. MapServer tries to read the data with help of OGR, but OGR does not recognize, that axis order is north, east and everything fails.

Conclusion

Do not try to use MapServer as WFS 1.1.0 client. Use mapscript and for configuration of mapserver, downloading the data and convering them to some suitable SRS.

Disclaimer

I love MapServer and MapScript. It is powerful combination and till now, I have done everything with it, including displaying various strange types of input data. Last time, I was programming in C, it was, when I was working at GRASS, nevertheless, I have tried with my limited skills to fix those issues in MapServer, so it is able to work as propper WFS 1.1.0 client. But this went too far. I’m not able to do it and this blog post expresses all my frustration from last weeks. If anybody want’s to make WFS 1.1.0 work within MapServer with all it’s axis-order-issues for various servers, I’m ready to help with testing, having list of various WFS servers by hand. Till then, I have to imlement this “by hand” somehow.

Problem is, WFS 1.1.0 servers should use axis order for the request, which coresponds with the CRS’s definition. I assume, axis order can be found at http://epsg-registry.org/ , but I’m not able to find, where in WFS 1.1 standard is it written, that the axis order is to be used, as defined in the CRS. Could anybody give me a hint?

The conference should bring the spirit of global FOSS4G event to our region. This year, it will be connected with traditional Geoinformatics FCE CTU conference, which will cover the academic section of FOSS4G-CEE.

Important dates:

• 1.1.2012 Call for papers & workshops
• 1.2.2012 Workshop submission deadline
• 1.3.2012 Papers submission deadline
• 15.2.2012 Confirmation of accepted workshops
• 15.3.2012 Confirmation of accepted papers
• 1.4.2012 Early bird registration deadline

For more information including the registration and submission of your contribution, please visit the conference website:

http://www.foss4g-cee.org

Take the opportunity of FOSS4G-CEE to network with geospatial fellows, renewing old acquaintances and making new ones. Hope to see you there!

About FOSS4G-CEE & Geoinformatics 2012

FOSS4G-CEE & Geoinformatics 2012 is the first local conference focused on Free and Open Source Software for Geospatial in Central and Eastern Europe. This year, it is connected together with traditional Geoinformatics FCE CTU.

The conference is intended to move it’s location over the region every year. It should be similar to the global FOSS4G conference, with focus on local regional issues.

About FOSS4G

FOSS4G is “the global conference” focused on Free and Open Source Software for Geospatial, organized by OSGeo. At FOSS4G you can meet all kind of actors: Free Software developers and any kind of representatives from companies, institutions and the academic world.

About Geoinformatics FCE CTU

Geoinformatics FCE CTU is the international conference which is organized by Department of Mapping and Cartography, Faculty of Civil Engineering, Czech Technical University in Prague. The conference is focused on the relevance of Free and Open Source Software in Geoinformatics concerning wide range of topics. Geoinformatics FCE CTU is the event with a fruitful history, organized since 2006.
FOSS4G Organizing Committee

RELATED LINKS

• http://foss4g-cee.org/ Foss4G-CEE
• http://geoinformatics.fsv.cvut.cz/ Geoinformatics FCE CTU
• http://foss4g.org/ The Global FOSS4G Conference

As you might know, we are using (and developing) HSLayers for your mapping purposes. It is OpenLayers- and ExtJS-based JavaScript Mapping framework. The support for TIME in WMS arrived just few days ago and can be viewed in WMS Time Supprot in HSLayers video.

We are now facing the other problem. Customers and various project partners do want to display WCS and WFS services inside of the map. It does not make sense to try to convince them, that it does not make any sense – they don’t care. Basically, we have two possibilities there:

1. Try to write parser for WCS/WFS (which is partly done in OpenLayers). And hope to display the data somehow.
2. Translate the services to WMS and use current infrastructure

Even OpenLayers is capable to display WFS data, it is not usable for larger amount of data. Not speaking about WCS, where you can sometimes get just GeoTIFF and that’s all you have.

We decided to write something called OWSProxy. It parses WCS/WFS Capabilities response and builds temporal WMS on top of it. Advantage: we can use all we have got for the current WMS Client. It simply works nicely. I’m facing one issue now.

MapServer is not able to work as WCS client. No big problem -> we use GDAL, which works just great and in the trunk, there is support for temporal information inside WCS as well.

You can access various times using GDAL:

Python 2.7.1+ (r271:86832, Apr 11 2011, 18:13:53)
>>> from osgeo import gdal
>>> ds = gdal.Open("xml.wcs")
>>> ds.GetSubDatasets()[0]
('WCS_SDS:time="2011-06-15T21:00:00.000Z",/tmp/WCS-a7145b1a3d54e8df55f019a136f55f8408LK0Y/20110615T210000_dfm.wcs', 'Coverage 20110615T210000_dfm at time 2011-06-15T21:00:00.000Z')

We have now data source with time, which can be accessed from the command line as well

gdalinfo 'WCS_SDS:time="2011-06-15T21:00:00.000Z",/tmp/WCS-a7145b1a3d54e8df55f019a136f55f8408LK0Y/20110615T210000_dfm.wcs'

Driver: WCS/OGC Web Coverage Service
Files: none associated
Size is 1126, 341
Coordinate System is:
PROJCS["GGRS87 / Greek Grid",
    GEOGCS["GGRS87",
        DATUM["Greek_Geodetic_Reference_System_1987",
            SPHEROID["GRS 1980",6378137,298.257222101,
                AUTHORITY["EPSG","7019"]],
            TOWGS84[-199.87,74.79,246.62,0,0,0,0],
            AUTHORITY["EPSG","6121"]],
        PRIMEM["Greenwich",0,
            AUTHORITY["EPSG","8901"]],
        UNIT["degree",0.0174532925199433,
            AUTHORITY["EPSG","9122"]],
        AUTHORITY["EPSG","4121"]],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",24],
    PARAMETER["scale_factor",0.9996],
    PARAMETER["false_easting",500000],
    PARAMETER["false_northing",0],
    AUTHORITY["EPSG","2100"],
    AXIS["Easting",EAST],
    AXIS["Northing",NORTH]]
Origin = (606368.000000000000000,4790992.000000000000000)
Pixel Size = (64.000000000000000,-64.000000000000000)
Metadata:
  TIME_POSITION=2011-06-15T21:00:00.000Z
Corner Coordinates:
Upper Left  (  606368.000, 4790992.000) ( 25d18'38.23"E, 43d15'51.24"N)
Lower Left  (  606368.000, 4769168.000) ( 25d18'23.13"E, 43d 4' 3.95"N)
Upper Right (  678432.000, 4790992.000) ( 26d11'52.97"E, 43d15' 2.23"N)
Lower Right (  678432.000, 4769168.000) ( 26d11'27.66"E, 43d 3'15.27"N)
Center      (  642400.000, 4780080.000) ( 25d45' 5.75"E, 43d 9'36.26"N)
Band 1 Block=1126x341 Type=Float64, ColorInterp=Undefined
  Overviews: 563x17

NOW, I would like propagate this GDAL interface to MapServer. Should be pretty easy, you just need to create the TileIndex file (ESRI Shapefile), add time attribute the it, insert various times and locations …. ?

Unfortunately, MapServer seems not, that it would be able to access GDAL subdataset files,

 OGRFeature(20110308T220000_tem.wcs.tindex):120
  location (String) = WCS_SDS:time="2011-03-13T22:00:00.000Z",/tmp/WCS-a7145b1a3d54e8df55f019a136f55f84iYEWBn/20110308T220000_tem.wcs
  time (String) = 2011-03-13T22:00:00.000Z
  POLYGON ((409900 -11700,12900 -11700,12900 0,409900 0,409900 -11700))

does not work.

Well, I’m stuck at this point. How to access GDAL subdataset from MapServer? Anybody has idea? Wan’s to share?

For the mapping part, HSLayers (derivate of OpenLayers) is used, which development was speeded up during last months. However, we still have to do lots of work in it’s development.

The metadata part uses (beside ExtJS and OpenLayers on the client-side) MIcKA metadata catalogue server developed by HS-RS.

So, let there be INSPIRE in Czech.

Several unit tests suits are out there, you can see a nice list on JavaScript Assertation unit framework, which was both – easy to be installed and easy-to-be used, and JavaScript-only (nor server-side needed). OpenLayers is using test anotherway suit, but after that, Fireunit caught my eye.

If you have Firebug installed (which is assumed), just install other plugin – Fireunit. The project seems to be pretty new, but yet usable. You can follow some examples, which can be found – it is as easy as possible.

This will give you unit tests, integrated to the browser – no server-side installation, works everywhere any time, no configuration – just works out of the box. Too nice to be truth, but yet seems to be, by now.

PDF can be downloaded from http://gama.fsv.cvut.cz/data/geoinformatics/2009/geoinformatics-fce-ctu-2009-04.pdf

Content:

1. Bartoň R.: Custom OpenStreetMap Rendering – OpenTrackMap Experinence
2. Richta T., Hrubý M.: Dynamic object-oriented geospatial modeling
3. Charvát K.: Future of Open Source systems
4. Loewe P.: On scripting GRASS GIS: Building location-independent command line tools
5. Vohnout P., Cepický J.: OpenStreetMap over WMS
6. Růžička J.: Web Service Based on GeoTools in The Atlas of Fire Protection

Several steps have been provided, to get it working. And the main one is, that PyWPS runs with Jython as interpreter. My feeling is, that is is not Python anymore, but Java with Pythonish syntax. Anyway, it looks like little magic to me, but seems to be working. Documentation will follow soon.