2009/6/3 Colin Marquardt <[email protected]>: > 2009/6/3 Marcin Rudowski <[email protected]>: >> Colin Marquardt pisze: >>> The relief layer is different of course, but not so much IMO: >>> http://m4.mapserver.mapy.cz/relief-l/11_7e60000_8480000 vs. >>> http://opentiles.com/cmarqu/tiles_relief/12/2209/1372.png >>> >>> Does anybody have a guess as to what the crucial difference is? >>> >> They are more different then You think. In Your case You shade >> luminosity and assign opacity 0.7 (constant alfa). In mapy.cz image is >> all black and in fact shaded alfa channel is making it look relief. >> >> Try to invert Your gray value and make it alfa of new black image. >> Then simple composition with base layer without any additional opacity >> change in OpenLayers should be enough. > > Wow, thanks very much for this. Now it's all clear... > > Can your Mapnik work that went into 0.6 produce just such tiles? When > I use them to read the raster image created by hillshading.cpp from > demtools, they are much more nicely smoothed, and it would be great to > not have an additional step needed. >
My work allow You to generate complete tiles with shading and content in one step, also using 'multiply' method that gives effect that mapy.cz use. If You would like to have separate relief and content tiles using mapnik, it can't generate such alfa encoded shading from simple shaded raster. Solution depends, If You want dynamic tile generation (on demand) or one time seed (ie: tilecache_seed.py). In dynamic case, I assume You use mapnik to cut and resize tiff generated using demtools. To have: demtool->mapnik->WWW, You probably need modyfying hillshading.cpp to generate output image like You need (black piksels with computed values as alfa), because mapnik can't change existing tiff like I described. But there is still problem with png256 format conversion, as it is extreme case of: http://trac.mapnik.org/ticket/202 and any implementation wouldn't be as good as direct approach, that doesn't needs palette computation, only using specific one (alfa[i]=i and color[i]=black, i=0..255). In case of static relief tiles, it would be easier to convert current simple hillshaded tile images using palette manipulation only on gray png256: create tRNS from color palette(alfa value from gray value), and then assign black to each position in color palette. >> I tried this too when experimenting, but finally decided for different >> approach (like gimp's merge-grain): >> http://mapa.ump.waw.pl/ump-www/?zoom=10&lat=49.54125&lon=19.28081 >> https://lists.berlios.de/pipermail/mapnik-users/2009-February/001651.html > > Yes, I'm basically following your process on my "main map". IMHO the > mapy.cz way looks a bit nicer, as it doesn't have the plastic-looking > effect so much and leaves the colors intact. > > Do you think the separation of the tiles would help reducing colors > and total size of tiles needed? > Check and share results :) If I find some time (cpu time also :) ) I'll try to make tests on my own too. As example downside of separate tiles: browser needs to make 2x more http request and there are limits to maximum concurrent connections. If size is reduced enough to compensate potential time increase due to more files to download, it could be worth separating. Another advantage is when You need to shade more then one tile source: relief will be downloaded by browser only once. -- Marcin Rudowski _______________________________________________ Mapnik-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/mapnik-users
