Not, says Geo-Web’s Ron Lake.
I agree with him to a point. I think location references should surround the referring text, not an entire item/post, as that would turn the post into too blunt a geographic instrument. There is no reason to assume that only one location will ever be referenced by an item — a listing of the top five restaurants in Stockholm, for example, would be given little extra value if the accompanying geo-reference was for the location of Stockholm’s town hall.
I don’t particularly like the idea of forcing location information to reside elsewhere, however. While that is obviously a good idea if the geographic reference you are making is a no-fly zone, a hiking route, or a particular vineyard’s boundaries (all containing a lot of structured data), it becomes a real burden to first create a separate object off-site if all you want to do is the equivalent of sticking a pin on a map. In such instances, it has to be easy and instant.
So I propose (and if this has already been done elsewhere, forgive me) the following when it comes to simple geographic referencing:
<a href=”https://www.ogleearth.com” gref=”17.995,59.3019″>Ogle Earth HQ</a>
<a href=”http://124.12.91.02″ gref=”75 backvagen, 12647, Stockholm, Sweden”>Ogle Earth HQ</a>
<a gref=”17.045,59.201″>A nice meadow for a picnic</a>
( and of course <a href=”http://mail.google.com”>Gmail</a>)
<a /> tags, then, should be able to contain href and/or gref attributes. The reason this is a good idea is that both a link to a web/IP address and a link to a coordinate/postal address are, well, links, although to completely separate magisteria. There is never any overlap between the set of internet coordinates and the set of Earth coordinates, although there are many cases in which an object will benefit from having links to both.
How would Ron be able to incorporate complex geographic objects into such a setup? Well, the gref attribute could also take http://-style internet addresses, in which case the browser would expect a file containing KML, GML or somesuch:
<a gref=”https://www.ogleearth.com/somefile.kml”>A nice meadow for a picnic</a>
Why use gref instead of href in that case? Because with href we’d be downloading a file, any file. With gref, we are specifically referencing a geographic description of the anchored text. Here’s how I’d use href with that address:
<a href=”https://www.ogleearth.com/somefile.kml”>somefile.kml</a>
Finally (and thanks for making it this far) if geographic browsers are going to be the navigation tool of choice for online surfing, shopping and socializing within five years (as I believe they will), then these next-generation browsers need to have their own separate way of depicting where you’ve navigated. This proposed setup would work wonderfully for split-screen browsers, where a 3D Earth and HTML renderer appear side by side. Clicking on a link containing both gref and href attributes would result in both the 3D Earth and HTML browser navigating to a new spot — on Earth and on the internet. (Clicking on a link with just a gref or a href would leave the other browser’s window untouched.)
Finer grained geotagging
“I would like to argue now that RSS, ATOM, and even web pages SHOULD NOT encode location information at all – the possible exception being the encoding of observations. Otherwise the locations should be done ONLY by reference. Such a mechanism is simple,
Coordinates are handy and usable references. A reference to a coordinate (or other geospatial types) is a reference to a reference.
Such an indirection has some nice properties. But who is maintaining such a geospatial dataset and who wants to understand and pay for any additional indirection?
So, I agree with you and don’t see the benefit of the idea. It rather puzzles me that a GIS specialist has such ideas; it smells a little bit like a propagation of GML and WFS.