Ok, now i understand 
i’ll think about it, but imho it’s not a task for converter
it would be better to make standalone script for MP preprocessing
Joining nodes is exactly what i am doing. The assumption is “if the nodes are so close then what’s the difference - the driver will find it’s way anyway”. I know that this not solves the problem pretty, but it is better the have the routable maps of a country with a few joined nodes than nothing at all.
From technical point of view: I use sweep algorithm. I am not sure if this is official name, but you can probably find it in the net. It sorts the nodes taking x coordinate at first at then looks only for those which are close enough when looking at X axis. It works faster than naive comparison of n^2 nodes.
I don’t compute the distance exactly, because I don’t believe cgpsmapper does that anyway. Computation of REAL distance between two points having their Geo-coordinates is quite expensive. I simply check if the distance is not larger that n seconds. I suspect this is exactly what cgpsmapper and Garmin are doing.
Joining of nodes is a first problem. When you solve this, then you encouter another - self intersecting roads. Garmin prohibits the routable road to cross the same point more than once. And there is lot of such roads in OSM (roundabouts are the obvious example). I am splitting those into two parts but with checking if I am not creating two routing nodes laying to near etc.
I managed to produce some maps this way. I have just started to test them. You can download an UK & Ireland map from http://nickb.dev.openstreetmap.org/public/Setup_OSM-UK-Ireland.exe, but please be aware that this is first version. Not even beta 
Ra
Edit:
The link points to InnoSetup installer of a compiled set of maps. The installer installs it into Garmin MapSource program. There are no *.mp files there.
of course we do not need to make n^2 geo distance measurement
there are many ways to optimize such process
but i advise just use cgpsmapper -e
and correct these errors in the OSM
this problem is already solved in my script - it splits self-intersecting ways
it also filters some node dupes
Hi Liosha,
I had a quick look into your maps and they look very well. You have done a great job.
At first I thought you have lot of luck or very disciplined people working over map of Russia, because you have all the input data correct and I haven’t seen corrections implemented in your code. But I skimmed it quickly through so it is possible that I missed something.
Now I am a bit confused. Are you correcting the data in OSM manually? Do you do this in OSM or MP files?
LOL 
:lol:
I have some corrections implemented in code: duplicate nodes are filtered, self-intersecting roads are splitted.
I was found just 5 bad roads in Moscow area that causes fatal error in cgpsmapper, and i manually corrected them in OSM.
Now cgpsmapper can compile Moscow with -e switch (there are some errors like “too close nodes”, but they are not fatal).
I also made script that daily downloads some areas via osmxapi, converts them into MP and then tries to compile with cgpsmapper_free (w/o routing) and with cgpsmapper_personal.
Results are here: http://garminmapsearch.com/osm/mp/
As you can see, Saint-Petersburg area (piter_*) still can not be compiled with routing.
I have had some useful results with cgpsmapper -e. Trying to create a map of all Ireland still fails for some other reason, but that can probably be fixed.
I am a big fan of correcting bad data in the OSM data. However, this is not always possible (well, let’s say desirable). Take some cases:
-
You have a simple crossroad. But instead of meeting on a single node, the junction includes two nodes about a metre apart. This is a mapper error and should be fixed and cgpsmapper will then be happy
-
You have a small (but not mini) roundabout. cgpsmapper complains that the nodes on adjacent arms of the roundabout are too close together (BTW, I think you’re correct that the distance measurement it uses is inexact, because it has complained about nodes that IMHO are more than 5.4m apart).
The only way in the base data to make cgpsmapper stop complaining is to collapse the whole roundabout onto a single node (or fewer nodes in any case). This is bad for the navigation instructions that will result from this - because the junction will no longer be recognised as a roundabout. It’s also a very bad case of mapping-for-the-renderer, to remove map detail just because a single application can’t deal with it.
Preprocessing does, as you say, provide a solution to this.
- Junction of two dual-carriageways at traffic signals. In the standard case you will have four junction nodes. What if they are too close to each other? Once again, I don’t want to simplify that on the OSM side.
You can use the ‘merge nodes’ function in JOSM, after doing a rectangular selection around these nodes.
Split the roundabout into pieces at the crossings. Having ‘roundabout’ as topological object is a bad idea anyway.
I’m using some quick and dirty awk scripts to extract, download and edit certain OSM topological errors, but maybe we can extend
osm2mp to work as an osm2osm preprocessor. Then it will be possible to re-upload preprocessed data directly to the server.
It opens a big can or worms with concurrency, if two people will try to reprocess the same or overlapping areas simultaneously.
Fortunately, there are not that much people editing OSM late at night
You can’t avoid ‘mapping-for-garmin’ here, so think out some soultion that will be commonly acceptable.
Error R009: Limit of 60 segments for a single road exceed.
osm2mp should deal with it, since it’s a garmin-specific problem.
Distance is below 5.4, NODID1: 9513, NODID2: 8571 RgnID: 14
It does not show up in gpsmapedit, but i will check again.
Internal error during split of RGN80 objects - if this is supported version of program - contact with gps_mapper
I doubt we can do something about cgpsmapper internal bugs without having the source code.
One more reason to finish the NOD research, add it to mkgmap and put this cgpsmapper guy out of the business 
this fatal error is caused while trying to recover this error:
the way has nodes with different ID but with same coords. just redraw that way
I’m doing the full n(n-1)/2 distance qsort() on the original routable nodes table, so it just can’t happen.
edit:
sorry, the bridleways and similar weird ways were removed from the table. maybe it explains
what’s going on here.
Garmin has a specific type for roundabout (0xc, polyline). Can we have all ways tagged as junction=roundabout use this type. Modifying poly.cfg doesn’t seem to work. You might also want to set all roundabouts as oneway=yes if it was not tagged as such.
Thanks for such a great tool
Hi Guys,
I got a program written in python that corrects all the situations that do not fulfil Garmin requirements. But it makes the corrections while reading data. I have never planed to update OSM database itself. This is because I think, that these requirements are Garmin specific and OSM is not. What if there is someone preparing routable maps for X devices and they require roundabouts from one piece and nodes laying no closer that 10 meters? Should he correct the data in OSM? I’m sure not. Correcting data in fly should be no problem.
I quickly (=without lot of work) generated a map of Petersburg with my tool. You can download it here: [link removed]. I made a mistake declaring an area and the city is a bit off centre, but this shouldn’t be an issue. Everything that I have done manually was to declare an area of the map, it’s ID, name and some paths to planet and osm files. The whole process is automatic. I don’t correct any data in OSM. It took about 1,5 hour of computing time, but almost all the time was needed for Osmosis to extract the data from planet file. And obviously I am not yet ready to support cyrillic languages
I checked the map quick on my eTrex and it seems to be routable. Here is the screenshot: 
Admin edit: Link not working anymore
this osm2mp version uses latest tag to determine object type
so if it sees “junction=roundabout” after “highway=” it sets Type=0x0c, or highway type if before
some priority mechanism must be imbplemented to have it always use 0x0c
i’ll think about it
add line
$polydir = 1 if ("$1=$2" eq "junction=roundabout");
before
$polydir = $yesno{$2} if ($1 eq "oneway");
I think that certain changes should be put back into the database (all that are non-garmin specific).
It is much faster (and easier) to use OSMXAPI DB for this purpose.
I think it’s garmin to blame here for not using the utf8 fonts.
That should be easy to solve, if koi8r is the russian charset.
iconv -f utf8 -t koi8r planet-extract.osm >russian.osm
Might not parse in all OSM tools (osmosis) after that but it should convert from utf8 to koi8r.
garmin uses cp1251, but it is not an issue here. St. Petersburg area
borders with Finnland (iso8859-1) and Estonia (iso8859-4), so
it’s a pity to loose all national characters, which do not fit into
one codepage.
I agree. But I received several “Internal Server Error” responses while unsuccessfully trying to fetch London area so I switched to planet file which is a pain, but works. I am converting huge amounts of data (several GB) and I currently temporary have rather poor connection.
yes… I’m thinking when we get more routable maps people will see the real benefit of OSM and that can only boost the number of users contributing to the “map”
good job.
Hi,
i created a wikipage about routable garmin maps. Please add some information: http://wiki.openstreetmap.org/index.php/Routable_garmin_maps
Jonas
Do we know how these maps were created ?
I didn’t find any published source code, so it has zero value for me,
compared to the excellent work of liosha.