[postgis-devel] OGC WKB/T - PGIS EWKB/T

[strk at refractions.net]

On Wed, Dec 22, 2004 at 12:49:59PM -0000, Martin Daly wrote:
> strk,
> 
> I was just typing an e-mail to you when this one arrived.  I just knew
> that I should have started typing sooner (although Paul should hang his
> head in shame because I sent him the same thing eight months ago).
> 
> The attached document is an adopted (by electronic vote if I recall
> correctly) OGC spec that extends the WKB and WKT in SF-SQL etc, to 2.5D.
> For OGC members with OGC portal logins, the file can also be found here:
> http://portal.opengeospatial.org/files/?artifact_id=909
> 
> I hope that this takes some meat off your Christmas fire.

Very good Martin, thanks.

This does not change the situation described: we still
have a need for extension (M,ZM and SRID) and our extension
is still a superset of OGC. But it shifts the need for
separate OGC-only input/output routines.

On another front it specifies behaviour of Spatial Operators,
which must be implemented in GEOS/JTS in order to keep
OGC compliance.

--strk;

> 
> Regards,
> Martin
> 
> > -----Original Message-----
> > From: strk at refractions.net [mailto:strk at refractions.net] 
> > Sent: 22 December 2004 11:37
> > To: postgis-devel at postgis.refractions.net
> > Cc: Paul Ramsey
> > Subject: [postgis-devel] OGC WKB/T - PGIS EWKB/T
> > 
> > 
> > With help and support of Mark Cave-Ayland and Markus Schaber 
> > I've (conceptually) separated OGC-strict WKB and WKT formats 
> > from Postgis extended versions EWKB and EWKT.
> > 
> > Here is a clarification of the new status, in a format 
> > suitable for the postgis manual, below you'll find 
> > implementation notes.
> > 
> > ---8<----------------------------------------------------------
> > 
> > OGC formats only support 2d geometries, and the associated 
> > SRID is *never* embedded in the input/output representations.
> > 
> > Postgis extended formats are currently superset of OGC one 
> > (every valid WKB/WKT is a valid EWKB/EWKT) but this might 
> > vary in the future, specifically if OGC comes out with a new 
> > format conflicting with our extensions. Thus you SHOULD NOT 
> > rely on this feature!
> > 
> > Postgis EWKB/EWKT add 3dm,3dz,4d coordinates support and 
> > embedded SRID information.
> > 
> > Input/Output of these formats are available using the following
> > interfaces:
> > 
> > 	- OGC -
> > 	bytea WKB = asBinary(geometry);
> > 	text WKT = asText(geometry);
> > 	geometry = GeomFromWKB(bytea WKB, [SRID]); // will WARN on EWKB
> > 	geometry = GeometryFromText(text WKT, [SRID]); // will 
> > WARN on EWKT
> > 
> > 	- PGIS -
> > 	bytea EWKB = asEWKB(geometry);
> > 	text EWKT = asEWKT(geometry);
> > 	geometry = GeomFromEWKB(bytea EWKB);
> > 	geometry = GeomFromEWKT(text EWKT);
> > 
> > The "canonical forms" of a PostgreSQL type are the 
> > representations you get with a simple query (without any 
> > function call) and the one which is guaranteed to be accepted 
> > with a simple insert, update or copy. For the postgis 
> > 'geometry' type these are:
> > 
> > 	- Output -
> > 	binary: EWKB 
> > 	 ascii: HEXEWKB (EWKB in hex form)
> > 
> > 	- Input -
> > 	binary: EWKB
> > 	 ascii: HEXEWKB|EWKT
> > 
> > 
> > ---8<----------------------------------------------------------
> > 
> > A few notes about the implementation.
> > 
> > Since our WKT/WKB parsers are really *just* EWKT/EWKB parsers 
> > the implementation RELIES on the future that users SHOULD NOT 
> > RELY ON: superset nature of EWKT/EWKB in respect to WKT/WKB.
> > 
> > This means that the representations are always parsed as 
> > EWKT/EWKB and a second-step check is made for the presence of 
> > an embedded SRID or higher dimensions in the resulting 
> > geometry. When these are found the OGC-strict routines 
> > currently WARN the user about the fact that the corresponding 
> > extended input functions should be used. We could make that 
> > an ERROR instead, completely
> > *forbidding* EWKB/EWKT in OGC constructors functions.
> > 
> > Similarly, output functions are just LWGEOM to EKWT/EKWB 
> > converters, so the OGC-strict output procedures just *drop* 
> > higher dimensions and SRID before feeding the LWGEOM to them, 
> > obtaining a subset of EWKT/EWKB being WKT/EKB. 
> > 
> > As long as WKB/WKT remains a subset of EWKT/EWKB we don't 
> > have to worry about this, but in case they loose this nature 
> > we'll have to implement OGC-strict-only parsers/unparsers.
> > 
> > Finally, it has to be noted that all this layers of 
> > processing reduce the performance of input/outputs 
> > operations. Here is a 
> > table of input and output functions ordered by estimated 
> > speed (number of layers of processing).
> > 
> > 	- Input -
> > 
> > 	1 canon. ascii HEXEWKB
> > 	1 canon. ascii EWKT
> > 	1 GeomFromEWKT() - calls canon. ascii EWKT
> > 
> > 	2 canon. binary EWKB - converts to HEXEWKB first (can 
> > be improved)
> > 	2 GeomFromEWKB()  - calls canon. binary EWKB
> > 
> > 	3 GeomFromWKB()   - calls canon. binary EWKB, checks 
> > OGC conformance
> > 	3 GeometryFromText() - calls canon. ascii EWKT, checks 
> > OGC conformance
> > 	
> > 
> > 	- Output -
> > 
> > 	1 canon. ascii HEXEWKB
> > 	1 asEWKT()
> > 
> > 	2 canon. binary EWKB - converts HEXEWKB to binary (can 
> > be improved)
> > 	2 asEWKB() - calls canon. binary EWKB
> > 
> > 	3 asBinary() - drops SRID and ZM, calls canon. binary EWKB
> > 	3 asText() - drops SRID and ZM, calls asEWKT() 
> > 
> > 
> > There are also other issues that might be worth discussing, 
> > but I think we already have enough meat on the fire (as we 
> > say in Italy).
> > 
> > Merry Christmas !
> > 
> > --strk;
> > _______________________________________________
> > postgis-devel mailing list postgis-devel at postgis.refractions.net
> > http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >