[georss] Quick Fire Summary

[Christopher Schmidt]

On Sat, Apr 28, 2007 at 11:30:08AM -0700, Ron Lake wrote:
I'm actually going to snip most of the GML conversation: again, it's
ill-suited for the GeoRSS list, though I do find it interesting. I think
that we're essentially in rabid agreement -- the only difference is in
how much information I feel should be 'baked in' to any particular
format. Because of the narrow domain in which I work -- that is, making
maps of existing data on the web, usually just dealing with geometry and
some small amount of rendering rules -- my needs are tiny compared to
that solved by GML, and that represents the core of the difference of
our opinions on what GML should or should not be.  (This is why I'm a
Javascript developer, and not an OGC member. ;)) 

>> Er, I'm not sure what you mean. GeoRSS uses lat,lon everywhere, so I
>> think that means that GeoRSS *is* using 4326. 
> 
> Sorry - I was confused by your reference (a sleep I guess) - but if
> GeoRSS is (lat,lon) for EPSG:4326 then this is correct.

Right. 'Correct, but misunderstood' is probably a good way to put it. :) 

>> http://zuluviz.sdsu.edu:8080/geoserver/wfs?request=GetFeature&typeName=t
>> opp:states&BBOX=-75.102613,40.212597,-72.361859,41.512517
> 
> If so - it is NOT 4326.

Exactly, but it *is* how everyone perceives it; without much more clear
documentation in/around GeoRSS, since we do go against *everything else
on the web* in this regard, it looks like GeoRSS is wrong.

>> is *always the case* -- I have not yet run into a case where the order
>> of the results from somethign which is theoretically epsg:4326 is
>> returned in lat,lon order. 
> 
> Yes - there is a great deal of confusion on this issue - even within the
> OGC and as I said the OGC did its own version of "4326" in which lat,lon
> are reversed.  This was done so that map generators would draw things
> "upside right" if you get my meaning.  Not a decision I supported, but
> not wrong as long everyone knows what the CRS means.  For this reason we
> are deploying a world CRS Registry through the OGP (Oil and Gas
> Producers Association - BTW this replaces EPSG - but not the code).

Referring to more specs is a great CYA, but totally useless to
implementors since they won't read it. They'll copy paste examples, and
won't know they have it wrong (since machines can't tell) until they are
at a point where they may have already invested significant effort. Once
the new drupal site is up, I'll start adding this warning in more places
where it's considered important from my point of view.

> Totally agree - this is WHY we need online registries of CRS.

This is why we need clear documentation. The mechanism of that
documentation needs to be as widely varied as possible.  

> >> I'm not sure I understand the difference. You have content. You want
> it
> >> to show up a certain color on the map. You can use SLD, or you can
> use
> >> KML. Yeah? No?
> 
> > 
> > Actually I need to be a bit careful here since SLD has also changed.
> > The SLD has two "threads" - one for conventional WMS and one for
> feature
> > styling (I think this is now called Symbology Encoding) which defines
> > the styling of features into graphics - i.e. it provides a way to
> write
> > rules like "A road with 2 lanes and gravel surface should be drawn as
> a
> > 3 pt black line".  There is no way to do this in KML and it is NOT the
> > function or intent of KML.  I agree you can style in the sense of
> saying
> > this line is read.  But that is not styling geographic content. KML is
> > place centric and not feature centric. 
>  
> 
> Okay. I think this comes back to a central difference in the way we use
> the term feature, which I'm fine with. You have described the
> limitations here quite succinctly, and I think for various reasons,
> they're all unimportant for GeoRSS. Essentially, you don't need to
> provide rules for styling entities based on their attributes in GeoRSS,
> because in most cases, you simply don't have an entity to style, only
> geometry.
> 
> Exactly

Again, rabid agreement. :)

>> The difference here is where the styling decision based on the entity
>> attributes is made. In KML, that decision is made on the remote
>> end/server: "I have an entity, it has a geometry of type polygon, and I
>> want it to be red and 4px white border." In SLD, it's made on the client
>> side, and what you provide to that client is a way to make that
>> decision. 
> 
> No. With SLD it can be made ANYWHERE. The SLD only provides the
> interpretation rules based on a model of the geography (e.g. GML Schema)
> - KML has no such model to work with and provides no such rule building
> mechanism.  We use SLD for example to define the rules for interpreting
> GML (from a WFS) into SVG or KML.  We do this on a server and expose the
> result through the WMS interface.  This could also be done on the client
> but we do it mostly on the server side.  

Yeah, using client/server here was silly. The question is simple: is the
rendering rule based on finding entities, and rendering based on their
attributes? (SLD) Or is it based on finding entities, and rendering
based on the specific rule assigned to that entity? (KML, CSS.) In the
case of GeoRSS, we want the latter. 

I think we're on the same page. KML-style style description is what
works best for GeoRSS -- it tells you how to draw a geometry, rather
than a feature. 

Regards,
-- 
Christopher Schmidt
Web Developer
_______________________________________________
georss mailing list
georss at lists.eogeo.org
http://lists.eogeo.org/mailman/listinfo/georss