Michael

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

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.

There a new standard in the work for a Uniform Resource Identifier for geographic locations named geoURI. The published their IETF Internet Draft. They even already released a Firefox extension which supports geoURIs. From their website: “A dedicated …

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!

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.