first draft of WPVS HowTo
|
|
|
||||||||
|
Hi Christian,
thanks that looks really good, about the geotiff to xyz conversion, I think (in the near future) we might be able to use geotiff instead of converting first to xyz... Christian Willmes wrote: > Hi, > > I posted a first draft of the WPVS HowTo. It uses an public domain > dataset from www.citygml.org. > > I thought this would maybe good to have something to discuss about that > everybody can test for himself and maybe correct the errors of the > process I posted, because textures and buildings are not redered from > the wpvs instance created by this HowTo. This is unfortunate, did you fix the translation vector?, could you send me the buildings you use, maybe I find some time to check if I'm able to load them in the bonn datasets. About the textures, this is very cumbersome, you should be able to see something... Currently it is very important, that the overall texture envelope is exactly that of the DEM, is this the case? Maybe markus can give some hints on this as well (maybe in the other thread) he wrote most of the dem->texture mapping functionality. > > See: https://wiki.deegree.org/deegreeWiki/deegree3/HowToSetupWPVS > > best regards, > Christian with kind regards, Rutger -- Rutger Bezema l a t / l o n GmbH Aennchenstrasse 19 53177 Bonn, Germany phone ++49 +228 184960 fax ++49 +228 1849629 http://www.lat-lon.de http://www.deegree.org ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ deegree-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/deegree-users |
||||||||
signature.asc (204 bytes) |
|
|
||||||||
|
In reply to this post
by Christian Willmes
Hi Christian,
I succeeded to setup your datasets for use in the (interactive) deegree 3 WPVS. - DEM without textures: http://web.lat-lon.de/~schneider/pics/dem.jpg - DEM with textures: http://web.lat-lon.de/~schneider/pics/dem+texture.png The latter image may not look as good as expected. This is because the texture is a shaded image of the DEM -- and the shading is also performed in the rendering. I achieved to set it up by following the instructions on your wiki page. However, I had to change the parameters for the DEMDatasetGenerator and the RasterTreeGridifier slightly. DEMDatasetGenerator ------------------- Original: DEMDatasetGenerator -default_z 0 -max_z 183.0 -in_file [...] -in_x 1300 -in_y 1100 -res_x 10 -res_y 10 -in_scale 0.1 -out_levels 4 -out_rows 64 -offset_x 0 -offset_y 0 -in_offset 0 -out_x 2048 -out_y 2048 -out_dir [...] Mine: DEMDatasetGenerator -default_z 0 -max_z 183.0 -in_file [...] -in_x 1300 -in_y 1100 -res_x 10 -res_y 10 -in_scale 0.1 -out_levels 6 -out_rows 128 -offset_x 0 -offset_y 0 -in_offset 0 -out_x 10240 -out_y 10240 -out_dir [...] Differences: - out_levels: 6 The number of levels must be chosen so the resolution of the finest geometry level matches the value (out_rows * res_x). Only then, every heixel information will be present in the multiresolution model. You can check this in the output: ... Starting a worker at location code 1. Starting a worker at location code 0. tile 000000, height: 1280.0 (THIS IS THE IMPORTANT INFORMATION: 1280.0 = 128 * 64) tile 00000, height: 1810.1934 tile 0000, height: 2560.0 tile 000, height: 3620.3867 ... - out_rows: 128: This change is not critical. out_rows determines the size of the geometry tiles. The size of the tiles should be "reasonable". Not too big and not to small, as each tile must be read using a separate disk access. With 128, the tile size is about 600KB (which performs very well in our setups). However, you could choose 64 as well, but you must adapt out_levels then. - out_x/out_y: 10240: This one is mean ;-) As you know, the number of heixels in each direction must be a power of two, which is a requirement that stems from the internal multiresolution structure. However, these parameters are actually specified in world units. As we only have a single heixel value every 10 meter, we must multiply by 10 here. So why not 20480, I hear you ask. The actual dimensions of the defined domain are 13000/11000 (1300*10, 1100*10). If we use 20480 instead of 10240, we don't have any heixel or texture information for (large) parts of the terrain -- and this actually caused the problem with the unrendered textures... I know, this is an annoying limitation (which should be solved in the tools), but for now, lets go with 10240 and just clip a part of the domain. RasterTreeGridifier ------------------- Original: RasterTreeGridifier -crs EPSG:31466 -e tiff -blob_size 512000 -tile_height 512 -tile_width 512 -inputdir [...] -outputdir [...] -max_x 2577000 -max_y 5662000 -min_x 2564000 -min_y 5651000 Mine: RasterTreeGridifier -crs EPSG:31466 -e tiff -blob_size 2147483648 -tile_height 512 -tile_width 512 -inputdir [...] -outputdir [...] -min_x 2564000 -min_y 5651000 -max_x 2580000 -max_y 5670000 - blob_size: 2147483648: 512000 (bytes) is so small that a blob cannot hold a single texture tile (yes, an error message should be printed rather than failing miserably in the WPVS...). Just choose a large value here. 2147483648 is 2 GB, which is the maximum file size of some older filesystems. This value just specifies when a new blob has to be opened and not the inital size, so don't worry -- you won't end up with 2GB files, as your dataset is rather small. - max_x: 2580000: This should be calculated as min_x + domain width (10240). So max_x would be 2574240. However, this gives me an error when the texures are fetched. I found that it can be overcome by choosing a value that's a bit bigger. We're investigating this and will report when it is fixed. - max_y (same as max_x) Please report whether you manage to get it running now. We will do our best to solve the remaining problems -- and make the configuration easier in the medium term. Best regards, Markus -- Markus Schneider l a t / l o n GmbH Aennchenstrasse 19 53177 Bonn, Germany phone ++49 +228 184960 fax ++49 +228 1849629 http://www.lat-lon.de http://www.deegree.org ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ deegree-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/deegree-users |
||||||||
|
|
|
||||||||
| Free Embeddable Forum Powered by Nabble | Help |
