[uf-discuss] proposed geo syntax addition (affects hCard) Re: [microformats-discuss] adr and geo microformats finally written up

[Tantek Ç elik]

On 9/23/05 10:00 AM, "Tantek Çelik" <tantek at cs.stanford.edu> wrote:

> On 9/23/05 2:01 AM, "Kevin Marks" <kmarks at technorati.com> wrote:
> 
>> 
>> On Sep 22, 2005, at 6:56 PM, Tantek Çelik wrote:
>> 
>>> In the "I should have written this up a couple of months ago"
>>> department, I
>>> give you the ridiculously simple, and 100% reused from previous work,
>>> adr
>>> and geo microformats, to specifically provide a simple solution to the
>>> problems raised and discussed in location-formats.
>>> 
>>>  http://microformats.org/wiki/geo
>> 
>> I think that fails the humans-first, machines second test very
>> significantly,
> 
> While I agree that describing an address or naming a location is far more
> human-friendly (and actually published today), we agreed that some folks do
> like to publish lat long (e.g. use of GeoURL), and publishing it visibly
> rather than invisibly is an improvement.
> 
> However, even visible lat long numbers are less "verifiable" by humans than
> even ISO8601 dates, so certainly we can come up with an alternate
> representation, like perhaps an <object> that shows that point on a map,
> with the marked up coordinates inside as fallbacks.

Following up on this, I'm finding more examples of where there is a human
viewable/clickable presentation of a point on a map, and the desire to
include the machine readable geo information with the same element, e.g.
something like:

<abbr class="geo" title="machine-readable-geo-info">
 human readable/clickable point on a map
</abbr>

But to do this we must specify a syntax for putting both the latitude and
longitude into the title attribute as the machine-readable-geo-info.

Fortunately, there already is a syntax for that, in vCard RFC2426 3.4.2:

   Type value: A single structured value consisting of two float values
   separated by the SEMI-COLON character (ASCII decimal 59).

   Type special notes: This type specifies information related to the
   global position of the object associated with the vCard. The value
   specifies latitude and longitude, in that order (i.e., "LAT LON"
   ordering).

...

   Type example:

        GEO:37.386013;-122.082932

Thus:

<abbr class="geo" title="37.386013;-122.082932">
 Mountain View, CA
</abbr>

or even with a map image (or map URL from a mapping service):

<abbr class="geo" title="37.386013;-122.082932">
 <img src="map.png" alt="Mountain View, CA" />
</abbr>


I think this is pretty much a no-brainer, because the rules for parsing
"geo" are simply altered to:


=== latitude longitude shorthand ===

If a "geo" property lacks explicit "latitude" and "longitude" subproperties,
then the "geo" property is treated like any other string property  (e.g.
following rules for parsing <abbr title>, <img alt> etc.), where that string
value has the same literal syntax as specified in RFC 2426 section 3.4.2:
single structured value consisting of two float values separated by the
SEMI-COLON character (ASCII decimal 59), specifying latitude and longitude,
in that order.


In addition, people may publish Google Maps links like this:

<a href="http://maps.google.com/maps?q=37.386013+-122.082932">this spot</a>

(N.B. I tried and failed to get Yahoo Maps and local to do something
intelligent with both "37.386013;-122.082932" and "37.386013 -122.082932").

Is it worth permitting this to be a geo as well?

I'm raising this to make sure it is considered.

However, my first guess is NO for two reasons.

1. No such examples in the wild have been documented or seen as of yet (I
certainly haven't seen any).

2. It would involve additional parsing requirements which are almost
certainly going to be site/domain specific, and encoding a particular site's
query parameter syntax into a format seems like a bad idea (against
principle of decentralization).

This could be mitigated if mapping services would simply accept the literal
vCard GEO syntax "37.386013;-122.082932", e.g.
http://maps.google.com/maps?q=37.386013;-122.082932 (which currently doesn't
work) then we could make a simple rule such as parse the href for a geo
value at the end of the href, delimited before the value by a "=" (or
perhaps "/" for services that use friendlier URLs).


I have added these to hcard-brainstorming page so that we capture them.

http://microformats.org/wiki/hcard-brainstorming#geo_improvements



Thoughts?

Thanks,

Tantek