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

strk at refractions.net strk at refractions.net
Fri Sep 24 01:35:39 PDT 2004 

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' ?

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

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

> 
> 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.)
> 
> 
> 
> On Thursday 23 September 2004 12:39, strk at refractions.net wrote:
> > On Thu, Sep 23, 2004 at 09:03:18AM -0700, Paul Ramsey wrote:
> > > Please bear in mind that there are other uses for the higher dimensions
> > > than Z and M. There could also be a time dimension (think of a GPS
> > > track, for example). I don't like the idea that we are setting up
> > > implicit uses for our higher dimensions (M shall always be the 4th
> > > entry, Z shall always be the 3rd entry!).
> > >
> > > I would rather anonymously fill out the higher dimensions using the
> > > least storage space and have any function that expects to operate on
> > > them sufficiently flexible to be pointed at the right coordinate space.
> > > So if have have a measured_point(<linstring>,<%>) function, it needs a
> > > third parameter, ordinate, to tell it which ordinate to look in for the
> > > measure. measured_point(<linestring>,<%>,<ordinate = 3|4>).
> >
> > This is a bigger problem then the one being discussed actually...
> > XYZ have well-defined semantics as for spatial handling, so
> > they should have well-known positions (IMHO).
> > For any other (non-spatial) coordinate I'm with you.
> >
> > So postgis should provide functions to retrive X,Y,Z or M(#).
> > Geometry flags should state not only number of dimensions, but
> > number of *spatial* dimensions AND number of *other* dimensions.
> >
> > Current (LWGEOM) API is far from ready for that.
> > Basic structures are POINT2D, POINT3D, POINT4D, where POINT4D have
> > x,y,z,m elements (in that order..)
> >
> > Anyway... to consider this issue in pgsql2shp changes, how
> > would you do ? I imagine the case in which you use XY spatial
> > coordinates and M in 3d geometries so you want to dump TypeM
> > using postgis Z as M value...
> >
> > --strk;
> >
> > > strk at refractions.net wrote:
> > > >On Thu, Sep 23, 2004 at 12:12:28PM +0200, Pierrick Brihaye wrote:
> > > >>Hi,
> > > >>
> > > >>strk at refractions.net a écrit :
> > > >>> Now that postgis supports up to 4 dimensions geometry, what do you
> > > >>>
> > > >>>think should be done ? My vision is this:
> > > >>>
> > > >>>Type  <-> geometry2d
> > > >>>TypeM <-> geometry3d
> > > >>>TypeZ <-> geometry4d
> > > >>>
> > > >>>What do you think ?
> > > >>
> > > >>How long shall we pay for ESRI's weird data model ? :-)
> > > >>
> > > >>IMHO, the 3rd dimension has well-known semantics : Z.
> > > >>
> > > >>Therefore, any other dimension should be considered as a 4th one.
> > > >>
> > > >>Any other thoughts ?
> > > >
> > > >I'm with you, but quetions are:
> > > >
> > > >1) how should we import TypeM shapefiles ?
> > > >	a) as x,y,Z,m // wasting Z space in postgis
> > > >	b) as x,y,z   // interpreting M as Z
> > > >
> > > >2) how should we import TypeZ shapefiles ?
> > > >	a) as x,y,z,m // respecting shapefile meanings
> > > >	b) as x,y,z,m // swapping M<->Z meaning
> > > >	c) as x,y,z   // discarding M
> > > >	d) as x,y,z   // using M, discarding Z
> > > >
> > > >3) how should we export geometry3d ?
> > > >	a) as TypeM // using M for Z values
> > > >	b) as TypeZ // wasting M space in shapefile
> > > >
> > > >3) how should we export geometry4d ?
> > > >	a) as TypeZ // respecting shapefile meanings (4th dim -> M)
> > > >	b) as TypeZ // swapping M<->Z meaning
> > > >
> > > >Does anyone see the light ?
> > > >I suppost some command line switches would do but finding an easy
> > > >interface is not straightforward ...
> > > >
> > > >--strk;
> > > >
> > > >>Regards,
> > > >>
> > > >>--
> > > >>Pierrick Brihaye, informaticien
> > > >>Service régional de l'Inventaire
> > > >>DRAC Bretagne
> > > >>mailto:pierrick.brihaye at culture.gouv.fr
> > > >>+33 (0)2 99 29 67 78
> > > >>_______________________________________________
> > > >>postgis-users mailing list
> > > >>postgis-users at postgis.refractions.net
> > > >>http://postgis.refractions.net/mailman/listinfo/postgis-users
> > > >
> > > >_______________________________________________
> > > >postgis-users mailing list
> > > >postgis-users at postgis.refractions.net
> > > >http://postgis.refractions.net/mailman/listinfo/postgis-users
> > >
> > > _______________________________________________
> > > postgis-users mailing list
> > > postgis-users at postgis.refractions.net
> > > http://postgis.refractions.net/mailman/listinfo/postgis-users
> >
> > _______________________________________________
> > postgis-users mailing list
> > postgis-users at postgis.refractions.net
> > http://postgis.refractions.net/mailman/listinfo/postgis-users
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users

More information about the postgis-devel mailing list