-
Notifications
You must be signed in to change notification settings - Fork 2
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
Add support for GI.crs
#24
Comments
Yes we are in the middle of fixing this globally using DataAPI metadata. See: Maybe jump on to that issue if you have suggestions, or want to finish the PR with some tests and docs |
You could also PR here to actually attach metadata to the DataFrame, followilling the standard in that PR |
Got it, I'll wait for the GeoInterface PR to be merged so I can make a PR adding the CRS to the metadata. |
It seems that the GeoInterface PR is already well underway, I will make the PR adding the CRS in the metadata |
Yeah the standard is pretty set so feel free to add it. Loading GeoDataFrames will make this just work even now. |
Regarding the other question by @eliascarv:
What is the reason to depend on DataFrames.jl for this package? |
That sounds like a better approach to me too. We need the metadata either way but it should be attached to the |
The
GeoParquet.read
function returns aDataFrame
, which I imagine is what prevents theGI.crs
function from being implemented, as that would be type piracy. Perhaps returning a wrapper type that implements the Tables.jl interface would be a viable solution?Here is an example of a file that has CRS, but is not returned by the
GI.crs
function:Link to download the
example.parquet
file: https://github.com/opengeospatial/geoparquet/raw/v1.0.0/examples/example.parquetThe text was updated successfully, but these errors were encountered: