[postgis-users] Light WeightLight Weight Geometry (LWGEOM)Proposal

[Mark Cave-Ayland]

Hi Ralph/Dave/Listers,

> Hi David,
> 
> This looks very nice to me. Remind me why anyone would want 
> to use the 
> 'full' geometry when this one is in place?

I agree. I think that having two internal GEOMETRY datatypes is more
than enough and it would appear that the new format supports all
existing functionality while being a lot more compact. At the same time
it would be a good excuse to go through the code and tidy up a lot of
things, for example the different functions used for indexed/non-indexed
operators. As a side note, it would be interesting to see if the format
would speed conversion to/from GEOS geometries.

> Anyhow a couple of suggestions:
> 
> Be able to use the extra bit to specify floats for a bounding box.  I 
> think this would almost always be a good optimization.
> A way to specify that the data is in floats not doubles.  
> Perhaps using 
> the extra space in the geometry type field.

I think the main reason for this is the the OGC spec specifies the use
of doubles so if PostGIS were to use floats then it would no longer be
compliant OGC compliant :(. I can also see more issues arising with
accuracy when converting between floats/doubles that would alter the
geometric data - for example what if I were to take a dataset using
double coordinates and transfer to a DB compiled to use float
coordinates? I'm guessing that at the moment, the pg_dump would have to
be in WKB format since this contains endian information required for
transferring across machines - so how would we indicate to the user that
their GIS data had been altered? Perhaps we do need to include endian
information in the type byte after all...

> Another Idea, use the spare bit to indicate an extended type byte 
> (coming after the type byte).
> 
> This could be something could have extra flags if present.
> 
> Bounding box data type
> Float bounding box
> Int16    bounding box
> Int32   bounding box
> 
> Data Type
> Float data
> int 16 data
> int32 data

Extensibility seems interesting. Was there a particular application that
you had in mind for this feature?

> Also, since I'm here -  in the beginning there would be lots of 
> LWGEOM->WKB->PostGIS GEOMETRY conversions, perhaps a direct
> LWGEOM->PostGIS GEOMETRY would be a nice little optimization.

Yes. It would be really nice to have everything use the new LWGEOM
internally and just have direct import/export filters as appropriate.
Going indirectly through WKB (while being quicker to program initially)
would seem to lack flexibilty and increase the chances of introducing
hard-to-catch errors in a two-stage conversion process.


Cheers,

Mark.

---

Mark Cave-Ayland
Webbased Ltd.
Tamar Science Park
Derriford
Plymouth
PL6 8BX
England

Tel: +44 (0)1752 764445
Fax: +44 (0)1752 764446


This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender. You
should not copy it or use it for any purpose nor disclose or distribute
its contents to any other person.