[microformats-discuss] Re: [Geowanking] geo microformat
BOF session at Where 2.0
Bud Gibson
bud at thecommunityengine.com
Thu Jul 7 14:26:19 PDT 2005
> Ryan King wrote:
>
>
>> I don't think we need to divide this effort at this point, for
>> several reasons:
>> 1. Most people who are interested in one, will be interested in both
>> 2. They have implications for each other.
>> 3. Implementors will want to implement both of them.
>> 4. They're trying to solve the same problem.
>>
>
> I think you're right on all counts (though some implementors will
> be more interested in one aspect or the other). Depending on your
> point of view for your particular application of geolocation data,
> a street address might be considered metadata for lat/lon, or vice
> versa.
My main point in raising this was actually to try to push discussion
forward on this list, particularly in a direction that real people
could use. While I appreciate (and in some sense even like) the idea
of geographic precision and the data it would bring, I have to ask
myself the real question of how achievable it is. Also, you get an
issue of coverage.
Whether the effort needs to be split or not is a question I'll leave
to the group. Personally, I could see splitting it because I believe
the precise place location coordinates are most likely to come from
some source other than the users as is indicated by this tell tale
interchange between someone named "bewest" , Ryan, and myself on IRC
last night:
> budGibson
> Who's going to fill in all of this information? I imagine
> geowankers all out there with their GPSs, but what about the rest
> of us.
> bewest
> well it's not necessary for humans to fill out lat long computers
> can do it if it's a part of the standard
> kingryan
> right, bewest, but microformats are for humans first
> budGibson
> right on ryan baby
Ryan, let me hit a few of your points:
> This idea has come up several times before and was actually my
> original idea (in f2f conversations with Tantek and Kevin). It has
> also come up as a current practice on http://microformats.org/wiki/
> location-formats and come up during the BOF.
I remember raising it during the BOF as something akin to what I now
describe as bdgeotag (brain dead geotagging). There's a difference
between a URL representation of a place and a tag that represents a
place.
bdgeotag is meant to allow people latitude in describing place names
while tying them to having their tag actually resolve to something.
My point is that the tag only need to resolve to something via some
transformation. The ultra lazy method of achieving this
transformation is to say its gotta work in a geo search service.
Like any tagging operation, tags will have ambiguity. Let's say I
have two tags (assume URL encoding as required by reltag):
1. 701 Tappan Street, Ann Arbor, Michigan
2. University of Michigan Business School, Ann Arbor, Michigan
They appear different but are, in fact, equivalent. Well, this is
the standard tagging problem. Geniuses like Kevin Marks can resolve
it :).
The URL scheme is exactly like reltag. Maybe we add a class
attribute so you can indicate the search service where this works.
As for the tiger database, there is a map interface, and that map
interface is at:
http://brainoff.com/worldkit/mapproxy/
among other places.
To some extent, I am just shaking the tree here.
Bud
On Jul 7, 2005, at 15:35, Dougal Campbell wrote:
>
> I think the best format is going to allow for both types of
> addressing, but only require one. Just off the top of my head, a
> pseudo outline might look something like:
>
> <location>
> <geo>
> <lat />
> <lon />
> </geo>
> <address>
> ...something using hCard, maybe?...
> </address>
> </location>
>
> With a requirement that either geo or address (or both) must be
> present. Implementations that only utilize geo coordinates can
> simply ignore locations that don't include it (and vice versa). Or,
> they can do their own geocoding translations.
>
> --
> Dougal Campbell <dougal at gunters.org>
> http://dougal.gunters.org/
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss at microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://microformats.org/pipermail/microformats-discuss/attachments/20050707/d12abcf5/attachment.htm
More information about the microformats-discuss
mailing list