[postgis-devel] loader/dumper - XY,XYM,XYZ,XYZM

strk at refractions.net strk at refractions.net
Wed Oct 6 03:39:58 PDT 2004


I've added a zmflag(geom) function returning the ZM flag
as a small integer:
	0 == 2d
	1 == 3dm
	2 == 3dz
	3 == 4d

The dumper uses this function to find out output Shapefile TYPE.
For postgis < 1.0.0 no functions were available to extract
dimensions so the '-d' switch was used and is still accepted.

The dumper checks postgis version. If postgis is < 1.0.0 it
will use the '-d' switch to decide, otherwise will call zmflag.

Now, for the loader case we need the user to specify postgis
version as no connection is made to the backend, so that information
can not be extracted. When it comes to loading TypeZ or TypeM
Shapefiles the output is different depending on intended postgis
destination, as postgis 1.0.0+ supports 3dm and 4d, so can
correctly handle TypeM and TypeZ.

Maybe we should embed in the loader output some checker function
making the transaction abort when the requirement is not matched.
It would be a plpgsql temporary function (I can't see another way).

As an alternative, new loader could drop support for old postgis
installation, at least as far as the 0_9_0 branch is maintained.

So. What do you think ?

	- adding a postgis-target command line switch (defaults to?)
	  and embedding a version checker for import time ?

	- dropping support for old postgis installation ?

--strk;

On Tue, Oct 05, 2004 at 11:07:41PM +0200, strk at refractions.net wrote:
> News from the ZM front (still awake due to nightmare bugs!).
> 
> Four functions help you modifying dimensions of geometries:
> 	force_2d(geom)
> 	force_3dm(geom)
> 	force_3dz(geom)
> 	force_4d(geom)
> 
> The function do not change the semantic of the geometries,
> rather they add or remove coordinate values.
> 
> Do you think a swapzm(geom) function would be useful ?
> For example, I have a POINT(1 2 3) and want to change it
> into a POINTM(1 2 3). Force_3dm would make it a POINTM(1 2 0).
> 
> force_3dm(swapzm(force_4d('POINT(1 2 3)'))) will do what I need:
> 	force_4d  --> 'POINT(1 2 3 0)'
> 	swapzm    --> 'POINT(1 2 0 3)'
> 	force_3dm --> 'POINTM(1 2 3)'
> 
> What do you think ?
> 
> --strk;
> 
> On Tue, Oct 05, 2004 at 09:53:26AM +0200, strk at refractions.net wrote:
> > Ok. The ZM flags are now handled as for internal representation.
> > If you have 3d or 4d data already within LWGEOM you'll probably
> > need a dump/restore. Internal storage size is the same, but two
> > bits gets interpreted differently (old:DD, new:ZM)
> > 
> > 	DD 	ZM
> > 2d	00	00
> > 3d	01	10|01
> > 4d	10	11
> > 
> > Old 3d geoms will be considered XYM.
> > Old 4d geoms will be considered XYZ (and will be messed up in coordinates).
> > 
> > The summary(geometry) function show all present flags for each geometry
> > and subgeometry (ZMBS).
> > 
> > Creation:
> > 
> > WKT:
> > 	Type(0 0)	<=> TYPE
> > 	Type(0 0 0)	<=> TYPEZ
> > 	Type(0 0 0 0)	<=> TYPEZM
> > 	TypeM(0 0 0)	<=> TYPEM
> > 
> > WKB:
> > 	#define WKBZOFFSET 0x80000000
> > 	#define WKBMOFFSET 0x40000000
> > 	WARNING ! new WKB input is incompatible with previous version
> > 	where 3D flag was current WKBZ and 4d flag was current WKBM
> > 	This means that if you now use an OLD 4d WKB to create
> > 	a NEW geometry it will be interpreted as TYPEM (3dimensions)
> > 	thus corrupting the output.
> > 
> > Questions ?
> > --strk;
> > 
> > On Mon, Oct 04, 2004 at 11:22:31AM +0200, strk at refractions.net wrote:
> > > The adt work is on its way. We now have an LWGEOM abstract data type
> > > with deserialize/serialize/clone/release functionalities.
> > > 
> > > The GEOS<->POSTGIS conversion has been fixed to keep geometry structure,
> > > and the summary() function has a new format for better debugging.
> > > 
> > > Before going on with constructurs I think it's important to decide
> > > what to do with hasM, hasZ flags.
> > > 
> > > My idea was to use two flags so to support:
> > > 	XY 	- hasM=false hasZ=false
> > > 	XYM	- hasM=true hasZ=false
> > > 	XYZ	- hasM=false hasZ=true
> > > 	XYZM	- hasM=true hasZ=true
> > > 
> > > This would allow for space saving in the db and better semantic
> > > specification.
> > > 
> > > In order to keep semantic in input/output WKT functions we might 
> > > add a <GEOM>M type as a custom extension:
> > > 
> > > 	POINT(1 2) 	<--> POINT
> > > 	POINT(1 2 3)	<--> POINTZ
> > > 	POINT(1 2 3 4)	<--> POINTZM
> > > 	POINTM(1 2 4)	<--> POINTM
> > > 
> > > Comments ?
> > > 
> > > --strk;
> > > _______________________________________________
> > > postgis-devel mailing list
> > > postgis-devel at postgis.refractions.net
> > > http://postgis.refractions.net/mailman/listinfo/postgis-devel
> > _______________________________________________
> > postgis-devel mailing list
> > postgis-devel at postgis.refractions.net
> > http://postgis.refractions.net/mailman/listinfo/postgis-devel
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel



More information about the postgis-devel mailing list