hCard multiple locations

I'm having an issue with an hcard that has multiple
locations.  Since
having multiple locations nested in the hcard would result
in only one
location being exported (others ignored/overwritten) I'm
trying to use
the include pattern to make each location its own hcard and
then
include the fn/org properties.  However, this seems to be
resulting in
a lot of extraneous wrapper elements (2 wrappers and an
'include' link
for *each* location). Suggestions?

Original markup:

<div class="vcard">
 <span>Copyright 2007 by <span class="fn
org">ORG</span></span>
 <span id="cities" class="adr">
   <abbr class="locality geo"
title="39.202130;-84.372071">Cincinnati</abb
r> |
   <abbr class="locality geo"
title="39.969873;-83.003934">Columbus</abbr&
gt; |
   <abbr class="locality geo"
title="35.230437;-80.838467">Charlotte</abbr
>
 </span>
</div>

Proposed revision:

<div>
 <span>Copyright 2007 by <span class="fn
org"
id="fn-org">ORG</span></span>
 <span id="cities">
   <span class="vcard"><span
class="adr">
     <a class="include"
href="#fn-org"></a>
     <abbr class="locality geo"
title="39.202130;-84.372071">Cincinnati</abb
r> |
   </span></span>
   <span class="vcard"><span
class="adr">
     <a class="include"
href="#fn-org"></a>
     <abbr class="locality geo"
title="39.969873;-83.003934">Columbus</abbr&
gt; |
   </span></span>
   <span class="vcard"><span
class="adr">
     <a class="include"
href="#fn-org"></a>
     <abbr class="locality geo"
title="35.230437;-80.838467">Charlotte</abbr
>
   </span></span>
 </span>
</div>
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

On Aug 24, 2007, at 9:38 AM, Jason Karns wrote:

> I'm having an issue with an hcard that has multiple
locations.  Since
> having multiple locations nested in the hcard would
result in only one
> location being exported (others ignored/overwritten)
I'm trying to use
> the include pattern to make each location its own hcard
and then
> include the fn/org properties.

Multiple ADR in a single hCard is valid (though multiple
LOCALITY in  
a single ADR is not) .  Have you tried it and found parsers
don't  
support it?  If so, it may be helpful to document which
parsers are  
ignoring multiple ADR.

> However, this seems to be resulting in
> a lot of extraneous wrapper elements (2 wrappers and an
'include' link
> for *each* location). Suggestions?

I have three:

1) Unless you're doing something special with that <span 

id="cities">, you don't need to use the include
pattern to put the FN  
in the first hCard; you could just put it in the actual
hCard.

2) It shouldn't hurt anything, but FN isn't really part of
ADR, so  
you should probably include it outside the ADR.

3) I think using <abbr> with your LOCALITY like that
will result in  
the city names being replaced by the GEO coordinates, just
as "Saint  
Louis" would be the LOCALITY value resulting from this:
<abbr  
class="locality" title="Saint
Louis">STL</abbr>.  If you want GEO to  
take the <abbr> title, but LOCALITY to keep the
element content  
value, you probably need even more wrapping, e.g.: <abbr
class="geo"  
title="35.230437;-80.838467"><span
class="locality">Charlotte</span></ 
abbr>.

It's unfortunate we need so much markup, but as long as
every bit of  
that additional markup is communicating something new,
that's as  
efficient as we can get.

Peace,
Scott

_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

On 8/24/07, Scott Reynen <scottrandomchaos.com> wrote:
> Multiple ADR in a single hCard is valid (though
multiple LOCALITY in
> a single ADR is not) .  Have you tried it and found
parsers don't
> support it?  If so, it may be helpful to document which
parsers are
> ignoring multiple ADR.
>

Sorry, I wasn't specific enough. I can have multiple ADR's
per hCard
but if I want to add geo information to the hCard they must
be
separate. Currently, hCard only supports 0 or 1 instances of
geo in an
hCard.  But now that I think about it, is this not an issue
with the
spec? If one can have multiple ADR's per hCard, shouldn't
multiple
GEO's be valid as well? I would expect that one should be
able to have
each ADR marked up with GEO coordinates as well.

Should this issue be added to the wiki?
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

On Aug 24, 2007, at 11:37 AM, Jason Karns wrote:

