GeoRSS Simple Features Proposal

[Martin Daly]

Any chance of adding support for holes in Polygons at the same time as
adding the rest of SF?

M
_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss

[joshli]

As simple as GML-SF is, my feeling is that it is still too complicated  
for core GeoRSS. My sense from the use cases I have seen so far is  
that use of multi-geometries, inside rings, and other subtlies of  
GML / ISO geometry generally require the client / user to understand  
more about the associated feature type in order to work with them, as  
well as utilize more complex topology processing and indexing. Just  
inserting them into georss:where doesn't do a lot for interoperability  
as far as I can see.

There is no restriction of course on putting a GML feature into  
something like an Atom entry, either in the <Content> tag or just  
intercalated, as an alternative or addition to a simpler GeorssGML  
geometry. The CGDI Pilot also experimented with a  
georss:FeatureofInterest element (analogous to O&M) to include a full  
(GML-SF0) feature in an Atom entry, in addition to the georss:where  
element.

Josh

On Apr 9, 2008, at 5:17 AM, Martin Daly wrote:

> Any chance of adding support for holes in Polygons at the same time as
> adding the rest of SF?
>
> M
> _______________________________________________
> georss mailing list
> georss@...
> http://lists.eogeo.org/mailman/listinfo/georss

_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss

[Martin Daly]

> As simple as GML-SF is, my feeling is that it is still too complicated
> for core GeoRSS. My sense from the use cases I have seen so far is
> that use of multi-geometries, inside rings, and other subtlies of
> GML / ISO geometry generally require the client / user to understand
> more about the associated feature type in order to work with them, as
> well as utilize more complex topology processing and indexing. Just
> inserting them into georss:where doesn't do a lot for interoperability
> as far as I can see.
>
> There is no restriction of course on putting a GML feature into
> something like an Atom entry, either in the <Content> tag or just
> intercalated, as an alternative or addition to a simpler GeorssGML
> geometry. The CGDI Pilot also experimented with a
> georss:FeatureofInterest element (analogous to O&M) to include a full
> (GML-SF0) feature in an Atom entry, in addition to the georss:where
> element.

Simple being simpler than simple is fine by me.
 
I'm not even sure if they are disallowed at the moment in GeoRSS GML,
but they are never mentioned.  They are disallowed in GeoRSS Simple, and
the SF Proposal for GeoRSS Simple does not change this.

Disallowing holes in Simple, but allowing them in GML (as is the case
for GeometryCollection) seems like a reasonable compromise to me.  I see
no rationale in adding everything *except* holes to GML.

M



_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss

[Andrew Turner-8]

On Wed, Apr 9, 2008 at 11:23 AM, Martin Daly <Martin.Daly@...> wrote:
>  >
>  > There is no restriction of course on putting a GML feature into
>  > something like an Atom entry, either in the <Content> tag or just
>  > intercalated, as an alternative or addition to a simpler GeorssGML
>  > geometry. The CGDI Pilot also experimented with a
>  > georss:FeatureofInterest element (analogous to O&M) to include a full
>  > (GML-SF0) feature in an Atom entry, in addition to the georss:where
>  > element.

This seems entirely too complex. How is removing potential confusion
around GML-SF in where simplified by adding more arbitrary elements?

>
>  Simple being simpler than simple is fine by me.
>
>  I'm not even sure if they are disallowed at the moment in GeoRSS GML,
>  but they are never mentioned.  They are disallowed in GeoRSS Simple, and
>  the SF Proposal for GeoRSS Simple does not change this.
>
>  Disallowing holes in Simple, but allowing them in GML (as is the case
>  for GeometryCollection) seems like a reasonable compromise to me.  I see
>  no rationale in adding everything *except* holes to GML.

I think that I agree with Martin - removing confusion by having a
GeoRSS specific GML profile seems good. Just make it synonymous with
GML-SF. So if someone want's really simple, then GeoRSS-Simple,
otherwise you have GML-SF.

>
>
>
>  M
>
>
>
>  _______________________________________________
>  georss mailing list
>  georss@...
>  http://lists.eogeo.org/mailman/listinfo/georss
>

--
Andrew Turner
mobile: [phone]
andrew@... 42.2774N x 83.7611W
http://highearthorbit.com Ann Arbor, Michigan, USA

http://mapufacture.com Helping build the Geospatial Web
Introduction to Neogeography - http://oreilly.com/catalog/neogeography
_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss

[Raj Singh-2]

