-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Swap to returning Tuples instead of LibGEOS.Point
for anything GeoInterface related
#190
Comments
After #191 it's at least type stable, but indeed, much copying is done. |
I think it can be 50x faster, for linestrings anyway |
Sure, but not sure whether this is the right place to do so. Libgeos should be consistent. What could work is making a single efficient copy to a GI Polygon/Ring for Ops to work on? |
We already did this for ArchGDAL for the same reason. We only need to be consistent with GeoInterface in GeoInterface methods. The idea is to do what your saying, but how could you do that in GeometryOps without a LibGeos dep? The only way I can see to do it is here in |
I like to keep packages internally consistent as well. I missed the ArchGDAL change, let me check that. Maybe this isn't needed with all the other activities. |
This is likely related to the memory leak too. We are creating LibGEOS
Point
objects for every single point we read in a geometry, but they're incredibly expensive and allocate objects that need to be finalized:LibGEOS.jl/src/geos_types.jl
Lines 29 to 50 in 7ad3b3c
Which leads to insane performance like this:
JuliaGeo/GeometryOps.jl#32
74 allocations to get the area of an 11 point geometry.
We also call
getPoint
:LibGEOS.jl/src/geos_functions.jl
Lines 1516 to 1546 in 7ad3b3c
We should replace all of this with just getting two floating point values in the simplest way possible, and getting them all at once for whole LinearRing/LineString in
GI.getpoint(linestring)
The text was updated successfully, but these errors were encountered: