[postgis-devel] 1.3.4rc1

[Courtin Olivier]

On Oct 28, 2008, at 6:49 PM, Mark Cave-Ayland wrote:

> Courtin Olivier wrote:
>
>> Well the point (to my opinion) is to be able to send to client only  
>> the amount of data really
>> needed.
>> Generalisation could be a way (ST_SImplify, ST_SnapToGrid), and  
>> decimal precision
>> an another (and sometime both of them)
>> So i keep thinking that's the most usefull way to handle that for  
>> PostGIS users is a decimal
>> precision approach (%*.f) rather than a significant digits (%*.g)
>
> True, but then this throws up the issue in the regression tests  
> whereby different platforms have
> different precisions in terms of decimal places. The only thing we  
> know that can control this is
> significant figures - for example, even if the user specifies a  
> precision of 15 then we know for a
> fact that the number doesn't contain this information, and the  
> problem gets worse the larger
> the numbers.

Humm maybe it's a naive approach, but what about DECIMAL_DIG ?
It 's supposed to do the job to give a limit for decimal places precison
Cf <http://www.opengroup.org/onlinepubs/009695399/basedefs/float.h.html>

So what about something like that:

#ifndef DECIMAL_DIG
#define DECIMAL_DIG 10
#endif

#define MAX_DOUBLE_PRECISION DECIMAL_DIG

And then use %*.f as previously

> So this only leaves the question of would changing the meaning of  
> the function in this way cause
> you great problems? Given that most data should be within a similar  
> area, I think specifying a
> slightly different fixed precision should give you a similar result  
> as you have now.

Problem mainly occurs when i begin to reproject with PostGIS, for  
example:

SELECT st_asgeojson(transform(geometryfromtext('POINT(1000 2300000)',  
27582), 4326), 5);
  {"type":"Point","coordinates":[-5.61668,47.42663]}

In this case, i 'know' that output will be in Decimal Degrees, so 5  
decimal digits enough.


--
Olivier