Kurt Schwehr writes:
> Thanks Gred and Andrew! Those are exactly the kind of comments that help.
>
> Greg,
>
> I have lots of experience packaging GDAL in fink for the mac, but less
> elsewhere. I found this like which implies that pkgsrc is at GDAL 1.11.3.
> Are there better links?
Yes, it's
That's a possibility, but as longs as we require most of the code base to
work with C++03, merging is going to be miserable. I'm suggesting we flip
the requirement but make no immediate changes. GDAL builds cleanly with
C++11 and C++14 right now, so it's just a matter of flipping the
requirement
There's a lot of code to work on. Would it make sense just to make a C++11
branch and get to work, merging into master whenever it seems the right
time?
On Thu, Jan 12, 2017 at 2:42 PM, Nyall Dawson
wrote:
> On 13 January 2017 at 02:57, Greg Troxel wrote:
> >
> > Kurt Schwehr writes:
> >
> >
I didn't need to do anything to build with kakadu 7.9 (with something close
to trunk), so +1 from me for a release.
On Thu, Jan 12, 2017 at 12:43 AM, Kurt Schwehr wrote:
> I just got a copy of Kakadu v7.9 this week. I need to see if GDAL needs
> any patches for it, but I don't think it does.
>
On 13 January 2017 at 02:57, Greg Troxel wrote:
>
> Kurt Schwehr writes:
>
> If no other packages start to depend on unreleased GDAL, and the first
> GDAL release requiring C++11 is a ways off, and by then enough other
> things require it that a system not having a C++11 compiler is totally
> non
Thanks Gred and Andrew! Those are exactly the kind of comments that help.
Greg,
I have lots of experience packaging GDAL in fink for the mac, but less
elsewhere. I found this like which implies that pkgsrc is at GDAL 1.11.3.
Are there better links?
- http://pkgsrc.se/geography/gdal-lib
- https
Kurt Schwehr writes:
> Greg,
>
> Can you explain the use case as to what keeps you on an older NetBSD but
> unable to use a branch of a recent GDAL? e.g. I'm am suggesting that we
> keep GDAL 2.1 and older to stay with the current requirement of supporting
> C++03.
That is probably ok. I shou
Hi list,
I have a 5 band GeoTiff and I want to derive a new image of it by doing
some simple band calculations. For example (band5-band3) / (band5+band3).
I was hoping I could do this with a VRT file, but can't find an example.
I did found details about GDAL Algebra and Pixel Functions, but I'm no
> Any ideas what may cause this?
Yes, a typo...
I just fixed it per
https://trac.osgeo.org/gdal/ticket/6775
Even
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.
Running:
opts = gdal.DEMProcessingOptions(zeroForFlat=True)
gdal.DEMProcessing('my\out\file_aspect.tif', 'my\in\dem.tif', 'aspect',
options=opts)
resuts in the error:
Too many command options 'zero_for_flat'
However, if I run it as:
opts = ['-zero_for_flat']
gdal.DEMProcessing('my\out\file_asp
I just got a copy of Kakadu v7.9 this week. I need to see if GDAL needs
any patches for it, but I don't think it does.
On Thu, Jan 12, 2017 at 12:08 AM, Even Rouault
wrote:
> Hi,
>
>
>
> I'm considering issuing a release candidate for 2.1.3 end of next week.
>
> Anything that should be in it th
Hi,
I'm considering issuing a release candidate for 2.1.3 end of next week.
Anything that should be in it that isn't already ?
16 tickets (perhaps a few more if backported to 2.0.X or 1.11.X) are listed:
https://trac.osgeo.org/gdal/query?status=closed&resolution=fixed&milestone=2.1.3&group=resolu
12 matches
Mail list logo
