> Andrew,
>
> I recommend that the META tag information you suggest in
> draft-daviel-html-geo-tag-00.txt include a sphere radius around the
> designed point to indicate the size of the volume being refered to
> and, in general, be made compatible with the LOC RR as defined in RFC
> 1876.
Thank you for your comments.
The geo.position tag is referring to a document content, and as such is a
different object than the LOC RR. I chose float values in degrees (as did
the V-card spec. authors) following extensive discussion last year with
people in Dublin Core & geographic communities - the DD MM SS notation is
potentially ambiguous if mis-typed. Decimal degrees long/lat feeds right
into many coordinate conversion programs.
Re. extent (sphere) - I was considering some specification of extent or
accuracy in a future revision, depending on the demand. As written, there
is some support for implicit accuracy based on places of decimal, but I
wanted to keep the tag as simple as possible.
I am not so sure that a sphere is such a useful concept, anyway. For many
resources, a rectangular or polygonal area is more appropriate, as a
definition of coverage of something like a school catchment area or
political region. As a measure of accuracy, although (I hope) most people
are capable of looking up a lat/long in a gazetteer or reading a GPS set,
properly defining accuracy is I suspect beyond them, in terms of defining
a surface inside which there is a 99% chance of finding the point, or
whatever. A geotag-enabled search engine would typically assume a certain
inaccuracy in any case, returning a result for the closest resource to a
query point, or a list of resources inside a query region, rather than
a list of resources whose accuracy sphere included the query point.
BTW, I have created a mailing list for discussion; see
http://geotags.com/archive/
regards
Andrew Daviel
http://vancouver-webpages.com/andrew
Deniable unless digitally signed.