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

[Ralph Mason]

Mark Cave-Ayland wrote: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...
>  
>
If the  bounding box is just an optimization so it doesn't need to be 
calculated for each row during a select where a non geometric index is 
being used, then a float representation should be just as good, so long 
as it's inflated enough that it covers the loss in precision.  Seems you 
always need to use a 'real' operator after a bounding box operation 
anyway.  Thus cutting the side in half appears to have no unwarranted 
side effects except perhaps a very small amount of false positive matches.

As for the 'dump' it is problematic, the WKB type field is 32 bits, so 
perhaps if the user has specified a column that isn't compliant a non 
compliant WKB (or not so well known binary) is dumped with some 
'extended' types.

The main idea here is, if a float or an int32 high enough resolution for 
the application, why force a dataset that is twice as large to be 
'compliant'.  The user knows best what they want to do, and how they 
want to do it. Using an a couple of  int32's I can specify any point on 
the planet down to a 10cm square area, what do the extra 8 bytes give me 
if i don't need them? I personally am looking at a dataset of about 14gb 
in shapefiles.  A little loss of resolution for speed is an option I 
would like to have, even if I'm non compliant.  I can also think of 
other examples like cad applications - integer data is probably preferable.

It seems that WKT would be an easy go-between for non compliant types. 
Then to get a 'confirming' table you can create a view that takes it 
between a WKT and then to a conformant WKB with a function that can 
create WKB from WKT and a set of flags saying the desired extended format.

>>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?
>  
>
Keeping room to extend a data format is always worthwhile. 

Ralph