GPC gives simplest solution, Clipper doesn't

[Anonymous]

I know that the topic has already been treated, I want you to remember this
case.

Giving 2 squares, touching

the union return the same two polygons, and not only one.

GPC gives the simplest solution, Clipper doesn't

I'm asking you is there a workaround for this type of input?

Sample data (set1)

Polygon1:
[1]([4]({X=0 Y=0 },{X=10 Y=0 },{X=10 Y=10 },{X=0 Y=10 }))
Polygon2:
[1]([4]({X=10 Y=0 },{X=20 Y=0 },{X=20 Y=10 },{X=10 Y=10 }))
Output:
[2]([4]({X=20 Y=000 },{X=10 Y=000 },{X=10 Y=10 },{X=20 Y=10 }),[4]({X=10 Y=000 },{X=000 Y=000 },{X=000 Y=10 },{X=10 Y=10 }))

Sample data (set2)

Polygon1:
[1]([4]({X=0 Y=0 },{X=10 Y=0 },{X=10 Y=10 },{X=0 Y=10 }))
Polygon2:
[1]([4]({X=0 Y=10 },{X=10 Y=10 },{X=10 Y=20 },{X=0 Y=20 }))
Output:
[2]([4]({X=10 Y=10 },{X=000 Y=10 },{X=000 Y=20 },{X=10 Y=20 }),[4]({X=10 Y=000 },{X=000 Y=000 },{X=000 Y=10 },{X=10 Y=10 }))

[Angus Johnson]

There's no easy way to do this. However, as I've said before, even though it
could be simpler, the solution is still correct.

[Anonymous]

Ok, you compare the execution times of your library with others, perhaps you
should indicate that your results are partial compared with other libraries.

Using GIS data frequently encountered datastet cut up regular grid, and
this library is not suitable for this.

Thanks for your effort.

[Anonymous]

Angusj has been very clear from the very start of the Releases.The result from
his program may consist of split regions.

Also you may have a polygon with a hole filling the entire polygon.

This type of Result may not be suitable for integration into a collection of
computational routines as you wished.

[Anonymous]

Ok, no problem.

I suggest you better specify this limit

I will use GPC.

Thanks a lot

[Ignorant]

A bit late....
GPC also has problems..(touching contours....) AND 4/5 Turing class bugs.Its only plus over Angus clipper are
(A)spcialised for odd/even parity
(B)Edge bundles treated as single Hybrid edge ..leading to a corresponding reductio in edge X edge intesections within a beam.
(C)A horizontal processing model along beam boundries....

When it seems to run faster ..check on the number of Within beam Xs both handle in a millisec.
Both spew out nearly similar figures.

[Angus Johnson]

OK, I've just uploaded an early beta of version 2.8 to the code repository
here:

http://polyclipping.svn.sourceforge.net/viewvc/polyclipping/trunk/

This new version (currently a beta release and only in Delphi and C++ so far)
joins output polygons that share a common edge.

Please let me know if you spot any problems.

[Anonymous]

First of all thanks for your work.

The first case is resolved, it remains the second that is not handled
correctly.

You can try also this, composed by 2 triangles, maybe it helps:

(({X=0 Y=0 },{X=0 Y=10 },{X=10 Y=10 }))

(({X=0 Y=10 },{X=10 Y=10 },{X=0 Y=20 }))

Thanks

[Angus Johnson]

Thanks. I can see the problem.

[Angus Johnson]

Should now be fixed in ver 2.85.

[Anonymous]

Albertino80,

There is a conjured up version of gpc(using Qsort) which is very very fast and
tidier, .

Clipper tramples even that by a factor of 2.1 .

As soon as Angus gets time to do a writeup ,probably his method can also be
integrated into

other libraries.He seems to have a slick way of generating scan beams on the
fly.

[Anonymous]

Clipper generates the scanbeams on the fly while doing the operation.

But why does it have such few minimas? .I compared with the other widely used
c version of vatti'smethod.

That version has just far too many (in hundreds) minimas compared to 17(that
is 34 if we repeat it for both sides) in clipper.

I checked this with the demo input(the characters) with clipper benchmark.To
my surprise the # of scanbeams are same in boththe libraries.(all the distinct
y values of the polygon points)

. Major speed up is because of the Y scanbeams being generated just before the
next Y scan.