search

Sintrastes / MapAlgebra.jl

High-level declarative GIS processing library for Julia.
MIT License
2 stars 0 forks source link

Hi, and package goals #9

Open rafaqz opened 1 year ago

rafaqz commented 1 year ago

I like your design goals and rigor here, they seem very similar to Rasters.jl! The structure is also pretty similar to GeoArrays.jl

I just wanted to flag that we have put a lot of work into abstractions for GIS objects in DiskArrays.jl and GeoInterface.jl so you don't need to explicitly handle things like lazy raster loading and array math. DiskArrays.jl already lets you lazily broadcast arbitrary Julia functions over GDAL arrays like RasterDataset in ArchGDAL.jl. Rasters.jl uses this and can do most of what you specify in the readme here, but abstracted to allow multidimensional backends like netcdf.

GeoJSON/Shapefile etc loading is also generic with GeoInterface.jl traits, you don't need to explicitly handle those packages.

It's taken quite a few years to get all of this (mostly) working, as the GIS community for julia is pretty small, its a few of us doing a lot of work.

If you want to make another raster/vector package that's great (and probably fun), but there are also a lot of opportunities to contribute code and ideas to JuliaGeo and the other packages I've mentioned that might also be fun, and keep things less fragmented. We can use all the help we can get on Rasters.jl, DiskArrays.jl, GeoInterface.jl etc.

Sintrastes commented 1 year ago

Hi @rafaqz, thanks for reaching out and the references.

I'm pretty new to Julia, and mostly made this to have fun experimenting with the language, by implementing a framework similar to one I've built internally at work in Kotlin (as we need to deploy to Android, and the raw SWIG GDAL bindings in Java are pretty abysmal).

I'll try to make this more clear in the readme, and maybe reference some of these other (I'm sure much more mature) libraries as well to help avoid fragmentation.

I may contribute as well if I get the chance.

Do you know if any of these existing packages would support my notion of an "anisotropic raster"? If not, I may see if I can contribute something to that effect -- though as far as I know this is fairly new research, so I may wait until after publication to try to codify this as part of a larger package.

Sintrastes commented 1 year ago

I'm realizing now that the readme doesn't really explain this "aniso raster" concept.

Basically, this is a raster where each band represents the cost of moving in some concrete direction in a raster grid, so we can faithfully represent all directional costs of a slope-based cost model. This differs from approaches such as GRASS GIS's r.walk, as there is no accumulated costs, but rather a serialized version of the directed weighted graph across the raster grid induced by the elevation data.