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

strk at refractions.net strk at refractions.net
Mon Sep 27 02:05:35 PDT 2004


I forgot to mention another problem:
is 'POINT(0 0 0)' a PointZ or a PointM ?
In other words, how to propagate ZM flags to text format ?
And what about OGC WKB ?
--strk;

On Mon, Sep 27, 2004 at 09:53:04AM +0200, strk at refractions.net wrote:
> 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;
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel



More information about the postgis-users mailing list