Re: [gdal-dev] Get max elevation on "squares"

[Volker Wichmann]

Hi Luca,

I haven't followed the discussion in detail, but you could use

https://gdal.org/programs/gdallocationinfo.html

to read out the values from your resampled raster.

The elevation differences between high and coarse resolution DEMs 
strongly depend on the relief in the area of investigation. So the 
differences between 25m and 5000m DEMs might be quite significant. Maybe 
better query the path on the high resolution and then smooth the profile 
afterwards (to keep min/max values for example).


Another approach would be to resample your high res DEM with the min/max 
resampling options of


https://gdal.org/programs/gdalwarp.html

and thus create low res DEMs with the extreme values.


Best regards,
Volker


On 12/28/21 20:51, Luca Bertoncello wrote:

Am 28.12.2021 um 04:54 schrieb Alan Snow:

After some thought, you may achieve what you want by resampling the file
to a 5km grid size with the Resampling.max option:

https://rasterio.readthedocs.io/en/latest/topics/resampling.html

https://rasterio.readthedocs.io/en/latest/api/rasterio.enums.html#rasterio.enums.Resampling.max

You can then store the centroid of the grid cell and the value in a
database.


So, maybe I got something...
I started with the EU DEM data from
https://land.copernicus.eu/imagery-in-situ/eu-dem/eu-dem-v1.1?tab=download
Then I created a VRT file of a part of these data, about what I need
(later I'll refine the sampling):

gdalbuildvrt -tr 25 25 -tap -te 300 100 800 600 r.vrt
../eudem/*.TIF

and then I resample the data saving all in a TIFF file:

gdalwarp -tr 5000 5000 r.vrt ../x/x.tif

Now I have a TIFF file with a resolution of 5x5 km (I hope):

$ gdalinfo -mm x.tif

Origin = (300.000,600.000)
Pixel Size = (5000.000,-5000.000)
Metadata:
.

Do I am right until now?
I checked some known location (airports) and I see the elevation from
the 25 meter precision VRT file is better (of course) but the elevation
from the 5 km precision TIFF file is quite accurate, with a difference
of less than 10 meter. To create a vertical profile using during the
flight 10 meter are damned good.

Now I have to extract the data and save them in a SQLite file...
And I don't know how to do it per Script... :(

Any help?

Or maybe there are a Java-Library to using in Android to read the TIFF file?

Thanks
Luca Bertoncello
(lucab...@lucabert.de)
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] mapping of shadows casted by other slopes

[Volker Wichmann]

Hi,

another, may be simpler option is SAGA GIS, its analytical hillshading 
tool includes a ray tracing option:


http://www.saga-gis.org/saga_tool_doc/4.1.0/ta_lighting_0.html

Volker


On 05/16/2017 10:22 AM, Newcomb, Doug wrote:

Kenlo,
Suggest you look at  GRASS GIS r.sun , 
https://grass.osgeo.org/grass72/manuals/r.sun.html.


Doug

On Tue, May 16, 2017 at 3:16 AM, NASAHARA Kenlo <24dake...@gmail.com 
> wrote:


Dear GDAL people:

Using DSM, I want a "shadow map" not only by the slope
itself but also by the other slopes. I mean, if a tall and
steep peak exists, and if it is illuminated by the sun from
near the horizon, the shadow of the peak falls on a wide
area of the foot of the mountain. Such shadow is normally
not estimated by a simple "hillsahde" algorithm, which
includes the "gdaldem" command. I want to map such
shadows as well as the normal "hillshade" shadows.

If you know a library or command to help it, please let
me know!!

--
Kenlo Nishida Nasahara
Faculty of Life and Environmental Sciences
University of Tsukuba, Japan 305-8572
24dake...@gmail.com 
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org 
https://lists.osgeo.org/mailman/listinfo/gdal-dev





--
Doug Newcomb
USFWS
551F Pylon Dr
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov 
-
The opinions I express are my own and are not representative of the 
official policy of the U.S.Fish and Wildlife Service or Dept. of the 
Interior.   Life is too short for undocumented, proprietary data formats.
*/NOTE: This email correspondence and any attachments to and from this 
sender is subject to the Freedom of Information Act (FOIA) and may be 
disclosed to third parties./*​



___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev



___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] [GSOC] Integration of cpp GDAL utilities into GDAL core library

[Volker Wichmann]

Hi Nishith,

On 03/18/2015 08:27 PM, Nishith Maheshwari wrote:

Hi,
I am a masters student from IIIT Hyderabad and currently in my final
year of study and working in the Lab for Spatial Informatics here.

I was a part of GSOC 2014 and worked on the project *'Schematization
Plugin for QGIS'* last year [1][2].

I am interested in the project *'Integration of cpp GDAL utilities into
GDAL core library'* .

I have already looked at a few codes of gdal utilities available in the
'apps' folder of the sourcecode and had a few queries -

1. From my understanding of the project description, the aim is to
refactor the individual codes of gdal utilities by removing the main()
and making them available in the form of functions. These functions can
then be accessed by another function like GDALRunUtility() which can be
used to call them individually using specific parameters. Please let me
know if I'm thinking in the right direction.

2. If we are implementing individual functions for every utility we
might not require a separate layer of interaction in the form of
GDALRunUtility(). Any thoughts?


yes, the idea was to move the functionality of the gdal utilities to 
GDAL core in order to have it available directly when using the library 
and thus to facilitate their usage from external programs. The 
functionality should be usable with the GDALRunUtility() function. This 
would avoid e.g. a system call to a tool or code duplication which is 
currently needed in order to create a GDAL vrt for example.


It is not intended to remove the GDAL tools, but they would have to be 
reworked to just provide the parameter interface and then to call 
GDALRunUtility() themselves. The idea to have a GDALRunUtility() 
function is to have a unique entry point and common interface to all 
tool functionality.


Best regards,
Volker




[1] http://hub.qgis.org/wiki/quantum-gis/nishithm
[2] https://github.com/nishithm/schematization

Regards,
Nishith Maheshwari
Lab for Spatial Informatics
IIIT Hyderabad, India


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev



___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Adding driver in run time

[Volker Wichmann]

On 12/08/2013 05:31 PM, Victor Fine wrote:

Hello,

I'm trying to write a driver , inside my program that uses GDAL (C++).

After the call to GDALAllRegister(); I call GDALRegister_MYDEM(),
which is much like in the example in
http://www.gdal.org/gdal_drivertut.html

After that, I try to call GDALOpen on some file and the breakpoint in
the .. *MYDEMDataset::Open(...) function is not even hit.
(And , of course, I get a message that this is not a recognized format).

It seems that I have some beginners mistake here - why does GDAL
ignores my driver?

Regards,
Victor.


Hi Victor,

did you add your driver to the GDAL tree (i.e. in 
gdal/gcore/gdal_frmts.h and frmts/gdalallregister.cpp) like described in 
the tutorial you mention?


Volker


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev



___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Removing Nodata pixels from raster

[Volker Wichmann]

In SAGA GIS there is a Crop to Data module (in Grid Tools module 
library), which performs the task.


But this would require you to import your Geotif with the GDAL import 
module, process it in SAGA, and finally export it as Geotif again with 
the GDAL export module.


Best regards,
Volker

On 10/25/2012 05:32 PM, katrin eggert wrote:

Hello
No I don't know where my valid pixels are.
Any alternative?

2012/10/25 Kyle Shannon k...@pobox.com


Katrin,
Do you know where you valid pixels are in the image?  If so,
gdal_translate with -srcwin would work:

kyle@ubuntu:~$ gdal_translate -srcwin xoff yoff 60 100 in.tif out.tif

where xoff, yoff are the number of pixels from the image origin that your
valid region begins(pixels, lines).  See
http://gdal.org/gdal_translate.html for more info.



On Thu, Oct 25, 2012 at 8:05 AM, katrin eggert katrineggert1...@gmail.com

wrote:



Greetings
I have a Geotif with only one Layer with a size of 6000x5000 but from
which I only have a square of 60x100 with bvalid pixels. the remaining are
NOdata. The problem is that this Geotiff is a big file 90MB and without
these NoData values I would have a much smaller raster.
How can I generate a new Geotiff without these noValid values and with
extent adjusted to the valid pixels?
Thank you
Regards,
Katrin E.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev








___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev



___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Hillshade + Topographic Map??

[Volker Wichmann]

The workflow with QGIS described by Frank is also working with SAGA GIS. 
SAGA also allows you to export a permament combination as image file 
(tif, jpg, png ... including world file and kml) with the 'Export Image' 
module.


Volker


On 02/21/2012 02:14 PM, Frank Broniewski wrote:

Hi,

the standard procedure for creating topo-maps is to overlay your land
coverage map with a semi-transparent hillshading. I don't know if
there's a tool for combining/adding two raster maps together in gdal,
but this is a rather standard procedure in any GIS. In QGIS, for
example, you can adjust the layer transparency slider to get the effect.

If you want to create a more permament combination of the land coverage
and hillshade, you can use a software like GIMP to combine the two maps.

Mapserver may be able to create a georeferenced version of your
combination also, as does mapnik. The biggest problem is probably to
overcome the alpha-transparency for your hillshading, which is not
something that every raster library is able to handle well.

Frank

Am 21.02.2012 11:01, schrieb TJMartin:

Hi

I have managed to create a hillshade using gdaldem and I have my original
topographic rasters. However I do not want the standard grey hillshad or
apply a colour ramp.

Is there a way to combine the hillshade and topo map together - ie add a
transparency or opacity to the hillshade.

I have looked at Photopshop and ImageMagik but the results are then not
supported in QGIS etc

After a trawl through the web the only entry is an ArGIS 10 tutorial

http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//009t01v100


Hopefully that will explain what I would like to achieve

thanks for anyones help

Tim

--
View this message in context:
http://osgeo-org.1560.n6.nabble.com/Hillshade-Topographic-Map-tp4490698p4490698.html

Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev






___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] problem with decimal precision (SAGA driver)

[Volker Wichmann]

Hi,

we encountered a problem with decimal precision when converting a SAGA 
grid to ESRI ASCII.


I expect the problem arising from ASCII to double conversion by atof() 
and/or from the Geotransform (pixel as point to pixel as area).


The SAGA header looks like

POSITION_XMIN   = 12181.80
POSITION_YMIN   = 219184.88
CELLSIZE= 1.00

The final ESRI ASCII header looks like

xllcorner12181.2999
yllcorner219184.3805

instead of
xllcorner12181.3
yllcorner219184.38

How is this problem handled in other drivers (using strtod(), 
stringstream, ...)?


The relevant lines of code in sagadataset.cpp 
(http://trac.osgeo.org/gdal/browser/trunk/gdal/frmts/saga/sagadataset.cpp) 
are:


406 
http://trac.osgeo.org/gdal/browser/trunk/gdal/frmts/saga/sagadataset.cpp#L406  
  dXmin = atof(papszTokens[1]);
408 
http://trac.osgeo.org/gdal/browser/trunk/gdal/frmts/saga/sagadataset.cpp#L408  
  dYmin = atof(papszTokens[1]);
410 
http://trac.osgeo.org/gdal/browser/trunk/gdal/frmts/saga/sagadataset.cpp#L410  
  dCellsize = atof(papszTokens[1]);


601 
http://trac.osgeo.org/gdal/browser/trunk/gdal/frmts/saga/sagadataset.cpp#L601  
  padfGeoTransform[0] = poGRB-m_Xmin - poGRB-m_Cellsize / 2;
602 
http://trac.osgeo.org/gdal/browser/trunk/gdal/frmts/saga/sagadataset.cpp#L602  
  padfGeoTransform[3] = poGRB-m_Ymin + (nRasterYSize - 1) 
* poGRB-m_Cellsize + poGRB-m_Cellsize / 2;




Thanks,
Volker

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] SAGA: problem to convert grid from ETRS 89 / ETRS-LAEA to WGS84 CRS

[Volker Wichmann]

This seems to me like an integer overflow - looking at the GDAL 1.7.2 
sources I see, that the WriteHeader() method of sagadataset.cpp is using


GInt16 nXSize, GInt16 nYSize

Most likely this should be changed to

int nXSize, int nYSize


Best regards,
Volker



Am 06.01.2011 10:48, schrieb Clément Tisseuil:

Dear all,

I try to convert a SAGA grid (SAGA), from a ETRS 89 / ETRS-LAEA  to
WGS84 CRS , but I get the following error message:

gdalwarp -s_srs +proj=laea +lat_0=52 +lon_0=10 +x_0=4321000
+y_0=321 +ellps=GRS80 +units=m +no_defs -t_srs +proj=longlat
+ellps=WGS84 +datum=WGS84 +no_defs -r near -of SAGA hdr.sdat ./tmp/hdr.sdat

Creating output file that is 39901P x 15248L.
ERROR 1: Invalid dataset dimensions : -25635 x 15248

Any ideas ?

Thanks in advance.

--
Clément



___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] software can display geotiff file in 3D viewer.

[Volker Wichmann]

Markus Neteler schrieb:

2010/4/2 weixj2003ld weixj200...@163.com:
  

Hi
Could you tell me some open source softwares(base on windows) that can
display geotiff files in 3D mode not in 2D mode?



GRASS GIS has the NVIZ 3D viewer included:
http://grass.osgeo.org/screenshots/viz.php

Download at:
http://grass.osgeo.org/download/

Markus
  

An alternative is SAGA GIS:
http://www.saga-gis.org
http://sourceforge.net/projects/saga-gis/

Have a look at
http://sourceforge.net/apps/trac/saga-gis/wiki/Climbing%20Mount%20St.%20Helens
on how to create a 3D View. To import a geotif to SAGA, have a look at 
the Import/Export - GDAL/OGR module library.


Volker

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev