Skip to content
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

Name overlaps #1

Open
asinghvi17 opened this issue Oct 25, 2024 · 6 comments
Open

Name overlaps #1

asinghvi17 opened this issue Oct 25, 2024 · 6 comments

Comments

@asinghvi17
Copy link
Member

e.g Rasters.reproject v/s GeometryOps.reproject, or similar overlaps.

Similarly for ArchGDAL and LibGEOS, etc.

What should we do about these? One option is to define a JuliaGeo.reproject that dispatches based on the type of the first argument (at least with Rasters it's fairly obvious). Depending on the number of intersections, it might make sense to add some methods stubs to GeometryOpsCore.

@evetion
Copy link
Member

evetion commented Oct 25, 2024

But do either packages also export those names? Your proposal is similar to JuliaGeo/GeoInterface.jl#141 no?

@asinghvi17
Copy link
Member Author

Both of them do 😅

@rafaqz
Copy link
Member

rafaqz commented Oct 25, 2024

It would work for Rasters but GO doesn't own any of the arguments. Putting it in GOCore would help with that

@asinghvi17
Copy link
Member Author

asinghvi17 commented Oct 25, 2024

I guess it kind of is, if we're doing this metapackage thing? But I don't think this is a very widespread problem, it's really just these two and a few others that intersect, not the entire API or something.

The main thing there was ArchGDAL, LibGEOS and GeometryOps. But if we're standardizing on GeometryOps then we don't necessarily need to create a blessed implementation. Rasters only overlaps with GeometryOps on three names of consequence:

julia> intersect(names(Rasters), names(GeometryOps))
5-element Vector{Symbol}:
 :Planar
 :Spherical
 :coverage
 :rebuild
 :reproject

Planar and Spherical are shared types via GeometryOpsCore so that's fine. It's just rebuild, coverage, and reproject that are issues.

Rasters should use GeometryOps coverage ideally, since they aim to do the same thing. We can explore dispatches for that.

Reproject can also be moved to GeometryOpsCore and Rasters can define a single dispatch on that.

Rebuild is more internal to GeometryOps, we don't necessarily need to export it I think.

@rafaqz
Copy link
Member

rafaqz commented Oct 26, 2024

Yeah rebuild is just my go to name for an extensible object reconstuctor. Only the Rasters one is exported.

coverage andreproject can extend GOCore

@rafaqz
Copy link
Member

rafaqz commented Dec 13, 2024

I'm thinking we just try to flesh out the functions we import (maybe always explicitly with using Package: func, func2 ?) and see where it breaks, then patch as we go?

Also just realised there are a bunch more clashes between Extents.jl predicates and GeometryOps.jl predicates.

Maybe we need special Geo.predicate function that then chose the Extents.jl/GeometryOps.jl predicate. Or... GeometryOps.jl extends Extents.jl predicates...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants