[postgis-devel] about interger storage

[xie jiong]

Davis: Why all your features must have extent which was limited to the size of  the offsets?

The formula looks like: 

Int X = truncate ((( X coordinate - false X ) * scale) + 0.5 )


0.5 is added to round off numbers. 



converted back to real coordinates with the following formula:

X coordinate = (( Int X / scale) + false X)

Because coordinates are often neither positive nor integer, we requires an 
offset distance (a false origin) to ensure numbers are positive and a minimum 
resolution multiplier (called the scale factor) to convert real numbers to integers.

A false origin can improve coordinate precision, especially for maps that  
cover a very small area. If we have data spaning ((2449499.9375,769499.9843) (2460501.3125,780500.3281)).
the fasle X could be 2400000 ( this need storage in metadata). This preserves the p
recision of the numbers when they are converted to integers.

32-bit positive integers is between 0 and 2147483647, this means the interger extent of a map or feature couldn't
exceed this. if we want to storage globe range data (about 0 to 40000000m) is enough if we use 1m precision, ist right?

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

Yes, need. may be: 
Get Int PostGeo from storage -> <<<convert to real PostGeo>>> ->Convert to Geos and Calculation ->Get the result and
convert bake to real PostGeo and return to client. 

If we could transmit Int PostGeo in Network, that would be efficient, but this needs client to convert back to real num.

Any idea?

Jiong







----- Original Message ----- 
From: "Martin Davis" <mbdavis at refractions.net>
To: "PostGIS Development Discussion" <postgis-devel at postgis.refractions.net>
Sent: Tuesday, May 13, 2008 12:10 AM
Subject: Re: [postgis-devel] about interger storage


> 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
> 
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel