[postgis-devel] about interger storage

Martin Davis mbdavis at refractions.net
Mon May 12 09:10:55 PDT 2008


One issue I can see with that idea is that you would then have to ensure 
that all your features had an extent which was limited to the size of 
the offsets (i.e. you wouldnt' be able to have a feature with high 
relative accuracy that spanned your entire coordinate space). This would 
imply that the space of features was not closed over some spatial 
operations, too (eg consider the union of two features which each had an 
extent of the offset space, but displaced from one another)

There's also the issue of requiring arithmetic operations to materialize 
geometry.

I think you have to state what goal you would be trying to solve with 
this scheme. Is it data compression or data precision? The two are 
orthogonal, I think.


Paul Ramsey wrote:
> Just to be the contrarian, can't I use a system of start point +
> offsets to obtain both high relative accuracy and positioning to
> within a mm?
>
> Of course, the same trick can be used in db, to even greater effect, so...
>
> P.
>
> 2008/5/9 Martin Davis <mbdavis at refractions.net>:
>   
>> Further to this issue:
>>
>> Perhaps the most important reason to choose double-precision storage
>> over integer storage is this:
>>
>> DP provides substantially more bits of precision for representing
>> values. Integer (32-bit) gives about 8 decimal digits of precision. This
>> is roughly enough to store values over a 1000 km range to mm precision.
>> DP on the other hand provides 16 decimal digits of precision - more than
>> enough to map the globe to mm precision.
>>
>> 1000 km to 1 mm may sound like a lot, but it isn't really. I work in a
>> jurisdiction which barely fits in this range. In many of our databases
>> we like to keep an extra digit or two of precision to give some room for
>> mathematical manipulation - so we need more than 9 digits.
>>
>> You may also say that 1 mm in 1000 km is much more accuracy than any
>> real data provides. That is probably true, but the key issue is the
>> relative accuracy requirements. The datastore has to provide a
>> coordinate space which can support the maximum required relative
>> accuracy. And it's quite common to have data which has fairly high
>> accuracy relative to nearby features. (Or at least, a high relative
>> precision is required in order to distinguish feature coordinates)
>>
>> Martin Davis wrote:
>>     
>>> Why do you think integer storage will provide better accuracy,
>>> integrity, and speed?
>>>
>>> - accuracy is a function of your data
>>> - if you are concerned about *precision*, then just having the database
>>> automatically force everything into a fixed precision model doesn't
>>> really address all concerns. You really need to round your data
>>> yourself, and deal explicitly with any data collapse issues
>>> - speed - well, in theory yes, since you are shipping half the data over
>>> the wire. But have you measured this? There's a lot more involved than
>>> raw wire speed.
>>>
>>> A major downside of integer storage IMO is the need to specify your data
>>> extent explicity up front. And the need to constantly transform between
>>> integer and the external coordinate system (in floating point) is a
>>> major pain.
>>>
>>> xie jiong wrote:
>>>
>>>       
>>>> Hi everyone:
>>>> Does postgis support interger storage? We are thinking about
>>>> conversion from floating point real–world units to positive integer
>>>> units for storage in the database to provide better data accuracy,data
>>>> integrity,and processing speed as ArcSDE do. Are there any possible
>>>> and difficulties of doing so? Dose Geos support it? As far as I know,
>>>> spatial databases such as Oralce spatial don't use it but I think it
>>>> will really improve performance and low down space. Any idea?
>>>> Jiong
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> postgis-devel mailing list
>>>> postgis-devel at postgis.refractions.net
>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>
>>>>
>>>>         
>>>       
>> --
>> Martin Davis
>> Senior Technical Architect
>> Refractions Research, Inc.
>> (250) 383-3022
>>
>> _______________________________________________
>> 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
>>     

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022




More information about the postgis-devel mailing list