search

evetion / GeoDataFrames.jl

Simple geographical vector interaction built on top of ArchGDAL
https://www.evetion.nl/GeoDataFrames.jl/dev/
MIT License
68 stars 6 forks source link

Discussion: make GeoDataFrames the main entry point for vector data #81

Open asinghvi17 opened 1 week ago

asinghvi17 commented 1 week ago

From https://discourse.julialang.org/t/screening-interest-in-a-unified-vector-raster-package-akin-to-r-terra/121613, it might make sense to make GeoDataFrames a single point of entry for vector datasets.

Would there be interest in creating a "backend system" for GeoDataFrames, so that we can use native Julia readers wherever possible, and fall back to ArchGDAL when needed? This would probably help performance quite a bit as well.

The other proposal was that GeoDataFrames could re-export Extents.jl and GeoFormatTypes.jl, so that users don't need to know about those!

evetion commented 1 week ago

That's certainly possible, and I think that still works without wrapping either the geometry, or Dataframes, but is that still the right way ahead? I like spatial to be not special, but that makes it also harder.

With regards to exporting, what happens if we re-export here and someone does using Extents?

asinghvi17 commented 1 week ago

Agreed that spatial should not be special. IMO we can sneak in quite a bit of stuff through metadata and GeoAcceleratedArrays.

On the using extents part of it - it's fine, there are no name clashes by definition since it's the same function. (I mean literally @reexport using Extents).