Hi, I created a merged map using osmosis: $ ./osmosis --rb finland.osm.pbf --rb germany.osm.pbf --rb us-west.osm.pbf --merge --merge --wx DE_FI_USW.osm which results in an uncompressed XML output map DE_FI_USW.osm of ~36G in size. So this maps contains three different countries which do not necessarily have any overlap or connections, and bounding rectangles far apart from each other. Now I try to create one single gmapsup.img out of it using the tile splitter and mkgmap: $ java -Xmx5000M -jar ../splitter.jar --mapid=63240345 --max-nodes=1000000 ../DE_FI_USW.osm after this step I get a list of tiles which is suspiciously small, about 165M. $ java -Xmx4000M -jar ../../mkgmap.jar --max-jobs --style-file=../../aiostyles/basemap_style/ --description='DeFiUs' --country-name=world --country-abbr=W --family-id=4 --product-id=45 --series-name='basemap' --family-name=OSM --area-name=W --latin1 --mapname=63240345 --draw-priority=10 --add-pois-to-areas --make-all-cycleways --link-pois-to-ways --remove-short-arcs --net --route --gmapsupp ../*.osm.gz ../../aiostyles/basemap.TYP When I install the map, I only get map data for Finland, nothing shown for Germany nor US West. So looks like the tile splitter took into account only the first part of the merged .osm map. Am I doing something wrong here? Or is this an incompatibility or a possible problem with the tile splitter? Thanks, Dominik
On Tue, Apr 26, 2011 at 08:00:27PM +0300, Dominik Röttsches wrote:
I created a merged map using osmosis: $ ./osmosis --rb finland.osm.pbf --rb germany.osm.pbf --rb us-west.osm.pbf --merge --merge --wx DE_FI_USW.osm which results in an uncompressed XML output map DE_FI_USW.osm of ~36G in size.
Side note: why not --wb DE_FI_USW.osm.pbf? Splitter can process osm.pbf.
So this maps contains three different countries which do not necessarily have any overlap or connections, and bounding rectangles far apart from each other.
I would not bee too sure about that. I have come across (and split) multipolygons that had members in Finland but also in Germany, Spain or North America.
Now I try to create one single gmapsup.img out of it using the tile splitter and mkgmap:
$ java -Xmx5000M -jar ../splitter.jar --mapid=63240345 --max-nodes=1000000 ../DE_FI_USW.osm
after this step I get a list of tiles which is suspiciously small, about 165M.
What kind of coordinates do you see in the areas.list? Could it be that splitter is misinterpreting the bounding box?
Am I doing something wrong here? Or is this an incompatibility or a possible problem with the tile splitter?
For what it is worth, about a year ago I experimented with merging a section of the Baltic Sea coastline to the (then) finland.osm.bz2 from Geofabrik, so that the coastline would extend to every tile border. I did not get the merging to work. Best regards, Marko
On 26/04/2011 21:00, Dominik Röttsches wrote:
Hi,
I created a merged map using osmosis: $ ./osmosis --rb finland.osm.pbf --rb germany.osm.pbf --rb us-west.osm.pbf --merge --merge --wx DE_FI_USW.osm which results in an uncompressed XML output map DE_FI_USW.osm of ~36G in size.
So this maps contains three different countries which do not necessarily have any overlap or connections, and bounding rectangles far apart from each other.
Now I try to create one single gmapsup.img out of it using the tile splitter and mkgmap:
$ java -Xmx5000M -jar ../splitter.jar --mapid=63240345 --max-nodes=1000000 ../DE_FI_USW.osm
after this step I get a list of tiles which is suspiciously small, about 165M.
$ java -Xmx4000M -jar ../../mkgmap.jar --max-jobs --style-file=../../aiostyles/basemap_style/ --description='DeFiUs' --country-name=world --country-abbr=W --family-id=4 --product-id=45 --series-name='basemap' --family-name=OSM --area-name=W --latin1 --mapname=63240345 --draw-priority=10 --add-pois-to-areas --make-all-cycleways --link-pois-to-ways --remove-short-arcs --net --route --gmapsupp ../*.osm.gz ../../aiostyles/basemap.TYP
When I install the map, I only get map data for Finland, nothing shown for Germany nor US West.
So looks like the tile splitter took into account only the first part of the merged .osm map. Am I doing something wrong here? Or is this an incompatibility or a possible problem with the tile splitter?
Would you use to use the --mixed option to splitter or does osmosis automatically sort files when it merges them?
Hi Marko, Charlie,
So looks like the tile splitter took into account only the first part of the merged .osm map. Am I doing something wrong here? Or is this an incompatibility or a possible problem with the tile splitter?
Would you use to use the --mixed option to splitter or does osmosis automatically sort files when it merges them?
Not sure whether osmosis sorts automatically. Now, I did a sort run before: $ ./osmosis --rx DE_FI_USW.osm --sort --wb DE_FI_USW.osm.pbf omitmetadata=true then tried splitting again. From Marko's mail:
Side note: why not --wb DE_FI_USW.osm.pbf? Splitter can process osm.pbf.
Thanks, I didn't know that. I had read posts about older versions of splitter that couldn't deal with pbf.
What kind of coordinates do you see in the areas.list? Could it be that splitter is misinterpreting the bounding box?
Areas only cover Finland :-( http://maps.google.com/maps?q=roettsches.de%2Fdominik%2Fareas.kml In the splitter output [1], the following bounding box is printed: "Bounding box 19.02427 59.287829999 31.600889999000003 70.09959" how to interpret these values to check whether the map bounding box is right? If I use 19.02427 59.287829999 in Google Maps, it shows a place in the Arabian Sea, the other coordinate is somewhere in Pakistan... Can I tell the splitter to ignore the map's bounding box altogether and find its own? Any other ideas how to make it take into account the whole merged map? Dominik [1] Splitter output: $ java -Xmx5000M -jar ../splitter.jar --mapid=63240345 --max-nodes=1000000 --write-kml=areas.kml ../DE_FI_USW.osm .pbf cache= description= geonames-file= legacy-mode=false mapid=63240345 max-areas=255 max-nodes=1000000 max-threads=8 (auto) mixed=false no-trim=false output-dir= overlap=2000 resolution=13 split-file= status-freq=120 write-kml=areas.kml Elapsed time: 0s Memory: Current 119MB (2MB used, 117MB free) Max 4444MB Time started: Wed Apr 27 08:58:57 CEST 2011 Map is being split for resolution 13: - area boundaries are aligned to 0x800 map units - areas are multiples of 0x1000 map units wide and high Processing ../DE_FI_USW.osm.pbf Bounding box 19.02427 59.287829999 31.600889999000003 70.09959
Areas only cover Finland :-( http://maps.google.com/maps?q=roettsches.de%2Fdominik%2Fareas.kml
Sorry, that link didn't work, here's the right one: http://maps.google.com/maps?q=http%3A%2F%2Froettsches.de%2Fdominik%2Fareas.k... d
On Wed, Apr 27, 2011 at 10:14:14AM +0300, Dominik Röttsches wrote:
Can I tell the splitter to ignore the map's bounding box altogether and find its own? Any other ideas how to make it take into account the whole merged map?
Can you split each extract separately and then tell mkgmap to produce a map from the tiles generated by the three splitter runs? IIRC, I tried producing a combined map of finland.osm.bz2 and estonia.osm.bz2 in 2009, when I visited Tallinn. It sort of worked, but routing did not work in Tallinn. I did not investigate or experiment further. It could also have been due to bad map data; I only keep Finland tidy. :-) In 2010, I loaded just the Estonian map and then just a small area where I moved, for adding some pedestrian crossings and sidewalks and the like. You could use my hand-made areas.list for Finland. It tries hard to get a nice generate-sea. It also avoids splitting the Lake Päijänne multipolygon. One of your tile borders slices the lake. The tile border should be a little more west near the line Jämsä-Kuhmoinen-Padasjoki. Best regards, Marko
Hi Marko,
Can you split each extract separately and then tell mkgmap to produce a map from the tiles generated by the three splitter runs?
Good idea, thanks. Generation seems to have worked, at least combining Finland and Germany. When adding US, it complained "map area too small to split". Will have to check that, maybe trying another split run on the US map with different parameters. Now downloading the result from my server and will test it on the gps device then later.
You could use my hand-made areas.list for Finland. It tries hard to get a nice generate-sea. It also avoids splitting the Lake Päijänne multipolygon. One of your tile borders slices the lake. The tile border should be a little more west near the line Jämsä-Kuhmoinen-Padasjoki.
That would be useful. Do you have it online somewhere? Or could you send it in a personal email? Thanks, Dominik
On Wed, Apr 27, 2011 at 01:14:33PM +0300, Dominik Röttsches wrote:
You could use my hand-made areas.list for Finland.
That would be useful. Do you have it online somewhere? Or could you send it in a personal email?
Ah, sorry, I forgot to add the link: http://www.polkupyoraily.net/osm/ http://www.polkupyoraily.net/osm/files/areas.list You can see the descriptions in osm2img.sh. I used to have a separate mkgmap.args file, but I wanted the flexibility of a shell script (in preparation for the multi-output-layer feature that I am going to prototype soonish). Marko
On 27.04.2011, at 10:14, Dominik Röttsches wrote:
In the splitter output [1], the following bounding box is printed: "Bounding box 19.02427 59.287829999 31.600889999000003 70.09959" how to interpret these values to check whether the map bounding box is right?
This bounding box is only Finland:
19.02427 59.287829999 31.600889999000003 70.09959
The order is: Lower Left E, N - Top Right E, N i.e. N59.288 E19.024 to N70.1 E 31.601 So does osmosis not generate the correct bounding box? Dominik
I came across a similar problem last year. The trouble was with the merge function of osmosis. It takes the bounding box of the output file, from the first input file, regardless of the bounding boxes of the other input files. But the data from all the input files is in the merged file. I contacted the maintainer of osmosis about this but received no reply. It may be that it is the intended behaviour, rather than a bug. I worked around this problem, but it is not at all convenient. You create the output file in uncompressed .osm format. This can result in a large file. Then you edit the file with a hexadecimal editor, because it will be too large to edit with a text editor. The bounds are very near to the start of the file. Use the hexadecimal editor to overwrite the bounds with the correct values. This way, you only need to rewrite one cluster, not the whole file. (For Mac, Hex Fiend from ridiculousfish.com is a good hex editor, free and open-source.) I have a vague recollection that it is also possible to get the splitter to ignore the bounds in the input file.
On Wed, Apr 27, 2011 at 02:48:03PM +0100, Adrian wrote:
I worked around this problem, but it is not at all convenient. You create the output file in uncompressed .osm format. This can result in a large file. Then you edit the file with a hexadecimal editor, because it will be too large to edit with a text editor.
Another option would be to pipe it through a stream editor, such as sed, awk or perl. I did that at one point in my osm2img.sh, for two tasks: moving the coastline endpoints outside the tile borders, and removing broken multipolygons generated by a bot. The broken multipolygons have since then been fixed, and when switching to osm.pbf, I worked around the coastline endpoint problem by choosing my tile borders carefully. Marko
Hi Adrian,
I came across a similar problem last year. The trouble was with the merge function of osmosis. It takes the bounding box of the output file, from the first input file, regardless of the bounding boxes of the other input files. But the data from all the input files is in the merged file. I contacted the maintainer of osmosis about this but received no reply. It may be that it is the intended behaviour, rather than a bug.
Good to know, I'll try to follow up on this.
I worked around this problem, but it is not at all convenient. You create the output file in uncompressed .osm format. This can result in a large file. [...]
Without having tried it. If - as it seems - osmosis takes the first map for the bounding box, one could create a dummy empty map with a spanning, large enough bounding box as the first one and merge it with the other ones.
I have a vague recollection that it is also possible to get the splitter to ignore the bounds in the input file.
Any more thoughts on this coming back in the meantime? Dominik
On 28/04/2011 14:32, Dominik Röttsches wrote: [snip]
I have a vague recollection that it is also possible to get the splitter to ignore the bounds in the input file.
Any more thoughts on this coming back in the meantime?
Dominik It's definitely possible in mkgmap using --ignore-osm-bounds, but I wasn't aware that you could do the same thing in splitter. Perhaps doing it in mkgmap is enough.
Hi Adrian, On 27.04.2011, at 16:48, Adrian wrote:
I came across a similar problem last year. The trouble was with the merge function of osmosis. It takes the bounding box of the output file, from the first input file, regardless of the bounding boxes of the other input files. But the data from all the input files is in the merged file. I contacted the maintainer of osmosis about this but received no reply. It may be that it is the intended behaviour, rather than a bug.
It's considered a bug now. Igor Podolsky replied to my question on osmosis-dev: http://lists.openstreetmap.org/pipermail/osmosis-dev/2011-May/001023.html Regards, Dominik
participants (4)
-
Adrian -
Charlie Ferrero -
Dominik Röttsches -
Marko Mäkelä