Re: [mkgmap-dev] New locator branch
On 03/18/2011 02:55 PM, Ralf Kleineisel wrote:
On 18.03.2011 14:45, WanMil wrote:
Yes, we provide the same option for coastlines. So it's possible although there is the size restriction. Boundaries take around 3% of the complete OSM data (3% as osm.gz compared to osm.pbf). So think about creating a europe map from the 4.5 GB dump. The boundary data file would be around 3%*4.5GB(osm.pbf) = 135MB(osm.gz). So in the end your computer additionally needs as much main memory as you need to compile a 135MB big tile.
Wouldn't it be enough to keep that part of the boundaries in memory which lie in the area of the map tile mkgmap is processing?
On 03/18/2011 02:55 PM, Ralf Kleineisel wrote:
On 18.03.2011 14:45, WanMil wrote:
Yes, we provide the same option for coastlines. So it's possible although there is the size restriction. Boundaries take around 3% of the complete OSM data (3% as osm.gz compared to osm.pbf). So think about creating a europe map from the 4.5 GB dump. The boundary data file would be around 3%*4.5GB(osm.pbf) = 135MB(osm.gz). So in the end your computer additionally needs as much main memory as you need to compile a 135MB big tile.
Wouldn't it be enough to keep that part of the boundaries in memory which lie in the area of the map tile mkgmap is processing?
Yes. For this we need: * A preprocessing that converts the (complete) boundary file to a file format that allows to load parts only. This may be one file for each 1°x1° part. * mkgmap would have to load the relevant parts during tile processing. Each boundary area gets and unambigious id so we could merge them easily when a tile overlaps more than one 1°x1° boundary part. * The boundary information might be ignored while loading the tiles. The same algorithm can be reused for coastline processing. WanMil
2011/3/20 WanMil <wmgcnfg@web.de>:
Yes. For this we need: * A preprocessing that converts the (complete) boundary file to a file format that allows to load parts only. This may be one file for each 1°x1° part. * mkgmap would have to load the relevant parts during tile processing. Each boundary area gets and unambigious id so we could merge them easily when a tile overlaps more than one 1°x1° boundary part. * The boundary information might be ignored while loading the tiles.
The same algorithm can be reused for coastline processing.
Wouldn't it make sense for the splitter - if we already have this boundary file - to split "tiles" primarily by political boundaries and only if one of them contains too many nodes, devide them by a straight line? I think I read on this list before that in theory, polygon-shaped tiles are no problem in garmin format. This would make it easier for mkgmap to assign the adress information and a meaningful "name" per tile. -Martin
On Sun, Mar 20, Martin Simon wrote:
I think I read on this list before that in theory, polygon-shaped tiles are no problem in garmin format.
At least garmin seems to do this for the City Navigator Maps for Europe and Noth America. It would be really great if mkgmap could create such maps, too. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Markus Rex, HRB 16746 (AG Nuernberg)
participants (4)
-
Martin Simon -
Ralf Kleineisel -
Thorsten Kukuk -
WanMil