Tronald/CoordinateSharp

Invalid lat/lon coordinates parsed as web mercator

lordti opened this issue · 4 comments

Describe the bug
In 2.14.2.1, when an invalid lat/lon (ie 90.1, 100) is entered as a string into Coordinate.TryParse, it parses it as web mercator. Previously TryParse would return false.

To Reproduce
bool retval = Coordinate.TryParse("100 100", out coordinate);

Expected behavior
Returns false on invalid lat/lon

Environment (please complete the following information):

  • .NET version: 4.8
  • CoordinateSharp version. 1.14.2.1
  • Application type: console
  • Is mutlithreading being used?No

Additional context
If EagerLoad with webMercator set to false is passed into the function, it will still parse as web mercator but will not return a web mercator result.

Thank you for reaching out.

The behavior described is intended (sort of), but not ideal with the addition of WebMercator in hindsight.

EagerLoad being false will still return a Coordinate even if it was parsed from a different format. The setting only impacts the EagerLoad state of the newly created Coordinate during property updates.

With the new WebMercator format being so similar however, I can see this creating annoying issues where people want to fail the parse vs returning a coordinate from a WebMercator formatted string. We have a beta going currently, but I will attempt to get a "restriction" feature in the next release that will allow you to specify which formats you want to parse in (allowing one to exclude WebMercator parses).

A work around to this problem you could use for now is to ignore parses / try parses that return in Parse_Format_Type.WebMercator.

Coordinate c = Coordinate.Parse("91 100");
if(c.Parse_Format == Parse_Format_Type.WebMercator)
{
        //ignore this parse
      c=null;
      return;
}

This problem certainly means that 2.14+ is more breaking of a change than previously anticipated, so my apologies.

I will work to get this condition specified in the documentation as well as push features for more parse control ASAP.

v2.15.2.1 will add the ability to restrict parse formats. A beta has been released to nuget.org if you would like to test it out.

You will now have a couple options.

OPTION 1

Set the default allowable parse formats at application start up. This will restrict what Coordinate.Parse can actually parse. Using a system parse call will override this however (ex WebMercator.Parse).

//Restrict parsable formats to Lat/Long, UTM and MGRS.
GlobalSettings.Default_Parsable_Formats = Allowed_Parse_Format.Lat_Long |  
     Allowed_Parse_Format.UTM | Allowed_Parse_Format.MGRS;

OPTION 2

Restrict parsable formats in the Coordinate.Parse() or Coordinate.TryParse() calls.

//Restrict parse format to Lat Long and MGRS only. This example will fail, even though it is a Web Mercator formatted string.
Allowed_Parse_Format formats = Allowed_Parse_Format.Lat_Long | Allowed_Parse_Format.MGRS;
Coordinate c = Coordinate.Parse("91 1", formats);

Coordinate.Parse() and Coordinate.TryParse() overloads can be reviewed in the documentation.

Leaving open until stable release of feature.

Awesome, thanks for the fast turn around on fixing this.

Stable release is up on nuget.org.

Thank you for bringing this to my attention.