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:1 by szekerest, 18 years ago

Does this problem candidate to be fixed at 4.8.1 ?

Tamas

comment:2 by fwarmerdam, 18 years ago

Status: newassigned
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 szekerest, 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 fwarmerdam, 18 years ago

Milestone: 4.10 release

comment:5 by fwarmerdam, 18 years ago

This is also somewhat related to Bug 1891 related to going from WKT to shapes.

comment:6 by fwarmerdam, 18 years ago

Resolution: fixed
Status: assignedclosed
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.