CoordinateSharp changelog

Changelog History

Page 2

• v2.5.2.1 Changes

  May 05, 2020

  • ➕ Adds standard Parse() method to both Coordinate and CoordinatePart. This method works just like a standard C# Parse call and will throw exceptions upon failure. It is still recommend that you use TryParse() unless you can ensure coordinate string formatting is correct or you desire to handle your own exceptions.

    //Will parse successfullyCoordinate c = Coordinate.Parse("45N 43.456, 64E 25.694");

    //Will throw a format exception as Latitude has exceeded boundsCoordinate c = Coordinate.Parse("205N 43.456, 64E 25.694");

  • Adds last and next , sun/moon rise and set static methods. As CoordinateSharp operates on a "per day" basis you may not always have a celestial rise or set on a given day (especially during the spring months when working in UTC time). These new method will ensure a DateTime is always returned.

    DateTime d = new DateTime(2019, 2, 6);//Returns 2/7/2019 12:08:33 AM (the next day) as no moon set occurs on the date specified.var val = Celestial.Get_Next_MoonSet(40.0352, -74.5844, d);

• v2.5.1.1 Changes

  March 31, 2020

  ➕ Adds new application wide global settings specification. This feature should only be set once during application start up to change the library's default behaviors. These defaults may be overridden just like before in the Coordinate objects properties and constructors.

  0️⃣ Example: How to change the application wide default EagerLoad settings for Coordinate objects

  //Eagerload UTM/MGRS only by defaultGlobalSettings.Default\_EagerLoad = new EagerLoad(EagerLoadType.UTM\_MGRS);
  

  ➕ Adds a geo-fence drawer to assist with shape drawing. This will allow users to specify a starting point with a heading. Users may then "draw" points using specified distances and bearing changes.

  Example: How to draw a square starting from a Coordinate

  //Create a starting point with eager loading off to maximize performance.Coordinate c = new Coordinate(35.68919, 51.38897, new EagerLoad(false)); //Create the drawer with the Coordinate as a starting point and an initial heading of 0 degrees.//Earth shape is specified as ellipsoid to increase accuracy.GeoFence.Drawer gd = new GeoFence.Drawer(c, Shape.Ellipsoid, 0);//Draw the first 5km line using the initial heading specified (0 degrees change in heading)gd.Draw(new Distance(5), 0);//Draw the next 2 lines by turning 90 degrees at each new point.gd.Draw(new Distance(5), 90);gd.Draw(new Distance(5), 90);//Draw a line to the starting point to close the shape. //Turning 90 degrees may not end at the exact starting point due to bearing shift.gd.Close();//Iterate the created points in the shape//There will be five points. 1 starting, 3 middle and 1 end which is this same as the start point//since we closed the shapeforeach (var coord in gd.Points) { Console.WriteLine(coord); }
  

  

• v2.4.3.1 Changes

  March 01, 2020

  Adds Eager Loading Options to Parsers

  //Create EagerLoad object with multiple flagsEagerLoad el = new EagerLoad(EagerLoadType.ECEF);//Parse string to coordinate with eager loading settings specified.Coordinate coord;Coordinate.TryParse("45.34, 65.47", el, out coord);
  

  ➕ Adds UTM/MGRS Gris Zone Over-Projection Option

  //Create a coordinate that projects to UTM Grid Zone 31Coordinate coord = new Coordinate(51.5074,1); //Display normal projected UTMConsole.WriteLine(coord.UTM); //31U 361203mE 5708148mN//Lock coordinate conversions to Grid Zone 30 (over-project);coord.Lock\_UTM\_MGRS\_Zone(30);//Display over-projected UTMConsole.WriteLine(coord.UTM); //30U 777555mE 5713840mN //Approximately 1 meter of precision lost with a 1° (111 km / 69 miles) over-projection.
  

  🛠 XML Fixes

• v2.4.2.1 Changes

  February 02, 2020

  • ➕ Adds .NET Standard 2.1 for .NET Core 3.0 support.
  • ⚡️ Updates Nuget package icon to new Nuget pack standard.

• v2.4.1.1 Changes

  January 02, 2020

  • ➕ Adds Universal Polar Stereographic (UPS) to UTM system to allow polar region use.
  • ➕ Adds MGRS Polar to MGRS system to allow polar region use.
  • 🗄 Deprecates WithinCoordinateSystemBounds properties for UTM/MGRS systems. This change is possibly breaking for users who rely on this property to determine UTM/MGRS boundaries.

  ⏱ There will no longer be boundaries when operating in the UTM and MGRS systems. A new property named SystemType has been added to both the UniversalTransverseMercator and MilitaryGridReferenceSystem classes. SystemType may be checked to determine if polar regions have been entered (previously WithinCoordinateSystemBounds). Because both systems no longer have limitation, WithinCoordinateSystemBounds will always return true until its scheduled removal.

  Example:

  //POLAR REGION COORDINATECoordinate c = new Coordinate(-85,10);Console.WriteLine(c.UTM.SystemType); //UPS;Console.WriteLine(c.MGRS.SystemType); //MGRS\_Polar;Console.WriteLine(c.UTM); //B 2096454mE 2547018mNConsole.WriteLine(c.MGRS); //B AT 96454 47018
  

  US ARMY TEC-SR-7 1996 was referenced for UPS/MGRS POLAR conversions. The formulas have been discovered to suffer accuracy loss during convert backs (UPS/MGRS POLAR to GEODETIC LAT/LONG). This accuracy loss ranges from 0-33 meters below the 88th parallel and up to 2.2 kilometers between the 88th parallel and the poles. Ensure this precision meets your requirements before using.

  🚀 Formulas will be improved upon in future releases.

• v2.3.1.1 Changes

  November 05, 2019

  • Coordinates may now operate in local / UTC offset time.
  • 🐎 Greatly improves local time conversion performance. Benchmarks now match UTC calculation benchmarks.
  • Simplifies local time conversion calls.
  • 🗄 Deprecates legacy local time calls.
  • ⬇️ Reduces GeoDate property change overhead.
  • Minor EagerLoad_Extensions improvements.
  • 📜 Parser improvements. Geodetic coordinates will now successfully parse if latitudes are before longitudes in string. UTM single strings will now parse.
  • Developer Guide, Celestial section changes to match new and improved methods.
  • 🆓 License modification to allow for free commercial use license issuance for certain use cases.
  • 📦 Split license packed with Nuget package.
  • ✂ Removes .pdb files from pack.

  Example of Coordinate local time operation.

  //EST Date 21-MAR-2019 @ 07:00 AMDateTime d = new DateTime(2017,3,21,7,0,0);Coordinate c = new Coordinate(40.57682, -70.75678, d);//Coordinate still assumes the date is UTC, so we must specify the local offset hours.c.Offset = -4; //EST is UTC -4 hoursc.CelestialInfo.SunRise.ToString(); //Outputs 3/21/2017 06:45:00 AM
  

• v2.2.2.1 Changes

  October 09, 2019

  ➕ Adds eager loading extensions to allow for finer performance tweaks. For example if you only need solar times, you may eager load solar calculations only. This will reduce benchmarks greatly.

  Example:

  //Create EagerLoad object with Celestial turned onEagerLoad el = new EagerLoad(EagerLoadType.Celestial);//Set EagerLoad Extensions to load Sun Cycle only.el.Extensions = new EagerLoad\_Extensions(EagerLoad\_ExtensionsType.Solar\_Cycle);//Create Coordinate with eager load settingsCoordinate coord = new Coordinate(45.34, 65.47, DateTime.Now, el);
  

  🐎 More information may be found on the websites performance page.

• v2.2.1.1 Changes

  August 30, 2019

  -UTM available precision increased.
  📜 -MGRS parser bug fix (some formats not parsing correctly).
  📜 -MGRS parser improvement (single string format will now parse).

  🚀 This version was quickly released after v2.1.1.1 due to planned improvements and the need to quickly fix a bug in the parser. The bug has been present in the parser since it's adoption. Tests have been adjusted to catch similar bugs in the future.

  This version received a minor increment due to the UTM precision change possibly effecting string outputs of UTM Easting and Northing values. Users will be required to determine their own rounding if plugging into those value directly and if desired.

• v2.1.1.1 Changes

  August 15, 2019

  🔦 Exposes more efficient UTM/MGRS to Signed Degree Methods

• « First
• ‹ Prev
• 1
• 2