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

Is there a need to standardize geom and geometry across ecosystem #164

Open
alex-s-gardner opened this issue Sep 25, 2024 · 16 comments
Open

Comments

@alex-s-gardner
Copy link
Contributor

I'm finding geom and geometry used interchangeably but this creates some conflicts across package. It seems like some guidance might be needed:

Documenting some of what I've noticed:

@evetion uses geom in GeoDataFrames which then can not be passed directly to @rafaqz Raster.rasterize

@asinghvi17 also uses geom in GeometryOps

GeoInterface has a GeometryCollection but a function call that is getgeom

Shapefile creates a geometry column

@rafaqz
Copy link
Member

rafaqz commented Sep 25, 2024

We have GI.geometrycolumns to clarify these in many cases. GeometryOps should use it everywhere, we don't use :geom ? except in one tutorial because GADM.jl did.

:geometry is the standard fallback for GI.geometrycolumns

@evetion I noticed this the other day too, is there a reason to still use :geom in GeoDataFrames?

Also GADM.jl recently fixed their :geom column to :geometry: JuliaGeo/GADM.jl#69

@asinghvi17
Copy link
Member

Using :geom for geometry columns started because that was how ArchGDAL returned it, I think. Users might expect it now though? I'm not sure how that should be handled.

@rafaqz
Copy link
Member

rafaqz commented Sep 25, 2024

We should as much as possible standardise table columns, it's worth the long term simplicity

@alex-s-gardner
Copy link
Contributor Author

alex-s-gardner commented Sep 25, 2024

Understanding that GI.geometrycolumns is being implemented making this less of an issue:

e.g.
which one if I'm package blind?

GeometryOps.intersects.(geomA[:, :geometry], geomB[:, :geom])
GeometryOps.intersects.(geomA[:, :geo], geomB[:, :geometry])
GeometryOps.intersects.(geomA[:, :geometry], geomB[:, :geometry])
GeometryOps.intersects.(geomA[:, :geom], geomB[:, :geom])

or just

GeometryOps.intersects.(geomA[:, :geometry], geomB[:, :geometry])

@asinghvi17
Copy link
Member

asinghvi17 commented Sep 25, 2024

GeometryOps.intersects.(geomA[:, first(GI.geometrycolumns(geomA))], geomB[:, first(GI.geometrycolumns(geomB))]) is the "correct" solution at this point but it's a mouthful. If you aren't using GeoDataFrames/ArchGDAL at all for vector features, then :geometry is your best bet.

@rafaqz
Copy link
Member

rafaqz commented Sep 25, 2024

Yeah... good demonstratiion that first(GI.geometrycolumns(geomA)) is waay too long to actually use

@alex-s-gardner
Copy link
Contributor Author

Reiterating that standardizing on the geometry column name (either "geometry" or "geom") early could provide long-term benefits. I find myself continually having to check if "geom" or "geometry"

@rafaqz
Copy link
Member

rafaqz commented Dec 4, 2024

Where is it still :geom? This is just GDAL?

There is not much more we can do here, GeoInterface has both a standard name (:geometry) and a function to get non standard names.

Probably an issue at the offending source is more actionable

@asinghvi17
Copy link
Member

Any non-GeoJSON thing loaded by GDAL has :geom as a geometry column, this includes everything returned by GeoDataFrames. That's the primary problem here.

I had two proposals on GeoInterface to extend this so we can do GI.geometry(df) instead and have it just work, maybe we should discuss those in Jan (or earlier, if we want to move things faster?)

@alex-s-gardner
Copy link
Contributor Author

OK, so is there a scenario where we rename GDAL "geom" columns to "geometry" for consistency, or is this bad practice?

I'm using GI.geometrycolumns, but it's pretty cumbersome and not easy for a new user to discover.

@rafaqz
Copy link
Member

rafaqz commented Dec 5, 2024

So there are two problems. GI.geometrycolums is cumbersome, and ArchGDAL is returning :geom.

An issue at ArchGDAL is the best place for the second problem.

The first is here, but I'm not sure how to fix that.

GI.geomcol(t) returning a single column is the shortest I can think of. But it really doesn't beat :geometry.

@evetion
Copy link
Member

evetion commented Dec 5, 2024

I have the same frustration, and it is an open discussion how to fix it. We went for the all should be compatible route, which now leads to some cumbersome code. I think the fixes are mostly in packages (those should use first(GI.geometrycolumns(thing)), not the user). And extending GI.geometry (now only defined for features) seems like a good plan.

@rafaqz
Copy link
Member

rafaqz commented Dec 5, 2024

GI.geometry(sometable) would be really nice.

But getting the column with other table syntax will also be something people try...
Is there a reason we cant also swap :geom to :geometry in ArchGDAL ?

@visr
Copy link
Member

visr commented Dec 5, 2024

As I understand, geom doesn't come from GDAL.jl or ArchGDAL.jl, but is a default geometry column name used by some GDAL drivers. See e.g. https://gdal.org/en/latest/drivers/vector/gpkg.html

GEOMETRY_NAME=value: Defaults to geom.

So far GDAL.jl and ArchGDAL.jl just followed GDAL's lead here. Besides geom vs geometry is also remember `` (the empty string) being one of the names that pops up. It probably makes sense for GDAL.jl to keep doing this, ArchGDAL.jl could be a bit more opinionated on this.

@rafaqz
Copy link
Member

rafaqz commented Dec 5, 2024

Yes it would make a lot of sense for ArchGDAL to change both :geom and empty strings to :geometry

@rafaqz
Copy link
Member

rafaqz commented Dec 5, 2024

Ok I made an ArchGDAL issue

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

5 participants