osm2mp.pl: OSM -> Polish format converter

Version 0.60

  • added street indexing support (from is_in tag)
  • added command-line options
  • added list of tags for Label (–nametaglist)
  • fixes

Now it needs two perl packages: Template-toolkit, Getopt::Long

have you got a wiki page for documentation for this package ?
and some 1,2,3 steps would be good for us noobies

There is a page in wiki, but not much documentation there

I tried to use mapcenter2. Is there a possibility to pass the -e option?

I just found out that there’s no license information of any sort in osm2mp.

Can you put it under some free software license?

it is under GPL v2 in svn: http://code.google.com/p/osm2mp/

10x for your work liosha. I am u junior programer(Still studying) but in Java and c# would like to help one day.


i tried your script and it works great but only with small areas. It worked with the state of saxony (a german state) and most other german states, but if i try Germany as a whole it crashes with some memory errors. Do you what i can do to fix this?
Ok, the resulting .mp file was also converted by cgps-mapper and MapSource shows it and can calculate routes and i’m able to transfer them with MapConverter onto my Mac.
But a problem arises for me:
If i create maps for every german state, i can show only one of the maps and also routing is possible inside one map only. How can i link or unify more maps to one bigger map? I know it should work with sendmap, but there i need img files while cgpsmapper created directories.

Thanks an best regards

I don’t think our current tools are able to identify the roads that cross different tiles. So currently you could use GPSMapEdit to add the necessary information to the map images. This is described in the wiki.

Some interesting info on this

That’s an old posting before liosha’s script was available :laughing:

My solution to the routing across tiles problem is more of a hack, rather than a solution. I use osmosis to split my OSM data into tiles, and the connecting nodes of the splitted roads are manually tagged as “garmin:is_external_node=true” (they are currently not that many in OSM Malaysia). In liosha’s script I added a conditional statement that will change the nod values for these connecting nodes (see http://forum.openstreetmap.org/viewtopic.php?pid=13274#p13274)

My previous tests shows that it works when the tiles are square (the connecting nodes are all at tile borders). I’m not sure how it’ll work if the tiles are irregular as in the shape of a state or country. Had a plan to experiment on this but haven’t got started yet :frowning:

It’d be great if osmosis or any tile splitter tool can automatically tag the connecting nodes as such, rather than doing a major overhaul of your current tools.

Oh ok, but it’s about the same method as described on the mkgmap/routing page.

Tagging nodes as routing node manually is out of the question for me. It should be done automatically or it doesn’t work :sunglasses:

If the tools are good at detecting edge nodes then irregular shapes should also work imho.

Yes, that would be awsome, but until now neither Osmosis as well as Osmcut are able to split tiles properly (let ways continue right onto the edge and insert dummy nodes on the edge). That’s why every Garmin map created with OSM tools shows gaps in the roadnetwork near tileborders.

Kevin Lindsey has an excellent intersection routines example done with javascript/svg. Could be useful in finding locations of the dummy nodes.

I think the problem with the current planet splitting tools like (osmosis and osmcut) is that it requires a lot of preprocessing or RAM to gather all the road polylines. Determining the intersection with a bbox when you have the polylines available is CPU intensive (but doable), but I guess the OSM XML format isn’t very suitable to read polylines from.

I see three possible solutions:
Load all ways into memory (lots of RAM needed) and check each node to see to which way it belongs (CPU intensive), then save the road/node combination as polyline. Finally check each polyline agains every tile bbox to determine if crosses the border. Then add a node on the border position. Then split the way on the border node and save the resulting ways in the individual tile files. That is a lot of work.

Do as described above, but convert the planet file into a shape file first using osm2shp (dunno what how much RAM/CPU time that requires).

While writing this I forgot the third option I had in mind :confused:

Edit: I cannot find any OSM to Shapefile converter in the SVN repository, so this leaves us at the first option…

Hi all!

I’ve updated osm2mp in svn.
Now it supports maxspeed and access=private

Do you mean you add new nodes to the way where it crosses the edge and tag those as “garmin:is_external_node=true”, or do you tag the nearest existing nodes to the edge that way? If it is the 2nd option, how does the Garmin know which route nodes connect to each other?

I’m looking at osmcut currently to do the job. Osmcut already knows which ways cross a tile edge so adding some more functions to enable routing shouldn’t be very difficult.

Yes, the new nodes should be right at the edge of the tile.

Ok, should the node have the same id in both tiles?

Doesn’t have to be the same id. Here’s an example (in polish format) of a way that extends to another tile. The most important thing is that the coordinates should match up, and it is exactly at the edge of the tile.

Tile 1
Label=~[0x04]E2 NSE
Data0=(3.0391936,101.7062182), … (2.6274582,102)


Tile 2
Label=~[0x04]E2 NSE
Data0=(2.6274582,102), … (2.1308003,102.7412188)

Some info from Rottweiller Auto-Routing guide (via http://cgpsmapper.com/route.htm))

All of the above are if we are using the gpsmapedit method. It seems that maproute can detect and join the matching nodes automatically, which I think is the best way to work with irregular-shaped maps.

Saved by the bell for me :smiley:


Now only Mkgmap needs to be adapted to set the correct edge routing information.

The following is a copy from the IRC talk about this, contains some additional info: