[mkgmap-dev] Commit: r868: Implement routing for .osm input files.

Wed Feb 11 15:36:25 GMT 2009

>>>> Using the osm2mp method gives a final file of 119.8MB where the  
>>>> direct
>>>> conversion gives a final file of 103.7MB
>>>
>>> Hmm, did it only include 90% of the roads?
>>
>> I don't know how you'd tell!!
>
> I think others are seeing similar shrinkage and nobody, yet, has  
> reported
> any missing roads.

This is using the splitter.jar, right? What might be happening:

The splitter's output contains a bounding box, and all data within a  
somewhat larger box. If mkgmap reads that .osm-file, it will clip all  
data to the bounding box. osm2mp on the other hand will disregard the  
bounding box and convert all data to .mp. If you then compile the .mp- 
file, you should get that extra safety margin also, which may well  
amount to 10%.

>> Sub-optimal. The best route home for me is to use 2 motorways  
>> (think the
>> 2 shortest sides of a triangle) whereas the Garmin has always tried  
>> to
>> send me along the hypoteneuse. Unfortunately whilst this is shorter  
>> this
>> is an A road which goes through three middle sized towns and  
>> therefore
>> has traffic lights B roads etc all the way along so takes  
>> considerably
>> longer.

You could try putting some special tags on this A-road:  
traffic_lights=many or expected_speed=low (these could be  
autogenerated in a preprocessing step). Then edit the "lines" file to  
give them a lower speed and/or class.

Cheers
Robert