RE: GDAL wrapper [WAS: how to put in octave forge?]

[shashank khare]

Hi Philip!

Uploaded files which now have README and test.m so that people can understand how to use the gdalread and gdalwrite. Also changed shaperead to gdalshaperead to avoid conflict. Hope this helps.

Thanks
Shashank

---

From: address@hidden
To: address@hidden; address@hidden
CC: address@hidden
Subject: RE: GDAL wrapper [WAS: how to put in octave forge?]
Date: Wed, 15 Jul 2015 08:16:32 +0000

> Date: Tue, 14 Jul 2015 21:52:00 +0200
> From: address@hidden
> To: address@hidden; address@hidden
> CC: address@hidden
> Subject: GDAL wrapper [WAS: how to put in octave forge?]
>
> Hi
>
> shashank khare wrote:
> > thanks for the input.
> >
> > I will keep it in github till documentation is in good shape. Its my
> > first contribution towards open source and I am still learning (Octave,
> > Doxygen, build management, unit tests, licensing, IDEs etc). I guess I
> > will be able to find out developer(s) who can maintain it in long term.
> > I am calling it octave-gdal project since primarily its a wrapper on
> > gdal. Will not develop wrapper on proj4 as it is already developed. As
> > far as compatibility with matlab I can take it up but little later.
> > Right now my goal is to help people read and write raster GIS data using
> > Octave.
>
> I've tried reading raster stuff with your gdalread function and it seems
> to work well and fast with some tiff files I downloaded (i.e., 5x5 m DEM
> data from the Netherlands).
> Some remarks though:
>
> - gdalread returns output arg "map" as a 1x1 cell array (containing a
> 1x1 struct). Please let it return a struct right away.
>
   raster data in stored in bands. Therefore it has to be an array. I have put the explanation in usage description.

> - There's no information at all about the second (required) argument
> "type". Can you provide info on what is does? I couldn't discern any
> differences between specifying 0 or 1.
>
 
   Taken it out. It is not used anymore. It was supposed to covert datatype stored in the imagery file to user defined type.

> I'd advise to just fix those 2 gdalread issues and then leave it alone;
> .m file wrappers can be used around it for the rest (error handling,
> Matlab compatibility, other options, etc). m-files are much easier to
> maintain.

   thanks ...you solved my dilemma regarding providing so many .oct files for matlab compatible API. Now developers can use gdalread/write/info to create wrappers. 

> I already have a simple wrapper for gdalread and I can absorb your stuff
> + that wrapper .m-file in the mapping package.
>
> BTW "Raw" raster data can also be read using imread followed by properly
> georeferencing the result.
>
> As to shaperead.cc: that doesn't compile with octave-4.1.0+ (development
> version) for 64-bit windows on my Win7 box.
> The mapping package already contains a shaperead function. Later on we
> can see which one is to be preferred in the long run.

I am changing it to gdalshaperead so that it can be used for further development and does not conflict with what is in already.

> >
> > In the meantime will put nice README and tests so that people start
> > using it. I see licensing as a restriction on freedom of
> > _expression_. Therefore I went to MIT style licensing which is liberal
> > and therefore fit in with more restrictive licensing.
>
> There exist several MIT licenses some of which do not look GPL-compatible.
> According to Carnë the version you use seems to be OK.
>
> Philip
>