Switch over from GML 3.1 to GML 3.2

At the last GWIE meeting, we commited to switch from GML 3.1 encoding to GML 3.2. We also decided to keep SOS 1.0 interface because of the limited availability of SOS 2.0 software out there. It is possible in the SOS interface to keep both GML 3.1 and GML 3.2 and select which schema we want during the request (reponseFormat and resultModel parameters). What I suggest is, if possible, to keep supporting both. The default schemas will be GML 3.1 and as we change the tools, we can progressively move to GML 3.2.

Here's a list of short and long term impacts to adapt 3.1 tools to 3.2

Changes

Direct impacts to client application

  • Current tools on GIN (HTML GetFeatureInfo, Excel, Google Earth) must be modified
  • Tools from partners (34 North,Kister) must also be changed
  • GIN Download manager must be reviewed (although, we already initiated an architecture change to Download Manager)
  • Generic SOS client won't work because they expect GML 3.1 out of SOS 1.0 services.

Long term impacts

  • If we want to keep these service operational, we will have to eventually switch to SOS 2.0 services

EPSG 4326

The right way to encode EPSG 4326 is y,x but legacy systems still use x,y. It's a similar problem to schemas changes except that flipping the x and y axis does not trigger errors to the unsuspecting client application (unless it actually validates for values beyond -90 and +90 for the expected y axis) which means it's undetectable for North America up to western limit of Great Lakes.

I suggest we bundle that switch with GML 3.2. At least for GIN we will have a way to 1) advertise this change and 2) have a way to tell which is which. Therefore, our GWML GML 3.1 will remain x,y while WaterML 2.0 will be correct y,x. Considering that GWML won't be embedded in WaterML 2.0 anyway, we will have a nice "rule" to figure out the axis order (the namespace of GML).

Suggested action plan

This is a suggested plan to move from GML 3.1 to GML 3.2 without breaking the current GWIE. It essentially implies that both schemas will be available at all time and client application will have to explicitly request GML 3.2 (otherwise, they will get GML 3.1)

  • At Oct 5th meeting, prepare all GWIE developers (client and service) for the switch.
  • Circulate an instance document encoded in WaterML 2.0 (see attached) and have a quick agreement (for IE, shall we keep the current TimeSeries encoding ?)
  • Implement WaterML 2.0 GML 3.2 services over existing SOS 1.0 GML 3.1 quicly so client can test it.
    • default service will be GML 3.1 and use responseFormat = text/xml;subtype=om/1.0.0 and resultModel wml:WaterMonitoringObservation xmlns:wml="http://www.wron.net.au/waterml2"
    • WaterML 2.0 will be GML 3.2 use responseFormat = text/xml;subtype=om/2.0.0 and resultModel wml:WaterMonitoringObservation xmlns:wml="http://www.wron.net.au/waterml2"
    • Note that they both have the same namespaces. The service is expected to use responseFormat to figure the version of GML.
    • Also note that prefix can be something different, it's just a proxy for the namespace.
  • Implement x,y flip on EPSG 4326
  • Progressively alter the tool so they call the om/2.0.0 version
  • Declare victory - have a beer
  • swith default to GML 3.2 (if necessary)

-- EricBoisvert - 04 Oct 2010

Topic revision: r3 - 07 Oct 2010, EricBoisvert
This site is powered by FoswikiThe information you supply is used for OGC purposes only. We will never pass your contact details to any third party without your prior consent.
If you enter content here you are agreeing to the OGC privacy policy.

Copyright &© by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding OGC Public Wiki? Send feedback