Re: [mkgmap-dev] remove splitter option align-for-dem again or change mkgmap?

Hi Andrzej, I don't understand. What layers do you mean? How does it help? Gerd Von: mkgmap-dev im Auftrag von Andrzej Popowski Gesendet: Sonntag, 28. Januar 2018 00:48 An:

Re: [mkgmap-dev] remove splitter option align-for-dem again or change mkgmap?

Hi Gerd, I think resolution in bits is a clever idea. This way we can get a tile, where border of all layers is exactly the same. Maybe this is not requirement for a map, but it seems to be a neat solution. -- Best regards, Andrzej ___ mkgmap-dev

Re: [mkgmap-dev] Is dem-tdb branch ready for trunk ?

Thanks for sharing your results. Have you tested data from http://opendem.info/opendemeu_download_4326.html ? El 27/01/18 a las 15:56, Peter Danninger escribió: Some results from my .hgt-tests: I wanted to find usable .hgt files for my web-application zu add height data to .gpx

Re: [mkgmap-dev] Is dem-tdb branch ready for trunk ?

Hi Henning, Steve and I agreed that it is okay to merge auto-block into dem-tdb branch instead of trunk. This already happened, so there is no plan to merge auto-block into trunk. I think you are right, it should be easier to reuse complete DEM files. Maybe I can implement this as a faster

Re: [mkgmap-dev] Is dem-tdb branch ready for trunk ?

El 27/01/18 a las 14:57, Carlos Dávila escribió: I have no objective method to compare hgt sources (is there any?) Well, a method I have already used is to get the number of voids in a hgt file using QGIS. ___ mkgmap-dev mailing list

Re: [mkgmap-dev] Is dem-tdb branch ready for trunk ?

Hi I think before having such a container we would need to have a clear idea what hgt sources are best. I have no objective method to compare hgt sources (is there any?) but I have done some test comparing contour lines generated from different sources. Copernicus (EU-DEM) data has been

Re: [mkgmap-dev] Is dem-tdb branch ready for trunk ?

Hi Gerd, first I would suggest to wait for Steve is merging the block size branch and just afterwards merge DEM branch to trunk. I think it's causing trouble merging DEM branch before, as user might end up with errors. Later start another branch for DEM-optimization. I don't know how other

Re: [mkgmap-dev] Is dem-tdb branch ready for trunk ?

Hi all, just to make this clear: The proposed container format is something for the future. I think we should wait at least 6 month to be sure that the encoder is working well, else we would end up with huge files containing wrong data. I think such a container format would require some kind of

Re: [mkgmap-dev] Is dem-tdb branch ready for trunk ?

Hi Thomas, I see two major problems with this: 1) A file containing all DEM data for e.g. dem-dist=9936 would be huge, and most users only need a small portion of it 2) I am not sure if it is allowed to publish this data when input comes from e.g. 1'' hgt files which are not free. My

Re: [mkgmap-dev] Is dem-tdb branch ready for trunk ?

Hi The idea of a dem.zip sounds would have some major disadvantages 1) Data can only be 3arc or 1 arc not both 2) 1 arc data to me is more preferable but contains void data which have to be replaced with 3arc data Nick On 27/01/2018 09:40, Thomas Morgenstern wrote: Maybee we can create a

Re: [mkgmap-dev] Is dem-tdb branch ready for trunk ?

Maybee we can create a ready to use DEM-model, store it like the bounds.zip and see.zip ? The user can download it and mkgmap reads the DEM from downloaded #DEM.ZIP# ? This method would be a graet advantage for users, who not so familiar with the DEM . Regards Thomas

[mkgmap-dev] splitter r590: (undocumented) option align-for-dem was removed

Hi all, see http://www.mkgmap.org.uk/websvn/revision.php?repname=splitter=590 Please make sure to remove the option from your scripts. Gerd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Is dem-tdb branch ready for trunk ?

Hi all, I am not aware of any erros in r4091, so I think it is time to merge it into trunk. I see only one problem: HGT data changes rarely, so I'd prefer to do the costly DEM calculations only once and be able to store the results. I've already described how to do this here [1] but I'd prefer

Re: [mkgmap-dev] remove splitter option align-for-dem again or change mkgmap?

Hi Andrzej, I've thought about removing --resolution as well in the past, but for different reasons: I'd prefer to let splitter decide what resolution is reasonable. I also wonder if there is a good reason to store coordinates in map units instead of degrees in splitter, maybe this was only