John,
John Swensen wrote:
On Mar 17, 2017, at 2:56 AM, Juan Pablo Carbajal
<address@hidden <mailto:address@hidden>> wrote:
On Fri, Mar 17, 2017 at 9:41 AM, PhilipNienhuis <address@hidden
<mailto:address@hidden>> wrote:
Juan Pablo Carbajal-2 wrote
On Thu, Mar 16, 2017 at 9:56 PM, piyushjain <
piyushjain1sa@
> wrote:
Sir, I went through the current geometry package development and also
read
about mkoctfile command, and how to use oct create and use oct-files.
So, can you tell me what are the milestones of the project? I
mean,going
step-wise, what do I need to implement?
--
View this message in context:
http://octave.1599824.n4.nabble.com/GSoC-2017-Implement-boolean-operations-on-polygons-tp4682161p4682435.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.
So you know what you want to pursue already?
1. Cleanning up the boost interface
2. Adding clipper interface, read this
https://savannah.gnu.org/patch/?func=detailitem&item_id=9000#options
From my memory, the Clipper interface should be about done.
I'm still busy with making it clip polylines (works now) and
interpolating Z
values (got stuck there); but for "ordinary" 2D polygons I think it just
works as it is.
Philip
--
In that case I suggest you provide patches to integrate Philip work
into geomtry, following the guidelines described in that savanah
thread.
I was planning to do this in Octconf so I will give you quick feedback
if you provide something beginning of next week.
One final comment. I know I pushed the Boost solution because at the
time I thought it had the most robust solution for self-intersecting
polygons, polygons with parallel lines, etc. I now feel a little bad
that we spent all that time and it hasn’t been incorporated into the
package. It is quite cumbersome to get Boost set up to compile with the
version that supports self-intersection correction. I think that more
work could be done to make it a much better solution by making a “Point
concept abstraction” that would allow it to operate on the Octave
variable data in-place without having to copy. For larger datasets, this
could be a huge memory (and potentially performance) improvement over
the other solutions where you have to transform the Octave data into the
format required by the library.
I have been trying the Boost version by Amr for some time, using Amr's unofficial geometry-3.0.0 version from github and the mapping package (also an unofficial version, but I'm the mapping pkg maintainer :-) ).
AFAICS it does work fine, reliably and fast.
Also the poly2fv function is very useful for graphical output.
We (package maintainers JuanPi and me) didn't know that Boost is so big. Later on Amr mentioned he has weeded it out but AFAICS that info is nowhere.
FYI Boost (an enormous collection of include files) alone is > 10 % disk space of an entire mxe-octave windows installer. That wouldn't be bad in itself, but the fact that it's used for just a few specialized functions puts that into another perspective.
Where you write "boost with self-intersection correction", I suppose that's version 1.61 and up, and it would be desirable to be able to have polybool be based on that version as well, depending on compile time availability through configure.
So a GSOC project could be bringing the polybool/boost solution further so that it can be included in OF-geometry.
I would really like that to happen.
Has anyone ever explored the license for GPC
(http://www.cs.man.ac.uk/~toby/gpc/
<http://www.cs.man.ac.uk/%7Etoby/gpc/>)? It says it is free for
private/hobbyist/education purposes, but I don’t know whether the
license is compatible with the GPL and Octave. From my experience, GPC
is one of the fastest and most robust polygon clipper out there. Maybe
we overlooked it because of its split license and the fact that the
license isn’t very well defined?
The GPL explicitly does not limit use of free SW. "Free for just education purposes" is incompatible with the GPL.
There are several benchmarks out there, some or most of them outdated now, that do not quite put GPC at #1. But I think many of those benchmarks are a bit "colored" as they usually relate to a specific polygon SW solution.
At my work we've been using it once (with matlab), my impression of that one -probably atypical- occasion was that GPC isn't so very fast.
Therefore I'm glad you share with us your experience with several polygon clipping libraries, I think that is very valuable, thanks.
Maybe we could find out what GIS SW like QGIS uses internally?
Philip