Hi PostGIS developers,<br><br>I'm working on PostGIS support for Safe Software's FME and have a couple questions about the way PostGIS does things.<br><br>In particular, it looks like the WKB geometry type codes used by PostGIS don't line up with those specified by the OGC.<br>

<br>For example, from liblwgeom.h:<br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote"><span class="preprocessor">#define CURVEPOLYTYPE    13</span><br>

<a name="l00670"></a><span class="preprocessor"></span><span class="preprocessor">#define MULTICURVETYPE   14</span><br><a name="l00671"></a><span class="preprocessor">#define MULTISURFACETYPE 15</span><br></blockquote><br>

Whereas the OGC has <br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">CurvePolygon 10<br>MultiCurve 11<br>MultiSurface 12<br>Curve 13<br>
Surface 14<br>
PolyhedralSurface 15<br></blockquote><br>SQLMM of course offers some completely different alternate choices, something like:<br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">

CurvePolygon 1000003<br>Multicurve 1000004<br>Multisurface 1000005<br></blockquote><br>which, if I recall the values correctly, have an unexpected (and possibly coincidental) alignment with the PostGIS choices...<br><br>
I'm curious about this apparent discrepancy, and what it implies about my chances of keeping our WKB parser more or less vendor neutral.<br>
<br>And I haven't tested this yet, but I presume that ST_AsBinary() will return the same PostGIS specific type codes as ST_AsEWKB()?<br><br clear="all">Thanks,<br>Raven<br>