[georss] place names

[Carl Reed OGC Account]

Rather than re-invent the wheel, perhaps we should look to what either the 
IETF or OASIS have done. The IETF folks spent a year agreeing on a simple 
way to express place names (civic location). The IETF work is grounded in 
what is required for location and emergency services. The OASIS work is 
captured in their Xal spec and theoretically works for any region/country of 
the world.

Just a thought. I can dig out the actual references if anyone is interested.

Cheers

Carl

----- Original Message ----- 
From: "Raj Singh" <raj at rajsingh.org>
To: "Allan Doyle" <adoyle at eogeo.org>; <georss at lists.eogeo.org>
Sent: Thursday, June 08, 2006 2:50 PM
Subject: Re: [georss] place names


> (I changed the subject to better reflect this discussion)
>
> Marc, I agree that encoding place names would be a really useful next 
> step,
> and Allan's right that the issue can quickly blow up.
>
> But our job shouldn't be to solve the problem of accurate specification of 
> a
> place, but adopt a happy medium that works 90% of the time. This is key
> because the problem usually blows up on those outlier cases.
>
> So I'll lay out a proposal here.
>
> 1. adopt a few tags for place, like:
> <address> {street address. As Allan suggests, let developers parse it}
> <town>
> <region> {this equates to, e.g., state in the US or province in Canada)
> <country>
> <planet>
>
> 2. use full names for town, region and country referenced to some
> authoritative source
>
> 3. there is no 3!
>
> --Raj
>
>
> On 6/8/06 4:40 PM, "Allan Doyle" <adoyle at eogeo.org> wrote:
>
>>
>> On Jun 8, 2006, at 16:20, Marc wrote:
>>
>>> Hi Everybody
>>>
>>> I think we have to be careful not to head too much into the gisRSS
>>> direction. Boxes, polygons and other gis entities are certainly
>>> useful,
>>
>> I'm happy with the set of geometries we have now. I don't see a need
>> for more.
>>
>>> but the huge majority of rss producers and consumers are playing in a
>>> different field. News-feeds, housing-feeds, dating-feeds, job-feeds
>>> and
>>> so on, all of them would be much more useful if aggregators and
>>> rss-reader software could filter, aggregate and group feed items
>>> according to 'geo' entities like country code, state, city, etc.
>>> With a
>>> standard for these encodings geoRSS would make a big step forward, we
>>> just have to be careful not to make it too complicated for the
>>> mainstream user. RSS is after all a 'Really Simple Syndication'.
>>
>> I like the idea of named locations, which is really what an address
>> is. I agree that they are more socially useful than geometries.
>>
>> Trouble is, addresses are hugely complex. I could envision some kind
>> of address blob that can get dropped in. Maybe use the featuretypetag
>> and relationshiptag
>>
>> Let someone else deal with the address parsing. There are some good
>> geocoders out there. Maybe we can convince the geocoder crowd to make
>> nice REST interfaces that take an address and produce a GeoRSS geometry.
>>
>> There could be some set of Really Useful codes. Country code
>> (.de, .ca, etc), Post code (02139, C5G Y0P), Telephone prefix (1,
>> 44). The trouble with codes is that they can become out of date
>> quickly, too. What will the cc for Montenegro be? How long until IETF
>> or ISO catch up and add them? What happens when the code for Serbia-
>> Montenegro goes away?
>>
>> Maybe we just need some more blobish tags to stuff some interesting
>> things into.
>>
>> By way of contrast, look at the hoops the microformat people have to
>> jump through because XHTML doesn't have anything really suitable.
>>
>> Allan
>>
>>>
>>> Just my two cents.
>>>
>>> Marc
>>> _______________________________________________
>>> georss mailing list
>>> georss at lists.eogeo.org
>>> http://lists.eogeo.org/mailman/listinfo/georss
>>>
>
>
> _______________________________________________
> georss mailing list
> georss at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/georss