[postgis-users] PointM, PolyLineM, PolygonM, ...

[Christoph Spoerri]

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.

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)

Exporting to shapefiles:
3) 3D -> TypeZ
4) 2D -> TypeM (let ESRI carry the waste)

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.

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