octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GSoC 2017 - Implement boolean operations on polygons


From: John Swensen
Subject: Re: GSoC 2017 - Implement boolean operations on polygons
Date: Tue, 21 Mar 2017 10:20:05 -0700

> On Mar 17, 2017, at 3:12 PM, Philip Nienhuis <address@hidden> wrote:
> 
> I have been meaning to dig into the Boost::Geometry examples at [3] to
>> see if I can implement an iterator facade for a custom polygon object
>> that allows us to operate directly on the octave data input without
>> having to copy all the points into the Boost::Geometry model for points,
>> rings, polygons, and multi-polygons. I think it should be possible. It
>> may speed up execution because we aren’t copying a bunch of double
>> values, but it should most certainly reduce memory usage a ton. If we
>> could push the performance/resources even better than now, it might be a
>> compelling reason to keep Boost.
> 
> (Maybe I do not fully understand your aim.)
> For any polygon library the input data will have to be morphed somehow from 
> the application/use case at hand into a format that the polygon library 
> expects; vice versa for output.
> I'm unsure if investing a lot of work in specialized data access in some .oct 
> file is better than clever and vectorized preprocessing at the Octave side. 
> The latter is much more flexible and adaptable to the use case at hand.
> 
> The Clipper library currently comprises a .mex wrapper file (in the Third 
> party subdir, in recent Clipper releases pointing to Matlab Central).
> While working on polyline clipping I noted there's quite some code required 
> to copy info from/to the structs that constitute the IMO rigid MEX data I/O 
> structures.  I suppose some of that code can be avoided, or reduced, by 
> rewriting the .mex wrapper into a proper .oct file using octave_value 
> objects.  That'll give more flexibility as well. I suppose even the 
> double<->int64 preprocessing can be absorbed in the .oct file (currently I've 
> put that in an .m file wrapper).
> 

I was only planning on making the specialized data access for the inputs to 
Boost so that it could operate directly on the fortran_vec() data pointer 
directly. Then, there would be no need for a complete memory duplication of the 
polygons being passed in. For large datasets like coastlines and other GIS 
data, this could be both memory and computationally prohibitive. Of course, the 
result of the Boost::Geometry operation would always need to be transformed 
into the appropriate Octave datatype for return.


>> One other option is to use the Boost-provided bcp utility to create the
>> subset of Boost headers that is are needed to compile Boost::Geometry
>> and include it in the package release. This is still 30MB uncompressed,
>> but it is much smaller than the whole Boost. this would also allow us to
>> distribute a version that has the self-intersection correction.
> 
> IIRC Amr mentioned he had brought down the boost stuff to around 11 or 12 MB.
> I think the Boost include files shouldn't be in the geometry package 
> directory; they'd rather live in /usr/include.
> 

I guess I am somewhat of the opinion that maybe the Boost headers should be 
included. Even the 30MB I was talking about compresses down to about 1.2MB and 
then we could ensure that they are always a set of headers that supports the 
code in the package and self-intersection correction. The uncompressed size is 
really only an issue for those who are building the package, but 30MB shouldn’t 
really be an issue for a temporary build step. I’m not sure what the Boost 
license looks like in terms of including headers in another project, though.


John S.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]