[Spatialml-discussion] Format and syntax of geo-coordinates

[Justin R. <jr...@mi...>]

The SpatialML DTD defines the syntax of the overall XML language, but it
doesn't yet define the syntax of a few of the fields that would benefit
from being machine-readable. The first of these is the "latLong" field
of the PLACE tag. The guidelines currently state:

  When gazref is available, the coordinate from the gazetteer
  may be copied here.

This effectively makes this field capable of holding any valid XML
string. Or more specifically:

  Any string, including strings with or without decimals that can be=20
  parsed into GML coordinates along with appropriate coordinate systems,
  including military coordinate systems.

On the other hand, we have these GML guidelines:

   <gml:Point gml:name=3D"Macy's" gml:id=3D"3"=20
        srsName=3D"urn:ogc:def:crs:EPSG:6.6:4326">
     <gml:coordinates>40.45 - 73.59</gml:coordinates>
   </gml:Point>

  This GML tag for Macy's says that the reference coordinate system is
  CRS 4326 (which happens to be the geodetic model WGS-84). It presents=20
  the coordinates in the format latitude followed by longitude (in this=20
  case in decimal degrees), with southern latitudes and western=20
  longitudes being expressed by negative signs. A richer tag might=20
  provide height and internal structure for Macy's as well.=20

Which adds in the complexity of specifying a geodetic model and doesn't
clear up the format of the actual coordinates much (at least not in this
portion of the guidelines).

I propose that we incorporate suggestions of several easily-parsable,
mutually-disambiguatable syntactical formats for this field. While a
user of the language COULD use a coordinate format different from this,
they SHOULD use one of these given formats to ensure interoperability.
So this becomes a strong suggestion of use, with solid guidelines and
examples.

The rules for lat/lon values:

  1) Latitude value given before longitude value, separated by any
amount of whitespace. Both values are always given together. [should
there be a wildcard for a single "unknown" value?]

  2) North/South latitude and East/West longitude designated by one of
the following:
     a) Negative sign (-) prepended to southern and western values,
optional positive sign (+) prepended to northern and eastern values,
with no intervening whitespace.
     b) Cardinal direction letter abbreviation (N, S, E, or W) appended
to each numeric value, with no intervening whitespace.

  3) Whole integers are considered to be degrees.

  4) Degrees may be in decimal form if there are neither minutes nor
seconds designated, with the whole and fractional parts of the degrees
separated by a single decimal (.) period.

  5) Degrees and minutes separated by a single colon (:) with no
intervening whitespace. Minutes may be in decimal form if there are no
seconds designated, with whole and fractional parts separted by a single
decimal (.) period.

  6) Minute and second separated by a single colon (:) with no
intervening whitespace. Seconds may be in decimal form, with whole and
fractional parts separted by a single decimal (.) period.

  7) A degree character (=C2=B0) may optionally follow all degree-based
designations such as whole degrees and decimal degrees, potentially
coming in between the numeric value and any cardinal direction, as in
71=C2=B0W.

This gives us the following list of valid, parsable values for the
latLong field:

42=C2=B0N 71=C2=B0W
42.358 -71.060
42.358=C2=B0 -71.060=C2=B0
42.358=C2=B0N 71.060=C2=B0W
42.358N 71.060W
42:35.8N 71:6.13W
42:35:8N 71:6:7W
42:35:8.453 -71:6:4.343


... among a few other possible combinations of the different parts. In
effect, this gives us Degree:Minute:DecimalSecond, Degree:DecimalMinute,
and DecimalDegree notational schemes with some bit of flexibility (but
unambiguity) in handling the directional requirements.

We could conceivably also add in guidelines for other coordinate
systems, such as MGRS and UTM. As long as the syntax could easily be
distinguished from what's allowable by the above rules, the various
systems could coexist in the same text field.

Comments are welcome!

 -- Justin