Hi Martin, thanks for the answer. Its a pity these thoughs havent been
pushed forward. Really hope JTS can find funding. JTS is a very
important part of many open source geospatial projects. I would say that
most the java projects use JTS. Hope some of these important projects
understand how important is JTS and what this project deserves.
Unfortunately, JASPA at this moment does not have any funding and I just
develop it because i like it. I am thinking in writing some proposal to
get an official research project from my University or the Spanish
ministry to get some funding. I will have JTS in my mind too. Maybe we
could apply for some international research projects announcements.
On 22/10/2010 20:48, Martin Davis wrote:
> What you're seeing is expected behaviour. As you probably know, this
> is due to the effects of using finite precision floating point to
> evaluate line intersections and overlay operations.
> In general, overlay operations do not fully obey the axioms of
> set-theoretic topology. So it's not always possible to conclude that:
> A.diiference(B).intersection(B) is contained in B.boundary()
> As you point out, one way to move closer to (or possibly fully meet?)
> the set-theoretic model is to always snap arguments together (using
> some tolerance distance). Something similar to this has been
> researched Guting et al with their realm-based spatial algebra:
> I have spent some time thinking about this, and there is some code in
> JTS which implements some of the functionality required. (I.e the
> snap-rounding algorithms in the snapround package. Currently this
> only produces noded linework, however - maintaining polyonal topology
> is a task to be done.) The supported PrecisionModel comes into play
> here too - overlay operations on snapped geometry probably need to be
> evaluated in a PrecisionModel which matches the snapping grid.
> These ideas haven't been pushed forward to a final implementation
> mostly due to lack of time, funding, and a truly inspiring use case.
> On Fri, Oct 22, 2010 at 6:55 AM, Jose C. Martinez-Llario
> <jomarlla@... <mailto:jomarlla@...>> wrote:
> Hi Martin,
> I have two polygons like:
> A - POLYGON ((280 320, 260 20, 540 20, 540 320, 280 320))
> B - POLYGON ((740 300, 440 160, 720 40, 740 300))
> If I do:
> C = A.Diference(B)
> D = C.Intersection(B)
> D should be empty?..I guess no because the boundary of polygon B
> can not
> be subtracted from A but the result is not what i was expecting to
> LINESTRING (540 206.66666666666666, 440 160)
> it is just half of the intersection boundary!.
> If I change the polygons A and B with this ones (snapping each
> other and
> inserting the new vertexes):
> POLYGON ((280 320, 260 20, 540 20, 540 117.14285714285714, 540
> 206.66666666666666, 540 320, 280 320))
> POLYGON ((740 300, 540 206.66666666666666, 440 160, 540
> 117.14285714285714, 720 40, 740 300))
> then i get the expected result:
> MULTILINESTRING ((540 206.66666666666666, 440 160), (440 160, 540
> Umm...just wanted to ask if it is normal or not. It makes me think
> the snapping tolerance we talked several months ago:
> Did you have time to develop or have you though about some
> funciontality to snap polygons?
> Thanks in advance.
> Nokia and AT&T present the 2010 Calling All Innovators-North
> America contest
> Create new apps & games for the Nokia N8 for consumers in U.S.
> and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi
> Jts-topo-suite-user mailing list