v.2.7.1.1

-Adds ability to get Equinox and Solstice information Issue 144.
-Adds Solstice/Equinox eager loading extension specification (to turn off new feature and save on performance).
-Fixes bug with "TryParse" throwing exceptions under certain conditions Issue 146.
-Fixes .NET Core 3.X specific round-tripping issue Issue 147.
-Fixes MGRS eager loading specification issues Issue 148 and Issue 150.

Solstice Example

Coordinate c = new Coordinate(45,112, new DateTime(2020,3,6));
Console.WriteLine(c.CelestialInfo.Solstices.Summer);//20-Jun-2020 21:44 (UTC)

v2.6.2.1

• Fixes Issue 142

v2.6.1.1

-Adds a strong named key to the assembly allowing for use of the assembly in strong named applications.

v2.5.2.1

• 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 successfully
Coordinate c = Coordinate.Parse("45N 43.456, 64E 25.694");

//Will throw a format exception as Latitude has exceeded bounds
Coordinate 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);

2.5.1.1

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

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

  //Eagerload UTM/MGRS only by default
  GlobalSettings.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 shape
  foreach (var coord in gd.Points)
  {
        Console.WriteLine(coord);
  }

  

v2.4.3.1

Adds Eager Loading Options to Parsers

//Create EagerLoad object with multiple flags
EagerLoad 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 31
Coordinate coord = new Coordinate(51.5074,1); 
//Display normal projected UTM
Console.WriteLine(coord.UTM); //31U 361203mE 5708148mN

//Lock coordinate conversions to Grid Zone 30 (over-project);
coord.Lock_UTM_MGRS_Zone(30);

//Display over-projected UTM
Console.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

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

v2.4.1.1

• 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 COORDINATE
Coordinate c = new Coordinate(-85,10);

Console.WriteLine(c.UTM.SystemType); //UPS;
Console.WriteLine(c.MGRS.SystemType); //MGRS_Polar;

Console.WriteLine(c.UTM); //B 2096454mE 2547018mN
Console.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

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 AM
DateTime 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 hours

c.CelestialInfo.SunRise.ToString(); //Outputs 3/21/2017 06:45:00 AM

v2.2.2.1

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 on
EagerLoad 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 settings
Coordinate coord = new Coordinate(45.34, 65.47, DateTime.Now, el);

More information may be found on the websites performance page.