

Dear all,
I would like to start contacting the Geometry package's maintainer so that we can decide how the code will be merged during the next days.
I implemented some functions as cc files and the package currently has only .m functions.
So, I will try to structure the src directory as in the image package (https://sourceforge.net/p/octave/image/ci/default/tree/src/).
The functions make use of the Boost library (>=1.60) so my Mentor told me that we will need to make a dependency for this version of Boost instead of adding the boostgeometry library as a part of the package.
However, If i were the user, i won't know how should i download the required version of Boost library and make octave's function use it.
Regards,
Amr Mohamed


On 9 August 2016 at 15:07, Amr Mohamed < [hidden email]> wrote:
> [...[]
> The functions make use of the Boost library (>=1.60) so my Mentor told me
> that we will need to make a dependency for this version of Boost instead of
> adding the boostgeometry library as a part of the package.
> [...]
Actually, instead of checking for the version, you should check if the
feature you want is there or if it behaves the way you need to behave.
Since you already linked to the image package, checkout its configure.ac.
There's two tests that may be of interest. One checks the compiler for
a bug with a test program, while another checks for the presence of a
function in Octave.
Carnë


amr mohamed wrote
Dear all,
I would like to start contacting the Geometry package's maintainer so that we can decide how the code will be merged during the next days.
I implemented some functions as cc files and the package currently has only .m functions.
So, I will try to structure the src directory as in the image package ( https://sourceforge.net/p/octave/image/ci/default/tree/src/).
The functions make use of the Boost library (>=1.60) so my Mentor told me that we will need to make a dependency for this version of Boost instead of adding the boostgeometry library as a part of the package.
However, If i were the user, i won't know how should i download the required version of Boost library and make octave's function use it.
(mapping package maintainer here, just a quick note as I'm on vacation with patchy Internet access until somewhere next week.)
Thanks for this work, a welcome contribution IMO.
Once it is included in the geometry package the mapping package will make use of it as well, several functions for that are almost finished. See a.o., savannah.gnu.org/patch/index.php?9000 for some developments along that line.
I have a few questions, mainly because I missed all progress on this GSOC project as I somehow missed blogs and progress reports might be my own fault :).
1. Is the entire boost library required or just a subset? Last time I looked boost comprised some 105 MB of a maze of include files, of which only a fairly small subset is required for boolean ops on polygons.
2. Did you implement interpolation of Zvalues on clipped polygon sides? That is something I discussed with John Swensen; it would be a useful asset for the mapping package as unlike its Matlab counterpart many of its polygon functions accept polygons with Zvalues and 3D polygons.
3. Similarly did you implement drawing polygons with holes using e.g., the polytri library? also something that came up in discussions with John S.
4. Where is your code currently hosted?
Philip


PhilipNienhuis wrote
amr mohamed wrote
Dear all,
I would like to start contacting the Geometry package's maintainer so that we can decide how the code will be merged during the next days.
I implemented some functions as cc files and the package currently has only .m functions.
So, I will try to structure the src directory as in the image package ( https://sourceforge.net/p/octave/image/ci/default/tree/src/).
The functions make use of the Boost library (>=1.60) so my Mentor told me that we will need to make a dependency for this version of Boost instead of adding the boostgeometry library as a part of the package.
However, If i were the user, i won't know how should i download the required version of Boost library and make octave's function use it.
(mapping package maintainer here, just a quick note as I'm on vacation with patchy Internet access until somewhere next week.)
Thanks for this work, a welcome contribution IMO.
Once it is included in the geometry package the mapping package will make use of it as well, several functions for that are almost finished. See a.o., savannah.gnu.org/patch/index.php?9000 for some developments along that line.
I have a few questions, mainly because I missed all progress on this GSOC project as I somehow missed blogs and progress reports might be my own fault :).
1. Is the entire boost library required or just a subset? Last time I looked boost comprised some 105 MB of a maze of include files, of which only a fairly small subset is required for boolean ops on polygons.
2. Did you implement interpolation of Zvalues on clipped polygon sides? That is something I discussed with John Swensen; it would be a useful asset for the mapping package as unlike its Matlab counterpart many of its polygon functions accept polygons with Zvalues and 3D polygons.
3. Similarly did you implement drawing polygons with holes using e.g., the polytri library? also something that came up in discussions with John S.
4. Where is your code currently hosted?
Philip
1No, i have manually removed unnecessary parts of the library so it reduced to approximately 14MB.
I think we can minimize the headers size to less than 10MB.
2No, We discussed adding a z coordinate to the polygons during our first chat (last May) and he told me to postpone it for now.
3Yes, we are drawing polygons with holes removed.
But, functions currently aren't working well with complex selfintersecting polygons as the Boost Geometry dissolve function that is used to solve selfintersections is still unstable (under the library's extension and not part of the core library).
4The clone of the package is hosted on bitbucket here:
https://bitbucket.org/amr_keleg/octavegeometryAnd kindly find my blog where i posted the project's progress.
https://amrkeleg.wordpress.com/Amr


AMR_KELEG wrote
PhilipNienhuis wrote
amr mohamed wrote
Dear all,
I would like to start contacting the Geometry package's maintainer so that we can decide how the code will be merged during the next days.
I implemented some functions as cc files and the package currently has only .m functions.
So, I will try to structure the src directory as in the image package ( https://sourceforge.net/p/octave/image/ci/default/tree/src/).
The functions make use of the Boost library (>=1.60) so my Mentor told me that we will need to make a dependency for this version of Boost instead of adding the boostgeometry library as a part of the package.
However, If i were the user, i won't know how should i download the required version of Boost library and make octave's function use it.
(mapping package maintainer here, just a quick note as I'm on vacation with patchy Internet access until somewhere next week.)
Thanks for this work, a welcome contribution IMO.
Once it is included in the geometry package the mapping package will make use of it as well, several functions for that are almost finished. See a.o., savannah.gnu.org/patch/index.php?9000 for some developments along that line.
I have a few questions, mainly because I missed all progress on this GSOC project as I somehow missed blogs and progress reports might be my own fault :).
1. Is the entire boost library required or just a subset? Last time I looked boost comprised some 105 MB of a maze of include files, of which only a fairly small subset is required for boolean ops on polygons.
2. Did you implement interpolation of Zvalues on clipped polygon sides? That is something I discussed with John Swensen; it would be a useful asset for the mapping package as unlike its Matlab counterpart many of its polygon functions accept polygons with Zvalues and 3D polygons.
3. Similarly did you implement drawing polygons with holes using e.g., the polytri library? also something that came up in discussions with John S.
4. Where is your code currently hosted?
Philip
1No, i have manually removed unnecessary parts of the library so it reduced to approximately 14MB.
I think we can minimize the headers size to less than 10MB.
2No, We discussed adding a z coordinate to the polygons during our first chat (last May) and he told me to postpone it for now.
3Yes, we are drawing polygons with holes removed.
But, functions currently aren't working well with complex selfintersecting polygons as the Boost Geometry dissolve function that is used to solve selfintersections is still unstable (under the library's extension and not part of the core library).
4The clone of the package is hosted on bitbucket here:
https://bitbucket.org/amr_keleg/octavegeometryAnd kindly find my blog where i posted the project's progress.
https://amrkeleg.wordpress.com/
Thanks Amr,
it all seems good.
Hopefully JuanPi will (geometry package maintainer) will jump in soon. As it is summer vacation season it might take a while.
I do not have his email address at hand as I'm away from home as well so can't cc him.
Philip


> On Aug 11, 2016, at 1:00 PM, PhilipNienhuis < [hidden email]> wrote:
>
> AMR_KELEG wrote
>>
>> PhilipNienhuis wrote
>>>
>>> amr mohamed wrote
>>>> Dear all,
>>>>
>>>> I would like to start contacting the Geometry package's maintainer so
>>>> that we can decide how the code will be merged during the next days.
>>>> I implemented some functions as cc files and the package currently has
>>>> only .m functions.
>>>> So, I will try to structure the src directory as in the image package
>>>> ( https://sourceforge.net/p/octave/image/ci/default/tree/src/).
>>>>
>>>> The functions make use of the Boost library (>=1.60) so my Mentor told
>>>> me that we will need to make a dependency for this version of Boost
>>>> instead of adding the boostgeometry library as a part of the package.
>>>> However, If i were the user, i won't know how should i download the
>>>> required version of Boost library and make octave's function use it.
>>> (mapping package maintainer here, just a quick note as I'm on vacation
>>> with patchy Internet access until somewhere next week.)
>>> Thanks for this work, a welcome contribution IMO.
>>> Once it is included in the geometry package the mapping package will make
>>> use of it as well, several functions for that are almost finished. See
>>> a.o., savannah.gnu.org/patch/index.php?9000 for some developments along
>>> that line.
>>>
>>> I have a few questions, mainly because I missed all progress on this GSOC
>>> project as I somehow missed blogs and progress reports might be my own
>>> fault :).
>>>
>>> 1. Is the entire boost library required or just a subset? Last time I
>>> looked boost comprised some 105 MB of a maze of include files, of which
>>> only a fairly small subset is required for boolean ops on polygons.
>>>
>>> 2. Did you implement interpolation of Zvalues on clipped polygon sides?
>>> That is something I discussed with John Swensen; it would be a useful
>>> asset for the mapping package as unlike its Matlab counterpart many of
>>> its polygon functions accept polygons with Zvalues and 3D polygons.
>>>
>>> 3. Similarly did you implement drawing polygons with holes using e.g.,
>>> the polytri library? also something that came up in discussions with John
>>> S.
>>>
>>> 4. Where is your code currently hosted?
>>>
>>> Philip
>> 1No, i have manually removed unnecessary parts of the library so it
>> reduced to approximately 14MB.
>> I think we can minimize the headers size to less than 10MB.
>>
>> 2No, We discussed adding a z coordinate to the polygons during our first
>> chat (last May) and he told me to postpone it for now.
>>
>> 3Yes, we are drawing polygons with holes removed.
>> But, functions currently aren't working well with complex
>> selfintersecting polygons as the Boost Geometry dissolve function that is
>> used to solve selfintersections is still unstable (under the library's
>> extension and not part of the core library).
>>
>> 4The clone of the package is hosted on bitbucket here:
>> https://bitbucket.org/amr_keleg/octavegeometry>>
>> And kindly find my blog where i posted the project's progress.
>> https://amrkeleg.wordpress.com/>
> Thanks Amr,
>
> it all seems good.
>
> Hopefully JuanPi will (geometry package maintainer) will jump in soon. As it
> is summer vacation season it might take a while.
> I do not have his email address at hand as I'm away from home as well so
> can't cc him.
>
> Philip
>
>
>
>
>
> 
> View this message in context: http://octave.1599824.n4.nabble.com/GSoC16BooleanOperationsonPolygonsMergeCodetogeometryPackagetp4679083p4679133.html> Sent from the Octave  Maintainers mailing list archive at Nabble.com.
>
Sorry, I have been out this week on vacation also and my contact with Amr has been less than previous weeks. I will get back in touch on Monday and help him get the configure.ac sorted out, in the case he hasn’t learned it on his own during this week.
John S.


On Fri, Aug 12, 2016 at 4:10 AM, John Swensen < [hidden email]> wrote:
>
>> On Aug 11, 2016, at 1:00 PM, PhilipNienhuis < [hidden email]> wrote:
>>
>> AMR_KELEG wrote
>>>
>>> PhilipNienhuis wrote
>>>>
>>>> amr mohamed wrote
>>>>> Dear all,
>>>>>
>>>>> I would like to start contacting the Geometry package's maintainer so
>>>>> that we can decide how the code will be merged during the next days.
>>>>> I implemented some functions as cc files and the package currently has
>>>>> only .m functions.
>>>>> So, I will try to structure the src directory as in the image package
>>>>> ( https://sourceforge.net/p/octave/image/ci/default/tree/src/).
>>>>>
>>>>> The functions make use of the Boost library (>=1.60) so my Mentor told
>>>>> me that we will need to make a dependency for this version of Boost
>>>>> instead of adding the boostgeometry library as a part of the package.
>>>>> However, If i were the user, i won't know how should i download the
>>>>> required version of Boost library and make octave's function use it.
>>>> (mapping package maintainer here, just a quick note as I'm on vacation
>>>> with patchy Internet access until somewhere next week.)
>>>> Thanks for this work, a welcome contribution IMO.
>>>> Once it is included in the geometry package the mapping package will make
>>>> use of it as well, several functions for that are almost finished. See
>>>> a.o., savannah.gnu.org/patch/index.php?9000 for some developments along
>>>> that line.
>>>>
>>>> I have a few questions, mainly because I missed all progress on this GSOC
>>>> project as I somehow missed blogs and progress reports might be my own
>>>> fault :).
>>>>
>>>> 1. Is the entire boost library required or just a subset? Last time I
>>>> looked boost comprised some 105 MB of a maze of include files, of which
>>>> only a fairly small subset is required for boolean ops on polygons.
>>>>
>>>> 2. Did you implement interpolation of Zvalues on clipped polygon sides?
>>>> That is something I discussed with John Swensen; it would be a useful
>>>> asset for the mapping package as unlike its Matlab counterpart many of
>>>> its polygon functions accept polygons with Zvalues and 3D polygons.
>>>>
>>>> 3. Similarly did you implement drawing polygons with holes using e.g.,
>>>> the polytri library? also something that came up in discussions with John
>>>> S.
>>>>
>>>> 4. Where is your code currently hosted?
>>>>
>>>> Philip
>>> 1No, i have manually removed unnecessary parts of the library so it
>>> reduced to approximately 14MB.
>>> I think we can minimize the headers size to less than 10MB.
>>>
>>> 2No, We discussed adding a z coordinate to the polygons during our first
>>> chat (last May) and he told me to postpone it for now.
>>>
>>> 3Yes, we are drawing polygons with holes removed.
>>> But, functions currently aren't working well with complex
>>> selfintersecting polygons as the Boost Geometry dissolve function that is
>>> used to solve selfintersections is still unstable (under the library's
>>> extension and not part of the core library).
>>>
>>> 4The clone of the package is hosted on bitbucket here:
>>> https://bitbucket.org/amr_keleg/octavegeometry>>>
>>> And kindly find my blog where i posted the project's progress.
>>> https://amrkeleg.wordpress.com/>>
>> Thanks Amr,
>>
>> it all seems good.
>>
>> Hopefully JuanPi will (geometry package maintainer) will jump in soon. As it
>> is summer vacation season it might take a while.
>> I do not have his email address at hand as I'm away from home as well so
>> can't cc him.
>>
>> Philip
>>
>>
>>
>>
>>
>> 
>> View this message in context: http://octave.1599824.n4.nabble.com/GSoC16BooleanOperationsonPolygonsMergeCodetogeometryPackagetp4679083p4679133.html>> Sent from the Octave  Maintainers mailing list archive at Nabble.com.
>>
>
> Sorry, I have been out this week on vacation also and my contact with Amr has been less than previous weeks. I will get back in touch on Monday and help him get the configure.ac sorted out, in the case he hasn’t learned it on his own during this week.
>
> John S.
>
>
Hi all,
I am sorry for the delay. I am quite behind updating several patches I
got for geometry. I will check the bitbucket repo and see how long it
will take me to integrate these changes (hopefully not much!).
After a quick look, what is the include/poli2try folder? Is it meant
to be part of the package?
Thanks


Sent: Monday, August 15, 2016 9:08 AM
Subject: Re: GSoC '16  Boolean Operations on Polygons : Merge Code to geometry Package
>> On Aug 11, 2016, at 1:00 PM, PhilipNienhuis < [hidden email]> wrote:
>>>>> I would like to start contacting the Geometry package's maintainer so
>>>>> that we can decide how the code will be merged during the next days.
>>>>> I implemented some functions as cc files and the package currently has
>>>>> So, I will try to structure the src directory as in the image package
>>>>> The functions make use of the Boost library (>=1.60) so my Mentor told
>>>>> me that we will need to make a dependency for this version of Boost
>>>>> instead of adding the boostgeometry library as a part of the package.
>>>>> However, If i were the user, i won't know how should i download the
>>>>> required version of Boost library and make octave's function use it.
>>>> (mapping package maintainer here, just a quick note as I'm on vacation
>>>> with patchy Internet access until somewhere next week.)
>>>> Thanks for this work, a welcome contribution IMO.
>>>> Once it is included in the geometry package the mapping package will make
>>>> use of it as well, several functions for that are almost finished. See
>>>> a.o., savannah.gnu.org/patch/index.php?9000 for some developments along
>>>> I have a few questions, mainly because I missed all progress on this GSOC
>>>> project as I somehow missed blogs and progress reports might be my own
>>>> 1. Is the entire boost library required or just a subset? Last time I
>>>> looked boost comprised some 105 MB of a maze of include files, of which
>>>> only a fairly small subset is required for boolean ops on polygons.
>>>> 2. Did you implement interpolation of Zvalues on clipped polygon sides?
>>>> That is something I discussed with John Swensen; it would be a useful
>>>> asset for the mapping package as unlike its Matlab counterpart many of
>>>> its polygon functions accept polygons with Zvalues and 3D polygons.
>>>> 3. Similarly did you implement drawing polygons with holes using e.g.,
>>>> the polytri library? also something that came up in discussions with John
>>>> 4. Where is your code currently hosted?
>>> 1No, i have manually removed unnecessary parts of the library so it
>>> reduced to approximately 14MB.
>>> I think we can minimize the headers size to less than 10MB.
>>> 2No, We discussed adding a z coordinate to the polygons during our first
>>> chat (last May) and he told me to postpone it for now.
>>> 3Yes, we are drawing polygons with holes removed.
>>> But, functions currently aren't working well with complex
>>> selfintersecting polygons as the Boost Geometry dissolve function that is
>>> used to solve selfintersections is still unstable (under the library's
>>> extension and not part of the core library).
>>> 4The clone of the package is hosted on bitbucket here:
>>> And kindly find my blog where i posted the project's progress.
>> Hopefully JuanPi will (geometry package maintainer) will jump in soon. As it
>> is summer vacation season it might take a while.
>> I do not have his email address at hand as I'm away from home as well so
>> Sent from the Octave  Maintainers mailing list archive at Nabble.com.
> Sorry, I have been out this week on vacation also and my contact with Amr has been less than previous weeks. I will get back in touch on Monday and help him get the configure.ac sorted out, in the case he hasn’t learned it on
his own during this week.
I am sorry for the delay. I am quite behind updating several patches I
got for geometry. I will check the bitbucket repo and see how long it
will take me to integrate these changes (hopefully not much!).
After a quick look, what is the include/poli2try folder? Is it meant
to be part of the package?
Dear Juan,
Let me summarize my contribution to the package:
1) Created a new src directory for cc files with a configure.ac and Makefile.in files.
2) Editted the Makefile in the root of the package.
3) Added a new bootstrap script in the root of the package.
4) Added a new include directory that contains the library used by the poly2fv function.
5) Added 4 new .m files to the inst/polyygons2d directory.
I just wanted to know how would you like to merge the code?
Do you want me to create new patch requests with my changes?
If so, I can start by creating a patch request that includes 2 of the implemented .m files.
Amr
To unsubscribe from GSoC '16  Boolean Operations on Polygons : Merge Code to geometry Package,
click here.
NAML


In reply to this post by Juan Pablo Carbajal2
Juan Pablo Carbajal wrote:
> On Fri, Aug 12, 2016 at 4:10 AM, John Swensen < [hidden email]> wrote:
>>
>>> On Aug 11, 2016, at 1:00 PM, PhilipNienhuis < [hidden email]> wrote:
>>>
>>> AMR_KELEG wrote
>>>>
>>>> PhilipNienhuis wrote
>>>>>
>>>>> amr mohamed wrote
>>>>>> Dear all,
>>>>>>
>>>>>> I would like to start contacting the Geometry package's maintainer so
>>>>>> that we can decide how the code will be merged during the next days.
>>>>>> I implemented some functions as cc files and the package currently has
>>>>>> only .m functions.
>>>>>> So, I will try to structure the src directory as in the image package
>>>>>> ( https://sourceforge.net/p/octave/image/ci/default/tree/src/).
>>>>>>
>>>>>> The functions make use of the Boost library (>=1.60) so my Mentor told
>>>>>> me that we will need to make a dependency for this version of Boost
>>>>>> instead of adding the boostgeometry library as a part of the package.
>>>>>> However, If i were the user, i won't know how should i download the
>>>>>> required version of Boost library and make octave's function use it.
>>>>> (mapping package maintainer here, just a quick note as I'm on vacation
>>>>> with patchy Internet access until somewhere next week.)
>>>>> Thanks for this work, a welcome contribution IMO.
>>>>> Once it is included in the geometry package the mapping package will make
>>>>> use of it as well, several functions for that are almost finished. See
>>>>> a.o., savannah.gnu.org/patch/index.php?9000 for some developments along
>>>>> that line.
>>>>>
>>>>> I have a few questions, mainly because I missed all progress on this GSOC
>>>>> project as I somehow missed blogs and progress reports might be my own
>>>>> fault :).
>>>>>
>>>>> 1. Is the entire boost library required or just a subset? Last time I
>>>>> looked boost comprised some 105 MB of a maze of include files, of which
>>>>> only a fairly small subset is required for boolean ops on polygons.
>>>>>
>>>>> 2. Did you implement interpolation of Zvalues on clipped polygon sides?
>>>>> That is something I discussed with John Swensen; it would be a useful
>>>>> asset for the mapping package as unlike its Matlab counterpart many of
>>>>> its polygon functions accept polygons with Zvalues and 3D polygons.
>>>>>
>>>>> 3. Similarly did you implement drawing polygons with holes using e.g.,
>>>>> the polytri library? also something that came up in discussions with John
>>>>> S.
>>>>>
>>>>> 4. Where is your code currently hosted?
>>>>>
>>>>> Philip
>>>> 1No, i have manually removed unnecessary parts of the library so it
>>>> reduced to approximately 14MB.
>>>> I think we can minimize the headers size to less than 10MB.
>>>>
>>>> 2No, We discussed adding a z coordinate to the polygons during our first
>>>> chat (last May) and he told me to postpone it for now.
>>>>
>>>> 3Yes, we are drawing polygons with holes removed.
>>>> But, functions currently aren't working well with complex
>>>> selfintersecting polygons as the Boost Geometry dissolve function that is
>>>> used to solve selfintersections is still unstable (under the library's
>>>> extension and not part of the core library).
>>>>
>>>> 4The clone of the package is hosted on bitbucket here:
>>>> https://bitbucket.org/amr_keleg/octavegeometry>>>>
>>>> And kindly find my blog where i posted the project's progress.
>>>> https://amrkeleg.wordpress.com/>>>
>>> Thanks Amr,
>>>
>>> it all seems good.
>>>
>>> Hopefully JuanPi will (geometry package maintainer) will jump in soon. As it
>>> is summer vacation season it might take a while.
>>> I do not have his email address at hand as I'm away from home as well so
>>> can't cc him.
>>>
>>> Philip
>>>
>>>
>>>
>>>
>>>
>>> 
>>> View this message in context: http://octave.1599824.n4.nabble.com/GSoC16BooleanOperationsonPolygonsMergeCodetogeometryPackagetp4679083p4679133.html>>> Sent from the Octave  Maintainers mailing list archive at Nabble.com.
>>>
>>
>> Sorry, I have been out this week on vacation also and my contact with Amr has been less than previous weeks. I will get back in touch on Monday and help him get the configure.ac sorted out, in the case he hasn’t learned it on his own during this week.
>>
>> John S.
>>
>>
> Hi all,
>
> I am sorry for the delay. I am quite behind updating several patches I
> got for geometry. I will check the bitbucket repo and see how long it
> will take me to integrate these changes (hopefully not much!).
>
> After a quick look, what is the include/poli2try folder? Is it meant
> to be part of the package?
Juan /others
Now that I am (just) back from vacation it appears to me that Amr has
implemented several functions that have already been submitted earlier
on in patch #9000; most of them have matgeom counterparts that are
already in the geometry package. In hindsight I think the communication
between John S. as mentor and you and me as involved package maintainers
could have been better :(
Once I have my holiday backlog sorted out (~end of this week) I'll try
to make an overview of the various implementations of the function we
now have so that we can decide what goes where. Some performance tests
might be helpful.
IMO some of the new functions should go in geometry, some in mapping.
Patch #9000 is still a good start.
As to polytri, that is a dependency hat Amr hasn't mentioned  it is a
library for triangulation that can transform patcheswithholes into a
triangulated surface for the filled part(s). It is merely meant for
drawing polygons (and as such indispensable although polycut does merely
the same  hopefully the polytri solution is faster).
Philip


Juan Pablo Carbajal wrote: Hi all,
I am sorry for the delay. I am quite behind updating several patches I got for geometry. I will check the bitbucket repo and see how long it will take me to integrate these changes (hopefully not much!).
After a quick look, what is the include/poli2try folder? Is it meant to be part of the package?
Juan /others Now that I am (just) back from vacation it appears to me that Amr has implemented several functions that have already been submitted earlier on in patch #9000; most of them have matgeom counterparts that are already in the geometry package. In hindsight I think the communication between John S. as mentor and you and me as involved package maintainers could have been better :( Once I have my holiday backlog sorted out (~end of this week) I'll try to make an overview of the various implementations of the function we now have so that we can decide what goes where. Some performance tests might be helpful. IMO some of the new functions should go in geometry, some in mapping. Patch #9000 is still a good start. As to polytri, that is a dependency hat Amr hasn't mentioned  it is a library for triangulation that can transform patcheswithholes into a triangulated surface for the filled part(s). It is merely meant for drawing polygons (and as such indispensable although polycut does merely the same  hopefully the polytri solution is faster). Philip
Sorry, that is probably my fault. I guess I had missed this bug/patch. We had gone and looked at the splitPolygon and joinPolygon in the geometry package repository, but I don’t recall why we didn’t just repurpose those.
We had discussed the usage of clipper vs Boost.Polygon vs Boost.Geometry vs one other library at the outset. We had seen an implementation of the polybool using Clipper, but there was some discussion about whether converting to 64 bit integer, performing the boolean operations, then converting back to floating point numbers was the correct approach. We had decided to us Boost.Geometry instead because of its ability to use float/double as the core representation, has emerging support for correcting selfintersections, and it very actively being maintained by a community of GIS professionals. Maybe we should have gotten permission/blessing from you guys as maintainers before heading in that direction fullforce.
poly2tri is a library I have used with great success in the past for doing triangulations of polygons with holes. I had seen that one of you was working on the polycut function, but because the poly2tri library has been around for so long, seems to have the majority of kinks and corner cases worked out, and it involved including a relatively small number of source files as a dependency, that it would be an ideal solution to implementing the poly2fv function. Sometimes I like to reinvent the wheel because I learn a lot about what is really going on under the hood, and other times I just want to use an algorithm that I know works well. This was one of those latter cases.
I don’t think Amr has checked it into his repository yet, but one of the really great things he accomplished was to take all of the polygon tests from http://www.angusj.com/delphi/clipper.php and implement them to run in both Matlab and Octave. This allows us to compare performance between both Matlab and Octave, other nonOctave implementation, and the alternative Octave implementations that were in this Patch #9000.
I apologize if we duplicated work unnecessarily. That was not our intent. I think Amr has done a pretty good job and any shortcomings are really my fault for not keeping tabs with you two better.
John S.


John Swensen3 wrote
> On Aug 15, 2016, at 8:05 AM, Philip Nienhuis < [hidden email]> wrote:
>
> Juan Pablo Carbajal wrote:
>> Hi all,
>>
>> I am sorry for the delay. I am quite behind updating several patches I
>> got for geometry. I will check the bitbucket repo and see how long it
>> will take me to integrate these changes (hopefully not much!).
>>
>> After a quick look, what is the include/poli2try folder? Is it meant
>> to be part of the package?
>
> Juan /others
>
> Now that I am (just) back from vacation it appears to me that Amr has implemented several functions that have already been submitted earlier on in patch #9000; most of them have matgeom counterparts that are already in the geometry package. In hindsight I think the communication between John S. as mentor and you and me as involved package maintainers could have been better :(
>
> Once I have my holiday backlog sorted out (~end of this week) I'll try to make an overview of the various implementations of the function we now have so that we can decide what goes where. Some performance tests might be helpful.
> IMO some of the new functions should go in geometry, some in mapping. Patch #9000 is still a good start.
>
> As to polytri, that is a dependency hat Amr hasn't mentioned  it is a library for triangulation that can transform patcheswithholes into a triangulated surface for the filled part(s). It is merely meant for drawing polygons (and as such indispensable although polycut does merely the same  hopefully the polytri solution is faster).
>
> Philip
>
Sorry, that is probably my fault. I guess I had missed this bug/patch. We had gone and looked at the splitPolygon and joinPolygon in the geometry package repository, but I don’t recall why we didn’t just repurpose those.
We had discussed the usage of clipper vs Boost.Polygon vs Boost.Geometry vs one other library at the outset. We had seen an implementation of the polybool using Clipper, but there was some discussion about whether converting to 64 bit integer, performing the boolean operations, then converting back to floating point numbers was the correct approach. We had decided to us Boost.Geometry instead because of its ability to use float/double as the core representation, has emerging support for correcting selfintersections, and it very actively being maintained by a community of GIS professionals. Maybe we should have gotten permission/blessing from you guys as maintainers before heading in that direction fullforce.
poly2tri is a library I have used with great success in the past for doing triangulations of polygons with holes. I had seen that one of you was working on the polycut function, but because the poly2tri library has been around for so long, seems to have the majority of kinks and corner cases worked out, and it involved including a relatively small number of source files as a dependency, that it would be an ideal solution to implementing the poly2fv function. Sometimes I like to reinvent the wheel because I learn a lot about what is really going on under the hood, and other times I just want to use an algorithm that I know works well. This was one of those latter cases.
I don’t think Amr has checked it into his repository yet, but one of the really great things he accomplished was to take all of the polygon tests from http://www.angusj.com/delphi/clipper.php < http://www.angusj.com/delphi/clipper.php> and implement them to run in both Matlab and Octave. This allows us to compare performance between both Matlab and Octave, other nonOctave implementation, and the alternative Octave implementations that were in this Patch #9000.
I apologize if we duplicated work unnecessarily. That was not our intent. I think Amr has done a pretty good job and any shortcomings are really my fault for not keeping tabs with you two better.
John,
It wasn't my intention to blame anyone :) I just made the observation that apparently some duplicate work has been done due to less than optimal communications. From my side setting insufficient priority (due to lack of time) is also to "blame"; probably the same goes for JuanPi. Well, that is how it goes with volunteer projects.
However, the nottobeignored upside of that is that we now have choice; we can select the best solutions/implementations or make a combination of the best ones.
I agree with what you wrote about polytri  AFAICS Matlab also suggests to use poly2fv rather than polycut. I just "made" polycut.m because I already had a similar implementation lying around. Initially I didn't even know about the existence of polycut in TMW's mapping toolbox, I just found that the use of branch cuts was one way of properly drawing of (nested) polygons with holes and initially my subfunction for that job was called "optimize_branch_cuts" (it is in shapedraw.m in the mapping package).
A remaining question for me is how to interpolate clipped Zvalues. In my work I often have "3D"planes (e.g., polygons of semi3D tiles of geological strata) that I want to visualize in 3D views. I know that clipperlib can do it using callbacks.
In a more general sense, unlike Matlab's mapping toolbox I'd like all polygon functions in the mapping package to be able to handle semi3D polygons (i.e.,polygons with different Zvalues for each vertex). Most of what I have made already does so.
OK, as far as I'm concerned to be continued later this week,
Philip


> On Aug 15, 2016, at 11:31 AM, PhilipNienhuis < [hidden email]> wrote:
>
> John,
>
> It wasn't my intention to blame anyone :) I just made the observation
> that apparently some duplicate work has been done due to less than optimal
> communications. From my side setting insufficient priority (due to lack of
> time) is also to "blame"; probably the same goes for JuanPi. Well, that is
> how it goes with volunteer projects.
>
> However, the nottobeignored upside of that is that we now have choice; we
> can select the best solutions/implementations or make a combination of the
> best ones.
>
> I agree with what you wrote about polytri  AFAICS Matlab also suggests to
> use poly2fv rather than polycut. I just "made" polycut.m because I already
> had a similar implementation lying around. Initially I didn't even know
> about the existence of polycut in TMW's mapping toolbox, I just found that
> the use of branch cuts was one way of properly drawing of (nested) polygons
> with holes and initially my subfunction for that job was called
> "optimize_branch_cuts" (it is in shapedraw.m in the mapping package).
>
> A remaining question for me is how to interpolate clipped Zvalues. In my
> work I often have "3D"planes (e.g., polygons of semi3D tiles of geological
> strata) that I want to visualize in 3D views. I know that clipperlib can do
> it using callbacks.
> In a more general sense, unlike Matlab's mapping toolbox I'd like all
> polygon functions in the mapping package to be able to handle semi3D
> polygons (i.e.,polygons with different Zvalues for each vertex). Most of
> what I have made already does so.
>
> OK, as far as I'm concerned to be continued later this week,
>
> Philip
>
>
>
> 
> View this message in context: http://octave.1599824.n4.nabble.com/GSoC16BooleanOperationsonPolygonsMergeCodetogeometryPackagetp4679083p4679230.html> Sent from the Octave  Maintainers mailing list archive at Nabble.com.
>
I think that the Zvalues for the vertices might be pretty simple with the Boost.Geometry solution. We can define the point model in any manner we want internally for use by the Boost algorithms. This could easily be adapted to include a Zvalue. However, what you would probably need to give us is a specified algorithm for how to determine the Zvalue of the output vertices of an operation, based on the Zvalues of the inputs.
For example, if you are doing a difference between two polygons A and B as AB, can you assume that all the vertices of A have the same Zvalue and all the vertices of B have the same Zvalue? Should the output of the AB operation have the Zvalues of A, the Zvaluse of B, or the average of the Zvalues of A and B? I think that once the logic of how resultant Zvalues are determined that the implementation should be pretty straightforward, even if it is don’t as a “post” step after the Boost.Geometry polygon operation.
The nice thing about using the Zvalues is that we can just modify the various functions we have made (polyjoin, polysplit, poly2fv, polybool) so that they have an optional third parameter and will only include Zvalues in the output if it included Zvalues for the input.
John


On Mon, Aug 15, 2016 at 8:57 PM, John Swensen < [hidden email]> wrote:
>
>> On Aug 15, 2016, at 11:31 AM, PhilipNienhuis < [hidden email]> wrote:
>>
>> John,
>>
>> It wasn't my intention to blame anyone :) I just made the observation
>> that apparently some duplicate work has been done due to less than optimal
>> communications. From my side setting insufficient priority (due to lack of
>> time) is also to "blame"; probably the same goes for JuanPi. Well, that is
>> how it goes with volunteer projects.
>>
>> However, the nottobeignored upside of that is that we now have choice; we
>> can select the best solutions/implementations or make a combination of the
>> best ones.
>>
>> I agree with what you wrote about polytri  AFAICS Matlab also suggests to
>> use poly2fv rather than polycut. I just "made" polycut.m because I already
>> had a similar implementation lying around. Initially I didn't even know
>> about the existence of polycut in TMW's mapping toolbox, I just found that
>> the use of branch cuts was one way of properly drawing of (nested) polygons
>> with holes and initially my subfunction for that job was called
>> "optimize_branch_cuts" (it is in shapedraw.m in the mapping package).
>>
>> A remaining question for me is how to interpolate clipped Zvalues. In my
>> work I often have "3D"planes (e.g., polygons of semi3D tiles of geological
>> strata) that I want to visualize in 3D views. I know that clipperlib can do
>> it using callbacks.
>> In a more general sense, unlike Matlab's mapping toolbox I'd like all
>> polygon functions in the mapping package to be able to handle semi3D
>> polygons (i.e.,polygons with different Zvalues for each vertex). Most of
>> what I have made already does so.
>>
>> OK, as far as I'm concerned to be continued later this week,
>>
>> Philip
>>
>>
>>
>> 
>> View this message in context: http://octave.1599824.n4.nabble.com/GSoC16BooleanOperationsonPolygonsMergeCodetogeometryPackagetp4679083p4679230.html>> Sent from the Octave  Maintainers mailing list archive at Nabble.com.
>>
>
> I think that the Zvalues for the vertices might be pretty simple with the Boost.Geometry solution. We can define the point model in any manner we want internally for use by the Boost algorithms. This could easily be adapted to include a Zvalue. However, what you would probably need to give us is a specified algorithm for how to determine the Zvalue of the output vertices of an operation, based on the Zvalues of the inputs.
>
> For example, if you are doing a difference between two polygons A and B as AB, can you assume that all the vertices of A have the same Zvalue and all the vertices of B have the same Zvalue? Should the output of the AB operation have the Zvalues of A, the Zvaluse of B, or the average of the Zvalues of A and B? I think that once the logic of how resultant Zvalues are determined that the implementation should be pretty straightforward, even if it is don’t as a “post” step after the Boost.Geometry polygon operation.
>
> The nice thing about using the Zvalues is that we can just modify the various functions we have made (polyjoin, polysplit, poly2fv, polybool) so that they have an optional third parameter and will only include Zvalues in the output if it included Zvalues for the input.
>
> John
>
>
Hi all,
I think there is no sad thing about redundant functions. We should
sort out whether we remove some of them or we make a frontend function
to select them according to user's needs.
Is poly2tri hosted somewhere (upstream)? if yes, then it is better to
provide instructions to install it rather than to repack it inside
geometry.
Let see how fast we can merge all this neat work.


On Aug 15, 2016, at 1:32 PM, Juan Pablo Carbajal < [hidden email]> wrote:
On Mon, Aug 15, 2016 at 8:57 PM, John Swensen < [hidden email]> wrote:
On Aug 15, 2016, at 11:31 AM, PhilipNienhuis <[hidden email]> wrote:
John,
It wasn't my intention to blame anyone :) I just made the observation that apparently some duplicate work has been done due to less than optimal communications. From my side setting insufficient priority (due to lack of time) is also to "blame"; probably the same goes for JuanPi. Well, that is how it goes with volunteer projects.
However, the nottobeignored upside of that is that we now have choice; we can select the best solutions/implementations or make a combination of the best ones.
I agree with what you wrote about polytri  AFAICS Matlab also suggests to use poly2fv rather than polycut. I just "made" polycut.m because I already had a similar implementation lying around. Initially I didn't even know about the existence of polycut in TMW's mapping toolbox, I just found that the use of branch cuts was one way of properly drawing of (nested) polygons with holes and initially my subfunction for that job was called "optimize_branch_cuts" (it is in shapedraw.m in the mapping package).
A remaining question for me is how to interpolate clipped Zvalues. In my work I often have "3D"planes (e.g., polygons of semi3D tiles of geological strata) that I want to visualize in 3D views. I know that clipperlib can do it using callbacks. In a more general sense, unlike Matlab's mapping toolbox I'd like all polygon functions in the mapping package to be able to handle semi3D polygons (i.e.,polygons with different Zvalues for each vertex). Most of what I have made already does so.
OK, as far as I'm concerned to be continued later this week,
Philip
 View this message in context: http://octave.1599824.n4.nabble.com/GSoC16BooleanOperationsonPolygonsMergeCodetogeometryPackagetp4679083p4679230.html Sent from the Octave  Maintainers mailing list archive at Nabble.com.
I think that the Zvalues for the vertices might be pretty simple with the Boost.Geometry solution. We can define the point model in any manner we want internally for use by the Boost algorithms. This could easily be adapted to include a Zvalue. However, what you would probably need to give us is a specified algorithm for how to determine the Zvalue of the output vertices of an operation, based on the Zvalues of the inputs.
For example, if you are doing a difference between two polygons A and B as AB, can you assume that all the vertices of A have the same Zvalue and all the vertices of B have the same Zvalue? Should the output of the AB operation have the Zvalues of A, the Zvaluse of B, or the average of the Zvalues of A and B? I think that once the logic of how resultant Zvalues are determined that the implementation should be pretty straightforward, even if it is don’t as a “post” step after the Boost.Geometry polygon operation.
The nice thing about using the Zvalues is that we can just modify the various functions we have made (polyjoin, polysplit, poly2fv, polybool) so that they have an optional third parameter and will only include Zvalues in the output if it included Zvalues for the input.
John
Hi all, I think there is no sad thing about redundant functions. We should sort out whether we remove some of them or we make a frontend function to select them according to user's needs. Is poly2tri hosted somewhere (upstream)? if yes, then it is better to provide instructions to install it rather than to repack it inside geometry. Let see how fast we can merge all this neat work.
Unfortunately there are no packages for poly2tri in any of the major distributions. The project code was originally developed on code.google.com, which is now defunct. The original author transferred the repository to his Github account at https://github.com/greenm01. There haven’t been any updates in a couple of years on the main repository and a few on a branch at https://github.com/jhasse/poly2tri/commits/master that doesn’t some const parameter modifications, which I assume might allow the compile to optimize a little bit more.
We had included the source in the repository because it is only 12 files, but if you think we should pull it from Github as part of the build process, that is fine also.
Amr is working right now on making the configure check the version of Boost.Geometry that is available. His repository currently has the necessary Boost header files (Geometry is a headeronly library) in his repository. He is working to just use the system Boost. The reason we are checking the Boost.Geometry version is: a) If the version is < 1.60, then the selfintersection correction is not supported b) If the version is > 1.60, we then will check if the dissolve algorithm is included in the library (currently not available in 1.60 or 1.61, but planned for some future release) c) If the version is > 1.60 and the dissolve algorithm isn’t in the system Boost.Geometry, include the dissolve.h and dissolver.h files that are part of the package. These have been extracted from the Boost.Geometry repository (but are not part of the release tarballs). I guess they don’t think the dissolve algorithm is robust enough yet, but we haven’t seen any problems in all our test cases.
John S.


On Mon, Aug 15, 2016 at 10:55 PM, John Swensen < [hidden email]> wrote:
>
> On Aug 15, 2016, at 1:32 PM, Juan Pablo Carbajal < [hidden email]>
> wrote:
>
> On Mon, Aug 15, 2016 at 8:57 PM, John Swensen < [hidden email]> wrote:
>
>
> On Aug 15, 2016, at 11:31 AM, PhilipNienhuis < [hidden email]> wrote:
>
> John,
>
> It wasn't my intention to blame anyone :) I just made the observation
> that apparently some duplicate work has been done due to less than optimal
> communications. From my side setting insufficient priority (due to lack of
> time) is also to "blame"; probably the same goes for JuanPi. Well, that is
> how it goes with volunteer projects.
>
> However, the nottobeignored upside of that is that we now have choice; we
> can select the best solutions/implementations or make a combination of the
> best ones.
>
> I agree with what you wrote about polytri  AFAICS Matlab also suggests to
> use poly2fv rather than polycut. I just "made" polycut.m because I already
> had a similar implementation lying around. Initially I didn't even know
> about the existence of polycut in TMW's mapping toolbox, I just found that
> the use of branch cuts was one way of properly drawing of (nested) polygons
> with holes and initially my subfunction for that job was called
> "optimize_branch_cuts" (it is in shapedraw.m in the mapping package).
>
> A remaining question for me is how to interpolate clipped Zvalues. In my
> work I often have "3D"planes (e.g., polygons of semi3D tiles of geological
> strata) that I want to visualize in 3D views. I know that clipperlib can do
> it using callbacks.
> In a more general sense, unlike Matlab's mapping toolbox I'd like all
> polygon functions in the mapping package to be able to handle semi3D
> polygons (i.e.,polygons with different Zvalues for each vertex). Most of
> what I have made already does so.
>
> OK, as far as I'm concerned to be continued later this week,
>
> Philip
>
>
>
> 
> View this message in context:
> http://octave.1599824.n4.nabble.com/GSoC16BooleanOperationsonPolygonsMergeCodetogeometryPackagetp4679083p4679230.html> Sent from the Octave  Maintainers mailing list archive at Nabble.com.
>
>
> I think that the Zvalues for the vertices might be pretty simple with the
> Boost.Geometry solution. We can define the point model in any manner we want
> internally for use by the Boost algorithms. This could easily be adapted to
> include a Zvalue. However, what you would probably need to give us is a
> specified algorithm for how to determine the Zvalue of the output vertices
> of an operation, based on the Zvalues of the inputs.
>
> For example, if you are doing a difference between two polygons A and B as
> AB, can you assume that all the vertices of A have the same Zvalue and all
> the vertices of B have the same Zvalue? Should the output of the AB
> operation have the Zvalues of A, the Zvaluse of B, or the average of the
> Zvalues of A and B? I think that once the logic of how resultant Zvalues
> are determined that the implementation should be pretty straightforward,
> even if it is don’t as a “post” step after the Boost.Geometry polygon
> operation.
>
> The nice thing about using the Zvalues is that we can just modify the
> various functions we have made (polyjoin, polysplit, poly2fv, polybool) so
> that they have an optional third parameter and will only include Zvalues in
> the output if it included Zvalues for the input.
>
> John
>
>
> Hi all,
>
> I think there is no sad thing about redundant functions. We should
> sort out whether we remove some of them or we make a frontend function
> to select them according to user's needs.
> Is poly2tri hosted somewhere (upstream)? if yes, then it is better to
> provide instructions to install it rather than to repack it inside
> geometry.
>
> Let see how fast we can merge all this neat work.
>
>
> Unfortunately there are no packages for poly2tri in any of the major
> distributions. The project code was originally developed on code.google.com,
> which is now defunct. The original author transferred the repository to his
> Github account at https://github.com/greenm01. There haven’t been any
> updates in a couple of years on the main repository and a few on a branch at
> https://github.com/jhasse/poly2tri/commits/master that doesn’t some const
> parameter modifications, which I assume might allow the compile to optimize
> a little bit more.
>
> We had included the source in the repository because it is only 12 files,
> but if you think we should pull it from Github as part of the build process,
> that is fine also.
>
If the project is abandoned I guess we can ship it with geometry.
However I would include it inside the src folder.
> Amr is working right now on making the configure check the version of
> Boost.Geometry that is available. His repository currently has the necessary
> Boost header files (Geometry is a headeronly library) in his repository. He
> is working to just use the system Boost. The reason we are checking the
> Boost.Geometry version is:
> a) If the version is < 1.60, then the selfintersection correction is not
> supported
> b) If the version is > 1.60, we then will check if the dissolve algorithm is
> included in the library (currently not available in 1.60 or 1.61, but
> planned for some future release)
> c) If the version is > 1.60 and the dissolve algorithm isn’t in the system
> Boost.Geometry, include the dissolve.h and dissolver.h files that are part
> of the package. These have been extracted from the Boost.Geometry repository
> (but are not part of the release tarballs). I guess they don’t think the
> dissolve algorithm is robust enough yet, but we haven’t seen any problems in
> all our test cases.
>
> John S.


Dear Juan,
I can easily move the include directory from the root path of the package to the src directory.
Will this be more convenient to you?
Amr
From: Juan Pablo Carbajal2 [via Octave] <mlnode+[hidden email]>
Sent: Tuesday, August 16, 2016 12:23 PM
To: AMR_KELEG
Subject: Re: GSoC '16  Boolean Operations on Polygons : Merge Code to geometry Package
On Mon, Aug 15, 2016 at 10:55 PM, John Swensen < [hidden email]> wrote:
>
> On Aug 15, 2016, at 1:32 PM, Juan Pablo Carbajal < [hidden email]>
> wrote:
>
> On Mon, Aug 15, 2016 at 8:57 PM, John Swensen < [hidden email]> wrote:
>
>
> On Aug 15, 2016, at 11:31 AM, PhilipNienhuis < [hidden email]> wrote:
>
> John,
>
> It wasn't my intention to blame anyone :) I just made the observation
> that apparently some duplicate work has been done due to less than optimal
> communications. From my side setting insufficient priority (due to lack of
> time) is also to "blame"; probably the same goes for JuanPi. Well, that is
> how it goes with volunteer projects.
>
> However, the nottobeignored upside of that is that we now have choice; we
> can select the best solutions/implementations or make a combination of the
> best ones.
>
> I agree with what you wrote about polytri  AFAICS Matlab also suggests to
> use poly2fv rather than polycut. I just "made" polycut.m because I already
> had a similar implementation lying around. Initially I didn't even know
> about the existence of polycut in TMW's mapping toolbox, I just found that
> the use of branch cuts was one way of properly drawing of (nested) polygons
> with holes and initially my subfunction for that job was called
> "optimize_branch_cuts" (it is in shapedraw.m in the mapping package).
>
> A remaining question for me is how to interpolate clipped Zvalues. In my
> work I often have "3D"planes (e.g., polygons of semi3D tiles of geological
> strata) that I want to visualize in 3D views. I know that clipperlib can do
> it using callbacks.
> In a more general sense, unlike Matlab's mapping toolbox I'd like all
> polygon functions in the mapping package to be able to handle semi3D
> polygons (i.e.,polygons with different Zvalues for each vertex). Most of
> what I have made already does so.
>
> OK, as far as I'm concerned to be continued later this week,
>
> Philip
>
>
>
> 
> View this message in context:
>
http://octave.1599824.n4.nabble.com/GSoC16BooleanOperationsonPolygonsMergeCodetogeometryPackagetp4679083p4679230.html
> Sent from the Octave  Maintainers mailing list archive at Nabble.com.
>
>
> I think that the Zvalues for the vertices might be pretty simple with the
> Boost.Geometry solution. We can define the point model in any manner we want
> internally for use by the Boost algorithms. This could easily be adapted to
> include a Zvalue. However, what you would probably need to give us is a
> specified algorithm for how to determine the Zvalue of the output vertices
> of an operation, based on the Zvalues of the inputs.
>
> For example, if you are doing a difference between two polygons A and B as
> AB, can you assume that all the vertices of A have the same Zvalue and all
> the vertices of B have the same Zvalue? Should the output of the AB
> operation have the Zvalues of A, the Zvaluse of B, or the average of the
> Zvalues of A and B? I think that once the logic of how resultant Zvalues
> are determined that the implementation should be pretty straightforward,
> even if it is don’t as a “post” step after the Boost.Geometry polygon
> operation.
>
> The nice thing about using the Zvalues is that we can just modify the
> various functions we have made (polyjoin, polysplit, poly2fv, polybool) so
> that they have an optional third parameter and will only include Zvalues in
> the output if it included Zvalues for the input.
>
> John
>
>
> Hi all,
>
> I think there is no sad thing about redundant functions. We should
> sort out whether we remove some of them or we make a frontend function
> to select them according to user's needs.
> Is poly2tri hosted somewhere (upstream)? if yes, then it is better to
> provide instructions to install it rather than to repack it inside
> geometry.
>
> Let see how fast we can merge all this neat work.
>
>
> Unfortunately there are no packages for poly2tri in any of the major
> distributions. The project code was originally developed on code.google.com,
> which is now defunct. The original author transferred the repository to his
> Github account at
https://github.com/greenm01. There haven’t been any
> updates in a couple of years on the main repository and a few on a branch at
>
https://github.com/jhasse/poly2tri/commits/master that doesn’t some const
> parameter modifications, which I assume might allow the compile to optimize
> a little bit more.
>
> We had included the source in the repository because it is only 12 files,
> but if you think we should pull it from Github as part of the build process,
> that is fine also.
>
If the project is abandoned I guess we can ship it with geometry.
However I would include it inside the src folder.
> Amr is working right now on making the configure check the version of
> Boost.Geometry that is available. His repository currently has the necessary
> Boost header files (Geometry is a headeronly library) in his repository. He
> is working to just use the system Boost. The reason we are checking the
> Boost.Geometry version is:
> a) If the version is < 1.60, then the selfintersection correction is not
> supported
> b) If the version is > 1.60, we then will check if the dissolve algorithm is
> included in the library (currently not available in 1.60 or 1.61, but
> planned for some future release)
> c) If the version is > 1.60 and the dissolve algorithm isn’t in the system
> Boost.Geometry, include the dissolve.h and dissolver.h files that are part
> of the package. These have been extracted from the Boost.Geometry repository
> (but are not part of the release tarballs). I guess they don’t think the
> dissolve algorithm is robust enough yet, but we haven’t seen any problems in
> all our test cases.
>
> John S.
To unsubscribe from GSoC '16  Boolean Operations on Polygons : Merge Code to geometry Package,
click here.
NAML


On Wed, Aug 17, 2016 at 8:46 AM, AMR_KELEG < [hidden email]> wrote:
> Dear Juan,
>
> I can easily move the include directory from the root path of the package to
> the src directory.
> Will this be more convenient to you?
>
> Amr
>
> ________________________________
> From: Juan Pablo Carbajal2 [via Octave] <mlnode+[hidden email]>
> Sent: Tuesday, August 16, 2016 12:23 PM
> To: AMR_KELEG
> Subject: Re: GSoC '16  Boolean Operations on Polygons : Merge Code to
> geometry Package
>
> On Mon, Aug 15, 2016 at 10:55 PM, John Swensen <[hidden email]> wrote:
>
>>
>> On Aug 15, 2016, at 1:32 PM, Juan Pablo Carbajal <[hidden email]>
>> wrote:
>>
>> On Mon, Aug 15, 2016 at 8:57 PM, John Swensen <[hidden email]> wrote:
>>
>>
>> On Aug 15, 2016, at 11:31 AM, PhilipNienhuis <[hidden email]> wrote:
>>
>> John,
>>
>> It wasn't my intention to blame anyone :) I just made the observation
>> that apparently some duplicate work has been done due to less than optimal
>> communications. From my side setting insufficient priority (due to lack of
>> time) is also to "blame"; probably the same goes for JuanPi. Well, that is
>> how it goes with volunteer projects.
>>
>> However, the nottobeignored upside of that is that we now have choice;
>> we
>> can select the best solutions/implementations or make a combination of the
>> best ones.
>>
>> I agree with what you wrote about polytri  AFAICS Matlab also suggests to
>> use poly2fv rather than polycut. I just "made" polycut.m because I already
>> had a similar implementation lying around. Initially I didn't even know
>> about the existence of polycut in TMW's mapping toolbox, I just found that
>> the use of branch cuts was one way of properly drawing of (nested)
>> polygons
>> with holes and initially my subfunction for that job was called
>> "optimize_branch_cuts" (it is in shapedraw.m in the mapping package).
>>
>> A remaining question for me is how to interpolate clipped Zvalues. In my
>> work I often have "3D"planes (e.g., polygons of semi3D tiles of
>> geological
>> strata) that I want to visualize in 3D views. I know that clipperlib can
>> do
>> it using callbacks.
>> In a more general sense, unlike Matlab's mapping toolbox I'd like all
>> polygon functions in the mapping package to be able to handle semi3D
>> polygons (i.e.,polygons with different Zvalues for each vertex). Most of
>> what I have made already does so.
>>
>> OK, as far as I'm concerned to be continued later this week,
>>
>> Philip
>>
>>
>>
>> 
>> View this message in context:
>>
>> http://octave.1599824.n4.nabble.com/GSoC16BooleanOperationsonPolygonsMergeCodetogeometryPackagetp4679083p4679230.html>> Sent from the Octave  Maintainers mailing list archive at Nabble.com.
>>
>>
>> I think that the Zvalues for the vertices might be pretty simple with the
>> Boost.Geometry solution. We can define the point model in any manner we
>> want
>> internally for use by the Boost algorithms. This could easily be adapted
>> to
>> include a Zvalue. However, what you would probably need to give us is a
>> specified algorithm for how to determine the Zvalue of the output
>> vertices
>> of an operation, based on the Zvalues of the inputs.
>>
>> For example, if you are doing a difference between two polygons A and B as
>> AB, can you assume that all the vertices of A have the same Zvalue and
>> all
>> the vertices of B have the same Zvalue? Should the output of the AB
>> operation have the Zvalues of A, the Zvaluse of B, or the average of the
>> Zvalues of A and B? I think that once the logic of how resultant Zvalues
>> are determined that the implementation should be pretty straightforward,
>> even if it is don’t as a “post” step after the Boost.Geometry polygon
>> operation.
>>
>> The nice thing about using the Zvalues is that we can just modify the
>> various functions we have made (polyjoin, polysplit, poly2fv, polybool) so
>> that they have an optional third parameter and will only include Zvalues
>> in
>> the output if it included Zvalues for the input.
>>
>> John
>>
>>
>> Hi all,
>>
>> I think there is no sad thing about redundant functions. We should
>> sort out whether we remove some of them or we make a frontend function
>> to select them according to user's needs.
>> Is poly2tri hosted somewhere (upstream)? if yes, then it is better to
>> provide instructions to install it rather than to repack it inside
>> geometry.
>>
>> Let see how fast we can merge all this neat work.
>>
>>
>> Unfortunately there are no packages for poly2tri in any of the major
>> distributions. The project code was originally developed on
>> code.google.com,
>> which is now defunct. The original author transferred the repository to
>> his
>> Github account at https://github.com/greenm01. There haven’t been any
>> updates in a couple of years on the main repository and a few on a branch
>> at
>> https://github.com/jhasse/poly2tri/commits/master that doesn’t some const
>> parameter modifications, which I assume might allow the compile to
>> optimize
>> a little bit more.
>>
>> We had included the source in the repository because it is only 12 files,
>> but if you think we should pull it from Github as part of the build
>> process,
>> that is fine also.
>>
> If the project is abandoned I guess we can ship it with geometry.
> However I would include it inside the src folder.
>
>> Amr is working right now on making the configure check the version of
>> Boost.Geometry that is available. His repository currently has the
>> necessary
>> Boost header files (Geometry is a headeronly library) in his repository.
>> He
>> is working to just use the system Boost. The reason we are checking the
>> Boost.Geometry version is:
>> a) If the version is < 1.60, then the selfintersection correction is not
>> supported
>> b) If the version is > 1.60, we then will check if the dissolve algorithm
>> is
>> included in the library (currently not available in 1.60 or 1.61, but
>> planned for some future release)
>> c) If the version is > 1.60 and the dissolve algorithm isn’t in the system
>> Boost.Geometry, include the dissolve.h and dissolver.h files that are part
>> of the package. These have been extracted from the Boost.Geometry
>> repository
>> (but are not part of the release tarballs). I guess they don’t think the
>> dissolve algorithm is robust enough yet, but we haven’t seen any problems
>> in
>> all our test cases.
>>
>> John S.
>
>
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://octave.1599824.n4.nabble.com/GSoC16BooleanOperationsonPolygonsMergeCodetogeometryPackagetp4679083p4679247.html> To unsubscribe from GSoC '16  Boolean Operations on Polygons : Merge Code
> to geometry Package, click here.
> NAML
>
> ________________________________
> View this message in context: Re: GSoC '16  Boolean Operations on Polygons
> : Merge Code to geometry Package
>
> Sent from the Octave  Maintainers mailing list archive at Nabble.com.
That will be great. It is an orderly package structure, src contains
source files.


AMR_KELEG wrote
PhilipNienhuis wrote
amr mohamed wrote
Dear all,
I would like to start contacting the Geometry package's maintainer so that we can decide how the code will be merged during the next days.
I implemented some functions as cc files and the package currently has only .m functions.
So, I will try to structure the src directory as in the image package ( https://sourceforge.net/p/octave/image/ci/default/tree/src/).
The functions make use of the Boost library (>=1.60) so my Mentor told me that we will need to make a dependency for this version of Boost instead of adding the boostgeometry library as a part of the package.
However, If i were the user, i won't know how should i download the required version of Boost library and make octave's function use it.
(mapping package maintainer here, just a quick note as I'm on vacation with patchy Internet access until somewhere next week.)
Thanks for this work, a welcome contribution IMO.
Once it is included in the geometry package the mapping package will make use of it as well, several functions for that are almost finished. See a.o., savannah.gnu.org/patch/index.php?9000 for some developments along that line.
I have a few questions, mainly because I missed all progress on this GSOC project as I somehow missed blogs and progress reports might be my own fault :).
1. Is the entire boost library required or just a subset? Last time I looked boost comprised some 105 MB of a maze of include files, of which only a fairly small subset is required for boolean ops on polygons.
2. Did you implement interpolation of Zvalues on clipped polygon sides? That is something I discussed with John Swensen; it would be a useful asset for the mapping package as unlike its Matlab counterpart many of its polygon functions accept polygons with Zvalues and 3D polygons.
3. Similarly did you implement drawing polygons with holes using e.g., the polytri library? also something that came up in discussions with John S.
4. Where is your code currently hosted?
Philip
1No, i have manually removed unnecessary parts of the library so it reduced to approximately 14MB.
I think we can minimize the headers size to less than 10MB.
2No, We discussed adding a z coordinate to the polygons during our first chat (last May) and he told me to postpone it for now.
3Yes, we are drawing polygons with holes removed.
But, functions currently aren't working well with complex selfintersecting polygons as the Boost Geometry dissolve function that is used to solve selfintersections is still unstable (under the library's extension and not part of the core library).
4The clone of the package is hosted on bitbucket here:
https://bitbucket.org/amr_keleg/octavegeometryAnd kindly find my blog where i posted the project's progress.
https://amrkeleg.wordpress.com/Amr
Hi Amr,
Tonight I cloned your bitbucket repo and found that you already have done a nice job of integrating your work into the geometry package. Wow.
I presume polytri is included in the src/ subdir.
Yet I need some guidance as to what parts of the boost library need to be installed where to be able to install & build the geometry package.
Just pretend I am a n00b; now how to get what required boost library parts and where to put them? (I suppose in <OCTAVE_HOME>/include/boost ?)
Can you enlighten me a little, please?
Philip


PhilipNienhuis wrote
AMR_KELEG wrote
PhilipNienhuis wrote
amr mohamed wrote
Dear all,
I would like to start contacting the Geometry package's maintainer so that we can decide how the code will be merged during the next days.
I implemented some functions as cc files and the package currently has only .m functions.
So, I will try to structure the src directory as in the image package ( https://sourceforge.net/p/octave/image/ci/default/tree/src/).
The functions make use of the Boost library (>=1.60) so my Mentor told me that we will need to make a dependency for this version of Boost instead of adding the boostgeometry library as a part of the package.
However, If i were the user, i won't know how should i download the required version of Boost library and make octave's function use it.
(mapping package maintainer here, just a quick note as I'm on vacation with patchy Internet access until somewhere next week.)
Thanks for this work, a welcome contribution IMO.
Once it is included in the geometry package the mapping package will make use of it as well, several functions for that are almost finished. See a.o., savannah.gnu.org/patch/index.php?9000 for some developments along that line.
I have a few questions, mainly because I missed all progress on this GSOC project as I somehow missed blogs and progress reports might be my own fault :).
1. Is the entire boost library required or just a subset? Last time I looked boost comprised some 105 MB of a maze of include files, of which only a fairly small subset is required for boolean ops on polygons.
2. Did you implement interpolation of Zvalues on clipped polygon sides? That is something I discussed with John Swensen; it would be a useful asset for the mapping package as unlike its Matlab counterpart many of its polygon functions accept polygons with Zvalues and 3D polygons.
3. Similarly did you implement drawing polygons with holes using e.g., the polytri library? also something that came up in discussions with John S.
4. Where is your code currently hosted?
Philip
1No, i have manually removed unnecessary parts of the library so it reduced to approximately 14MB.
I think we can minimize the headers size to less than 10MB.
2No, We discussed adding a z coordinate to the polygons during our first chat (last May) and he told me to postpone it for now.
3Yes, we are drawing polygons with holes removed.
But, functions currently aren't working well with complex selfintersecting polygons as the Boost Geometry dissolve function that is used to solve selfintersections is still unstable (under the library's extension and not part of the core library).
4The clone of the package is hosted on bitbucket here:
https://bitbucket.org/amr_keleg/octavegeometryAnd kindly find my blog where i posted the project's progress.
https://amrkeleg.wordpress.com/Amr
Hi Amr,
Tonight I cloned your bitbucket repo and found that you already have done a nice job of integrating your work into the geometry package. Wow.
I presume polytri is included in the src/ subdir.
Yet I need some guidance as to what parts of the boost library need to be installed where to be able to install & build the geometry package.
Just pretend I am a n00b; now how to get what required boost library parts and where to put them? (I suppose in <OCTAVE_HOME>/include/boost ?)
Can you enlighten me a little, please?
Philip
Dear Philip,
Yes, poly2tri is part of the package for now.
I am using Ubuntu 16.04 so i will mention simple instructions from my perspective.
The Boost Library should be located in any directory that is part of the $PATH environment variable.
So you need to add the Boost Library Header files in any of these directories.
On Ubuntu 16.04, you can also install the libraries using sudo apt install libboostalldev .
The recommended version is 1.60.
Amr


John Swensen wrote:
>
>> On Aug 15, 2016, at 11:31 AM, PhilipNienhuis < [hidden email]> wrote:
>>
>> John,
>>
>> It wasn't my intention to blame anyone :) I just made the observation
>> that apparently some duplicate work has been done due to less than optimal
>> communications. From my side setting insufficient priority (due to lack of
>> time) is also to "blame"; probably the same goes for JuanPi. Well, that is
>> how it goes with volunteer projects.
>>
>> However, the nottobeignored upside of that is that we now have choice; we
>> can select the best solutions/implementations or make a combination of the
>> best ones.
>>
>> I agree with what you wrote about polytri  AFAICS Matlab also suggests to
>> use poly2fv rather than polycut. I just "made" polycut.m because I already
>> had a similar implementation lying around. Initially I didn't even know
>> about the existence of polycut in TMW's mapping toolbox, I just found that
>> the use of branch cuts was one way of properly drawing of (nested) polygons
>> with holes and initially my subfunction for that job was called
>> "optimize_branch_cuts" (it is in shapedraw.m in the mapping package).
>>
>> A remaining question for me is how to interpolate clipped Zvalues. In my
>> work I often have "3D"planes (e.g., polygons of semi3D tiles of geological
>> strata) that I want to visualize in 3D views. I know that clipperlib can do
>> it using callbacks.
>> In a more general sense, unlike Matlab's mapping toolbox I'd like all
>> polygon functions in the mapping package to be able to handle semi3D
>> polygons (i.e.,polygons with different Zvalues for each vertex). Most of
>> what I have made already does so.
>>
>> OK, as far as I'm concerned to be continued later this week,
>>
>> Philip
>>
>>
>>
>> 
>> View this message in context: http://octave.1599824.n4.nabble.com/GSoC16BooleanOperationsonPolygonsMergeCodetogeometryPackagetp4679083p4679230.html>> Sent from the Octave  Maintainers mailing list archive at Nabble.com.
>>
>
> I think that the Zvalues for the vertices might be pretty simple with the Boost.Geometry solution. We can define the point model in any manner we want internally for use by the Boost algorithms. This could easily be adapted to include a Zvalue. However, what you would probably need to give us is a specified algorithm for how to determine the Zvalue of the output vertices of an operation, based on the Zvalues of the inputs.
>
> For example, if you are doing a difference between two polygons A and B as AB, can you assume that all the vertices of A have the same Zvalue and all the vertices of B have the same Zvalue? Should the output of the AB operation have the Zvalues of A, the Zvaluse of B, or the average of the Zvalues of A and B? I think that once the logic of how resultant Zvalues are determined that the implementation should be pretty straightforward, even if it is don’t as a “post” step after the Boost.Geometry polygon operation.
<sorry for a bit of delay in answering>
My interest is mainly in clipping polygons ("AND"). Other boolean
operations are less of interest for me, although I think that the basic
principles of what I want are similar.
The polygons I work with contain Zvalue attributes that can differ for
each individual vertex. Those "Z"values need not be coordinates like X
or Y (but sometimes are). To me they're just values of some property
that varies over the subject polygon.
What I needed up till now, and AFAICS for foreseeable future, is a
simple linear interpolation of (one or more) Zvalues between subject
polygon vertices along the side connecting those subject polygon
vertices  i.e., interpolated Zvalue(s) for each "new" vertex resulting
from polygon clipping operations.
So in case of some clipping polygon that zigzags e.g. ten times between
two subject polygon vertices, ten new vertices are created each of one
would need Zvalues linearly interpolated between the Zvalues of the
original subject polygon.
Thinking more about it, what would really be useful is rather a relative
value (0  1, or 0  100 %) for the distance of such a new vertex from
one subject polygon vertex to the other subject polygon vertex, e.g. in
clockwise direction. That way I can more easily work with e.g. Zvalues
that depend on yet other factors, e.g., change in time.
Is what I wrote is clear enough?
Philip

