[georss] Quick Fire Summary

[Ron Lake]

Hi Chris:

 

A good discussion.  See a few additional comments below.

Ron

 

 

On Fri, Apr 27, 2007 at 05:39:49PM -0700, Ron Lake wrote:

>  * GeoRSS NS is simple geometry description for the web of content.   

>    This means that it can be used in much more than RSS. However, it's


>    not 'feature description' -- its not GML. It's not meeting the
needs

>    of people who need complex feature description -- it's a framework

>    for simple description of web content. (Despite what was said
earlier

>    on the list, GML is *not* the de facto simple encoding of Geo Data
on

>    the web, nor will it be, due to its reliance on XML Schema and its

>    relative complexity compared to GeoRSS Simple.)

> 

> It should be noted that GML is intended to provide language to create

> geo-languages. IT is currently written in XML Schema but has
previously

> been written in DTD and RDF. I would not say that it is BOUND to XML

> Schema anymore than GeoRSS is bound to RSS.  

 

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.

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. 

 

In most cases (e.g. WFS) you are returned or transfer a feature
collection.  In the WFS this is defined by WFS, not GML.  In GML this
was (up to version 3.2) defined by derivation of your feature collection
from gml:AbstractFeatureCollectionType. I agree this was messy - but was
used so you can name (and restrict membership in) the collection as you
want - e.g. <abc:City> might be a collection of Road, River and Park
features.  In GML 3.2 this was changed. A FeatureCollection is anything
with a gml:featureMember property or a property derived from it (i.e. a
specilaization).  Once again, though you must be able to read the
schema.  This is like dealing with a relational database - you could not
do much if I sent you the string (Bob 100000 24). Without a schema it
would be hard to know that this some's name, their salary and age.  As I
said we did not want to go dow n the routw of creating a schema language
in GML.  Note, however, that GML is much more comprehensible than the
correponding result set from the relational schema.

 

<abc:Person gml:id="t134">

      <gml:name>Bob</gml:name>

      <abc:salary>100000</abc:salary>

      <abc:age>24</abc:age>

</abc:Person>

 

(For

example, in WFS, it is featureMember, but in other examples, it is not.)

 

(see above)

 

I don't know if this is caused by an adherence to XML Schema, but this

has been my understanding. In any case, it seems clear that GML is

designed for something that GeoRSS Simple is not. 

 

Not a consequence of XML Schema - but of the design of GML - Schema
makes some things hard to do in GML - some were easier in RDF and some
were harder.  Remember that GML is, like RDF, a kind of XML encoding of
an extended E-R model.

 

Don't disagree - GML is designed to enable the representation and
transport of geographic entities (features).

 

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

 

>  * GeoRSS GML uses gml properties in the reverse way that every other

>    GML example on the web seems to use them. (i've been using lots of

>    WFS servers via OpenLayers, and they always spit out x,y, not y,x).

>    As a result of this, we should make it VERY CLEAR on all pages that

>    we are using y,x. This probably means that we should add examples

>    that are in places like new zealand, and hawaii: well outside the

>    comfortable -90 -> 90 box where there can be confusion. 

> 

> I am not at all sure what this means?  GML properties have no

> pre-assigned order of any kind. If you mean the order of coordinates
in

> a tuple as in <gml:coordinates> or <gml:pos> the order is determined
by

> the associated coordiate reference system, and NOTHING ELSE.  

 

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.

 

> It is NOT

> fixed anywhere in GML.  We can thus have coordinate systems (assuming

> here we are talking about geographic coordinates) in which the order
is

> (lat,lon) and ones in which it is (lon, lat). This is simply a matter
of

> what CRS you choose to reference. 

 

Yes.

 

> No more and no less.  Note that

> talking about x,y or y,x is not very meaningful (completely so

> independent of a coordinate reference system). 

 

You are correct. I meant to say 'lat,lon is what GeoRSS uses inside all

of its coordinate properties, simple or GML. Most GML I have encountered

uses lon,lat inside its properties when asked for EPSG:4326.' Again, I

don't really know enough to know whether this is right or wrong, I just

whined for a while, and Raj/Josh pushed the issue up the line to

EPSG/spec-based choices :) 

 

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.

 

 

>  * georss:when should be proposed, if people want it. However, in

>    general, GML properties are at best not recommended, and at worst

>    actively discouraged, in favor of two alternatives:

> 

>      * Encoding GML information inside alternative existing

>        atom-friendly namespaces

> 

> What consistitues a friendly namespace?

 

"Atom-friendly" meaning, in this case, "Already used with Atom", rather

than creating new namespaces and elements to do things which already

exist. I can't speak to georss:when in this case, because I've never

invesitgated the environment around Atom namespacing, which is where

this kind of thing is decided, but there are many communities using Atom

to do many things, and finding one which has a need like this is

probably possible without co-opting GeoRSS for it.

 

I would agree that it does not make sense to use GML times unless 1) you
need them - GML defines a lot of time constructs or 2) You are defining
a GML feature.  I don't think anyone expects ATOM to become a GML
application schema.

 

>        your GeoRSS feed, you may want to create/propose a
georss:feature

>        property, which then lets you refer to a full GML Feature,

>        including 'time', full gml geometry, etc.

> 

>  

> 

> This is done in KML.  

 

I don't think this is done in KML. <Metadata> is not this, though it is

something in which something like this could be specified. However,

that's a different level of disagreement that is unrelated to GeoRSS. :)

 

<Metadat> can be this - and since that is one of the choices I think you
will see this more in the future.  Note that KML is NOT intended to
model geographic features but to draw them.

 

>  I think this is reasonable.

 

Excellent.

 

>  * Styling via KML should probably be a 'best practice'
recommendation, 

>    but probably not a 'part of GeoRSS' -- something to be described by

>    example, since it applies equally to all RSS, rather than something

>    that is a normative part of a spec. (The alternatives here are

>    basically KML / SLD -- SLD seems likely to be too complex, and
lacks

>    the built in remote-refrence semantics that the KML styling
mechanism

>    has -- at least to the knowledge of the participants in the conf

>    call.)

> 

>  

> 

> I think you mean presentation via KML, since styling means the

> interpretation of the GeoRSS for presentation and there is no
mechanism

> in KML to express such styling (as in styling GeoRSS to KML via XSLT).

 

You're right. I apologize for being non-specific. Blame the

establishment we stopped at on our way out of the meeting :)

 

We all need lubrication!

 

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

 

> The

> Style in KML is more like a Style in SVG (KML is more like SVG than
GML)

> that is it provides properties of the graphical presentation.

 

Yes. Does SLD do something different? that was how I understood SLD when

I tried to write it a couple months ago.

 

See above.

 

>  * GeoRSS GML is a small set of extension (georss:where) wrapped
around

>    GML geometry. 

> 

>       The where property is correctly used in the sense of GML. You
have

> used a foreign property (in another namespace) to hold a GML object

> (geometry) - and this is correct.

 

Correct.

 

> 

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

 

Regards,

-- 

Ron Lake

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