[postgis-devel] Inconsistency in Measured Geometries

[Markus Schaber]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, Strk,

strk at refractions.net schrieb:

> Implementation choice as been taken looking at backward compatibility.
> Old postgis supported 2d/3d, so their EWKT are compatible with that.
> The 'M' has been added for the sole purpose of distinguish between
> 3dZ and 3dM geoms. More consistency in general would be:
> 	POINT
> 	POINTM
> 	POINTZ
> 	POINTZM
> As both Z and M are nore *real* dimensions, just an additional info
> on each coordinate. 

Well, but the Z dimension may change to be a real geometric dimension in
the future, while I cannot imagine this for measures.

So I think it could be justified to mark all measured geometries
equally. (I can even think of 1D+M geometries, e. G. in telemetrics. One
has the number of kilometers driven so far, or the time, and the
measured value. But I clearly have too much phantasy at night, and I
think this is not necessarily something I would call a GIS application.)

Maybe we should wait for the feedback we get from the OpenGIS meeting
mentioned by Martin and Paul.

>>I did not look at the C code yet, but at least on the Java side it would
>>make the code a little simpler. I also think that this consistency may
>>be a plus point for getting OpenGIS approval of EWKT. But, on the other
>>hand, it may be too late to change this in the implementation,
>>especially as RC1 is out.

> How does simplicity come from the M addition ?

While working on the code after writing this email, I restructured it a
little, and now the the code difference is very small.

My new java Point implementation has four attributes (X, Y, Z, M) and
two additional attributes (dimension and haveMeasure) decide which of
them are present and have a meaning.

I'm not shure whether it is worth the effort to implement the XY, XYZ
and XYM variants of Point. This would save RAM for the applications
using them. But, on the other hand, this would hurt backwards
compatibility, at least for Code that accesses Point.Z attribute
directly instead via the getZ()/setZ() methods. Maybe those attributes
should have never been public in the first place, but now, it's too late.

Expect my first release on this list tomorrow in the afternoon.

Markus



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB6vyNOVWsnapT9i0RAraDAKCsYkYa3vkC1PW5auf4hO+lG/AV5QCgtwMM
v9uT70Zy/yUK3/BswvSzU2o=
=/Yig
-----END PGP SIGNATURE-----