search

JuliaGeo / GeoInterface.jl

A Julia Protocol for Geospatial Data
https://juliageo.org/GeoInterface.jl/stable/
MIT License
97 stars 17 forks source link

feature request: setcrs #158

Open alex-s-gardner opened 3 weeks ago

alex-s-gardner commented 3 weeks ago

A simple setcrs utility would be a nice to have. Doing this:

GI.MultiPolygon.(multipoly, crs=GFT.EPSG[3413])
GI.Polygon.(poly, crs=GFT.EPSG[3413])

is a bit awkward. a setcrs utility

GI.setcrs(multipoly, GFT.EPSG[3413])
GI.setcrs(poly, GFT.EPSG[3413])

would help clean things up

rafaqz commented 3 weeks ago

Nice. Then rasters can extend that method too.

It should work on any geometry but return a GI geometry.

evetion commented 3 weeks ago

I have it as crs! in GeoArrays, which is more Julian? But yeah, would be good to have as a common definition (like read/write). Not sure about it always wrapping if the object doesn't implement it.

alex-s-gardner commented 3 weeks ago

I like crs or crs! if it doesn't reallocate

asinghvi17 commented 3 weeks ago

IMO crs!(x) only makes sense if x is mutable and can change its CRS, which is not the case for LibGEOS, Shapefile, GeoJSON, WKB, all other Julia reader geometries, and GI wrappers (I'm probably missing a few here). crs is also used as a getter so I'd tend to prefer setcrs (and maybe optional setcrs! for e.g. ArchGDAL and GeoDataFrames / Tables in general).

alex-s-gardner commented 3 weeks ago

I guess if we went down this road we might want to introduce:

GI.getcrs and then phase out GI.crs

rafaqz commented 3 weeks ago

I'm ok with crs and setcrs. That's what Rasters always had

rafaqz commented 3 weeks ago

setcrs can have the fallback of just wrapping with GI geoms for when the original object can't hold crs