My intention was just to match SF. If holes in polygons aren't part of  
SF we shouldn't add them. I'm also not completely sure what the use  
case for GeoRSS SF is (even though I posted the proposal). I feel I've  
heard a need for it, but I'd like to add some motivation behind it.

Also, just turned comments on for that page.
---
Raj


On Apr 9, 2008, at 11:39 AM, Andrew Turner wrote:

> On Wed, Apr 9, 2008 at 11:23 AM, Martin Daly  
> <Martin.Daly@...> wrote:
>>>
>>> There is no restriction of course on putting a GML feature into
>>> something like an Atom entry, either in the <Content> tag or just
>>> intercalated, as an alternative or addition to a simpler GeorssGML
>>> geometry. The CGDI Pilot also experimented with a
>>> georss:FeatureofInterest element (analogous to O&M) to include a  
>>> full
>>> (GML-SF0) feature in an Atom entry, in addition to the georss:where
>>> element.
>
> This seems entirely too complex. How is removing potential confusion
> around GML-SF in where simplified by adding more arbitrary elements?
>
>>
>> Simple being simpler than simple is fine by me.
>>
>> I'm not even sure if they are disallowed at the moment in GeoRSS GML,
>> but they are never mentioned.  They are disallowed in GeoRSS  
>> Simple, and
>> the SF Proposal for GeoRSS Simple does not change this.
>>
>> Disallowing holes in Simple, but allowing them in GML (as is the case
>> for GeometryCollection) seems like a reasonable compromise to me.  
>> I see
>> no rationale in adding everything *except* holes to GML.
>
> I think that I agree with Martin - removing confusion by having a
> GeoRSS specific GML profile seems good. Just make it synonymous with
> GML-SF. So if someone want's really simple, then GeoRSS-Simple,
> otherwise you have GML-SF.
>
>
>>
>>
>>
>> M
>>
>>
>>
>> _______________________________________________
>> georss mailing list
>> georss@...
>> http://lists.eogeo.org/mailman/listinfo/georss
>>
>
>
>
> --
> Andrew Turner
> mobile: [phone]
> andrew@... 42.2774N x 83.7611W
> http://highearthorbit.com Ann Arbor, Michigan, USA
>
> http://mapufacture.com Helping build the Geospatial Web
> Introduction to Neogeography - http://oreilly.com/catalog/neogeography
> _______________________________________________
> georss mailing list
> georss@...
> http://lists.eogeo.org/mailman/listinfo/georss

_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss

[joshli]

There is already a simple and tightly constrained GML profile for  
georss - gmlgeorss
( http://www.georss.org/xml/1.1/gmlgeorss.xsd ) which is being used  
informally in other places and will be published as a best practice at  
the next TC. It does not, by the way, include holes:

<!-- This profile restricts polygons to one exterior ring and no  
interior rings -->

There is not a single "GML-SF", there are three different compliance  
levels and more geometry options than most users of georss are aware  
of or prepared for.

Georss SImple is defined as a shortcut for the present GeoRSS GML  
definitions. If GeoRSS is just a tag + GML, that definition is lost.

Nonetheless, specialized users are interested in putting other forms  
of GML into Atom, etc. The notes below were simply advice on how it  
might be done. I'm not averse myself to having a GML-SFL1-2-3 form of  
GeoRSS, just not by getting rid of what is already there for good  
reason. I also noted in my earlier email that more complex geometries  
usually need to be associated to a particular type of feature in order  
to be made sense of (e.g. multi-points -> sampling locations for an  
average measurement).

--Josh

On Apr 9, 2008, at 11:39 AM, Andrew Turner wrote:

> On Wed, Apr 9, 2008 at 11:23 AM, Martin Daly  
> <Martin.Daly@...> wrote:
>>>
>>> There is no restriction of course on putting a GML feature into
>>> something like an Atom entry, either in the <Content> tag or just
>>> intercalated, as an alternative or addition to a simpler GeorssGML
>>> geometry. The CGDI Pilot also experimented with a
>>> georss:FeatureofInterest element (analogous to O&M) to include a  
>>> full
>>> (GML-SF0) feature in an Atom entry, in addition to the georss:where
>>> element.
>
> This seems entirely too complex. How is removing potential confusion
> around GML-SF in where simplified by adding more arbitrary elements?
>
>>
>> Simple being simpler than simple is fine by me.
>>
>> I'm not even sure if they are disallowed at the moment in GeoRSS GML,
>> but they are never mentioned.  They are disallowed in GeoRSS  
>> Simple, and
>> the SF Proposal for GeoRSS Simple does not change this.
>>
>> Disallowing holes in Simple, but allowing them in GML (as is the case
>> for GeometryCollection) seems like a reasonable compromise to me.  
>> I see
>> no rationale in adding everything *except* holes to GML.
>
> I think that I agree with Martin - removing confusion by having a
> GeoRSS specific GML profile seems good. Just make it synonymous with
> GML-SF. So if someone want's really simple, then GeoRSS-Simple,
> otherwise you have GML-SF.
>
>
>>
>>
>>
>> M
>>
>>
>>
>> _______________________________________________
>> georss mailing list
>> georss@...
>> http://lists.eogeo.org/mailman/listinfo/georss
>>
>
>
>
> --
> Andrew Turner
> mobile: [phone]
> andrew@... 42.2774N x 83.7611W
> http://highearthorbit.com Ann Arbor, Michigan, USA
>
> http://mapufacture.com Helping build the Geospatial Web
> Introduction to Neogeography - http://oreilly.com/catalog/neogeography

_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss

[joshli]

I did take a look at GML-SF. Holes are supported through gml:Polygon  
or gml:Surface or gml:MultiSurface (MultiPolygon is depracated in GML  
3.2+). Basically, all of the compliance levels support the same set of  
geometry types and place no more constraints on them than GML as a  
whole does.


On Apr 9, 2008, at 3:59 PM, Raj Singh wrote:

> My intention was just to match SF. If holes in polygons aren't part of
> SF we shouldn't add them. I'm also not completely sure what the use
> case for GeoRSS SF is (even though I posted the proposal). I feel I've
> heard a need for it, but I'd like to add some motivation behind it.
>
> Also, just turned comments on for that page.
> ---
> Raj
>
>
> On Apr 9, 2008, at 11:39 AM, Andrew Turner wrote:
>> On Wed, Apr 9, 2008 at 11:23 AM, Martin Daly
>> <Martin.Daly@...> wrote:
>>>>
>>>> There is no restriction of course on putting a GML feature into
>>>> something like an Atom entry, either in the <Content> tag or just
>>>> intercalated, as an alternative or addition to a simpler GeorssGML
>>>> geometry. The CGDI Pilot also experimented with a
>>>> georss:FeatureofInterest element (analogous to O&M) to include a
>>>> full
>>>> (GML-SF0) feature in an Atom entry, in addition to the georss:where
>>>> element.
>>
>> This seems entirely too complex. How is removing potential confusion
>> around GML-SF in where simplified by adding more arbitrary elements?
>>
>>>
>>> Simple being simpler than simple is fine by me.
>>>
>>> I'm not even sure if they are disallowed at the moment in GeoRSS  
>>> GML,
>>> but they are never mentioned.  They are disallowed in GeoRSS
>>> Simple, and
>>> the SF Proposal for GeoRSS Simple does not change this.
>>>
>>> Disallowing holes in Simple, but allowing them in GML (as is the  
>>> case
>>> for GeometryCollection) seems like a reasonable compromise to me.
>>> I see
>>> no rationale in adding everything *except* holes to GML.
>>
>> I think that I agree with Martin - removing confusion by having a
>> GeoRSS specific GML profile seems good. Just make it synonymous with
>> GML-SF. So if someone want's really simple, then GeoRSS-Simple,
>> otherwise you have GML-SF.
>>
>>
>>>
>>>
>>>
>>> M
>>>
>>>
>>>
>>> _______________________________________________
>>> georss mailing list
>>> georss@...
>>> http://lists.eogeo.org/mailman/listinfo/georss
>>>
>>
>>
>>
>> --
>> Andrew Turner
>> mobile: [phone]
>> andrew@... 42.2774N x 83.7611W
>> http://highearthorbit.com Ann Arbor, Michigan, USA
>>
>> http://mapufacture.com Helping build the Geospatial Web
>> Introduction to Neogeography - http://oreilly.com/catalog/ 
>> neogeography
>> _______________________________________________
>> georss mailing list
>> georss@...
>> http://lists.eogeo.org/mailman/listinfo/georss
>
> _______________________________________________
> georss mailing list
> georss@...
> http://lists.eogeo.org/mailman/listinfo/georss

_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss

[Raj Singh-2]

Actually, this is a terminology problem. I'm trying to align not with  
GML Simple Features, but with the simpler:
"OpenGIS Implementation Specification for Geographic information -  
Simple feature access - Part 2: SQL option"
<http://www.opengeospatial.org/standards/sfs>

I just found these key clauses in that document.

page 36:
A conforming implementation shall support a subset of the following  
set of SQL Geometry Types: {Geometry, Point, Curve, LineString,  
Surface, Polygon, PolyhedralSurface, GeomCollection, MultiCurve,  
MultiLineString, MultiSurface, MultiPolygon, and MultiPoint}

page 15:
d) Polygons may contain holes, as described in the Geometry object  
model.

