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

Tue May 22 08:39:41 BST 2018

Hi Randolph,

I think it would be a lot of work to change splitter like that, and probably it would require a lot more resources.
I'd be interested in the original error message from MapSource and the tile that produces it, maybe the error is somewhere
in mkgmap.

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Randolph J. Herber <army.bronze.star at gmail.com>
Gesendet: Dienstag, 22. Mai 2018 00:45:49
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

Dear Sirs:

My definition of "ways" was requested.

Splitter first scans nodes (points of various kinds), then ways (forming lines, paths and polygons) and finally relations (container polygons for any or all of nodes, ways or relations). I was using "ways" in the same sense that I understand that splitter uses "ways" in its messages. I hope this helps.

--maxnodes sets a soft upper limit on the number of nodes in a map tile.

I am requesting a similar in concept --maxways to set a soft limit on the number of ways in a map tile.

Randolph J. Herber

On 5/21/2018 12:27 PM, Andrzej Popowski wrote:
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.