-
Notifications
You must be signed in to change notification settings - Fork 10
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
Accessor #10
Comments
Ideally it should also minimize the risk of a conflict with coordinate and variable names. There's no real consensus regarding how to name xarray extension packages and accessors, it varies from one package to another. If the package aims to provide a unique accessor, I'd tend to choose the same name for both the package and the accessor as it is easier to remember. I also like this pattern: |
True. That eliminates We can also consider following |
+1 |
It may be too premature, but I'm also wondering how would co-exist geometry and geography coordinates in a Dataset / DataArray? Should we reuse the same With the suggested API in https://github.com/martinfleis/xvec/pull/11#issuecomment-1334964188, any method called with |
I would try to match the behaviour of geopandas in relation to geometry/geography and that is not defined yet. We can potentially raise for unsupported ops when geography is passed, I assume that geopandas will do that as well. |
In some occasions (#4 #5) we mentioned that the accessor would be a nice addition here and could eventually expose a lot of what shapely/geopandas now offer.
What would be the ideal name, that is not ambiguous and minimises a risk of a conflict with another accessor by another package?
We mentioned
.vec
but that may not be the most intuitive..geo
is taken by geoxarray and does apply to both raster and vector anyway. What about using.geom
indicating an operation on geometry? That would also be consistent withGeometryIndex
.The text was updated successfully, but these errors were encountered: