hello, I am a GSoC 2019 student working on
I am integrating the astronomical coordinate system with
boost::units currently coordinate system uses boost.geometry as the underlying framework and uses
geometry::model::point to store the coordinate data. Underlying data is always converted in SI units first and then stored.
I am facing some confusion and would like to get some suggestions.
suppose two coordinates are stored
(100cm, 200cm, 300cm) and
(400cm 500cm, 600cm). expected cross product result would be
(-30000cm, 60000cm, -30000cm).
But as I mentioned earlier all the coordinates are stored in SI units so actual points inside the class would be
(1m, 2m, 3m) and
(4m, 5m, 6m) and cross product of it would be
(-3m, 6m, -3m) and converting it back to
cm while returning because user originally stored it in
cm will result in
(-300cm, 600cm, -300cm)
Please correct me where I am wrong and what is the correct answer.
@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.