[postgis-devel] Re: [postgis-users] PointM, PolyLineM, PolygonM, ...

[strk at refractions.net]

On Sat, Sep 25, 2004 at 04:21:25PM -0400, Christoph Spoerri wrote:
> 
> On Friday 24 September 2004 04:35, strk at refractions.net wrote:
> > On Thu, Sep 23, 2004 at 10:55:52PM -0400, Christoph Spoerri wrote:
> > > just to add my thoughts here, since I'm interested in the M 'coordinate'.
> > >
> > > I also believe that we should keep the positions of the coordinates the
> > > same. Otherwise, we would need to store all this information in some
> > > place (geometry_column ?) which can become out-of-sink sooner or later.
> > > So, I would favour the schematics X,Y,Z,M (3D) and X,Y,M (2D) if we have
> > > measures.
> >
> > mmm.. this is confusing. postgis has 2d/3d/4d, shapefile has
> > Type,TypeM,TypeZ. what do you mean by 'keeping position the same' ?
> 
> I meant that M would always be in the last position. Sorry for the confusion.
> 
> >
> > > With regard to importing shapefiles:
> > > 1) TypeM -> x,y,m (option b)
> > > 2) TypeZ -> x,y,z,m (option b, since we don't know if M is actually
> > > populated or not)
> >
> > again, if you want to keep the position the same number 2) should become
> > x,y,m,z (otherwise m would sometimes be 2nd, simetime 3rd....)
> >
> > > Exporting to shapefiles:
> > > 3) 3D -> TypeZ
> > > 4) 2D -> TypeM (let ESRI carry the waste)
> >
> > Note that 3) gives ESRI a waste, as TypeZ shapefile is X,Y,M,Z
> > and 4) does not need waste (ESRI has X,Y - Type)
> >
> 
> I checked the ESRI shapefile documentation (dated 1998). The TypeZ is defined 
> as X,Y,Z,M (page 15).

You're right. Sorry for the confusion.
Still 4 wastes nothing (-> Type) while 3 does (M is undefined).

> 
> > > Now, would it be possible to have more specific flags for the geometry
> > > type? I would see something like 2D (X,Y),  2DM (X,Y,M), 3D (X,Y,Z) and
> > > 3DM (X,Y,Z,M). This would make exporting a bit easier.
> >
> >  * LWGEOM types are an 8-bit char in this format:
> >  *
> >  * BSDDtttt
> >  *
> >  * WHERE
> >  *    B = 16 byte BOX2DFLOAT4 follows (probably not aligned) [before SRID]
> >  *    S = 4 byte SRID attached (0= not attached (-1), 1= attached)
> >  *    DD = dimentionality (0=2d, 1=3d, 2= 4d)
> >  *    tttt = actual type (as per the WKB type):
> >
> > We could interpret DD as:
> > 	ZM (has Z, has M)
> > 	01 would have M but no Z, M will be in 3rd position
> > 	10 would have Z but no Z, Z will be in 3rd position
> > 	11 would have both M and Z, Z will be in 3rd position, M in 4th
> >
> > All functions making use of Z or M values should extract their value
> > trough a function or macro to hide this.
> >
> > What do you think ?
> 
> This would work great and covers all the possiblities.
> How would the dimension 
> be reported for the geometry? Should we have a 4D? Or just report dimension 
> based on spatial coordinates (x,y,z)? 

We currently have 4d, which is encoded as XYZM.
Problem is just whether 3d is XYZ or XYM.

> I could see the following functions (if they aren't implemented yet):
> bool hasMeasure(unsigned char type)
> int hasDimension(unsigend char type)  - this would return 2D or 3D, depending 
> if there's a Z value or not.

int ndims(unsigned char type) // 2,3,4 - needed for point size computation
bool hasM(unsigned char type) 
bool hasZ(unsigned char type)

structures should be expanded to be POINT, POINTM, POINTZ, POINTZM.

> 
> With regard to the shapefile conversions:
> Type < -- > DD = 00
> TypeM < -- > DD = 01
> TypeZ  < -- > DD = 11 (since we don't know if M is populated in the shapefile)
> TypeZ <-- DD = 10

DD==ZM.
Yes. It sounds. Choice between final two would have a command line switch...
Now the big work is going throug the whole LWGEOM codeset to add knowledge
about ZM=01 case.

--strk;