> Sorry, I wasn't specific enough. I can have multiple
ADR's per hCard
> but if I want to add geo information to the hCard they
must be
> separate. Currently, hCard only supports 0 or 1
instances of geo in an
> hCard.  But now that I think about it, is this not an
issue with the
> spec? If one can have multiple ADR's per hCard,
shouldn't multiple
> GEO's be valid as well? I would expect that one should
be able to have
> each ADR marked up with GEO coordinates as well.

I would too, but someone else may know of a good reason for
limiting  
it to one geo per hCard.

> Should this issue be added to the wiki?

There are at least two of us who don't understand the reason
for that  
limitation, so I think it's worth documenting in the wiki:

http://micr
oformats.org/wiki/hcard-issues

Peace,
Scott

_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

>> Sorry, I wasn't specific enough. I can have
multiple ADR's per hCard
>> but if I want to add geo information to the hCard
they must be
>> separate. Currently, hCard only supports 0 or 1
instances of geo in an
>> hCard.
>
> I would too, but someone else may know of a good reason
for limiting it
> to one geo per hCard.

The limitation comes from vcard, so hcard can't do much
about that.


Ted

_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

Conceptually vcard has multiple mailing addresses and one
current location:

Type name: GEO

   Type purpose: To specify information related to the
global
   positioning of the object the vCard represents.

   Type encoding: 8bit

   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). The longitude represents the location east and
west of the
   prime meridian as a positive or negative real number,
respectively.
   The latitude represents the location north and south of
the equator
   as a positive or negative real number, respectively. The
longitude
   and latitude values MUST be specified as decimal degrees
and should
   be specified to six decimal places. This will allow for
granularity
   within a meter of the geographical position. The text
components are
   separated by the SEMI-COLON character (ASCII decimal 59).
The simple
   formula for converting degrees-minutes-seconds into
decimal degrees
   is:

        decimal = degrees + minutes/60 + seconds/3600.

   Type example:

        GEO:37.386013;-122.082932


On Aug 24, 2007 4:05 PM, Edward O'Connor <hober0gmail.com> wrote:
> >> Sorry, I wasn't specific enough. I can have
multiple ADR's per hCard
> >> but if I want to add geo information to the
hCard they must be
> >> separate. Currently, hCard only supports 0 or
1 instances of geo in an
> >> hCard.
> >
> > I would too, but someone else may know of a good
reason for limiting it
> > to one geo per hCard.
>
> The limitation comes from vcard, so hcard can't do much
about that.
>
>
> Ted
>
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discussmicroformats.org
> http://microformats.org/mailman/listinfo/microforma
ts-discuss
>
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

In message 
<73766b160708241616j7a13fc7bnde57e741041e07b9mail.gmail.com>, Kevin 
Marks <kevinmarksgmail.com> writes

 >The longitude and latitude values MUST be specified as
decimal degrees
 >and should be specified to six decimal places.

That's interesting; it's clearly not suitable when giving
the 
coordinates for very large sites like a county or a park,
where 
precision to 1 metre is unwarranted; nor for giving very
precise 
coordinates for, say, the location of the camera taking a
picture of a 
single flower or insect. It's certainly not what's used in
practice.

Perhaps the Geo spec, and those of the other microformats
which use it, 
should allow fewer or more decimal places, and require
parsers to 
convert to six places when exporting as a vCard? Or perhaps
a revision 
to the vCard spec is required?

The spec does, though, emphasise the points I've always
made; the number 
of decimal place for latitude and longitude should be equal;
and 
trailing zeroes are significant.

-- 
Andy Mabbett
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

In message <CRL6tWGEZ$zGFwr9pigsonthewing.org.uk>,
Andy Mabbett 
<andypigsonthewing.org.uk> writes

>>The longitude and latitude values MUST be specified
as decimal degrees
>>and should be specified to six decimal places.
>
>That's interesting

It seems that draft-ietf-calsify-rfc2445bis-07.txt (i.e.,
the revision 
of iCalendar) proposes changing that MUST to a MAY.

<http://tools.ietf.org/wg/calsify/draft-i
etf-calsify-rfc2445bis/draft-ietf-calsify-rfc2445bis-07.chan
ges.html#GEOGRAPHIC_POSITION>

(aka <http://tinyurl.com/3xbj
4h> ) N.B. page size is 1.6 Mb!

-- 
Andy Mabbett
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss