Am 09.11.2014 um 12:14 schrieb Oliver Eichler: > > - 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.
Mine is a garmin map. It's a synoptic map from data the piemontese regional government has released under CC-BY for reuse, plus ways and POIs from OSM. There are quite a few copyright notices in the map: the copyrights for the individual components, and finally my own CC-BY-NC-SA license for the combined product. Still they all must be present to satisfy the licensing requirements of all parties involved. I know this is tedious and I was very unhappy to deal with these issues myself, when I would much rather have spent my time with more 'meaningful' work, but, alas, there is no way around it :( > 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. Good! So I do hope you get around to filling it for garmin maps as well. I'd really like to recommend your program for use with my map - I could just stop supporting use with basecamp, mapsource and qlandkartegt and therefore stop publishing a 'split' version of the map, which is a headache I could well do without, and I'm sure it would reduce traffic to the download site as well, since many people want both versions. > > > > > > - 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. I'll look into the issue - but ultimately my aim is to make a map which looks all right on my GPS unit, and if there is some way to tweak it easily when it's displayed on a big screen, this is simply helpful. One of my 'problems' here is that the garmin devices don't seem to be made to use maps as detailed as mine, which is derived from source material in 1:10000 with 10m contours. And the badly scaled maps won't go away just because QMS doesn't support them well ;) Think of it as a defensive measure. > > > > > > - 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);" The documentation shows me that QImage supports alpha channels. So the way to go would be to have the map all black and assign the calculated hillshade to the alpha channel instead of the pixel's grey value. If I understand the docu right, you can continue using the same QImage you make, and could use a coulour table. The coulour table's entries can be ARGB values, so you can let the transparency correspond with the value in the QImage by assigning 0 -> 0, 0, 0, 0 1 -> 1, 0, 0, 0 ... 255 -> 255, 0, 0. I tried a quick hack, but failed, due to my ignorance of Qt's data types... you'd probably be much quicker, knowing Qt well. You just need to initialize the colour table once as a QVector<QRgb>, then you can assign it to the greyscale image by using QImage::setColorTable() It looks like you are using a textbook algorithm to generate the grayscale. Might be easier to use external code! They might have improved upon the 'raw' version of the algorithm - I see you have quite a few transcendental functions in the code, which is expensive, and the people who design libraries often go to great lengths to avoid stuff like that as best as they can. And you might get the transparency thing thrown in for free. How about something like http://grass.osgeo.org/grass64/manuals/r.shaded.relief.html > > > 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? I'm aware of the fact that tiles of DEM data are filled up with no-data-values where there are no data. But here it looks to me like the effect extends beyond the boundaries of the set of tiles. I take the tile sets and create a VRT file from them, which I feed into QMS - maybe something untoward happens to the interpretation of the data whhen thy are put into a VRT. I'll gladly provide screenshots of my overlap problem. The two DEMs I'm using is the 10m-grid DEM of the Regione Piemonte, which is also published for reuse by www.dati.piemonte.it, and the free 200m-grid DEM of switzerland, which is the best resolution on offer for free from swisstopo. The (very detailed, high quality, liberally licensed) piemontese data end at the piemontese border, the swiss data are inside a set of overlapping rectangles roughly enclosing the swiss territory, with a bit of the neighbouring countries thrown in. The swiss data are of course very imprecise by comparison, but I still prefer them to just having an empty (or should I say middle grey) space around my map when I look at it. Maybe I should just not bother with the swiss data and have viewfinder data for the area outside the Piedmont, but the viewfinder data is in 1° sqaure tiles, and there would also be some overlap. > > > > > > 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. Same here - the piemontese data are simply much better than any other free source I have found so far. Maybe I'll have to make the DEMs I have into one and use that in QMS. I was only hoping to get away without the extra work... Kay ------------------------------------------------------------------------------ _______________________________________________ Qlandkartegt-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qlandkartegt-users
