Finish coordinate suite

[brandonjpierce]

1. Finish the coordinate parser regex and edge case detection

This is definitely the most complex part of the suite. The general ethos around the parsing is that we try and make our capture groups as deterministic as humanly possible. Less tricks in the regex the better for simplification sake. E.g. for a coordinate passed to us in DD form we will always capture the following groups, regardless if there is a value there or not:

[dir][sign][degrees][decimals][dir][sign]

With this, we can capture either lon or lat independently, or combined by simply concating the regex's. Additionally, we now have more deterministic inputs for our value normalization described further below.

The current Regex partials can be found here:

packages/geo/src/coordinates/regex.ts
packages/geo/src/coordinates/match.ts

We currently are testing against a number of variations for each coordinate format as seen here:

packages/geo/src/coordinates/__fixtures__/index.ts

This covers the bulk of the edge cases and or use cases that you would see in the wild. We will want to slightly adjust these fixtures potentially just so that the snapshot output is a tad more consistent and or our expect() calls can be simplified a bit or in a more generic way.

2. Finish the coordinate normalization

Given that we now have the input, either from a machine or a user, deterministic split into N number of capture groups, we can normalize this input into a common form. Notably, regardless of the input format, we want the normalized format to be a simple float value that can then be used as the input for external formatting outwards. E.g. N 87.2123 would become 87.2123 , 87.2123 S would become -87.2123 etc.

We have some initial work started for this for specifically the DD format capture groups here:

packages/geo/src/coordinates/normalize.ts

3. Create coordinate formatting

Given our normalized float value for both lon and lat we can take that and format it into the common standards of DD, DMS, DDM. We might be able to actually reuse the regex segments to assist with this but this area is largely tbd. Additionally, we will potentially need to support MGRS, CGRS, and other standard military coordinate formats.

4. Create coordinate component

[kalisjoshua]

... some interesting interplay with #24. @brandonjpierce

[kalisjoshua]

Thinking about edge cases:

1. User input: "22 33" - should we allow this as valid input and assume "22 / 33" and if LATLON "22 N / 33 E"?
2. User input: "11 22 33 66 55 44" - becomes "11 22 33 / 66 55 44" and if LAT LON "11 22 33 N / 66 55 44 E"?
3. User input "44 55" - is this valid for any system - Decimal Degrees, Degrees Decimal Minutes, or Degrees Minutes Seconds - if we allow omitted values to default to "0"?
   • DD = "44 / 55" and if LATLON "44 N / 55 E"
   • DDM = "44 0 / 55 0" and if LATLON "44 0 N / 55 0 E"
   • DMS = "44 0 0 / 55 0 0" and if LATLON "44 0 0 N / 55 0 0 E"
4. User input "N 1 2 3 4 5"
   • DD = invalid because too many numbers
   • DDM = invalid because too many number
   • DMS - invalid because too few numbers: options are "1 2 3 N / 4 5 0 E" or "1 2 N / 3 4 5 E"
5. User input "1 2 3 N 4 5"
   • DD = invalid
   • DDM = invalid
   • DMS = invalid: options are "1 2 3 N / 4 5 0 E" or "1 2 3 E / 4 5 0 N"
6. User input "1 N 1" - should we assume
   • "1 N / 1 E" - the coordinate it just not completely entered yet "1 N 1 E"
   • "1 E / 1 N" - there is a missing coordinate bearing indicator at the beginning "E 1 N 1"

There is a difference between the user having missed a keystroke and not being done entering a value. Either way, do we want to return a positive result when there is ambiguity in the input?