[OSM-talk] osmcut.c Some problems with my solution :-)

Michael Hufer michael.hufer at gmx.de
Tue Oct 28 20:03:10 GMT 2008


Hi,
While playing around with osmcut (C-Version) and mkgmap I came across a few 
problems.

1) some ways which cross the tile boundaries where not correctly drawn i.e. 
the ways end at the last node inside the tile boundary. Even thought the 
nodes of these ways are also present in the tile osm-file albeit after the 
way elements at the end of the tile osm-file.

My solution: 
The input.osm file is already read twice to add the nodes outside the tile 
boundaries. But the ways were already written in the first pass. I changed 
that so that the ways are also written to the tile osm-file in the second 
pass not the first so that now all node elements are above the ways elements 
they are used in. This solution unfortunately increases the processing time 
as the current version stops when it reached the first way element in the 
second parse pass of the input file. I.e. it processed only the node elements 
in the second pass while this new version must process node AND way elements 
in the second pass.

2) A tile size less than ~1 degree is not possible in the current version of 
osmcut as the tile numbers are stored in a unsigned short int variable and 
the tile numbers are always calculated across the whole planet (i.e. 360x180 
degrees).

AFAIK , splitting the whole planet in <1degrees tiles would exceed some limits 
in the Garmin IMG/TDP file format, anyway. So I figured it will only make 
sense with input files containing only parts of the planet. (In my case the 
germany.osm excerpt from GEOFABRIK.) So I added new calling arguments for 
osmcut --left --right --bottom --top to tell osmcut the actual boundaries of 
the input file. Tile numbers are then calculated using this boundingbox. I 
did not add any error handling if the input file contains a node with 
coordinates outside this BB. Thought in this case the calculated tile number 
is either negative or greater than the maximum tile number calculated from 
the BB, and this was checked in the original code already.
I also considered to read the boundingbox from the input file itself, but at 
least, the germany.osm from GEOFABRIK does not contain boundingbox 
information (i.e. the 'bounds' element) in the file. So I opted for this 
manual way via arguments when calling osmcut.

3) The new mkgmap feature to crop the IMG-Tiles at the tile boundaries does 
not work as osmcut does not add a boundingbox i.e. the 'bounds' element into 
the tile osm-file.

Calculate the boundingbox of a tile and add it as a 'bounds' element when the 
tile osm-file is first opened i.e. the first node is added to the file.


Since I don't have SVN access I attached the source with my changes to this 
mail. Please check and test the code, and someone with svn access should 
check it into the OSM repository.

Cheers,
	Micha H.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmcut.c.bz2
Type: application/x-bzip2
Size: 6365 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20081028/965f6d30/attachment.bin>


More information about the talk mailing list