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.
I really like your proposal for the geo-uri and am already working on adding it to an application. After reading the specification, I have some questions:
Say I want to add an application-specific property to a geo-uri, say an ID of an item that only makes sense for the application, but leave the remainder of the geo-uri useable to other applications. As far as I understand the specification, you have to register other parameters. Would it be possible to use domain-name-based parameter names? Like org.example.itemid, this way we could avoid collisions without having to register every parameter.
I think there are two extra parameters that would be useful: Time and direction.
I read somewhere in this blog that you have reasons against adding “Time”, because URIs should be independent of time. IMHO, for geo-uris, however, exactly the opposite is the case: If you find a geo link to some place, knowing an associated time would allow a mapping application to show you a map of the place at the time the link was created, or warn you if the area has changed substantially in between. Think of history books, which might want to point you to middle-age London.
This would also be useful for another application which could also benefit from direction: astronomy. Imagine taking a picture with a camera which includes a compass, and then later copying the link to that location into your astronomy-software and looking at the stars you just photographed. 3-d views of cities are also becoming common (think google streetview), therefore when you provide someone with a link to the location of your house, a direction helps him to look in the right direction.
Thanks for your work,
Michael
I forgot: Astronomy would also benefit from a “tilt” angle in addition to direction.
Michael
I follow your website for quite a long time and will need tell that your content articles usually prove to be of a high value and high quality for readers.