Hi Kay, > Am 02.11.2014 um 19:43 schrieb Oliver Eichler: > > Hi, > > > > new release! > > gosh, you're fast!
Well doing the database now will take a bit longer. And I have to send in my laptop due to BIOS problems. That will slow down the development progress. But, yes, development is fast as I do not have to reinvent the wheel. It's more like restructuring the code in an intelligent way. > - QLGT has the information/configuration window (from the maps tab). My > map has parts under CC-BY and parts from OSM, so I have to attribute, > and the way I can do that in QLGT is via this window. In QMS I have > found no way to display the map's licensing information or attributions. Right now TMS maps display the copyright notice as tool tip. It can be edited in the TMS file. For all other maps I haven't spend time to dig out the copyright notices. In the WMTS maps the copyright notice is often written as comment. The Garmin maps are flooded with a lot of copyright notices. And the usual raster maps have no notice at all. It's no fun at all to find a common solution for that. But the necessary structure is already implemented. If the IMap::copyright string carries information it is displayed as tool tip. > > - I miss the detail button under QLGT's main window. I work my map with > detail set above 0, which seems roughly to be QMS's default. With this > default, my contour lines (resolution 23/24) disappear too early when > zooming out. I hope to get rid of that. Imho that button is only needed for badly scaled maps. I really love the Freizeitkarte for that reason. It's detail levels match perfectly with global screen scales. > > - issues with the hill shading: > > The method you use translates the virtual shadows into a gradient from > white to black. When this is overlayed on the map data, it results in > pastel colours, since the white parts of the hill shading mix with the > underlying colours. Wouldn't it be possible to display a gradient from > transparent to black instead? I switched algorithm from my own funny algorithm to the one from the school books ;) The advantage: You see more details and there is also shading on the sunny side of the hills. But as you say it manipulates the colors. If I play with the two sliders (transparency and amplification) I always get quite agreeable results. The shading is done in IDem::hillshading(...). Maybe you can improve the last line "img.setPixel(n - 1, m - 1, cang);" > > I also noticed that the hill shading extends beyond the boundaries of > the terrain that is covered by the DEM, tinting it a uniform middle > grey, as if it were a flat surface. This creates a pastel effect on > areas which aren't covered by the DEM. No it does not. Your DEM file extends beyond the boundaries with NULL data. We are talking about SRTM Alps from Viewfinder Panorama, don't we? > > Working with several DEMs active at the same time, the hill shadings > generated from the DEMs add up, which is, in my opinion, wrong. I don't > know what a wise course would be to deal with overlapping DEMs - ideally > there would be a choice, like to either give preference to the highest > resolution DEM, or to calculate an average, or to manually set a > preference, i.e. by layering. I am aware of that, but have no good solution. I handle that by switching hill shading in the different files. Another way is to use DEM data for a large area. But the only source I know are the ASTER GDEM files and I have better data than that for some areas. Oliver
------------------------------------------------------------------------------
_______________________________________________ Qlandkartegt-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qlandkartegt-users
