[georss] Transport of Toponyms with GeoRSS

[creed at opengeospatial.org]

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
>