[prev in list] [next in list] [prev in thread] [next in thread]
List: geos-devel
Subject: [geos-devel] Re: [Jts-topo-suite-user] Improve accuracy in
From: Martin Davis <mtnclimb () telus ! net>
Date: 2011-10-07 16:55:04
Message-ID: 4E8F2EE8.6010505 () telus ! net
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@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
>
[Attachment #5 (text/html)]
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Yes, agreed, it would be good if this found it's way into GEOS and
PostGIS.<br>
<br>
(cc-ing geos-devel so they can get on it!)<br>
<br>
<br>
On 10/6/2011 11:42 PM, Peter Hopfgartner wrote:
<blockquote cite="mid:4E8E9F72.7040202@r3-gis.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
On 10/06/2011 06:33 PM, Martin Davis wrote:
<blockquote cite="mid:4E8DD877.6080209@telus.net" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
(...)<br>
<blockquote cite="mid:4E8D55D6.20707@r3-gis.com" type="cite">
<blockquote cite="mid:4E8CCB0D.4010208@telus.net" type="cite">
I suppose to provide even more accuracy the largest x value
(in absolute value) could be used as the constant offset.<br>
<br>
</blockquote>
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.<br>
As I understand it, that would require to first calculate that
center estimate, which has at least the cost to loop through
all coordinates.<br>
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 <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://www.apfloat.org">http://www.apfloat.org</a>.<br>
<br>
Having the origin in the first coordinate allows to drop the
first term, since x1 is zero.<br>
</blockquote>
As you say, it's probably not worth the effort to make this
minor improvement in accuracy.<br>
<br>
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.<br>
<br>
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?<br>
<br>
</blockquote>
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.<br>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://postgis.refractions.net/pipermail/postgis-devel/2011-February/011715.htm" \
>http://postgis.refractions.net/pipermail/postgis-devel/2011-February/011715.htm</a> \
> was a first version of this patch.<br>
<br>
Peter<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">------------------------------------------------------------------------------
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.
<a class="moz-txt-link-freetext" \
href="http://p.sf.net/sfu/splunk-d2dcopy2">http://p.sf.net/sfu/splunk-d2dcopy2</a></pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Jts-topo-suite-user mailing list
<a class="moz-txt-link-abbreviated" \
href="mailto:Jts-topo-suite-user@lists.sourceforge.net">Jts-topo-suite-user@lists.sourceforge.net</a>
<a class="moz-txt-link-freetext" \
href="https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user">https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user</a>
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<p class="avgcert" color="#000000" align="left">No virus found in
this message.<br>
Checked by AVG - <a moz-do-not-send="true"
href="http://www.avg.com">www.avg.com</a><br>
Version: 10.0.1410 / Virus Database: 1520/3941 - Release Date:
10/06/11</p>
</blockquote>
</body>
</html>
_______________________________________________
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic