09-05-2017 04:56 PM - edited 09-07-2017 06:11 PM
Our client is using WebMap 2016Ep02 and they publish WFS services in EPSG2193. The services are consumed fine in my client's customers. However, when we consume they in Geospatial, these services are not displaying properly. The WFS features are fliped and X and Y value in Geosportal is swapped.
WMPS shows feature correctly and Portal Y and X shows correct value
With WFS, the feature is shown in wrong place (portal X, Y values are swapped) and WFS features are fliped
We did have some work-around from analyst to fix the problem but it requires a combination of modifying the service source web.config (use GlobalCRSStore) and portal web.config (use quirkMode). We have no issue with updating portal web.config but we should not modify the client service web.config, because they have being tested and used by their customers.
Appreciate all suggestions and ideas on this problem
Solved! Go to Solution.
09-06-2017 02:53 AM
It looks as though EPSG:2193 is defined as a Northing/Easting CRS and that seems to be reflected in CRSConfig. The problem is that the WFS doesn't use this XML file, but instead operates on CSF files, which also need to be referenced properly in its web.config.
My guess is that Portal is working correctly and according to specs here, while the WFS is not. I'm wondering why you needed to modify the CRSConfig xml file and a quirk mode enabling isn't sufficient...
09-06-2017 02:13 PM
Thank you for looking at this issue. Would you mind sharing us some ideas or tips, please?
09-07-2017 04:49 PM
Hi hbm & team,
Here is the detail of my investigation. The WFS source is publised in GeoMedia with workspace content showing with the csf below.
Get feature from this WFS still shows coordinate values with X & Y order. There is no further change in the service's web.config
I create three Portal instance. One is out of the box, one has WFS quirkmode configured with incorrectlySwappedCoordinates mode and one has expectsIncorrectlySwappedCoordinates mode.
In all three portal instances, the WFS is grey out (The data is not available in the current view); however, if I use "Right-Click -> Fit layer" option, then it shows the current correct bounding box, but the wfs still grey out.
In the first portal (out of the box, no quirk applied), if I go to the wrong location which has X & Y values swapped, the WFS is shown and flipped.
However, the other portal instances (quirkmode applied), the locaiton above doesn't have the WFS shown.
Hopefully, it will make the issue clearer
09-07-2017 06:28 PM
Hi hbm & team,
Some update on testing WMS service, the capabilities show the valid correct bounding box. We use the csf above and we make no change to the service's web.config
However, when consuming in Geospatial Portal, it is shown in the wrong location that has X & Y values swapped. Moreover, we can't pan or zoom in or out correctly.
We also tried to apply quirk for WMS services, but none of them are working.
09-07-2017 05:36 AM
There is no quirk in Portal which would allow you to use a WMS with wrong axis order understanding. However, switching over to WMS 1.1.1 instead of using 1.3.0 should do the trick. There is a difference between those two versions of the OGC specification in the handling of axis orders, with the 1.1.1 always using Easting/Northing order regardless of the CRS definition.
Now for the WFS. I see that you edited the CSF file but this is not enough. The WFS needs to be specifically told to use it through appropriate web.config settings. Regretfully, this is a manual process described in part here: GeoMedia WebMap Administrator Guide/Configuring WFS. First you reference the CSF in the GlobalCRSStore and then reference that in the WFSBasicOriginatingPipe's CRSStore section.
The last part is actually analogous for the WMS, to have it properly detect that the CRS should be using a different axis order than is hardcoded for specific CRSes.
09-07-2017 01:38 PM
I had exactly the same problem setting up a WFS. To overcome it I did the following:
<!-- <Id> - represents identifier of coordinating system.
- value - [mandatory] the alias name (identifier) of coordinating system (i.e its urn)
- primaryId - [optional] the attribute that indicates if element is primary id or not; Default value is false;
<!-- <Id value="EPSG:4326" primaryId="true" /> -->
<Id value="EPSG:2193" primaryId="true" />
<!-- <Id value="urngc:def:crs:EPSG:6.3:4326" /> -->
<Id value="urngc:def:crs:EPSG:6.3:2193" />
and uncomment the following:
<CRSStore storeName="globalStore" />
Essentially, it is exacty the same as getting a WMS with swapped coordinates to work.
09-07-2017 02:23 PM
Hi Liz & team,
Thanks Liz for the update. We avoid changing the WFS service web.config, so Shaun shows me that we can apply the quirk mode below in the portal instead:
<serviceQuirk serviceType="WFS" urlPattern="WaterCourse"> <incorrectlySwappedCoordinates> <add key="EPSG:2193" value="true" /> </incorrectlySwappedCoordinates> <expectsIncorrectlySwappedCoordinates> <add key="EPSG:2193" value="true" /> </expectsIncorrectlySwappedCoordinates> </serviceQuirk>
However, my testing shows that this work-around still can't be applied to WMS.
09-18-2017 10:27 PM
Here is some updates. For WMTS we apply the quirk as follows:
For WMS, thanks hbm for pointing out that only version 1.1.1 works. However, the WMS capabilities shows version 1.3.0 by default and portal does not have an option to choose version when consuming a wms service. So, we work around this by excluding the version 1.3.0 to indirectly force portal to consume wms with version1.1.1
So finally we have a work around for consume EPSG2193 WFS/WMS/WMTS services without modifying the service configuration.
Thank you for all the suggestions, ideas and input.