On Tuesday, 13 March 2012, at 11:36:09 +0100, Oliver Eichler wrote: > it certainly would be nice to have a relief even for larger areas. > However your approach will not work due to limitations in GDAL. To > access the values the API function RasterIO is used. RasterIO can even > scale the requested data. However it does a poor job. It simply uses the > "nearest neighbor" method. This is kind of acceptable for maps. For > elevation data this is bad, as the shading it the differential function > of the data and reveals every non-linear disturbance. > Thank you for the response, although I am not sure if I explained myself correctly. As I said, the only place where optimizations may be needed is in the drawing of the DEMs, because no matter how large is the DEM, its internal usage is very fast, and UI performance seems to be unaffected.
To see if artifacts appear by using low resolution DEMs to render the
shading / contours I have downsampled (using GDAL command line tools) the
original 700 MB GeoTIFF DEM to 10% in both dimensions, yielding a file
under 10 MB. I have added that DEM to a Garmin vector map in QLGT 1.4.0,
and I can happily see the shading for the whole country of Spain, with no
difference compared to a 25%-scaled version of the original DEM, which is
the largest one I can fit into the 10000x10000 limit in the code.
Of course, the DEM resolution is much poorer (less real points to use for
heights), but zooming in the map the shading renders smoothly (no
artifacts), and the "contour" still shows without artifact, but useless at
extreme amplification levels, which is to be expected.
Which leads me to the following:
> In other words: If I scale the data via RasterIO stripes will get
> visible in the relief shading.
>
I may not understand the internals of the GDAL API, but to me reading a
10%-scaled down version of the original DEM to render to the screen (while
at the same time, using the full resolution one to calculate heights) from
a filesystem file, or from a GeoTiff overview of the same size embedded in
the file, is the same:
CMapDEM.cpp:484:
pBand = dataset->GetRasterBand(1);
But pBand->GetOverview(int), after checking for overview number and sizes
(pBand->GetOverviewCount ()), would be the same, but pointing to an scaled
down version of the original GeoTIFF. It may be a matter of, given the
viewport, checking overview availability and just make pBand point to the
optimal overview for the current viewport, if any, or to the default
GeoTIFF itself.
As pBand seems to be local to the class constructor and draw() methods, I
think it could be possible to implement this change to draw() without
affecting in any way the rest of the class. As I understand draw() gets
called for every viewport change, checking the DEM internals for every
redraw would add little processing to the whole function.
As I realize I may have explained myself badly again, and it seems the
changes could be something I could do myself by spending some hours on it,
let me try to get a proof of concept implementation, just in case I am
right (which I doubt, given my abilities and you being the creator of the
software).
Thank you for your patience.
--
Jose Luis Domingo Lopez
Linux Registered User #189436 Linux Kubuntu 11.10 (Linux
3.0.0-16-generic-pae)
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________ Qlandkartegt-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qlandkartegt-users
