If you need an interactive solution that also supports masking, Leveller
can do that.
http://www.daylongraphics.com/images/volume.png
Ray
On 5/9/2019 7:14 PM, Shubham Baranwal wrote:
Hi team,
I just wanted to know whether is there any way to calculate the volume
of the whole Digital Elevat
Yay
On 12/21/2018 5:45 AM, Even Rouault wrote:
Hi,
On behalf of the GDAL/OGR development team and community, I am pleased to
announce the release of GDAL/OGR 2.4.0.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/
Just to add a small note regarding OS X (and iOS) and UTF-8 filenames:
The HFS+ filesystem stores accented characters in decomposed form, which
can differ from the filename given to an API that creates the file such
as fopen(..., "wb").
Applications that store a filename (e.g. into a preferenc
How about C++11 threads?
Ray
On 5/5/2016, Thursday 12:43 PM, Mark Coletti wrote:
On Thu, May 5, 2016 at 11:15 AM, Even Rouault
mailto:even.roua...@spatialys.com>> wrote:
[...]
That would be interesting if you (or anyone) could list which
C++11 features would be killer features
I was wondering if there is a list, for each projection supported by
OGR, reasonable default values for each projection parameter. For
example, if the user is switching projections in an app, a small table
listing the projection parameters appears, but they need to be populated
with reasonable
The functions are to allow mapping between logical and physical pixel
values. This is very common in e.g. elevation DEMs.
Applying them is done by the calling code. At least, I haven't seen any
routines in GDAL that
would apply them for you.
Ray
On 6/22/2015 7:50 AM, Alexander Bobkov wrote:
Sorry, false alarm, my copy of PROJ.4 pj_init is old and was not using
strdup(setlocale(...))
Ray
On 1/18/2015 1:46 AM, Ray Gardener wrote:
Has anyone had a problem (GDAL 1.8.0.0 or higher) with the
OGRCreateCoordinateTransformation function
in ogr/ogrct.cpp changing the current locale back
Has anyone had a problem (GDAL 1.8.0.0 or higher) with the
OGRCreateCoordinateTransformation function
in ogr/ogrct.cpp changing the current locale back to the default "C" locale?
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.or
For reasons to long to go into, it's handy for me to link PROJ4
statically into GDAL. But then PROJ4's pj_set_finder() call gets hidden
from the linker. Does GDAL have a CPLSetConfig option or other API to
have it forward the data finder info to static PROJ4? I can easily hack
such a thing but
Oh man. So over time, as more GPL'd drivers are written, the very
purpose of GDAL gets watered down. It's not like people are going to
develop MIT-licenced drivers if they see an existing GPL driver that
does the job. At the very least, the motivation will be blunted.
The whole reason I went w
I should ask, is it okay for commercial apps to include GPL'd drivers
currently? What would happen if my app included one? Do I have to wait
for it to be under LGPL?
I don't mind at all sharing any changes I may make to such drivers, but
if I can't even include the drivers, that seems excessiv
On 1/31/2011 12:32 PM, Frank Warmerdam wrote:
That would be adequate for those who are building things from source
and wanting to distribute the resulting binaries under a single
consistent licensing policy. However it does not help me for the
OSGeo4W need.
OSGeo4W is a unified installer... [sni
how. And easy to exclude such drivers, just skip building that folder's
makefile. If I want total certainty, I can even delete those folders.
And if someone makes a classification mistake, it'll be more obvious too
("hey, driver XXX shouldn't be in
Best way is probably to add a driver option (if it doesn't already have
one for that).
Ray
On 12/3/2010 3:01 PM, Todd Smith wrote:
When opening .asc files, they are scanned for any values that may be
floating point so the type of data (int or float) can be set properly.
For the case I'm dealin
Sorry if this has been brought up before, but was anyone planning to add
a raster driver for the HF2/HFZ format? Specs are at
www.bundysoft.com/docs/doku.php?id=l3dt:formats:specs:hf2
Ray
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.o
You're right -- that post was incomprehensible. I read it twice and
still wonder what it's all about. :)
But it's a good lesson to learn. And it happens to everyone. The
software is telling us "Please refactor me, even my interfaces or
fundamental design if you have to, because I'm getting ove
g indices.
I'd note that currently efficient implementations of SetNextByIndex()
exist in Shapefile, MEM and GRASS drivers. GDAL/OGR 1.7.0dev has also
added implementation of it for PostgreSQL and VRT (for the latter, only
if the underlying layer has OLCFastSetNextByIndex capability).
The OGRLayer::SetNextByIndex() function can be sped up by keeping track
of the previously used index, and calling ResetReading() only if the new
index is lesser than it. Otherwise, read forward and skip features by
the difference of the new and old indices.
For thread safety, the old index sho
18 matches
Mail list logo
