From: Viechnicki, P. D. <Pet...@ng...> - 2007-09-05 16:23:29
|
Justin, Thanks for raising this issue. I would just add a recommendation that = you try to make sure your proposals are interoperable with geospatial = data exchange formats which already exist out there. Perhaps the best = one to start with would be the one defined by the United Nations Group = of Experts on Geographic Names (UNGEGN), which has a draft toponymic = data exchange format, which you can find at the end of this paper: http://unstats.un.org/unsd/geoinfo/9th-UNCSGN-Docs/E-CONF-98-CRP-60.pdf Best wishes, -Peter Viechnicki =20 -----Original Message----- From: spa...@li... = [mailto:spa...@li...] On Behalf Of = Justin Richer Sent: Thursday, August 30, 2007 2:32 PM To: spa...@li... Subject: [Spatialml-discussion] Format and syntax of geo-coordinates 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 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 the coordinates in the format latitude followed by longitude (in this case in decimal degrees), with southern latitudes and western longitudes being expressed by negative signs. A richer tag might 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 (=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=B0W. This gives us the following list of valid, parsable values for the = latLong field: 42=B0N 71=B0W 42.358 -71.060 42.358=B0 -71.060=B0 42.358=B0N 71.060=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 -------------------------------------------------------------------------= This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ = _______________________________________________ Spatialml-discussion mailing list Spa...@li... https://lists.sourceforge.net/lists/listinfo/spatialml-discussion |