[postgis-devel] [gdal-dev] Bogus <gml:Face> interpretation

[Even Rouault]

Hi Sandro,

CC'ing Chaitanya who implemented the reading of topological GML3 elements.

Le dimanche 30 janvier 2011 12:09:12, strk a écrit :
> Hello,
> I'm writing GML output routines for Topologically-defined features
> in PostGIS and found what I think is a bug in how ogr interprets
> the <gml:Face> tag contents.
> 
> Take this topology:
> 
>  n1
>   +-----e1-->-----.
> 
>   |      F1       |
>   |      
>   |           n3  |
>   |   
>   |   ,-e2->-+    |
>   |   
>   |   |  F2  |    |
>   |   
>   |   +-<-e7-'    |
>   | 
>   | n4            |
> 
>   `---<-e2--------+
>                    n2

There's probably an error with the name of the edges in your first schema : 
there are 2 e2 and one e7. I guess the edges of the interior ring should be 
named e3 and e4, right ?

> 
> It occurs to me that face F1 above is bounded by all edges,
> not just the exterior ones, so I'd put _all_ edges inside
> one gml:Face tag:
> 
>  <Face id="F1">
>   <directedEdge orientation="-" id="e1" />
>   <directedEdge orientation="-" id="e2" />
>   <directedEdge id="e3" />
>   <directedEdge id="e4" />
>  </Face>
> 
> This is expressed clearly in the OGC 03-105r1 document (GML-3.1.1, 2004)
> and 07-036 (GML-3.2.1, 2007)
> 
> <<
> The non-dangling edges in the boundary of a face comprise one or more
> topological rings. Each such ring consists of directedEdges connected
> in a cycle, and is oriented with the face on its left.
> 
> 
> Now, when encountering such a GML snippet, ogr2ogr (GML driver)
> insists in considering all edges as being part of the same ring
> thus producing an invalid polygon as a result.

If I understand well, the face should be interpreted as a polygon with 
exterior ring being e1,e2 and interior ring being e3, e4 ?

I've reviewed a bit the code and my understanding is that we concatenate all 
the linestring geometries found in the directedEdge of a Face into a single 
ring as you noticed. So we should implement detection of cycles to emit as 
many rings as necessary.

> 
> It basically interprets a <gml:Face> tag as if it was a ring, which
> I belive is wrong.
> 
> Another example of such invalid intepretation follows:
> 
>   +------+------+
> 
>   | F1   |  F2  |
> 
>   +------+------+
> 
> A surface/polygon formed by the two faces above (F1,F2) should be
> represented as:
> 
>  <TopoSurface id="P1">
>    <directedFace> <Face id="F1"/> </directedFace>
>    <directedFace> <Face id="F2"/> </directedFace>
>  </TopoSurface>
> 
> Whereas the resulting feature geometry should be a single-ring polygon:
> the topological _union_ of the two faces (I haven't tested this but
> I belive GDAL would get this wrong as well).

Yes we should likely use GEOSUnion instead of putting all the rings into a 
single polygon as we do currently.

> 
> On the PostGIS side, I've so far implemented the "invalid" representation
> for the sake of interoperability with GDAL, but being a new implementation
> I'd rather get it right from the start...
> 
> Note that using the "invalid" (but GDAL-compatible) representation also
> has the negative effect of making it _impossible_ to map PostGIS(ISO)
> topologies to GML in a lossless way (PostGIS topology faces would have
> no direct corrispondence to <gml:Face> tags).
> 
> I hope, with this mail, to get some feedback from the authors of the
> GML reading capabilities of GDAL to plan actions towards interoperability
> of the two systems and adherence to the standard (if possible).

I think you shouldn't try too hard to be OGR compatible in Postgis if you 
believe that we are currently not interpreting GML correctly. The GML3 
topology interpretation in OGR is completely new, so I would definitely not 
label it as a reference implementation, and it probably needs adjustements.

What could help is that you file GDAL trac tickets with examples of GML3 
topology and what you think would be the expected WKT.

Best regards,

Even

> 
> --strk;
> 
>   ()   Free GIS & Flash consultant/developer
>   /\   http://strk.keybit.net/services.html
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev