[georss] Transport of Toponyms with GeoRSS

[Pat Cappelaere]

Carl,

Wow! Interesting.  I guess we are not pedaling fast enough!! :)

I understand the concept of an address ->xAl...

I was trying to query the community about the concept of regions/AOI to help
user subscriptions.  I was intrigued with the pubsub/USGS approach.  The
alternative would be to force the user in defining BBOX's and giving them
recognizable names (so that other people could understand the semantic
meaning of the subscription and subscribe to it)

Do you think this would be a good thing?
Pat.


> From: <creed at opengeospatial.org>
> Date: Mon, 28 Aug 2006 10:23:23 -0400 (EDT)
> To: Andrew Turner <georss at highearthorbit.com>
> Cc: <georss at lists.eogeo.org>
> Subject: Re: [georss] Transport of Toponyms with GeoRSS
> 
> Andrew -
> 
> Yes! This is what I was thinking but you expressed much better. FYI, Pat,
> OASIS also wants a GML Application Schema for xAL. Also, not sure if
> anyone has seen the following:
> 
> "August 1, 2006: Google Earth KML 2.0 uses OASIS CIQ xAL for representing
> and expressing addresses on Earth
> ".
> 
> And Marc, xAL/xNAL uses ISO 11180 as one of their foundation requirements
> documents. A bit more info on xNAL can be found on XML Coverpages. From
> this page:
> 
> The (OASIS) CIQ TC has spent close to two years in building xNAL that is
> application independent and truly global, and hence, can be readily
> applied to any name and address specific applications including Postal
> services and address validation. . . . Given that xNAL is designed to
> handle the address structures of all countries at an abstract or detailed
> level, it make it easier for applications to concentrate on building
> domain specific standards/applications around xNAL.
> 
> Cheers
> 
> Carl
> 
> 
>> On 8/27/06, Marc <marc at geonames.org> wrote:
>>>> If the georss group does decide to enable encoding of civil address
>>>> information, why re-invent the wheel?
>>> 
>>> I would not go as far and speak about 'invention' in the context of
>>> GeoRSS or RSS. All I am suggesting is using the country code invented by
>>> ISO, use it for the vehicle RSS and call this combination GeoRSS. (The
>>> same is true for ISO 3166-2, the postal code and similarly for the place
>>> name.)
>>> The really hard work, the invention and maintenance is done by ISO. They
>>> have invented the wheel. Using it in a xml schema is a piece of cake and
>>> I don't really care how this combination is called. I have therefore
>>> setup a draft for a "geonamesRSS" encoding :
>>> http://www.geonames.org/geonamesRSS.html
>>> 
>> 
>> Marc, aren't you in fact reinventing the wheel/overloading the domain
>> by adding YAN (Yet Another Namespace)?
>> 
>> You're right that making an XML schema can be easy. The problem is in
>> use and adoption. Adding another namespace works against that. What I
>> had suggested was leaving GeoRSS as is, and then bringing in something
>> else (existing, like xNAL) for address encoding. Other people have
>> already spent a lot of time thinking of the problems and a solution.
>> 
>> Just as an example:
>> <georss:point>45.256 -71.92</georss:point>
>> <xnl:AddressDetails>
>>  <xnl:Country>
>>   <xnl:CountryName>United States</CountryName>
>>   <xnl:Locality Type="City">
>>    <xnl:LocalityName>Seattle</LocalityName>
>>     <xnl:Thoroughfare>
>>      <xnl:ThoroughfareName>MainStreet</ThoroughfareName>
>>      <xnl:ThoroughfareNumber>16</ThoroughfareNumber>
>>     </xnl:Thoroughfare>
>>    </xnl:DependentLocality>
>>   </xnl:Locality>
>>  </xnl:Country>
>> </xnl:AddressDetails>
>> 
>> 
>> --
>> Andrew Turner
>> ajturner at highearthorbit.com        42.4266N x 83.4931W
>> http://highearthorbit.com              Northville, Michigan, USA
>> _______________________________________________
>> 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