Make read_polygon_shapefile place read-coordinates in the right order. - #627
Make read_polygon_shapefile place read-coordinates in the right order.#627thomcom wants to merge 2 commits into
read_polygon_shapefile place read-coordinates in the right order.#627Conversation
|
|
||
| auto random_walk_func = [segment_length](auto const& prev, auto const& rad) { | ||
| return cartesian_2d<T>{prev.x + segment_length * rad.x, prev.y + segment_length * rad.y}; | ||
| return cartesian_2d<T>({prev.x + segment_length * rad.x, prev.y + segment_length * rad.y}); |
There was a problem hiding this comment.
Please don't include this change in this PR. I don't agree that this is the right way to fix this issue, and we haven't even root-caused the issue yet. I have been discussing it with @trxcllnt
There was a problem hiding this comment.
I'll be sure to remove it before this is finalized.
|
|
||
| // append points in reverse order | ||
| for (cudf::size_type i = num_vertices - 1; i >= 0; i--) { | ||
| for (cudf::size_type i = 0; i < num_vertices; ++i) { |
There was a problem hiding this comment.
I interpreted @zhangjianting 's comment here: #609 (comment) to mean that clockwise vs. counterclockwise is a matter of choice since the OGC and ESRI shapefile formats are opposites. In which case why not either leave this as-is, or provide a parameter to specify which is expected?
There was a problem hiding this comment.
Providing a parameter might be the way to go here, just in case. In this context, GeoPandas is used to read a shapefile and read_polygon_shapefile is used to read a shapefile. While both are valid technically, the coordinates are wound in the opposite direction for the result that is produced by read_polygon_shapefile which is why I want to introduce this change.
Co-authored-by: Mark Harris <mharris@nvidia.com>
|
Abandoned in favor of #609 |
read_polygon_shapefileinserts the coordinates in the opposite order. This PR fixes that issue. I also wrote a pip test inpolygon_shapefile_reader_test.cpp, thinking that would prove that the ordering mattered.However, the pip test works in both cases - it does not test for pip based on the "left hand rule" of point-to-linesegment projection. I'm looking at writing a different test to demonstrate the winding.