[mkgmap-dev] I would like a maxways parameter and associated code to limit the number of ways in a tile

Wed May 30 08:06:11 BST 2018

Hi Andrzej,

I think your goal is to create evenly sized tiles, e.g. around 8 MB. Most others are probably happy as long as the calculated tiles don't reach the hard size limits
in the img format. The current algo in splitter simply counts the nodes (with an equal weight). Some nodes produce no data in the img files and
others produce many bytes ( e.g. a POI ). I think the current algo in splitter assumes that there is a rather constant ratio when you look at enough nodes.

This might not be the case, esp. in areas which are dominated by imports or by few mappers using special techniques to map something.

My approach to handle this would be to compute a grid similar to the density map created by splitter, but this grid would contain a weigh factor for each grid element. So, when the node count is 12121 for a grid element and the weigh factor is 1.5 the used value for the area calculation would be 1.5 * 12121.
The question is how to fill the weigh factor grid. Possible solution:
Split planet file using the grid, run mkgmap with the desired options for each grid element, store the size of the img file, and normalize these values to a weigh factor.
If one uses e.g. a country extract instead of planet we would use factor 1 for all grid elements not fully covered by the extract.

I see these special cases:
1) In areas with rather few OSM nodes (deserts, large woods) the img size mainly depends on bytes for background polygons and even more on elevation / DEM data
The actual amount of data depends on the profile of the area.
2) In areas with many small islands we have many bytes for background + sea polygons and the coastlines.
Maybe that means we also need a constant value for each grid element.

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej at poczta.onet.pl>
Gesendet: Montag, 21. Mai 2018 19:27:04
An: mkgmap-dev at lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] I would like a maxways parameter and associated code to limit the number of ways in a tile

Hi Randolph,

what do you mean by "ways"? Any line, road with an address, road used
for routing? I don't remember if I ever spotted similar problem.

On the other side, I think splitter can be better tuned for current
mkgmap. I get impression, that splitter is designed to make a good work
with simple maps and doesn't account for addresses, routing nodes od DEM
data. It would be nice, if there were more options, than maxnodes.

For my maps, I split OSM data in two stages. First I prepare artificial
data, that I believe represent better actual size of compiled tiles.

I extract addresses as points and highways as simple 2-points lines (I
do it with modified osmfilter). Then I make splitter to calculate all
tiles using as an input following data:
- OSM source
- 0-2 times extracted addresses
- 6-10 times extracted highways
- 1-2 times contour lines

I believe, that additional points form address account for some NET
size, points form highways for additional NOD size and duplicated
contour lines for DEM size. It needs some tuning for different areas,
but I think I get a bit more uniform sizes of img than with direct
splitting.

On second stage I use prepared areas.list to split real data.

Basically I do something like this:

osmfilter.exe data.o5m --keep= --keep-ways=highway=* -o=net.o5m
osmfilter.exe data.o5m --keep= --keep-nodes=addr:housenumber=* -o=adr.o5m

splitter.jar --stop-after=split --max-nodes=3000000 data.o5m net.o5m
net.o5m net.o5m net.o5m net.o5m net.o5m net.o5m net.o5m adr.o5m adr.o5m
contour.pbf contour.pbf

splitter.jar --split-file=areas.list data.o5m contour.pbf

It would be helpful, if I could do it in a single pass. Maybe splitter
could filter internally specific nodes - these which would end as
routing nodes or address information and add some multiplier when
counting these nodes for splitting? Assuming this is easy to implement,
otherwise my procedure is good enough.

--
Best regards,
Andrzej

_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev