MapInfo Pro

 View Only

Longitude/Latitude (WGS 84) naming convention ambiguity

  • 1.  Longitude/Latitude (WGS 84) naming convention ambiguity

    Posted 07-20-2023 07:11
    Edited by Ryan Cook 07-20-2023 11:09

    Dear Precisely,

    The manner in which the latest release catalogs projections in the UI exasperates an ambiguity in naming convention. 

    In the previous release MapInfo 16, users selected projection via a UI that first selected from the "Category" level, then a "Category Member". This meant when searching for and assigning "Longitude/Latitude (WGS 84)", one always hit upon the 'correct' "EPSG 4326" projection and never revealed the fact that a second "Longitude/Latitude (WGS 84)" actually exists, unless you were digging knowingly into the category of "Turkish Coordinate Systems With Datum Conversion From ED50 to WGS84". That this projection is called purely "Longitude/Latitude (WGS 84)" with no other reference to Turkish datum conversions, is obviously problematic but likely never cropped up. 

    In the latest release, the UI for choosing projections has changed to a single window containing screeds and screeds of projections that no user in their right mind will sit and scroll through to find their requirement, especially when a "Search" box is provided above it - one enters Long/lat or WGS 84 and the results provide multiple options, the two 'exact' matches providing no indication of what Category they come from. Mistakenly choosing one over the other can have severe consequences, especially if you are using the projection to update coordinate fields - the object locations would appear correct in a MapInfo mapper, but should the user export the table to CSV for sharing with other software, everything will be shifted. 

    This issue is made even harder to detect by the fact that just about every facet of MapInfo that displays the projection name, displays both the Turkish datum conversion "Longitude/Latitude (WGS 84)" and the standard "Longitude/Latitude (WGS 84) [EPSG 4326]" in exactly the same way: "Longitude/Latitude (WGS 84)".

    • The mapper projection displayed in the footer: Longitude/Latitude (WGS 84) - could mean either. 
    • The projection information in Table Structure: Longitude/Latitude (WGS 84) - could mean either.
    • The projection information in Coordinate Extractor's dialog: Longitude/Latitude (WGS 84) - could mean either.
    • The call out bubble in the Save Cope As dialogue box: Longitude/Latitude (WGS 84) - could mean either.

    This would be comical if it wasn't for the fact that this has caused a great deal of problems for us. How a projection can be named "Longitude/Latitude (WGS 84)" that is entirely specific to a datum conversion in Turkey, while MapInfo continues to refuse to provide the full name of projections to include the EPSG suffix anywhere but the projection UI is staggering.

    Further, what exactly is the purpose of "Table Projection" anyway? We have session projection default. We have mapper projections. We have projections in which we plot objects, we have projections we use to extract coordinates to table fields. Why on earth do we need "Table Projections" also? If I create a table of points using British National Grid coordinates, it doesn't matter what projection the table is in. The table projection is just telling MapInfo what language to code the objects locations with, but surely if only MapInfo reads that, it could be in any projection - it might as well be in MapInfo's own custom one. It just further increases the confusion and room for error that surrounds coordinate systems. Throw in the fact that the Aerial photographs and Precisely raster maps change the mapper projection when you add them and you have quite a fight on your hands training anyone new to the world of GIS!



    ------------------------------
    Ryan Cook
    ORH LTD
    ------------------------------