[georss] Lack of standardisation and forethought in Draft forEncoding Geographic Features in GeoRSS

[Carl Reed OGC Account]

Just to follow-up on Josh's email, the dialogue about using spaces vs commas 
for separating coordinates in XML encodings goes back years. For many of the 
reasons stated in Marc's and Josh's email, various organizations in 
geospatial standards community (ISO and the OGC) decided to use the space as 
the delimiter. The working group in the IETF that deals with location has 
also gone with the use of space for separating coordinates and I have a 
proposal before OASIS for a GML OASIS profile that hopefully will be used in 
any OASIS standard that requires location elements. Again, space delimited. 
I would guess that the use of a space to separate coordinates is quickly 
becoming international best practice. Now, if we could get Google to use 
space delimited coordinates in KML .  . . :-)

WRT addresses, in the OGC, the organizations focused on location services 
are discussing enhancing the address abstract data type so that it works 
anywhere in the world. As they wish to keep this abstract data type and 
resulting schemas as simple as possible, we may be able gain additional 
knowledge in terms of an address scheme that is both simple and 
international and useable in GeoRSS.

Regards

Carl

----- Original Message ----- 
From: "Josh at oklieb" <josh at oklieb.net>
To: <georss at lists.eogeo.org>
Sent: Monday, June 19, 2006 6:18 AM
Subject: Re: [georss] Lack of standardisation and forethought in Draft 
forEncoding Geographic Features in GeoRSS


> Andy,
>
> The GeoRSS spec and schema is at http://www.georss.org. There you
> will see that the space-separated coordinates are the recommended
> usage in all of GeoRSS, following that in GML, but other separators
> should be acceptable to a GeoRSS parser.
>
> We are now discussing how and whether to include placenames and
> addresses of various types in the specification. There is distinctly
> less available standardization in this area, so we have to be careful
> to include what can be widely used and not try to implement
> everything imaginable. Please feel free to contribute to this
> discussion, particularly with any existing address encodings which
> are pretty simple but might satisfy your hotel room use case.
>
> Cheers,
>
> Josh Lieberman
>
>
> On Jun 19, 2006, at 4:16 AM, Andy Mabbett wrote:
>
>>
>>
>>
>> Hi,
>>
>> My first post to this list ;-)
>>
>> If I use geo-metadata in my web pages, I have to use two formats:
>>
>>          <meta name="ICBM" content="52.6866, -2.1937">
>>
>> (with a comma separating the latitude and longitude)
>>
>>          <meta name="geo.position" content="52.6866; -2.1937">
>>
>> (with a semi-colon separating the latitude and longitude)
>>
>> and now, I see, that the "Draft for Encoding Geographic Features in
>> GeoRSS":
>>
>>          http://georss.geonames.org/georss-draft.html
>>
>> proposes using a space as a separator:
>>
>>          <georss:point>45.256 -71.92</georss:point>
>>
>> This makes my head hurt!
>>
>>
>> Also, I see that the draft says of the IETF encoding:
>>
>>          Too complex for our needs (we don't need room numbers ...)
>>
>> but suppose someone has an RSS feed for a list of, say, events at a
>> conference, including the room number of each...
>>
>> -- 
>> Andy Mabbett
>>                  Say "NO!" to compulsory ID Cards:  <http://
>> www.no2id.net/>
>>
>>                  Free Our Data:  <http://www.freeourdata.org.uk>
>> _______________________________________________
>> 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