[georss] Why this syntax?

[Raj Singh]

I think few people can claim to answer this question thoroughly--geographic
encoding formats have been debated for years--I can give some of the reasons
for the GML-style space-separated syntax.

First of all, the space is the delimiter because the comma was problematic
because in many countries commas are used the way the US uses decimal point.

But your main question was why a text delimiter instead of tags. In my
understanding, two issues were key. First, back when this all started (and
even today to some extent), XML parsers weren't assumed to be present, so
many developers expected to parse this stuff as text. In that situation the
tags are less useful.

Second--and I think by far the most significant--is that the syntax came out
of the GIS community, where even in the 1990s gigabyte datasets where common
and line and polygon datasets were just as common as points. Imagine how
much bigger your XML file would be if you encoded every vertex of a line as
a point with tags around each number.

So basically the answer is that you're right when looking at a single point
in a single coordinate reference system, but as soon as you do more
complicated things you run into a brick wall.

--
Raj

On 5/8/06 6:49 PM, "Danny Ayers" <danny.ayers at gmail.com> wrote:

> Sorry if I'm missing something in the docs, but I can't really see any
> reason for opting for:
> 
>   <gml:Point>
>       <gml:pos>45.256 -71.92</gml:pos>
>    </gml:Point>
> 
> ...syntax, when the
> 
>   <geo:Point>
>     <geo:lat>45.256</geo:lat>
>     <geo:long>-71.92</geo:long>
>   </geo:Point>
> 
> ...syntax is not only already "out there", but easier to parse using
> XML tools (and no harder to create). With "valueA valueB valueC..."
> it's necessary to micro-parse and determine what parameter each value
> corresponds to, an unnecessary processing step.
> 
> Ok, I believe the space separated approach is that taken by GML, but
> as you are talking about this vocabulary being deployed in RSS and
> Atom, new ground, surely the options are still open.
> 
> To put it another way, why not:
> 
> <georss:geo>point 45.256 -71.92</georss:geo>
> 
> which also happens to be entirely extensible, e.g.:
> 
> <georss:geo>polygon 45.256 -110.45 46.46 -109.48 43.84 -109.86 45.8
> -109.2</georss:geo>
> 
> One immediate reason for using XML at a more granular level is for
> ease of use with RDF vocabularies (e.g. RSS 1.0). If the components
> are separated, it would be possible to apply a SPARQL query to an RDF
> model directly like this:
> 
> SELECT  ?blog ?latitude
> WHERE   {
>     ?blog geo:lat ?latitude .
>     ?blog geo:lat ?longitude .
>     FILTER (?latitude > 50 && ?longitude < -60) .
> }
> 
> With the space-separated data, in the RSS 1.0 case you have the
> slightly  bizarre situation where an otherwise directly
> interpretable/queryable document would have to be transformed or have
> some other kind of custom processing before anything useful can be
> done with it.
> 
> Cheers,
> Danny.
> 
> 
> --
> 
> http://dannyayers.com
> _______________________________________________
> georss mailing list
> georss at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/georss