[postgis-devel] Canonical binary form AND WKB

[strk at refractions.net]

Just a note: I've made asText() output SRID=<srid> as well.
I don't see the point of being OGC conformant in the lack
of SRID and not in the number of dimensions...

At least we now have an HEXEWKB and an EWKT both containing
the same information (apart from lost of precision in EWKT).
What is missing for 'consistency' is a binary EWKB storing
SRID. If we add a SRID to EWKB we can use that as canonical
binary instead of native LWGEOM...

The next problem would be being OGC strict, which might be 
addressed more cleanly starting form a 'consistent' point.

--strk;

On Mon, Dec 20, 2004 at 01:48:46PM +0100, strk at refractions.net wrote:
> On Mon, Dec 20, 2004 at 01:26:30PM +0100, Markus Schaber wrote:
> > Hi, all,
> > 
> > On Fri, 17 Dec 2004 19:28:53 +0100
> > strk at refractions.net wrote:
> > 
> > > > > Another question is how to distinguish between an OGC WKB 
> > > > > (extended or not) and a canonical form, which are currently 
> > > > > both of type bytea. 
> > > > 
> > > > The only option I can think of would be to change the canonical form endian
> > > > identifiers from 0x00/0x01 to something like 0x80/0x81; then if the first
> > > > byte > 0x80 then we know we are dealing with canonical form, otherwise we
> > > > assume it is (E)WKB. Having said that, is it possible to tell the difference
> > > > between EWKB and WKB?
> > > 
> > > I agree with Markus actually... if OGC will extend WKB we'll end up
> > > with bad conflicts between our extension and their extension.
> > > We'd better leave WKB forms driven by OGC and just use byte casts
> > > and _recv/_send for out own extensions.
> > > 
> > > This would mean *dropping* EWKB support as a whole and document
> > > canonical binary form for clients willing to support that.
> > > Also the same thing should be done with EWKT in GeometryFromWKT().
> > 
> > You should notice that the client does not really lose any functionality
> > this way, as (s)he always can call geometry_send(), geometry_receive(),
> > geometry_in() and geometry_out() explicitly when needed. The only
> > difference is that he has to parse the new canonical rep instead of
> > EWKT/EWKB.
> 
> You can't directly call geometry_receive(), as it uses internal datatypes.
> I've provided bytea::geometry cast for this purpose.
> 
> > But usually, clients will be either plain OpenGIS (and then expect plain
> > WKT/WKB using GeometryFromText et al), or will be PostGIS aware and rely
> > on the canonical representations created by PostgreSQL implicitly.
> 
> See also my latest proposal of making EWKB==native_LWGEOM
> 
> --strk;
> 
> > 
> > Markus
> > -- 
> > markus schaber | dipl. informatiker
> > logi-track ag | rennweg 14-16 | ch 8001 zürich
> > phone +41-43-888 62 52 | fax +41-43-888 62 53
> > mailto:schabios at logi-track.com | www.logi-track.com
> > _______________________________________________
> > 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