Research e-Labs

hCard Microformat Creator for New Zealand [updated 15 July 2008]

May 23rd, 2008 by Matthew Ross

The hCard microformat is an open format for representing people, companies, organizations, and places with machine-readable semantic HTML. We have published a tool (beta) for generating hCard code for a typical New Zealand address and testing the mapping of that address with Google maps.

New Zealand addresses do not follow the US model of street / city / state. The typical New Zealand format is street / suburb / city or for rural addresses street / RD number / mail location.

This typical New Zealand usage does not map well to hCard format (as well as vCard on which it is based). To reflect this New Zealand format, we recommend the following mapping of NZ address elements to hcard elements:

street: street-address

suburb or RD number: locality

city: region

The following is a example of hCard markup:

<div class=”vcard”>
 <div class=”fn org”>State Services Commission</div>
 <div class=”adr”>
 <div class=”street-address”>100 Molesworth</div>
 <div class=”locality”>Thorndon</div>
 <span class=”region”>Wellington</span> <span class=”postal-code”>6140</span>
 </div>
</div>

[updated 15 July 2008] The hCard creator will now optionally add latitude/longitude co-ordinates to the hCard

The hCard creator tool is at:

http://research.elabs.govt.nz/resources/hcard/hcard-creator-0.1.html

(28 votes, average: 2.86 out of 5)

This entry was posted on Friday, May 23rd, 2008 at 5:47 pm under Standards & Compliance. You can leave a response, or trackback from your site.

4 Responses to “hCard Microformat Creator for New Zealand [updated 15 July 2008]”

1. Cj Wells says:

   May 28th, 2008 at 10:34 am

   Oh awesome! This will be very useful

2. Pete says:

   May 29th, 2008 at 11:31 pm

   This is great guys. One idea I had (that you guys no doubt had to), was populating the Latitude/Longitude fields from the google map if they are empty. You could also use something like the geo codes for the postcode as well (mainly cause I still haven’t learnt mine :)).

3. Matt says:

   May 30th, 2008 at 12:30 pm

   Thanks Pete. There are a couple of issues…

   Having both address and geo lat/long within the hcard introduces data redundancy (and potential for mismatched address/geo). Also the co-ordinates that Google and other geo-coders return is an approximation: a street address doesn’t convert to a single lat/long.

   Our current plan is to make it clearer about when it is appropriate to use both address AND lat/long. We’re planning a tabbed interface where input is either address OR geo, with an explanation of how to combine them when appropriate.

   But, yes we’ll publish the lat/long as returned by the Google geo-coder when it processes an address.

   I’m interested in feedback on this.

4. Gavin Treadgold says:

   July 29th, 2008 at 3:13 pm

   I definitely think it is useful to have lat/long available - it is currently the only reasonable way to take an address, download it, and put it into a GPS for navigation. I guess it all comes down to the source of the coordinates, if they are +/-5m or less, then they are fine for navigation, however if they are geocoded, they are only as good as the source dataset, and geocoding doesn’t always work well with vanity addresses (e.g. popular address differs from geocoding dataset address location). Perhaps geo needs a source tag or similar that identifies the accuracy based upon the source for the coords.

   But adr only means that it pretty much rules out downloading for GPS navigation/bookmarking.