[georss] GeoRSS Simple Features Proposal

[Raj Singh]

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 at cadcorp.com> 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 at lists.eogeo.org
>>>> http://lists.eogeo.org/mailman/listinfo/georss
>>>>
>>>
>>>
>>>
>>> -- 
>>> Andrew Turner
>>> mobile: 248.982.3609
>>> andrew at mapufacture.com 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 at lists.eogeo.org
>>> http://lists.eogeo.org/mailman/listinfo/georss
>>
>> _______________________________________________
>> georss mailing list
>> georss at lists.eogeo.org
>> http://lists.eogeo.org/mailman/listinfo/georss
>
> _______________________________________________
> georss mailing list
> georss at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/georss