You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One feature that was brought up on that xarray/geoxarray issue was wanting to be able to take a CRS-like object and use the getitem method to use bracket access to projection parameters like my_crs['lon_0'] or something like that. Not sure if proj.4 parameter naming is the best thing, but yeah it was brought up and I think it could be a good idea. Not sure how to accomplish this with the current interfaces though given how everything is split up in to its own class.
So the requested feature here is perhaps about an easy way to access parameters. Right now how you would do it is by recursively accessing the correct nested sub-elements. E.g. metermultiplier = crs.toplevel.unit.unitmultiplier.value. In a way this would be the correct way to do it, as things would be logically grouped.
I could see the usefulness of also providing more convenient access in a way that kind of "searches" for the parameters for you based on the name, without the user needing to know about their nested structure. As you say, using the proj4 names may not be ideal here, but then again, all naming conventions come from one or another format spec, so it really just depends what you're used to I guess.
One way might be to implement a "get" and "set" method, where you could also supply which format you are using for your search and for the supplied and return values. That way, users more familiar with proj4 could use that, or those familiar with OGC WKT could use that, etc.
The text was updated successfully, but these errors were encountered:
@djhoese wrote:
So the requested feature here is perhaps about an easy way to access parameters. Right now how you would do it is by recursively accessing the correct nested sub-elements. E.g.
metermultiplier = crs.toplevel.unit.unitmultiplier.value
. In a way this would be the correct way to do it, as things would be logically grouped.I could see the usefulness of also providing more convenient access in a way that kind of "searches" for the parameters for you based on the name, without the user needing to know about their nested structure. As you say, using the proj4 names may not be ideal here, but then again, all naming conventions come from one or another format spec, so it really just depends what you're used to I guess.
One way might be to implement a "get" and "set" method, where you could also supply which format you are using for your search and for the supplied and return values. That way, users more familiar with proj4 could use that, or those familiar with OGC WKT could use that, etc.
The text was updated successfully, but these errors were encountered: