[geos-devel] Re: [Jts-topo-suite-user] Improve accuracy in signedArea

Martin Davis mtnclimb at telus.net
Fri Oct 7 12:55:04 EDT 2011

Yes, agreed, it would be good if this found it's way into GEOS and PostGIS.

(cc-ing geos-devel so they can get on it!)

On 10/6/2011 11:42 PM, Peter Hopfgartner wrote:
> On 10/06/2011 06:33 PM, Martin Davis wrote:
>> (...)
>>>> I suppose to provide even more accuracy the largest x value (in 
>>>> absolute value) could be used as the constant offset.
>>> From an heuristic POV I would guess, that the most accurate result 
>>> could be calculated, when the origin is placed in the center of mass 
>>> or center of the bounding box, since that would keep the coordinates 
>>> as small as possible.
>>> As I understand it, that would require to first calculate that 
>>> center estimate, which has at least the cost to loop through all 
>>> coordinates.
>>> From the rather synthetic test case, which I used, it is difficult 
>>> to have real numbers of the impact on the accuracy of the result on 
>>> that. If you think that there might be some benefit, it might make 
>>> sense to use real data, as in TIGER, and compare the result obtained 
>>> with floating points to the result obtained with an arbitrary 
>>> precision float library, like http://www.apfloat.org.
>>> Having the origin in the first coordinate allows to drop the first 
>>> term, since x1 is zero.
>> As you say, it's probably not worth the effort to make this minor 
>> improvement in accuracy.
>> I had thought about using higher-precision computation to check the 
>> area results.  I would use the DD (DoubleDouble) class which is now 
>> in JTS - it provides 106 bits of precision.
>> And as you say, more real-world examples would be better for 
>> testing.  I might try and do this - although it doesn't seem like 
>> anyone should be relying on the area computation to be "perfectly" 
>> accurate.  Or am I wrong on this?  How did you come to notice that 
>> the area was not as accurate as it could be?
> I agree that nobody should rely on exact area calculations. We had a 
> minor problem, when we did things like splitting polygons in PostGIS. 
> We compared the area of the parts to the area to the parent polygon 
> ane the difference was bigger then expected. Having a look at GEOS I 
> saw that it used the same algorithm as PostGIS (or vice versa) and 
> from there I decided to start from JTS. Now I like to apply tha same 
> on GEOS and PostGIS.
> http://postgis.refractions.net/pipermail/postgis-devel/2011-February/011715.htm 
> was a first version of this  patch.
> Peter
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2dcopy2
> _______________________________________________
> Jts-topo-suite-user mailing list
> Jts-topo-suite-user at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
> No virus found in this message.
> Checked by AVG - www.avg.com <http://www.avg.com>
> Version: 10.0.1410 / Virus Database: 1520/3941 - Release Date: 10/06/11
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/geos-devel/attachments/20111007/5c7f205e/attachment.html

More information about the geos-devel mailing list