[georss] Quick Fire Summary

[Ron Lake]

Chris:



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.)

 

So you would like GML itself to provide concrete names for everything ?
GML is currently being applied in a very wide range of domains from
commercial aviation (AIXM), defense (VPFGML, AMLGML), nautical charting
(S57GML), avalanche hazards (CAAML), intelligent transportation systems
(ITSGML), mining and mineral exploration (XMML) and thousands of others
that have no formal designation.  The variety is so great that it would
require enormous hubris on our part to tell all these application
domains what their objects are to be called.  So GML only names specific
things like geometries (Point, Polygon, Solid, LineString, Arc, Node,
TimeInstant, Edge, GeographicCRS, .. there are about 1000 of these tags)
and then provides a common structure by which you create your own
vocabulary or as would have it your own application specific language.
There would be NO HOPE at all in getting acceptance of the hundreds of
thousands of object names that people using GML would use.

 

> 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.)  

 

Whether or not you need an additional file is kind of irrelevant - it IS
part of GML (the schema part) and this is why a WFS provides the schema
through the describe feature mechanism.  If you have fixed features in
some narrow domain then you can give this up - but otherwise it is
essential. 

 

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. 

 

Sorry - I was confused by your reference (a sleep I guess) - but if
GeoRSS is (lat,lon) for EPSG:4326 then this is correct.

 

However, I look at:

 

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

 

This is returning a:

 

If so - it is NOT 4326.

 

<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. 

 

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).

 

I think the fact that we need to have this discussion at all shows the

level of confusion we're dealing with. 

 

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

 

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.

 

Not impossible.

 

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. 

 

You need to reference an authorative registry - which wil soon be
available.

 

>>> 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.


Exactly

 

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.  So SLD is styling rules (more
like XSLT with a defined set of "abstract" graphics outputs.

 

For this reason, KML-style entity rendering description is

probably better than SLD-style entity rendering description. 

 

Yes - I would say you can STYLE GeoRSS (perhaps using an SLD or just
XSLT) into KML. You can then RENDER the KML in GE or someother tool.

 

Snip;

 

> 

> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.eogeo.org/pipermail/georss/attachments/20070428/f4b4bdf9/attachment-0001.html 
-------------- next part --------------
_______________________________________________
georss mailing list
georss at lists.eogeo.org
http://lists.eogeo.org/mailman/listinfo/georss