[Geoserver-users] Rounding error with WPS

Dear all,

I was doing some tests with WPS and I am wondering if there is a rounding error in processes or maybe I am doing something totally wrong.

I took a very simple geometry like this one POINT(12 42)
Then apply a JTS:Buffer with several distance ranging from 1 to 0.000000001
Then I took the resulting geometry, a polygon of course, and used JTS:Centroid on it. It never returned POINT(12 42), I always got a decimal number that was very near to it.

I tried the same process on PostGIS, running

SELECT ST_ASTEXT(ST_BUFFER(ST_GEOMFROMTEXT(‘POINT(12 42)’),distance));

Saved the output to a text file and used it with this other statement:

SELECT ST_ASTEXT(ST_CENTROID(ST_GEOMFROMTEXT(‘POLYGON((…))’)));

Of course with distance ranging in the same interval.

It always returned POINT(12 42)

I know that libraries on the background are totally different, GeoServer is built on GeoTools while PostGIS is built on Geos, but again I wonder why such difference.

Is this the expected behaviour?

Thanks for your attention and patience

Stefano


41.95581N 12.52854E

http://www.linkedin.com/in/stefanoiacovella

http://twitter.com/#!/Iacovellas

The libraries are not that different, GEOS is a port of JTS after all.
You may wish to ask on the JTS mailing list for details on how buffer and centroid can be used.

···

Jody Garnett

On Tue, Mar 4, 2014 at 8:03 AM, Stefano Iacovella <stefano.iacovella@anonymised.com> wrote:

Dear all,

I was doing some tests with WPS and I am wondering if there is a rounding error in processes or maybe I am doing something totally wrong.

I took a very simple geometry like this one POINT(12 42)
Then apply a JTS:Buffer with several distance ranging from 1 to 0.000000001
Then I took the resulting geometry, a polygon of course, and used JTS:Centroid on it. It never returned POINT(12 42), I always got a decimal number that was very near to it.

I tried the same process on PostGIS, running

SELECT ST_ASTEXT(ST_BUFFER(ST_GEOMFROMTEXT(‘POINT(12 42)’),distance));

Saved the output to a text file and used it with this other statement:

SELECT ST_ASTEXT(ST_CENTROID(ST_GEOMFROMTEXT(‘POLYGON((…))’)));

Of course with distance ranging in the same interval.

It always returned POINT(12 42)

I know that libraries on the background are totally different, GeoServer is built on GeoTools while PostGIS is built on Geos, but again I wonder why such difference.

Is this the expected behaviour?

Thanks for your attention and patience

Stefano


41.95581N 12.52854E

http://www.linkedin.com/in/stefanoiacovella

http://twitter.com/#!/Iacovellas


Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk


Geoserver-users mailing list
Geoserver-users@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

2014-03-04 8:40 GMT+01:00 Jody Garnett <jody.garnett@anonymised.com>:

The libraries are not that different, GEOS is a port of JTS after all.
You may wish to ask on the JTS mailing list for details on how buffer and
centroid can be used.

Hi Jody,

thanks for the reply.
Yep Geos is a port but, also but non only because it is coded in C, the
implementation may be sligtly different.
Could it be due to different internal representation of coordinates?

Cheers,

Stefano

---------------------------------------------------
41.95581N 12.52854E

http://www.linkedin.com/in/stefanoiacovella

http://twitter.com/#!/Iacovellas

On Tue, Mar 4, 2014 at 8:40 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:

The libraries are not that different, GEOS is a port of JTS after all.
You may wish to ask on the JTS mailing list for details on how buffer and
centroid can be used.

Jody is spot on, aks on the JTS mailing list.
And yeah, I can confirm it's not specific to WPS, here is a sample self
contained program:

import com.vividsolutions.jts.geom.Geometry;
import com.vividsolutions.jts.geom.Point;
import com.vividsolutions.jts.io.ParseException;
import com.vividsolutions.jts.io.WKTReader;

public class BufferUnbuffer {

    public static void main(String args) throws ParseException {
        Geometry point = new WKTReader().read(" POINT(12 42)");
        Geometry buffer = point.buffer(0.0001);
        Point centroid = buffer.getCentroid();
        System.out.println(centroid);
    }
}

The output is: POINT (12 41.99999999999999)

If I had to venture a guess, this is due to Java using IEEE floating point
numbers to the letter,
whilst C compilers have them use whatever precision is available in the
native CPU, and if memory
serves me right, this results in more precision bits added to the
computation (80bits vs 64bits)

Hum... according to this page, Java can still perform calculations with 80
bits, but the final
representation is 64:
http://en.wikipedia.org/wiki/Strictfp

Cheers
Andrea

--
== Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information ==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

Note you can also mess with the precision model JTS uses for calculations (in part to workaround floating point arithmetic limitations).

···

Jody Garnett

On Tue, Mar 4, 2014 at 6:58 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Tue, Mar 4, 2014 at 8:40 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:

The libraries are not that different, GEOS is a port of JTS after all.
You may wish to ask on the JTS mailing list for details on how buffer and centroid can be used.

Jody is spot on, aks on the JTS mailing list.
And yeah, I can confirm it’s not specific to WPS, here is a sample self contained program:

import com.vividsolutions.jts.geom.Geometry;
import com.vividsolutions.jts.geom.Point;
import com.vividsolutions.jts.io.ParseException;
import com.vividsolutions.jts.io.WKTReader;

public class BufferUnbuffer {

public static void main(String args) throws ParseException {
Geometry point = new WKTReader().read(" POINT(12 42)");
Geometry buffer = point.buffer(0.0001);
Point centroid = buffer.getCentroid();
System.out.println(centroid);
}
}

The output is: POINT (12 41.99999999999999)

If I had to venture a guess, this is due to Java using IEEE floating point numbers to the letter,
whilst C compilers have them use whatever precision is available in the native CPU, and if memory
serves me right, this results in more precision bits added to the computation (80bits vs 64bits)

Hum… according to this page, Java can still perform calculations with 80 bits, but the final
representation is 64:
http://en.wikipedia.org/wiki/Strictfp

Cheers
Andrea

== Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information ==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it


2014-03-04 8:58 GMT+01:00 Andrea Aime <andrea.aime@anonymised.com>:

If I had to venture a guess, this is due to Java using IEEE floating point
numbers to the letter,
whilst C compilers have them use whatever precision is available in the
native CPU, and if memory
serves me right, this results in more precision bits added to the
computation (80bits vs 64bits)

Hum... according to this page, Java can still perform calculations with 80
bits, but the final
representation is 64:
http://en.wikipedia.org/wiki/Strictfp

Thanks Andrea, it makes sense, I will try to search some more hints on JTS
list.

Cheers,

Stefano

---------------------------------------------------
41.95581N 12.52854E

http://www.linkedin.com/in/stefanoiacovella

http://twitter.com/#!/Iacovellas