Re: GDAL Wrapper

[Will Kearney]

I will freely admit that I didn't really understand the stuff I was getting from Clang which is why I just wrote out what I needed, but I'll check out your repo, and see if I can't figure something out.

As far as visualization goes, there are a lot of options for displaying an individual raster. Images will certainly work; I've been using PyPlot as a sanity test while I've been building this. The harder part, I think, is going to be handling the georeferencing so that you can display multiple rasters together relative to each other, especially if those rasters come in different projections or resolutions. I haven't played enough with Images.jl to know if that's feasible.

-Will

On Mon, Feb 10, 2014 at 2:32 PM, Fabian Gans <fabia...@gmail.com> wrote:

This is great news,

I also started some work on this that might be useful to you. If you don't want to write out all the ccall's I used Clang.jl to parse the gdal header files. So feel free to grab whatever you need from here: https://github.com/meggart/GDAL-funs.jl

Did you think about visualization options? The more I think about it, I think an easy conversion Raster -> Image would be cool to make use of the functionlity that is already in the Images package. I will look into this.

Fabian

On Monday, February 10, 2014 8:13:36 PM UTC+1, Will Kearney wrote:

Hey everyone,

I threw together a Julia wrapper for GDAL this weekend: https://github.com/wkearn/GDAL.jl

Right now, it should be able to open a raster and read that raster into a newly-defined Raster type and write that Raster into a file using either of GDAL's two methods (CreateCopy() and Create()).

There are some big holes in the implementation, some of which are detailed in a Todo section in the README file. The goal was really to provide some minimal functionality for Julia interactions with GDAL to get the conversation about geodata going.

One thing I'm a little worried about is the number of pointers that are flying around to prevent the wrapper from having to interact directly with GDAL-defined types for datasets, raster bands, drivers, etc. Maybe someone with a bit more knowledge of C and memory management could tell me if this is particularly dangerous and a better way to deal with these types.

What do you think good next steps would be?

Of course, send me any questions, comments or pull requests you come up with!

Thanks,

Will Kearney

--
You received this message because you are subscribed to the Google Groups "julia-geo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to julia-geo+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Fabian Gans]

No worries, it took me quite some time to understand what Clang is doing and more time to get it running. It just auto-generates functions so that you can call GDAL-function in a more convenient way. When you clone the wrapper and do

julia> require("GDALfuns")

julia> GDALfuns.GDALAllRegister()

julia> hDataset = GDALfuns.GDALOpen( filename, GA_ReadOnly)

This means all constants and functions are already defined in a convenient way so you can concentrate on writing the high-level functions and it makes the code more readable.

NOTE I just renamed my repository to GDALfuns.jl , Julia did not like the - in the module name.  (https://github.com/meggart/GDALfuns.jl)