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

[Christoph Spoerri]

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).

> > 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)? 
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.

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

>
> > Christoph
> >
> > FYI.
> > I also check how Oracle handles 3D and measures. Here's a quick summary:
> > they have also x,y,z,m schematic. In the SDE_GTYPE variable they store
> > the dimension of the geometry (2,3,4) as well as the which position holds
> > the measure value for LRS (3 or 4). The SDe_GTYPE is stored along with
> > the geometry since it also contains the geometry type (point, line, etc.)
> >