Yes, you need to ensure the coordinates used to create a geometry match the
precision model specified for that geometry. This is done for performance
reasons, so that JTS doesn't have to create new coordinates just to force
them to be rounded. It's also because rounding coordinates can cause
geometries to become invalid, and the intention is that the client should
do this and be responsible for checking the validity of geometries. If the
rounding was done internally it's possible that Topology errors could occur
unexpectedly on apparently valid input.
Using WKT to do this is one way, but it's inefficient. You're better off
using the PrecisionModel.makePrecise method when creating the coordinates.
And if the geometry already exists, clone it and use
GeometryPrecisionReducer.
On Mon, Mar 2, 2015 at 9:44 AM, Jörg Verstraete <
[email protected]> wrote:
> Hello
>
> I'm not sure I replied in the correct way (not much experience with
> mailing lists). My apologies if i sent it in the wrong way.
>
> In my code, I have the Polygons generated using a GeometryFactory that has
> a PrecisionModel of the type FLOATING. In this, I have the Polygons
> POLYGON ((166.66666666666663 500, 333.33333333333326 500,
> 333.33333333333326 -500, 166.66666666666663 -500, 166.66666666666663 500))
> and POLYGON ((0 500, 166.66666666666666 500, 166.66666666666666 -500, 0
> -500, 0 500))
>
> To avoid rounding issues in calculations, I created a second geometry
> factory that has a PrecisionModel of type FIXED (with an appropriate INT).
> Using a constructor of that factory, I did created new polygons:
> -
> newGeometry = fixedPrecisionGeometryFactory.createGeometry(oldGeometry);
> -
> Printing the Geometries that come out of this factory results in the
> Polygons
>
> POLYGON ((166.7 500, 333.3 500, 333.3 -500, 166.7 -500, 166.7 500))
> and
> POLYGON ((0 500, 166.7 500, 166.7 -500, 0 -500, 0 500))
>
> Operations done on these 2 polygons however yield exactly the same as on
> the original polygons, as if the precision model is not used in the
> internal representation.
>
> To force it, I've now changed it to go via the WKT string:
> -
> String wellKnownText = geometryFactory.createGeometry(g).toText();
> WKTReader wktr = new WKTReader(geometryFactory);
> return wktr.read(wellKnownText);
> -
> which indeed gives me the rounded coordinates.
>
> But I assumed that when using the second geometryFactory, I would get
> geometries that are rounded according to that precision model. Perhaps this
> is my mistake?
>
> Thanks!
>
>
> Jörg
>
>
>
>
>
> On 2015-03-02 18:22, Martin Davis wrote:
>
>> When I run the polygons
>> POLYGON ((166.7 500, 333.3 500, 333.3 -500, 166.7 -500, 166.7 500))
>> and
>> POLYGON ((0 500, 166.7 500, 166.7 -500, 0 -500, 0 500))
>> in JTS 1.13 I get:
>>
>> relate: FF2F11212
>> intersection: LINESTRING (166.7 -500, 166.7 500)
>>
>> How did you create the polygons under the fixed-precision model? You
>> need to round the coordinates to the precision model explicitly - that
>> isn't done automatically.
>>
>> It's best if you can provide a running test case that demonstrates the
>> problem.
>>
>> On Mon, Mar 2, 2015 at 9:08 AM, Stefan Steiniger <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Hi Joerg,
>>
>> I forward this question to the JTS user list.
>>
>> cheers,
>> stefan
>>
>> -------- Forwarded Message --------
>> Subject: [jump-pilot:discussion] jts precision model issues.
>> Date: Mon, 02 Mar 2015 16:28:36 +0000
>> From: "J�rg Verstraete" <[email protected]>
>> <mailto:[email protected]>
>> Reply-To: [jump-pilot:discussion]
>> <[email protected]>
>> <mailto:[email protected]>
>> To: [jump-pilot:discussion]
>> <[email protected]>
>> <mailto:[email protected]>
>>
>>
>>
>> Hello,
>>
>> I have a problem with the JTS PrecisionModel. I have 2 Polygons, that
>> are defined like this:
>> POLYGON ((166.66666666666663 500, 333.33333333333326 500,
>> 333.33333333333326 -500, 166.66666666666663 -500, 166.66666666666663 500))
>> and
>> POLYGON ((0 500, 166.66666666666666 500, 166.66666666666666 -500, 0
>> -500, 0 500))
>>
>> >From their construction, they should only share a common boundary,
>> but most likely rounding errors result in something else. To overcome
>> rounding errors, I use a fixed precision model in a new geometryfactory,
>> which gives me these polygons:
>> POLYGON ((166.7 500, 333.3 500, 333.3 -500, 166.7 -500, 166.7 500))
>> and
>> POLYGON ((0 500, 166.7 500, 166.7 -500, 0 -500, 0 500))
>>
>> The operator "relation" on these precise polygons returns me this:
>> 212111212
>> If I check what the intersection is, I get this:
>> POLYGON ((166.7 500, 166.7 500, 166.7 -500, 166.7 -500, 166.7 500))
>>
>> Am I using the precisionmodel in a wrong way? This behaviour is a bit
>> unexpected to me...
>> I'm using the JTS 1.14-20140423 that comes with JUMP, as it is the
>> latest version I can find anywhere.
>>
>> Thanks for any help (or if this is the wrong place, a direction to
>> where to point this).
>>
>>
>> Jörg
>>
>>
>> ---
>>
>> [jts precision model issues.](https://sourceforge.
>> net/p/jump-pilot/discussion/729479/thread/73c4a9b7/?limit=25#d5d1)
>>
>>
>> ---
>>
>> Sent fromsourceforge.net <http://sourceforge.net> because you
>> indicated interest in<https://sourceforge.net/p/
>> jump-pilot/discussion/729479/> <https://sourceforge.net/p/
>> jump-pilot/discussion/729479/>
>>
>> To unsubscribe from further messages, please visit<
>> https://sourceforge.net/auth/subscriptions/> <
>> https://sourceforge.net/auth/subscriptions/>
>>
>>
>>
>>
>> ------------------------------------------------------------
>> ------------------
>> Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored
>> by Intel and developed in partnership with Slashdot Media, is your
>> hub for all
>> things parallel software development, from weekly thought leadership
>> blogs to
>> news, videos, case studies, tutorials and more. Take a look and join
>> the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Jts-topo-suite-user mailing list
>> [email protected]
>> <mailto:[email protected]>
>> https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
>>
>>
>>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Jts-topo-suite-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
