MapInfo Pro

Hello,

I have been looking at using a WFS layer in MapInfo 17 from the following URL: 
http://services.thelist.tas.gov.au/arcgis/rest/services/Public/OpenDataWFS/MapServer

It appears that the coordinates are reversed in these layers.  After Googling a bit I came across the following article:
https://support.pitneybowes.com/VFP06_KnowledgeWithSidebarTroubleshoot?id=kA280000000CrX5CAK&popup=false&lang=en_US

The above article describes some ways to reverse the coordinates back in a WMS or WFS layer.

I implemented the 'Server Override' described in the article and checked with "TableInfo(MyWMSTable, TAB_INFO_OVERRIDE_COORDINATE_ORDER)", as described at the bottom of the article, that the coordinates were being reversed (or not).  However, no matter where I set the OverrideCoordinateOrder as true or false, the results were the same; the points showing up somewhere in Greenland, rather than Tasmania where expected.

I couldn't figure out how to implement the 'TableOverride' described in the article.

Does anyone have any suggestions as to:

• Firstly, why implementing the server override from the article did not work
• Secondly, how to implement the table override from the article in MapInfo 17
• Thirdly, if there is any other way to get around this problem

Thanks in advance,

------------------------------
Ben Kleywegt
INSIGHT GIS
------------------------------

That does look at bit weird.

I accessed the data using this WFS URL: 
https://services.thelist.tas.gov.au/arcgis/services/Public/OpenDataWFS/MapServer/WFSServer?service=WFS

And just like you, I noticed that the data is located in Greenland, and not in Tasmania.

I'm however not sure it's just the reversing of the coordinate order.
I used this statement to extract the bounds of the map with the data I downloaded (List Land Districts). I only took the first ten records not knowing how big the data set would be.

Print "X: " + FormatNumber$(MapperInfo(FrontWindow(), 5)) + " Y: " + FormatNumber$(MapperInfo(FrontWindow(), 6)) + " | X: " + FormatNumber$(MapperInfo(FrontWindow(), 7)) + " Y: " + FormatNumber$(MapperInfo(FrontWindow(), 8))

For the full extent of Tasmania it gives me these coordinates:
X: 4.023.045,50169 Y: -9.997.964,94315 | X: 4.604.455,233399 Y: -9.997.964,94315

For the extent of my WFS dataset, it returns these extents:
X: -380.441,366574 Y: 9.378.282,077805 | X: -229.091,805303 Y: 9.463.196,603699

If you look at the bounding box values in the Capabilities document, the coordinate order looks fine:



------------------------------
Peter Horsbøll Møller
Pitney Bowes
------------------------------

Original Message:
Sent: 09-20-2019 01:42
From: Ben Kleywegt
Subject: Resolve Coordinates swapping when opening a Web Map Service layer from a Third Party Web Map Service server

Hello,

I have been looking at using a WFS layer in MapInfo 17 from the following URL:
http://services.thelist.tas.gov.au/arcgis/rest/services/Public/OpenDataWFS/MapServer

It appears that the coordinates are reversed in these layers.  After Googling a bit I came across the following article:
https://support.pitneybowes.com/VFP06_KnowledgeWithSidebarTroubleshoot?id=kA280000000CrX5CAK&popup=false&lang=en_US

The above article describes some ways to reverse the coordinates back in a WMS or WFS layer.

I implemented the 'Server Override' described in the article and checked with "TableInfo(MyWMSTable, TAB_INFO_OVERRIDE_COORDINATE_ORDER)", as described at the bottom of the article, that the coordinates were being reversed (or not).  However, no matter where I set the OverrideCoordinateOrder as true or false, the results were the same; the points showing up somewhere in Greenland, rather than Tasmania where expected.

I couldn't figure out how to implement the 'TableOverride' described in the article.

Does anyone have any suggestions as to:

• Firstly, why implementing the server override from the article did not work
• Secondly, how to implement the table override from the article in MapInfo 17
• Thirdly, if there is any other way to get around this problem

Thanks in advance,

------------------------------
Ben Kleywegt
INSIGHT GIS
------------------------------

I took a look at the both the capabilities as Peter did and some of the actual XML returned by the server.  There is something odd here especially since this is from ArcGIS who I can say generally do these things correctly but there are settings to override that I am not familiar with.
The bounds as Peter said, in degrees, looks fine. Note that the boundaries in WGS84Bounding box are Longitude and then Latitude.
The actual data, is in Popular Mercator (EPSG:3857), which has data in meters.
If you look at the data XML files that Pro leaves in the %temp%/MIPRO/ (folder named by the instance), you can see that the data is in Greenland, Well certainly west of 0 and northern hemisphere.

<ggml:posList>-4839347.189599998 16019788.2943 -4839347.189999998 16008453.2546 -4824574.4771 16008453.2543 -4824574.4771 16019788.2948 -4839347.189599998 16019788.2943</gml:posList>
This is incorrect if the intention is Tasmania. 3857 data is always Longitude and then Latitude. It is not one of the "ambiguous" coordinate systems for which Mi Pro created, as other did, the idea of swapping coordinates on the fly.
3857 is quite new and the standard has always been the same. 
We can check whether the option of "swapping coordinates" works on this coordinate system. Probably it should say "swap coordinate where ambiguous" or something like that. 
There is an XML file in MI Pro to force swapping but I forget its name right now. I think it is CSsysInfo.xml and not sure it will solve this.
You could try it but there is something really wrong on the server end. The data being sent is, in fact, in Greenland.



------------------------------
Eric Blasenheim
Spectrum Spatial Technical Product Manager
Troy, NY
------------------------------

Original Message:
Sent: 09-20-2019 01:42
From: Ben Kleywegt
Subject: Resolve Coordinates swapping when opening a Web Map Service layer from a Third Party Web Map Service server

Hello,

I have been looking at using a WFS layer in MapInfo 17 from the following URL:
http://services.thelist.tas.gov.au/arcgis/rest/services/Public/OpenDataWFS/MapServer

It appears that the coordinates are reversed in these layers.  After Googling a bit I came across the following article:
https://support.pitneybowes.com/VFP06_KnowledgeWithSidebarTroubleshoot?id=kA280000000CrX5CAK&popup=false&lang=en_US

The above article describes some ways to reverse the coordinates back in a WMS or WFS layer.

I implemented the 'Server Override' described in the article and checked with "TableInfo(MyWMSTable, TAB_INFO_OVERRIDE_COORDINATE_ORDER)", as described at the bottom of the article, that the coordinates were being reversed (or not).  However, no matter where I set the OverrideCoordinateOrder as true or false, the results were the same; the points showing up somewhere in Greenland, rather than Tasmania where expected.

I couldn't figure out how to implement the 'TableOverride' described in the article.

Does anyone have any suggestions as to:

• Firstly, why implementing the server override from the article did not work
• Secondly, how to implement the table override from the article in MapInfo 17
• Thirdly, if there is any other way to get around this problem

Thanks in advance,

------------------------------
Ben Kleywegt
INSIGHT GIS
------------------------------

We contacted the WFS server maintainer, who told us the coordinate order changed between ArcGIS server versions.

Based on that, we changed the 'Version Negotiation' option in the WFS server details in MapInfo to 'Prefer Version 1.0'.  This fixed the problem for now.

Cheers!

------------------------------
Ben Kleywegt
INSIGHT GIS
------------------------------

Original Message:
Sent: 09-20-2019 01:42
From: Ben Kleywegt
Subject: Resolve Coordinates swapping when opening a Web Map Service layer from a Third Party Web Map Service server

Hello,

I have been looking at using a WFS layer in MapInfo 17 from the following URL:
http://services.thelist.tas.gov.au/arcgis/rest/services/Public/OpenDataWFS/MapServer

It appears that the coordinates are reversed in these layers.  After Googling a bit I came across the following article:
https://support.pitneybowes.com/VFP06_KnowledgeWithSidebarTroubleshoot?id=kA280000000CrX5CAK&popup=false&lang=en_US

The above article describes some ways to reverse the coordinates back in a WMS or WFS layer.

I implemented the 'Server Override' described in the article and checked with "TableInfo(MyWMSTable, TAB_INFO_OVERRIDE_COORDINATE_ORDER)", as described at the bottom of the article, that the coordinates were being reversed (or not).  However, no matter where I set the OverrideCoordinateOrder as true or false, the results were the same; the points showing up somewhere in Greenland, rather than Tasmania where expected.

I couldn't figure out how to implement the 'TableOverride' described in the article.

Does anyone have any suggestions as to:

• Firstly, why implementing the server override from the article did not work
• Secondly, how to implement the table override from the article in MapInfo 17
• Thirdly, if there is any other way to get around this problem

Thanks in advance,

------------------------------
Ben Kleywegt
INSIGHT GIS
------------------------------

Ben, 
As I said I do not have nor know the details of setting this up in ArcGIS. However, as the PB representative at OGC I am very well aware of the axis order issues and I know that ESRI is as well from those meetings.  
This topic is pretty crazy so hold your hats if you are a neophyte. You could never explain this to your neighbor (or neighbour)
GIS software has traditionally always worked in a X/Y space just like you had in geometry class.  Coordinates systems are varied but the "easting" was always first (X) and then the northing (y).  This was regardless of the coordinate system. So for systems in degrees we often said "Longitude, Latitude" instead of the other way around.
Unless you were programming or manipulating textual versions of spatial data, this made no difference to you as long as it worked. Who cares what order the coordinates are stored in a native tab or SHP file. Even in the spatial databases, the order was Longitude/Latitude for those systems and Easting/Northing otherwise.
In the user interface, you had to know and read the labels to see but otherwise you mostly did not care.
Around 20 years ago, the Location Based Services groups started forming and they generally dealt with just points and did Latitude/Longitude. I guess that sounded better.  This created a conflict at places like OGC. The OGC services such as WMS and WFS had always done X/Y but now newer LBS services were representing data the other way. 
It took a while for OGC to take this up and in the end they kind of punted towards "Do what the coordinate system authority says".  Since EPSG is the most used authority, the EPSG database has become the final answer.
For example, if you go to https://www.epsg-registry.org/ you can enter codes by number and get information including the correct order.
EPSG:4326  (Lat/long WGS84, the most used system on earth) says that  its order is Latitude and then Longitude.
EPSG:3857, the popular Mercator created by Google, is easting and then northing. 

When OGC made this decision it also said that earlier versions of the specification would not change behavior.  These rules only applied to versions after such as WFS 2.0 and WMS 3.0. Our server software, Spectrum Spatial and MapInfo Pro both comply with this by default.
In the case of WGS84 Lat/Long there was so much data out there and so much confusion that many software vendors offered the ability "to do it wrong" so the end user could get it right. Yes 2 wrongs do make a right.  Thus the "flip coordinates" options.  Also note that OGC created its own code, CRS:84 that is Longitude/Latitude because so many GIS software was baked into that way of doing things.

However, to my knowledge there has never been any confusion on Popular Mercator. It is a very new system and was created by OGC to handle the popularity of Google. Note that Google itself never deals with coordinates this way. Its interface is always Lat/Long WGS84 in that order. It converts to its internal system on the fly.
In the end I am saying that it is possible that ESRI software flips the coordinates of all systems when this option is set.  I have not heard of that.  I doubt whether we do but I can check.I would hope that the server could return data in the only standard way for this coordinate system and you would not be limited to using WFS 1.0 for which these rules do not apply.
Again, try explaining that to you neighbor!

------------------------------
Eric Blasenheim
Spectrum Spatial Technical Product Manager
Troy, NY
------------------------------

Original Message:
Sent: 09-22-2019 22:52
From: Ben Kleywegt
Subject: Resolve Coordinates swapping when opening a Web Map Service layer from a Third Party Web Map Service server

We contacted the WFS server maintainer, who told us the coordinate order changed between ArcGIS server versions.

Based on that, we changed the 'Version Negotiation' option in the WFS server details in MapInfo to 'Prefer Version 1.0'.  This fixed the problem for now.

Cheers!

------------------------------
Ben Kleywegt
INSIGHT GIS

Original Message:
Sent: 09-20-2019 01:42
From: Ben Kleywegt
Subject: Resolve Coordinates swapping when opening a Web Map Service layer from a Third Party Web Map Service server

Hello,

I have been looking at using a WFS layer in MapInfo 17 from the following URL:
http://services.thelist.tas.gov.au/arcgis/rest/services/Public/OpenDataWFS/MapServer

It appears that the coordinates are reversed in these layers.  After Googling a bit I came across the following article:
https://support.pitneybowes.com/VFP06_KnowledgeWithSidebarTroubleshoot?id=kA280000000CrX5CAK&popup=false&lang=en_US

The above article describes some ways to reverse the coordinates back in a WMS or WFS layer.

I implemented the 'Server Override' described in the article and checked with "TableInfo(MyWMSTable, TAB_INFO_OVERRIDE_COORDINATE_ORDER)", as described at the bottom of the article, that the coordinates were being reversed (or not).  However, no matter where I set the OverrideCoordinateOrder as true or false, the results were the same; the points showing up somewhere in Greenland, rather than Tasmania where expected.

I couldn't figure out how to implement the 'TableOverride' described in the article.

Does anyone have any suggestions as to:

• Firstly, why implementing the server override from the article did not work
• Secondly, how to implement the table override from the article in MapInfo 17
• Thirdly, if there is any other way to get around this problem

Thanks in advance,

------------------------------
Ben Kleywegt
INSIGHT GIS
------------------------------

Ben,

I just checked and there is a file in the MiPro install folder called CSYSINFO.XML and this file is deployed with what we think is the correct order. It is only applied for service versions where the order is an issue such as WFS 2.0.
If you absolutely need to, you can edit the file and restart MiPro.
It should say:
  <EPSG-3857 axis1="east" axis2="north" />
and if you swap those (axis1= "north"...) then your data should end up in Tasmania without any server changes. However, note that everyone using it will have to make the same change so it would be much better all around to get this done correctly on the server side. The site manager who claims they have this correct are in my opinion, just wrong.  ​

------------------------------
Eric Blasenheim
Spectrum Spatial Technical Product Manager
Troy, NY
------------------------------

Original Message:
Sent: 09-23-2019 10:01
From: Eric Blasenheim
Subject: Resolve Coordinates swapping when opening a Web Map Service layer from a Third Party Web Map Service server

Ben,
As I said I do not have nor know the details of setting this up in ArcGIS. However, as the PB representative at OGC I am very well aware of the axis order issues and I know that ESRI is as well from those meetings.
This topic is pretty crazy so hold your hats if you are a neophyte. You could never explain this to your neighbor (or neighbour)
GIS software has traditionally always worked in a X/Y space just like you had in geometry class.  Coordinates systems are varied but the "easting" was always first (X) and then the northing (y).  This was regardless of the coordinate system. So for systems in degrees we often said "Longitude, Latitude" instead of the other way around.
Unless you were programming or manipulating textual versions of spatial data, this made no difference to you as long as it worked. Who cares what order the coordinates are stored in a native tab or SHP file. Even in the spatial databases, the order was Longitude/Latitude for those systems and Easting/Northing otherwise.
In the user interface, you had to know and read the labels to see but otherwise you mostly did not care.
Around 20 years ago, the Location Based Services groups started forming and they generally dealt with just points and did Latitude/Longitude. I guess that sounded better.  This created a conflict at places like OGC. The OGC services such as WMS and WFS had always done X/Y but now newer LBS services were representing data the other way.
It took a while for OGC to take this up and in the end they kind of punted towards "Do what the coordinate system authority says".  Since EPSG is the most used authority, the EPSG database has become the final answer.
For example, if you go to https://www.epsg-registry.org/ you can enter codes by number and get information including the correct order.
EPSG:4326  (Lat/long WGS84, the most used system on earth) says that  its order is Latitude and then Longitude.
EPSG:3857, the popular Mercator created by Google, is easting and then northing.

When OGC made this decision it also said that earlier versions of the specification would not change behavior.  These rules only applied to versions after such as WFS 2.0 and WMS 3.0. Our server software, Spectrum Spatial and MapInfo Pro both comply with this by default.
In the case of WGS84 Lat/Long there was so much data out there and so much confusion that many software vendors offered the ability "to do it wrong" so the end user could get it right. Yes 2 wrongs do make a right.  Thus the "flip coordinates" options.  Also note that OGC created its own code, CRS:84 that is Longitude/Latitude because so many GIS software was baked into that way of doing things.

However, to my knowledge there has never been any confusion on Popular Mercator. It is a very new system and was created by OGC to handle the popularity of Google. Note that Google itself never deals with coordinates this way. Its interface is always Lat/Long WGS84 in that order. It converts to its internal system on the fly.
In the end I am saying that it is possible that ESRI software flips the coordinates of all systems when this option is set.  I have not heard of that.  I doubt whether we do but I can check.I would hope that the server could return data in the only standard way for this coordinate system and you would not be limited to using WFS 1.0 for which these rules do not apply.
Again, try explaining that to you neighbor!

------------------------------
Eric Blasenheim
Spectrum Spatial Technical Product Manager
Troy, NY

Original Message:
Sent: 09-22-2019 22:52
From: Ben Kleywegt
Subject: Resolve Coordinates swapping when opening a Web Map Service layer from a Third Party Web Map Service server

We contacted the WFS server maintainer, who told us the coordinate order changed between ArcGIS server versions.

Based on that, we changed the 'Version Negotiation' option in the WFS server details in MapInfo to 'Prefer Version 1.0'.  This fixed the problem for now.

Cheers!

------------------------------
Ben Kleywegt
INSIGHT GIS

Original Message:
Sent: 09-20-2019 01:42
From: Ben Kleywegt
Subject: Resolve Coordinates swapping when opening a Web Map Service layer from a Third Party Web Map Service server

Hello,

I have been looking at using a WFS layer in MapInfo 17 from the following URL:
http://services.thelist.tas.gov.au/arcgis/rest/services/Public/OpenDataWFS/MapServer

It appears that the coordinates are reversed in these layers.  After Googling a bit I came across the following article:
https://support.pitneybowes.com/VFP06_KnowledgeWithSidebarTroubleshoot?id=kA280000000CrX5CAK&popup=false&lang=en_US

The above article describes some ways to reverse the coordinates back in a WMS or WFS layer.

I implemented the 'Server Override' described in the article and checked with "TableInfo(MyWMSTable, TAB_INFO_OVERRIDE_COORDINATE_ORDER)", as described at the bottom of the article, that the coordinates were being reversed (or not).  However, no matter where I set the OverrideCoordinateOrder as true or false, the results were the same; the points showing up somewhere in Greenland, rather than Tasmania where expected.

I couldn't figure out how to implement the 'TableOverride' described in the article.

Does anyone have any suggestions as to:

• Firstly, why implementing the server override from the article did not work
• Secondly, how to implement the table override from the article in MapInfo 17
• Thirdly, if there is any other way to get around this problem

Thanks in advance,

------------------------------
Ben Kleywegt
INSIGHT GIS
------------------------------

Thanks for your replies Eric, they were very informative.

The WFS server maintainer has promised to look into the issue so I am hoping they will eventually fix it on their side.

------------------------------
Ben Kleywegt
INSIGHT GIS
------------------------------

Original Message:
Sent: 09-23-2019 11:38
From: Eric Blasenheim
Subject: Resolve Coordinates swapping when opening a Web Map Service layer from a Third Party Web Map Service server

Ben,

I just checked and there is a file in the MiPro install folder called CSYSINFO.XML and this file is deployed with what we think is the correct order. It is only applied for service versions where the order is an issue such as WFS 2.0.
If you absolutely need to, you can edit the file and restart MiPro.
It should say:
  <EPSG-3857 axis1="east" axis2="north" />
and if you swap those (axis1= "north"...) then your data should end up in Tasmania without any server changes. However, note that everyone using it will have to make the same change so it would be much better all around to get this done correctly on the server side. The site manager who claims they have this correct are in my opinion, just wrong.  ​

------------------------------
Eric Blasenheim
Spectrum Spatial Technical Product Manager
Troy, NY

Original Message:
Sent: 09-23-2019 10:01
From: Eric Blasenheim
Subject: Resolve Coordinates swapping when opening a Web Map Service layer from a Third Party Web Map Service server

Ben,
As I said I do not have nor know the details of setting this up in ArcGIS. However, as the PB representative at OGC I am very well aware of the axis order issues and I know that ESRI is as well from those meetings.
This topic is pretty crazy so hold your hats if you are a neophyte. You could never explain this to your neighbor (or neighbour)
GIS software has traditionally always worked in a X/Y space just like you had in geometry class.  Coordinates systems are varied but the "easting" was always first (X) and then the northing (y).  This was regardless of the coordinate system. So for systems in degrees we often said "Longitude, Latitude" instead of the other way around.
Unless you were programming or manipulating textual versions of spatial data, this made no difference to you as long as it worked. Who cares what order the coordinates are stored in a native tab or SHP file. Even in the spatial databases, the order was Longitude/Latitude for those systems and Easting/Northing otherwise.
In the user interface, you had to know and read the labels to see but otherwise you mostly did not care.
Around 20 years ago, the Location Based Services groups started forming and they generally dealt with just points and did Latitude/Longitude. I guess that sounded better.  This created a conflict at places like OGC. The OGC services such as WMS and WFS had always done X/Y but now newer LBS services were representing data the other way.
It took a while for OGC to take this up and in the end they kind of punted towards "Do what the coordinate system authority says".  Since EPSG is the most used authority, the EPSG database has become the final answer.
For example, if you go to https://www.epsg-registry.org/ you can enter codes by number and get information including the correct order.
EPSG:4326  (Lat/long WGS84, the most used system on earth) says that  its order is Latitude and then Longitude.
EPSG:3857, the popular Mercator created by Google, is easting and then northing.

When OGC made this decision it also said that earlier versions of the specification would not change behavior.  These rules only applied to versions after such as WFS 2.0 and WMS 3.0. Our server software, Spectrum Spatial and MapInfo Pro both comply with this by default.
In the case of WGS84 Lat/Long there was so much data out there and so much confusion that many software vendors offered the ability "to do it wrong" so the end user could get it right. Yes 2 wrongs do make a right.  Thus the "flip coordinates" options.  Also note that OGC created its own code, CRS:84 that is Longitude/Latitude because so many GIS software was baked into that way of doing things.

However, to my knowledge there has never been any confusion on Popular Mercator. It is a very new system and was created by OGC to handle the popularity of Google. Note that Google itself never deals with coordinates this way. Its interface is always Lat/Long WGS84 in that order. It converts to its internal system on the fly.
In the end I am saying that it is possible that ESRI software flips the coordinates of all systems when this option is set.  I have not heard of that.  I doubt whether we do but I can check.I would hope that the server could return data in the only standard way for this coordinate system and you would not be limited to using WFS 1.0 for which these rules do not apply.
Again, try explaining that to you neighbor!

------------------------------
Eric Blasenheim
Spectrum Spatial Technical Product Manager
Troy, NY

Original Message:
Sent: 09-22-2019 22:52
From: Ben Kleywegt
Subject: Resolve Coordinates swapping when opening a Web Map Service layer from a Third Party Web Map Service server

We contacted the WFS server maintainer, who told us the coordinate order changed between ArcGIS server versions.

Based on that, we changed the 'Version Negotiation' option in the WFS server details in MapInfo to 'Prefer Version 1.0'.  This fixed the problem for now.

Cheers!

------------------------------
Ben Kleywegt
INSIGHT GIS

Original Message:
Sent: 09-20-2019 01:42
From: Ben Kleywegt
Subject: Resolve Coordinates swapping when opening a Web Map Service layer from a Third Party Web Map Service server

Hello,

I have been looking at using a WFS layer in MapInfo 17 from the following URL:
http://services.thelist.tas.gov.au/arcgis/rest/services/Public/OpenDataWFS/MapServer

It appears that the coordinates are reversed in these layers.  After Googling a bit I came across the following article:
https://support.pitneybowes.com/VFP06_KnowledgeWithSidebarTroubleshoot?id=kA280000000CrX5CAK&popup=false&lang=en_US

The above article describes some ways to reverse the coordinates back in a WMS or WFS layer.

I implemented the 'Server Override' described in the article and checked with "TableInfo(MyWMSTable, TAB_INFO_OVERRIDE_COORDINATE_ORDER)", as described at the bottom of the article, that the coordinates were being reversed (or not).  However, no matter where I set the OverrideCoordinateOrder as true or false, the results were the same; the points showing up somewhere in Greenland, rather than Tasmania where expected.

I couldn't figure out how to implement the 'TableOverride' described in the article.

Does anyone have any suggestions as to:

• Firstly, why implementing the server override from the article did not work
• Secondly, how to implement the table override from the article in MapInfo 17
• Thirdly, if there is any other way to get around this problem

Thanks in advance,

------------------------------
Ben Kleywegt
INSIGHT GIS
------------------------------