[Geowanking] Location encodings, URL schemes

Bill Kearney wkearney99 at hotmail.com
Fri Feb 18 07:08:02 PST 2005

> >     The location is <a href="geo:astbfqklzp">here</a>
> >
> > Clicking on a link would take you to a map but it'd be /your/ choice
> > of map rather than the author of the original page's choice of
> > map. You could, for example, set things up so that clicking on a geo:
> > URL fired up your route planning software and started a new route with
> > your home as the start point and the location described by the link as
> > the destination.
> >
> > I'm sure somebody must have discussed this before. Or maybe it's just
> > a crap idea :)
> Interesting... would there be some sort of a default behavior? Seems
> like big infoportals like google and mapquest would be *very*
> interested in somthing like this.

Only if it pointed toward their own services.  Being able to take one set of
search results and pop over to some other service is doesn't seem like
something they'd be interested in supported.  Whether or not it'd be good
for the user or not.  That and a link to a point is worthless if there is
other data that would likewise need to be present.  "Need" being highly
dependent on whose side of the situation you're considering.  For the
service there are doubtless other data they'd want on that map (presumably
driven by advertising revenue...)

What might be more useful would be extending the href tag with markup.

<a href="/html/link/to/something" geo:point="some;geo;data;">here</a>

This would allow for anything client-side that was aware of the namespace
and attributes to pay attention to it without distrupting things for tools
that don't.  Ihe case of route planning software, for example, it would have
the ability to perhaps intercept the right-click context menu when geo
markup was present.  Or perform page-level scanning for a toolbar, sidebar
or other action.

Besides "whatevever//:" are protocol prefixes, not metadata.

-Bill Kearney

More information about the Geowanking mailing list