Bring MapWinGIS into compliance with newer ISO Geometry Types coming out of GDAL/OGR
Based on an issue raised on MapWinGIS Forum [Delphi MapWinGIS OGR Issues], I have come to believe that there are many geometry types that can come out of an OGR datasource that are not currently handled by MapWinGIS (and which then result in a shape type of SHP_NULLSHAPE.
The current code interprets the basic 2D types and the 25D types as follows (note that it does not even account for an M value).
Starting at GDAL 2.1, additional types were added based on ISO SQL/MM Part 3, including, but not limited to:
I recommend that we adopt Shape Type support very similar to that of GDAL (based on their Shapefile driver), which is as follows:
Geometry type conversions have been extended as show below.
This required additional changes to the various conversion routines in OgrConverter.cpp in order to support the new types that may be returned from an OGR datasource.
More work is likely required in the Utility functions, which have not yet been modified.
The Shape.ExportToWKT now passes in the GDAL constant OGRwkbVariant::wkbVariantISO, so that exported text will include the Z parameter as necessary, for example “POINT Z (1.0, 2.0, 3.0)”.
When importing from WKT, in case there are both Z and M values, I am letting the Z value govern, interpreting the result as a Z type, since ZM types are not supported by Shapefiles.
At least in this iteration, we would only be implementing Shape types that are already supported in MapWinGIS, being the standard Shapefile types defined by ESRI, and as defined by our current enumeration.
A such, this would not include things such as 3-point curves or circular types. The GDAL Shapefile driver does not support these types either. Note that the GDAL constants match our enumeration values (except that they refer to POLYLINEs as ARCs).
Sounds good to me. Would be nice if we could add 'unit tests' for all possible types.
And how about the display on the map? Can MapWinGIS handle Curved and Circular types? I assume this needs a different approach to calculate the pixels to show?