Hi again, let me just start with an apology: I have about half an hour each day to test mkgmap. The other time I don't even have access to that (and any other) windows machine. So anything said here is from memory, with no possibiliy to go back and copy & paste some log data or try again. But I hope somebody still finds some feedback usefull. It's not meant as an request for fixing, but just as another usage report. So what I did was: - Downloaded .osm.bz files from geofabrik for thuringia(GER), bavaria (GER) and austria. - unpacked each file and processed each with splitter (I used the - mapid= switch to produce files with consecutive names) - thuringia produced 1 tile, bavaria 4 tiles and austria 6 - used mkgmap(r975) to produce a map of all tiles (options included -- route, --gmapsupp, --net, --road-name-pois) - used mapsettool to bring it in mapsource, uploaded to erex legend hcx What I observed: Output of mkgmap run: - Some bad turning restrictions - Some areas containing to much points (for some autogeneration of names I think) (this is really bad quality of information for a bug report, isn't it?) Routing in Mapsource: A route from erfurt (thuringia) to bad reichenhall (southern bavaria) fails. Inserting more and more waypoints in between results in narrowing the not-routable part down to the border between thuringia and bavaria. POI search on etrex: While "Bad Reichenhall" is findable in mapsource, it isn't on the etrex. Neither under 'citys' nor under 'all'. Same for some street names there. I think the routing problem originates in the overlapping or otherwise missaligning tile borders between the tiles generated from different .osm files. Is the intended workflow really: download the whole of europe, use splitter and mkgmap, use mapsource to identify interesting tiles, throw away the other ones and run mkgmap again? Or is there a way of telling splitter to take care of that? Does splitter allow more than one input file at once? regards Stefan