WebGIS Discussions

[Bob]

Hi team,

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

Kind regards, 

[lukasz.baraniak]

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...

[Bob]

Hi hbm,

Thank you for looking at this issue. Would you mind sharing us some ideas or tips, please?

Kind regards,

[Bob]

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.

Summary:

• With the WFS published above, the out of the box portal can't show it correctly, it is shown in wrong location and flipped. The two portal with quirk applied prevent the WFS feature to be shown in the wrong location, but the WFS is still not shown in the location it is supposed to show.

Hopefully, it will make the issue clearer

Kind regards

[Bob]

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.

Kind regards

[lukasz.baraniak]

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.

[Lizzy]

Hello Bob,

I had exactly the same problem setting up a WFS.  To overcome it I did the following:

1. Set up the csf exactly as you have done.
2. Assuming the WFS is created via WebMap publisher, ensure the csf is attached to the workspace
3. Ensure the csf is copied to the \csf folder of both the WFS WebMap publisher folder and the WFS service instance.
4. Ensure the csf is the default csf for the WFS webmap publisher service source.
5. Modify the WFS service web.config as follows:

      <CRS csfFileName="epsg2193.csf">
        <!-- <Id> - represents identifier of coordinating system.
            Attributes supported:
              - 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" />
      </CRS>

and uncomment the following:

      <CRSStore storeName="globalStore" />

Essentially, it is exacty the same as getting a WMS with swapped coordinates to work.

Cheers,

Liz

[Bob]

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.

Kind regards, 

[Bob · Accepted solution]

Hi team,

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.

Kind regards,