USE_POINT_Z_M usability

Frank Warmerdam warmerdam at POBOX.COM
Fri Oct 19 12:00:34 EDT 2007


Tamas Szekeres wrote:
> Hi All,
> 
> I guess the usability of the USE_POINT_Z_M option is quite limited
> right now, and none of the binary distributions are distributed with
> this setting enabled.
> 
> In my opinion mapserver should work using the 3D data sources as well
> without having to recompile the source for this particular data type.
> 
> Moreover as looking into the code most of the additional activity is
> limited only to retrieve the additional elements into the additional
> fields of the shapeObj-s.
> 
> There have also been some memory corruption problems with some of the
> SWIG bindings when mapscript and mapserver were compiled with
> different USE_POINT_Z_M settings and the size of the shapeObj
> structure was different accordingly.
> 
> Shouldn't we instead get rid of this option and treat every shapes as
> 2D shapes (or 3D shapes if we want)?

Tamas,

I think that *at the least* we need to be able to read 3d/4d shapefiles
as 2d regardless of the USE_POINT_Z_M setting.  There is no reason not
to do this, and I'm shocked that isn't how things work now.

The USE_POINT_Z_M was introduced because folks demonstrated some
non-trivial performance differences when z and m are carried all
through the system.  I'm hesitant to sacrifice performance for these
rarely needed extra data values.  But I do find the way we handle
definitions like USE_POINT_Z_M dangerous as it is easy for them to
get missed when bindings are built.  Perhaps all the "mapscriptvars"
type defines should instead be put into an include file that gets
pulled in by map.h or something similar.  This might be less fragile.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org



More information about the mapserver-dev mailing list