-
Notifications
You must be signed in to change notification settings - Fork 15
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
Deprecate predicates and functions like area
#127
Comments
Can we de-deprecate them later on? I would like that when we have a blessed fallback in GeometryOps? A "blessed" implementatation means accepting it does pirate some times, we have seen similar things with WellKnownGeometry and GeoFormatTypes. |
GeometryOps already implements everything except buffer, convex hull, relate, and symdiff. I guess GeometryOps would define generic dispatches for all trait combinations, and then any GI consumer package can handle its own geometry? We would have to ensure there are no signatures like: AG.within(::PolygonTrait, ::PointTrait, ::IGeometry, ::Any) to avoid ambiguities when ArchGDAL and LibGEOS are loaded together, for example. |
Ideally (but I think the slowdown is maybe not acceptable) we could change these GeoInterface methods to give an extra warning on a MethodError: "Make an issue or do |
We can always add an error hint that checks whether GeometryOps is loaded in the current environment...I do something similar for reproject there. Checking |
A blessed implementation is another option. The reason I didn't push for that is that I'm a little woried about the edge cases: Like this is a problem: GI.contains(gdalgeom, gdalgeom) -> ArchGDAL
GI.contains(libgeosgeom, libgeosgeom) -> LibGEOS
GI.contains(libgeosgeom, gdalgeom) -> GeometryOps There will be a bunch or unpredictable behaviour like this where its not clear what package is doing what operation, where to take issues, who to trust. |
In practice these don't actually work (widely), because of dispatch. As far as I know only ArchGDAL and LibGEOS objects have both the methods and the objects to provide the dispatch.
A recent slack thread pointed out this problem:
GeoJSON doesn't have
contains
and likely never will, and shouldn't depend on a package that does have it. So we are stuck with the error.What GeoInterface does very well at this stage is let LibGEOS.jl and GeometryOps.jl provide their own predicates that work on any type that follows the GI interface.
GeometryOps.contains
orLibGEOS.contains
will already just work with GeoJSON.jl geoms with no dependency or special treatment.Unless we think of some other solution I suggest we deprecate these methods to avoid confusing users, and focus on the object interface that lets other packages define them.
(I also think this part of GI not working is a distraction from just how well the other parts of the interface work)
The text was updated successfully, but these errors were encountered: