[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