[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.
- Re: GSoC 2017 - Implement boolean operations on polygons, (continued)
- Re: GSoC 2017 - Implement boolean operations on polygons, piyushjain, 2017/03/16
- Re: GSoC 2017 - Implement boolean operations on polygons, Juan Pablo Carbajal, 2017/03/16
- Re: GSoC 2017 - Implement boolean operations on polygons, PhilipNienhuis, 2017/03/17
- Re: GSoC 2017 - Implement boolean operations on polygons, Juan Pablo Carbajal, 2017/03/17
- Re: GSoC 2017 - Implement boolean operations on polygons, Philip Nienhuis, 2017/03/17
- Re: GSoC 2017 - Implement boolean operations on polygons, John Swensen, 2017/03/17
- Re: GSoC 2017 - Implement boolean operations on polygons, Juan Pablo Carbajal, 2017/03/17
- Re: GSoC 2017 - Implement boolean operations on polygons, Philip Nienhuis, 2017/03/17
- Re: GSoC 2017 - Implement boolean operations on polygons, John Swensen, 2017/03/17
- Re: GSoC 2017 - Implement boolean operations on polygons, Philip Nienhuis, 2017/03/17
- Re: GSoC 2017 - Implement boolean operations on polygons,
John Swensen <=
- Re: GSoC 2017 - Implement boolean operations on polygons, John Swensen, 2017/03/21
- Re: GSoC 2017 - Implement boolean operations on polygons, piyushjain, 2017/03/17
- Re: GSoC 2017 - Implement boolean operations on polygons, piyushjain, 2017/03/18
- Re: GSoC 2017 - Implement boolean operations on polygons, Juan Pablo Carbajal, 2017/03/18
- Re: GSoC 2017 - Implement boolean operations on polygons, piyushjain, 2017/03/18
- Re: GSoC 2017 - Implement boolean operations on polygons, piyushjain, 2017/03/20
- Re: GSoC 2017 - Implement boolean operations on polygons, Leo Yi, 2017/03/21