The first version of the geo-URI specification is now available as an Internet Draft on the IETF web site (announcement). An Internet Draft is the first step towards publication of a specification as an RFC.
The draft specifies syntax, format and semantics of the “geo” URI - it also requests registration of the respective Uniform Resource Identifier scheme (”geo:”) from IANA.
The draft will be presented during the session of the GEOPRIV (”geographic location and privacy“) working group on the 68th IETF meeting, taking place March 18-23, 2007 in Prague. The GEOPRIV session is currently scheduled for Tuesday, March 20, 0900 - 1130. Audio streaming will be available from here.
Comments and feedback on the Internet Draft is appreciated.
On the whole I like this draft and look forward to widespread use of a single way to represent a position as a text string.
Measuring altitude is tough both because of the lack of accuracy in todays GPS and differing ideas of what one should be measuring. Instead of saying altitude above general MSL you should specify height above the WGS 84 EGM96 Geoid.
On the other hand, as Laurence Penney points out at http://lists.eogeo.org/pipermail/georss/2005-November/000225.html, many geo tags will have wild and unknown errors because of user error and differences between tools. Date and “user-agent” would be useful optional meta-data.
In practice for many URIs height relative to the earth’s surface may be even more useful. For example, is a shop in a subway or on the ground floor? I’m not proposing that you include surface relative height, but it sucks that a person standing at the base of building with a geoURI of unknown origin and a modern GPS doesn’t have a good way to determine where the URI points. I guess the best solution is to pull out a map to find the altitude of the ground and hope the geoURI creator did the same thing.
Typo? “mean seal level” -> “mean sea level”
Spelling and wording suggestion: “five decimal rougly correlate to about one meter” -> “0.00001 degrees is roughly one meter”
“Remove abundant” -> “Remove redundant”
I don’t like the idea of using scale, height and width to specify a bounding box as common extension of a geoURI. The obvious criticism is that it depends on pixel size. You could fix pixel size to the smallest detail a human can normally see on a printed map, say 0.5mm. More fundamentally I’d like a geoURI to locate a rough area rather than a point. A radius in m can give the mapping service a hint of what scale map to return and helps a geoURI for a telephone look different from a geoURI for a country.
Tom,
thanks for the detailed comment, you made some excellent points!
We found the dilemma of how to indicate elevation information is what is technically correct and what is the common understanding of elevation.
E.g. a tourist (non-geodesy person) wants to provide a geouri for Badwater Basin:
geo:36.230833,-116.769167, but which elevation value would it be?
Please consider the document as a first draft, aimed to roughly give an idea about what geouri is about and what applications could be possible. There is still some work to do…
Thanks again!
I proposed a similar thing but using a crazy packed representation of latitude and longitude a couple of years ago:
http://lists.burri.to/pipermail/geowanking/2005-February/001399.html
Your idea is better for its simplicity. Oh, and the fact that you’ve actually done something about it
Excellent work, thanks.