Opened 18 years ago
Closed 18 years ago
#1618 closed defect (fixed)
msOGRShapeToWKT need to be fully implemented
Reported by: | szekerest | Owned by: | warmerdam |
---|---|---|---|
Priority: | high | Milestone: | 4.10 release |
Component: | GDAL Support | Version: | 4.8 |
Severity: | normal | Keywords: | |
Cc: |
Description
The following issues should be handled in msOGRShapeToWKT. 1. Support for converting multilinestrings 2. Support for converting multipoints 3. USE_POINT_Z_M should be taken into account instead of setting Z value to 0 If USE_POINT_Z_M is not definied the function should create 2D wkt-s. Tamas Szekeres
Change History (6)
comment:2 by , 18 years ago
Status: | new → assigned |
---|
Yes, that is possible though I think the focus should be on fixing it in 4.9. I think the changes would only be retrofit into 4.8 if there was evidence the lack was causing significant problems to users. Is it causing you significant problems? Or are you just pushing for completeness for ... completeness sake?
comment:3 by , 18 years ago
Yes, I am writing an application that makes it possible to copy and paste features to and from the clipboard, and I would like to replace my own WKT solution to the upcoming WKT implementation. Tamas
comment:4 by , 18 years ago
Milestone: | → 4.10 release |
---|
comment:5 by , 18 years ago
This is also somewhat related to Bug 1891 related to going from WKT to shapes.
comment:6 by , 18 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Tamas, I have implementd support for multipoint and multiline converstion to WKT in the OGR code. This was already in the GEOS version of the code though I fixed a few mapgeos.c quirks today too (see bug 1897 if that is of interest). I have *not* added support for Z/M values in the vertices. One reason I am hesitant to is that it is a fair amount of fiddling in the code. The other, more compelling reason is that currently mapserver has no way to distinguish between 2D and 3D features so all of a sudden we would end up producing WKT with the Z value even if it is always zero. This will make various tests break, and may cause other problems for folks trying to insert the WKT into databases that don't support this extension. So for now, I'd like to avoid this change. If you still feel it is important please open a new bug report specifically addressing the Z/M issues. BTW, the GEOS WKT translation (in mapserver) code also does not support 3D geometries, and the Simple Features Revision Working Group is working up an incompatible WKT represtnation for 3D and 4D geometries.
Note:
See TracTickets
for help on using tickets.