<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix"><font face="Courier New, Courier,
        monospace">Dear Sirs:<br>
        <br>
        My definition of "ways" was requested.<br>
        <br>
        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.<br>
        <br>
        --maxnodes sets a soft upper limit on the number of nodes in a
        map tile.<br>
        <br>
        I am requesting a similar in concept --maxways to set a soft
        limit on the number of ways in a map tile.<br>
        <br>
        Randolph J. Herber<br>
      </font><br>
      <br>
      On 5/21/2018 12:27 PM, Andrzej Popowski wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:3ece3259-9c9a-24d8-a565-fe493e6973a1@poczta.onet.pl">Hi
      Randolph,
      <br>
      <br>
      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.
      <br>
      <br>
      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.
      <br>
      <br>
      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.
      <br>
      <br>
      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:
      <br>
      - OSM source
      <br>
      - 0-2 times extracted addresses
      <br>
      - 6-10 times extracted highways
      <br>
      - 1-2 times contour lines
      <br>
      <br>
      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.
      <br>
      <br>
      On second stage I use prepared areas.list to split real data.
      <br>
      <br>
      Basically I do something like this:
      <br>
      <br>
      osmfilter.exe data.o5m --keep= --keep-ways=highway=* -o=net.o5m
      <br>
      osmfilter.exe data.o5m --keep= --keep-nodes=addr:housenumber=*
      -o=adr.o5m
      <br>
      <br>
      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
      <br>
      <br>
      splitter.jar --split-file=areas.list data.o5m contour.pbf
      <br>
      <br>
      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.
      <br>
      <br>
    </blockquote>
    <p><br>
    </p>
  </body>
</html>