<div dir="ltr">I wouldn't look at our BNFs as anything particularly authoritative, they were mostly transcribed from the ISO SQL specs, if I recall correctly. And at the time they were written (maybe) still, those specs didn't have anything to say about TIN or POLYHEDRALSURFACE. Those types were added later, and Olivier is the one to comment on where he got the info from on how to add them to the heirarchy. Since we don't really care much about the object heirarchy internal to postgis (the only thing we really care about is "are you a collection or not") any details of child/parent relationships are not really important to us.<div><br></div><div>I think you should go w/ what makes sense for you. The argument that a TIN is a MULTISURFACE makes sense to me, since I see a SURFACE as being a (unclosed) 2D structure embedded in 3-space, which is consistent w/ a TIN. A polyhedral surface is a closed 2D structure embedded in 3-space.</div><div><br></div><div>ATB</div><div>P<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jul 17, 2016 at 6:43 AM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
We've stumbled upon this philosophical question with our GDAL GSoC student<br>
when trying to convert a shapefile MultiPatch into a OGR Geometry. My idea was<br>
to model a MultiPatch as a MultiSurface whose children could be Polygons (for<br>
parts of type outer ring, inner ring, first ring or ring) or TINs (for parts of<br>
type triangle strip or triangle fan). But it seems that according to<br>
<a href="https://github.com/postgis/postgis/blob/svn-trunk/doc/bnf-wkb.txt" rel="noreferrer" target="_blank">https://github.com/postgis/postgis/blob/svn-trunk/doc/bnf-wkb.txt</a> or<br>
<a href="https://github.com/postgis/postgis/blob/svn-trunk/doc/bnf-wkt.txt" rel="noreferrer" target="_blank">https://github.com/postgis/postgis/blob/svn-trunk/doc/bnf-wkt.txt</a>, a<br>
MultiSurface can only have Polygon or CurvePolygon as elements. And PostGIS<br>
does enforce that when importing WKT (<br>
<a href="https://github.com/postgis/postgis/blob/svn-" rel="noreferrer" target="_blank">https://github.com/postgis/postgis/blob/svn-</a><br>
trunk/liblwgeom/lwin_wkt_parse.y#L260 )<br>
<br>
This restriction of MultiSurface to Polygon/CurvePolygon seems to me to be<br>
contradictory with the "Figure 1: Geometry class hierarchy" of OGC 06-103r4<br>
Simple feature access  1.2.1 (<br>
<a href="http://portal.opengeospatial.org/files/?artifact_id=25355" rel="noreferrer" target="_blank">http://portal.opengeospatial.org/files/?artifact_id=25355</a> ) where a TIN derives<br>
from Surface. And according to §6.1.13.1, "A MultiSurface is a 2-dimensional<br>
GeometryCollection whose elements are Surfaces".<br>
<br>
Even more confusing, according to bnf-wkt.txt, a polyhedral text or tin text<br>
could be a valid MultiSurface, despite PolyhedralSurface/TIN not being modeled<br>
as a MultiSurface.<br>
<br>
So I'm wondering if the restrictions of bnf-wkt.txt and bnf-wkb.txt regarding<br>
the accepted children type of MultiSurface are legitimate ?<br>
<span class="HOEnZb"><font color="#888888"><br>
Even<br>
<br>
--<br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org">postgis-devel@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/postgis-devel</a></font></span></blockquote></div><br></div>