[georss] Quick Fire Summary

Sat Apr 28 07:21:39 EDT 2007

On Fri, Apr 27, 2007 at 10:31:11PM -0700, Ron Lake wrote:
>> I can't claim to know enough to meaningfully disagree with this. The
>> feeling I get is that GML is an excellent modelling language, and a
>> crappy transport format: without reading some additional information, I
>> can't know what XML element contains my feature information. 
> 
> [RTL]  Here we get both opinions - so I guess it depends where you sit.
> You are quite right that you need (your software needs) to process the
> schema to understand the data.  This was true for the RDF version (long
> ago) as well.

I would have similar problems with any language which called itself a
transport language, and also required OWL (or even RDFS) knowledge for 
understanding. Compare to FOAF, where the only person-like class people
use is foaf:Person -- that means that parsers know they can always look
for that. You abandon part of the flexibility of RDF in order to create
a transport format. (DOAP took this to an extreme, claiming that many
perfectly valid RDF documents using the DOAP namespace were actually not
DOAP. I think this is the right way to go for a transport format.)

> The intent in GML is to use names (defined by the users/data creators
> that reflect what they are doing.  We did not want to create a schema
> language in GML itself (we tried that in GML v1.0) - so we use currently
> XML Schema. 

Right. This is what (I believe) makes GML a fine modeling language and a
poor transport format. In order to use the information encoded in GML,
you have to have a level of understanding that is beyond the realm of
what the GML itself provides. (You need an additional file.)  

All the rest of this discussion was interesting, but not important to
GeoRSS -- I appreciate the elucidation, and it has solidified my
position. :)

>>> It is intended to support
>>> the encoding of geometric and feature objects (models of real world
>>> things) in a uniform way and this makes the encoding structure more
>>> complex than GeoRSS NS, but no more than KML.
>> 
>> Absolutely. GeoRSS is targeting the 'simplest thing' subset. GML/KML do
>> not.
> 
> This is why it might stick to a simpler program and hence a simple
> encoding.  Somehere this all breaks down if you think it can handle a
> very broad range of applications - I am skeptical about just ad hoc
> extensions as the problem space gets more complex - that is just me I
> guess.

Well, I think the rest of my email made clear that that was my opinion
as well, so it's not just you (but it might be just you and I). :)

>> The default CRS choice for GeoRSS does not seem to match the output of
>> WFS servers claiming to serve data as EPSG:4326. You're right that this
>> is not a GML limitation, but instead a description of the data of the
>> content. 
> 
> Agreed:EPSG 4326 (see
> http://crs.opengeospatial.org/crsportal/index.html) a CRS Registry -
> this one is old and a real one will be appearing pretty soon - but you
> can see that it is (lat,lon).  This is arbitrary and the OGC has also
> defined another CRS which is the opposite order.  So GeoRSS is not using
> 4326.
> 
> <snip>
> 
> EPSG:4326 is (lat,lon).  You might also note that if you want to do
> things like draw polygons across the international date line or which
> enclose the poles you may need more than one CRS.

Er, I'm not sure what you mean. GeoRSS uses lat,lon everywhere, so I
think that means that GeoRSS *is* using 4326. 

However, I look at:

http://zuluviz.sdsu.edu:8080/geoserver/wfs?request=GetFeature&typeName=topp:states&BBOX=-75.102613,40.212597,-72.361859,41.512517

This is returning a:

<gml:MultiPolygon srsName="http://www.opengis.net/gml/srs/epsg.xml#4326">

the coordinates for New York in this MultiPolygon are:

-79.763466,42.267269 -79.444252,42.419304 -79.355118,42.493404 ...

To me, that says that GeoServer's interpretation of epsg:4326 is
different than yours. (Yours matches GeoRSS's.) 

However, in working with WFS layers in OpenLayers, I've found that this
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. 

I think the fact that we need to have this discussion at all shows the
level of confusion we're dealing with. 

If EPSG:4326 is lat,lon, then GeoRSS is right... and every chunk of GML
I've encountered on the web, which is mostly provided by WFS, is wrong.

This is why the GeoRSS documentation needs to be clear that it *is* lat,
lon. So people like me, who implement on examples instead of specs,
don't get confused. 

>>> I don't understand your comparison of SLD and KML?  KML Style has a
>>  very
>>> different meaning than Style in SLD. The latter is rules that
>>  interpret
>>> content FOR presentation. In the case of KML it IS the presentation. 
>> 
>> 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.

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. For this reason, KML-style entity rendering description is
probably better than SLD-style entity rendering description. 

>>>  * Extending GeoRSS should be secondary to well-documented fully
>>>    exampled current-spec driven code with implementations. There are
>>far
>>>    more importan things to think about than tweaking the spec to
>>include
>>>    some niche use case. 
>>> 
>>> I would urge GeoRSS to stick to simple and accept what this means in
>>> terms of what can and cannot be done with it. That route leads to
>>> success.
>> 
>> I agree with that. I have a feeling that others on the list will
>> disagree. In fact, I would not complain if georss GML went away entirely
>> -- any GML encoding should be done on a GML feature inside a seperate
>> element -- but I know I'm in the minority on this. I do think that
>> regardless of the spec-level decisions of GeoRSS GML, simple should be
>> where examples concentrate first.
> 
> I think I understand GeoRSS best when the program is well defined - and
> then the encoding matches that. For simple this makes some sense - but
> to just make ad hoc extensions to say "more or less anything"  -- that I
> have more trouble with.

We're in agreement. Now to convince everyone else. :)

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