octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: shashank khare
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
>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]