From: Justin R. <jr...@mi...> - 2007-09-11 14:44:38
|
> > 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 =20 > > 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. > > > > 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 >=20 > Looks good to me. This scheme doesn't match any standards I've seen, =20 > but it seems like your purpose here is just to define something =20 > that's unambiguous and parsable. I've never seen colons used to =20 > separate D:M:S, but I like it, it's entirely analogous to time notation. I've seen it used at least once before, for exactly the reason that it's analogous to time and it makes no ambiguity about decimal numbers vs. unit demarcations. > Degree symbols (=C2=B0) are superfluous since coordinates are already =20 > defined in terms of degrees. I agree that it's superfluous, but some gazeteering systems may insert that symbol into their output strings (we have one here that does). By allowing it as an optional character in a well-defined location we give a bit more flexibility without sacrificing the simple parsable nature of the string value. -- Justin |