---
Raj


On Apr 9, 2008, at 4:38 PM, Joshua Lieberman wrote:

> I did take a look at GML-SF. Holes are supported through gml:Polygon
> or gml:Surface or gml:MultiSurface (MultiPolygon is depracated in GML
> 3.2+). Basically, all of the compliance levels support the same set of
> geometry types and place no more constraints on them than GML as a
> whole does.
>
>
> On Apr 9, 2008, at 3:59 PM, Raj Singh wrote:
>
>> My intention was just to match SF. If holes in polygons aren't part  
>> of
>> SF we shouldn't add them. I'm also not completely sure what the use
>> case for GeoRSS SF is (even though I posted the proposal). I feel  
>> I've
>> heard a need for it, but I'd like to add some motivation behind it.
>>
>> Also, just turned comments on for that page.
>> ---
>> Raj
>>
>>
>> On Apr 9, 2008, at 11:39 AM, Andrew Turner wrote:
>>> On Wed, Apr 9, 2008 at 11:23 AM, Martin Daly
>>> <Martin.Daly@...> wrote:
>>>>>
>>>>> There is no restriction of course on putting a GML feature into
>>>>> something like an Atom entry, either in the <Content> tag or just
>>>>> intercalated, as an alternative or addition to a simpler GeorssGML
>>>>> geometry. The CGDI Pilot also experimented with a
>>>>> georss:FeatureofInterest element (analogous to O&M) to include a
>>>>> full
>>>>> (GML-SF0) feature in an Atom entry, in addition to the  
>>>>> georss:where
>>>>> element.
>>>
>>> This seems entirely too complex. How is removing potential confusion
>>> around GML-SF in where simplified by adding more arbitrary elements?
>>>
>>>>
>>>> Simple being simpler than simple is fine by me.
>>>>
>>>> I'm not even sure if they are disallowed at the moment in GeoRSS
>>>> GML,
>>>> but they are never mentioned.  They are disallowed in GeoRSS
>>>> Simple, and
>>>> the SF Proposal for GeoRSS Simple does not change this.
>>>>
>>>> Disallowing holes in Simple, but allowing them in GML (as is the
>>>> case
>>>> for GeometryCollection) seems like a reasonable compromise to me.
>>>> I see
>>>> no rationale in adding everything *except* holes to GML.
>>>
>>> I think that I agree with Martin - removing confusion by having a
>>> GeoRSS specific GML profile seems good. Just make it synonymous with
>>> GML-SF. So if someone want's really simple, then GeoRSS-Simple,
>>> otherwise you have GML-SF.
>>>
>>>
>>>>
>>>>
>>>>
>>>> M
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> georss mailing list
>>>> georss@...
>>>> http://lists.eogeo.org/mailman/listinfo/georss
>>>>
>>>
>>>
>>>
>>> --
>>> Andrew Turner
>>> mobile: [phone]
>>> andrew@... 42.2774N x 83.7611W
>>> http://highearthorbit.com Ann Arbor, Michigan, USA
>>>
>>> http://mapufacture.com Helping build the Geospatial Web
>>> Introduction to Neogeography - http://oreilly.com/catalog/
>>> neogeography
>>> _______________________________________________
>>> georss mailing list
>>> georss@...
>>> http://lists.eogeo.org/mailman/listinfo/georss
>>
>> _______________________________________________
>> georss mailing list
>> georss@...
>> http://lists.eogeo.org/mailman/listinfo/georss
>
> _______________________________________________
> georss mailing list
> georss@...
> http://lists.eogeo.org/mailman/listinfo/georss

_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss

[creed]

If we do align with SF SQL, then there is consistency with numerous database
implementations of that standard, such as in PostGIS, DB-2, SQLServer 2008,
Oracle, and so forth.. There is, however, an ambiguity in SF SQL regarding
CRS. For CRS, I would suggest we follow GML encoding rules.
Any questions about SF SQL, I am sure John Herring would be more than happy
to help.

Carl


----- Original Message -----
From: "Raj Singh" <raj@...>
To: "Joshua Lieberman" <josh@...>
Cc: <georss@...>
Sent: Wednesday, April 09, 2008 3:06 PM
Subject: Re: [georss] GeoRSS Simple Features Proposal

> Actually, this is a terminology problem. I'm trying to align not with
> GML Simple Features, but with the simpler:
> "OpenGIS Implementation Specification for Geographic information -
> Simple feature access - Part 2: SQL option"
> <http://www.opengeospatial.org/standards/sfs>
>
> I just found these key clauses in that document.
>
> page 36:
> A conforming implementation shall support a subset of the following
> set of SQL Geometry Types: {Geometry, Point, Curve, LineString,
> Surface, Polygon, PolyhedralSurface, GeomCollection, MultiCurve,
> MultiLineString, MultiSurface, MultiPolygon, and MultiPoint}
>
> page 15:
> d) Polygons may contain holes, as described in the Geometry object
> model.
>
> ---
> Raj
>
>
> On Apr 9, 2008, at 4:38 PM, Joshua Lieberman wrote:
>> I did take a look at GML-SF. Holes are supported through gml:Polygon
>> or gml:Surface or gml:MultiSurface (MultiPolygon is depracated in GML
>> 3.2+). Basically, all of the compliance levels support the same set of
>> geometry types and place no more constraints on them than GML as a
>> whole does.
>>
>>
>> On Apr 9, 2008, at 3:59 PM, Raj Singh wrote:
>>
>>> My intention was just to match SF. If holes in polygons aren't part
>>> of
>>> SF we shouldn't add them. I'm also not completely sure what the use
>>> case for GeoRSS SF is (even though I posted the proposal). I feel
>>> I've
>>> heard a need for it, but I'd like to add some motivation behind it.
>>>
>>> Also, just turned comments on for that page.
>>> ---
>>> Raj
>>>
>>>
>>> On Apr 9, 2008, at 11:39 AM, Andrew Turner wrote:
>>>> On Wed, Apr 9, 2008 at 11:23 AM, Martin Daly
>>>> <Martin.Daly@...> wrote:
>>>>>>
>>>>>> There is no restriction of course on putting a GML feature into
>>>>>> something like an Atom entry, either in the <Content> tag or just
>>>>>> intercalated, as an alternative or addition to a simpler GeorssGML
>>>>>> geometry. The CGDI Pilot also experimented with a
>>>>>> georss:FeatureofInterest element (analogous to O&M) to include a
>>>>>> full
>>>>>> (GML-SF0) feature in an Atom entry, in addition to the
>>>>>> georss:where
>>>>>> element.
>>>>
>>>> This seems entirely too complex. How is removing potential confusion
>>>> around GML-SF in where simplified by adding more arbitrary elements?
>>>>
>>>>>
>>>>> Simple being simpler than simple is fine by me.
>>>>>
>>>>> I'm not even sure if they are disallowed at the moment in GeoRSS
>>>>> GML,
>>>>> but they are never mentioned.  They are disallowed in GeoRSS
>>>>> Simple, and
>>>>> the SF Proposal for GeoRSS Simple does not change this.
>>>>>
>>>>> Disallowing holes in Simple, but allowing them in GML (as is the
>>>>> case
>>>>> for GeometryCollection) seems like a reasonable compromise to me.
>>>>> I see
>>>>> no rationale in adding everything *except* holes to GML.
>>>>
>>>> I think that I agree with Martin - removing confusion by having a
>>>> GeoRSS specific GML profile seems good. Just make it synonymous with
>>>> GML-SF. So if someone want's really simple, then GeoRSS-Simple,
>>>> otherwise you have GML-SF.
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>> M
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> georss mailing list
>>>>> georss@...
>>>>> http://lists.eogeo.org/mailman/listinfo/georss
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Andrew Turner
>>>> mobile: [phone]
>>>> andrew@... 42.2774N x 83.7611W
>>>> http://highearthorbit.com Ann Arbor, Michigan, USA
>>>>
>>>> http://mapufacture.com Helping build the Geospatial Web
>>>> Introduction to Neogeography - http://oreilly.com/catalog/
>>>> neogeography
>>>> _______________________________________________
>>>> georss mailing list
>>>> georss@...
>>>> http://lists.eogeo.org/mailman/listinfo/georss
>>>
>>> _______________________________________________
>>> georss mailing list
>>> georss@...
>>> http://lists.eogeo.org/mailman/listinfo/georss
>>
>> _______________________________________________
>> georss mailing list
>> georss@...
>> http://lists.eogeo.org/mailman/listinfo/georss
>
> _______________________________________________
> georss mailing list
> georss@...
> http://lists.eogeo.org/mailman/listinfo/georss 

_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss