awulkiew on develop
[test][arithmetic] Replace std:… (compare)
awulkiew on master
[sectionalize] Enable #include,… Merge branch 'develop' into bg-… Merge branch 'bg-prepare' (compare)
awulkiew on bg-prepare
[sectionalize] Enable #include,… Merge branch 'develop' into bg-… (compare)
awulkiew on develop
[sectionalize] Enable #include,… (compare)
@meastp Separate models for them are the most straightforward solution indeed. Besides of that:
You have to implement all strategies that are used in intersection, strategies calculating:
The problem I see is that internally we're considering segments as defined by 2 points, but in this case a segment is defined by 3 points. So I'd expect it to be an issue. You'd probably need some kind of thin wrapper around 3 points defining a segment between 2 first points. And this
circular_referring_segment should be passed into the utilities/strategies in algorithms instead of e.g. 2 points or linear segment or
referring_segment. So you'd also need some utility returning regular/linear
circular_referring_segmentbased on the tag of a geometry. Unless I'm missing something and it is possible to define a circular segment based on 2 points?
If the above fails and parts of circular segments cannot be represented as described above you'd have to write new versions of algorithms for these geometries as well as strategies.
But I think it should be possible to do it with 1 and 2. You could start with something simpler than intersection of 2 polygons. E.g.
relate(point, polygon) which needs less strategies. Or even
area(polygon) which needs only 1 strategy and you could straight away test if you need a separate algorithm or would
circular_referring_segment be enough.
Regarding the number of points in circular :point_up: July 15, 2019 7:37 AM
AFAIK, only requirement is that
CircularString has odd number of points, so it is composed from connected 3-point arc segments
lengthshould be the entry point.
areacould also be not that difficult (maybe replacing the determinants in shoelace formula with the area under the circular arc), for
centroidI am not sure, but those are a good start. The side predicates are implemented by @tinko92 here: boostorg/geometry#617
Speaking of which, @vissarion my implementation of uniform point distribution for LineStrings caches intermediate lengths and segments so that a single point can be interpolated in logarithmic, rather than linear time using binary search over the accumulated lengths. I now use line_interpolate for generating the point on a single segment now.
Do you think it would be sensible to make that caching in some way an option for line_interpolate for the benefit of users who repeatedly interpolate single points with varying max_distance over the same LineString? I am asking because I do not know what this algorithm is generally used for.
@tinko92 regarding caching I do not know of any particular use case for
line_interpolate I just implemented since it seems useful in GIS and there are many implementations of it in various libraries (
PostGIS included). But since you have already implemented I think it doesn't harm to add this functionality to
line_interpolate as long as it does not overcomplicate the user interface.
Regarding uniform points generated on a linestring, thanks for sharing your approach. I haven't reviewed your PR yet ;) An alternative would be to generate random numbers in [0,len] (where len := the length of the input linestring) sort them and then simply parse/navigate on the linestring by creating points in distances from the sorted list. That should be more efficient, as far as I can see.
@tinko92 & @meastp AFAIK, there is no plan to jump as far as C++20, not even C++17. The furthest stride that is being contemplated is C++14 but C++11 is currently a more likely option.
I'd suggest you to review and join the discussion here #590 and/or discuss details on the Boost.Geometry mailing list.
Gitter is not the best place to discuss important plans about the library future, as it is not monitored as well as the mailing list or GitHub and, most important, it is not properly publicly archived.