On 31.10.2010 23:39, Steve Ratcliffe wrote:

On 29/10/10 22:32, h.scholland@googlemail.com wrote:

...

Hi, I would like to use new binary-format with mkgmap splitter, but I've no idea how to build a jar-file from branch. In makgmap-dev I read that you have build it successfully. Would it be possible, that you send me a working splitter.jar with binary support?

You can email it to h.scholland@googlemail.com I've built a complete splitter distribution from the pbf branch and put it at http://files.mkgmap.org.uk/download/6/splitter-r161.zip It includes everything you need.

File: splitter-r161.zip created on 31 oct 2010 URL: http://files.mkgmap.org.uk/download/6/splitter-r161.zip Description: Complete splitter distribution built from the .osm.pbf enabled branch.

..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev Is this the crosby integration branch or trunk?

I tried to compile the crosby branch but it fails in many many places (would like to try it out, but impossible to find out about all missing dependencies).

Hi Steve, On Sun, Oct 31, 2010 at 10:39:27PM +0000, Steve Ratcliffe wrote:

I've built a complete splitter distribution from the pbf branch and put it at http://files.mkgmap.org.uk/download/6/splitter-r161.zip

Thanks, this cuts my splitting time to about half.

It includes everything you need.

Everything except the .svn directories. Could you add the jar files to the splitter repository, or are there some license considerations? How hard would it to be to make splitter output the data in osm.pbf format instead of osm.gz? By the way, I figured out that by carefully adjusting the tile borders, it is not necessary to filter the input (move the coastline endpoints). This approach also creates less "imaginary sea" around the map tiles. Polygon-shaped tiles would solve this problem in an even more elegant way. Best regards, Marko

Hi Steve,

There was no license indication on the osmpbf files last time I looked, but mainly I didn't check anything in because I just bodged it to get it to build and it needs sorting out properly.

Maybe the easy way would be to ask the Osmosis developers, because they are bundling some of the jars.

...

By the way, I figured out that by carefully adjusting the tile borders, it is not necessary to filter the input (move the coastline endpoints). This approach also creates less "imaginary sea" around the map tiles. Polygon-shaped tiles would solve this problem in an even more elegant way.

That sounds very interesting, is it something you do (or could do) automatically or are you adjusting by hand?

I did it by hand, but I guess that it could be assisted with a GUI, e.g., extracting a natural=coastline extract of the map extract with Osmosis and then drawing tile rectangles (using appropriate snap-to-grid) on top of that data. Maybe there should be a JOSM plugin for editing areas.list? (If the alignment of the coordinates were not that important, a converter from a subset of OSM XML to areas.list could do the trick.) If you look at the map of Finland, you can see that the south coast is sloping a little in the NE direction. Thus, if the southern (or southeastern) tile has its NE corner near where the coastline extract stops, you will have a nice sea in that tile. The tile to the north from that must extend further to the east, since the land border is sloping to the NE direction. In the north, it was a little tricky. I cut the Northern Finland tile so that it takes a little bit of sea in the south. In this way, its southern neighbour tile had a continuous coastline extending all way to the tile borders. I tried to split two tiny pieces from the northern tile to silence a warning and fix the flooding of an island, but in the end I enabled generate-sea: multipolygon,extend-sea-sectors for the northern tile. That apparently extended the abruptly ending west end of the coastline straight to south, to the tile border. I will update the files on http://www.polkupyoraily.net/osm/ hopefully tomorrow, if the data is OK. Someone had broken some oneway streets and a multipolygon in today's extract. Marko

On Thu, Nov 04, 2010 at 05:55:59AM -0700, aighes wrote:

I've problems with Paijanne, the lake in the south of Valkeakoski and with a lake about 50km east of the southern part of Paijanne, but I can't find a mistake in the Multipolygons of these lakes.

I fixed it by moving my tile border so that all of Päijänne is within the same tile. I currently have only two broken multipolygons that might be caused by tile borders (I have not checked recently): http://www.openstreetmap.org/browse/relation/302872 http://www.openstreetmap.org/browse/relation/900367 These multipolygons are (or were) too high-resolution for mkgmap: http://www.openstreetmap.org/browse/relation/405246 http://www.openstreetmap.org/browse/relation/934321 http://www.openstreetmap.org/browse/relation/1068062 http://www.openstreetmap.org/browse/relation/1225936 http://www.openstreetmap.org/browse/relation/1232121

Also there are many more routing errors ;)

Crowdsourcing to the rescue: http://forum.openstreetmap.org/viewtopic.php?pid=115222 Marko

On Wed, Nov 3, 2010 at 6:32 PM, Marko Mäkelä <marko.makela@iki.fi> wrote:

Hi Steve,

On Sun, Oct 31, 2010 at 10:39:27PM +0000, Steve Ratcliffe wrote:

...

I've built a complete splitter distribution from the pbf branch and put it at http://files.mkgmap.org.uk/download/6/splitter-r161.zip

Thanks, this cuts my splitting time to about half.

...

It includes everything you need.

Everything except the .svn directories. Could you add the jar files to the splitter repository, or are there some license considerations?

How hard would it to be to make splitter output the data in osm.pbf format instead of osm.gz?

Its not that hard to write a PBF serializer, but it is somewhat more effort than writing a parser. Scott