[postgis-devel] [MetaCRS] Inf in projection results

[Chris Hodgson]

Ok, sure, IEEE floating point standard provides some meaning to inf 
values - but we can't do much geometrically with them... area? 
perimeter? buffer? overlays? In this case PostGIS IS the upstream 
library and we have to handle them as errors.

I'm still for applying Magnus' patch.

Chris

Paul Ramsey wrote:
> So, given this, we can expect our proj to always potentially send us
> Infs. And perhaps theoretically we should pass them on to other
> libraries expecting that "do the right thing" is a question that is
> resolved best closest to the problem at hand. In the short term we're
> still left with a crasher in GEOS when that happens, so I think
> Magnus' patch at writ is still the best way forward for now.
>
> P.
>
> On Tue, May 24, 2011 at 1:03 PM, Paul Ramsey <pramsey at opengeo.org> wrote:
>   
>> ---------- Forwarded message ----------
>> From: Martin Desruisseaux <martin.desruisseaux at geomatys.fr>
>> Date: Tue, May 24, 2011 at 11:34 AM
>> Subject: Re: [MetaCRS] Inf in projection results
>> To: metacrs at lists.osgeo.org
>>
>>
>> Le 24/05/11 19:36, Paul Ramsey a écrit :
>>     
>>> And following on with a non-projection-related query: if you as a
>>> geometry processing routine got handed a geometry with Inf
>>> coordinates, what would you do? Give up? Coerce them into something
>>> else?
>>>       
>> I would suggest to keep the infinite values. IEEE arithmetic usually
>> do the right thing with infinities (x/Inf = 0 if x!=Inf, etc.), and
>> Java Math functions are properly defined (atan(Inf) = 90°, etc.).
>>
>> In Geotoolkit.org, we have allowed Map Projection to returns infinite
>> values (e.g. 90°N in a Mercator projection = Infinity, and ensuring
>> that the conversion back to EPSG:4326 give 90°N). In my point of view
>> this actually make the handling of geometries easier. By removing as
>> much special cases of the like "if (x < threshold)" as possible (which
>> were used in order to avoid divisions by zero in the legacy GeoTools
>> referencing code), users have reported that the reprojections were
>> smoother.
>>
>> Regards,
>>
>>    Martin
>>
>> _______________________________________________
>> MetaCRS mailing list
>> MetaCRS at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/metacrs
>>
>>     
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>