-
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
Design how *blessed* implementation of GeoInterface would work as generic fallback. #141
Comments
Random thought: We choose a single blessed package, and implement the "type piracy" method as a package extension here at GeoInterface. So something like Then again, single blessed packages are restrictive (and no single one might've fully implemented the spec) so we could also go with the above package extension route, but add dispatch on the module (possible in 1.10, will be LTS soon):
edit: The |
Might be useful for inspiration on what to do, or probably, what not to do from Plots: https://github.com/JuliaPlots/Plots.jl/blob/master/src/backends.jl |
The package extension here would be a circular dependency, since any such package would have depend on GeoInterface. This is the same issue with GeoInterfaceMakie and GeoInterface geoms. |
seems pretty fragile - what if a dependency loads one of the packages that sets a backend? Maybe a set priority list would be better but I would rather centralize all of this in GeometryOps, at least until we understand how people use the design. It already has a LibGEOS backend for example, we could simply add more (GDAL, S2) as required. |
Hmm, I keep forgetting about that. :/ Well then, packages could implement |
I think we should instead deprecate GeoInterface methods like area. Using LibGEOS and GeometryOps methods directly is simpler and works on all objects without confusion over what package is doing what. But I think we should standardise the function form and arguments in the implementing packages. |
That seems like a no-regret action to me, like #134 for read/write. However, ideally we would somehow have a (correct for crs trait) default fallback that just works, just like Plots works out of the box. But it might be too hard to do correctly 🤷🏻 ? |
read/write is a good example! It's basically the same problem. So we're talking about an "interface" where package specific functions have an identical definition following a specification, rather than methods extending a single function. That's an interesting kind of interface. For ecosystem level user experience consistency rather than anything technical. We could test it with a test function that accepts the function as an argument and calls it on generic GeoInterface geoms and keywords. |
Ok, after our nice little talk and some reflection, let's deprecate the operations here 💥. Motivation; accessing geometries is fundamentally different from operations on geometries. Different type of geometries often come from file drivers (99% of our implementations), and have no operations. Operations are hard and scarce. Impact of doing this is probably minimal, and for the packages implementing area and such we should still implement GeoInterface.area(::Any) and related interface methods as fallback to not "break" the contract. But we do not document it, and only document GO for operations. In terms of operations we keep the package/module trait ( We might want to reconsider |
Or how we could use GeometryOps as a default implementation of methods such GeoInterface.area, for packages that do define a geometry, but not the method.
If GeometryOps now would implement
GeoInterface.area(::geomtrait, geom)
, it would be type piracy.The text was updated successfully, but these errors were encountered: