[mkgmap-dev] [PATCH v1] grok unpavedness

Wed Dec 9 12:58:39 GMT 2009

Quoting Steve Hosgood <steve at tallyho.bc.nu>:

> Felix Hartmann wrote:
>>>
>>> I do agree though that OSM's tagging for road surfaces is a bit of  
>>>  a mess, but it needs an OSM-level cleanup if that's a problem,  
>>> not  at mkgmap-level.
>>>
>>> AFAIK there are "surface=???" "smoothness=???" "mtb:scale=???"   
>>> "sac_scale=???" "rtc_rate=???" tags in OSM, all of which   
>>> (sometimes in combinations) ought to be enough to give mkgmap the   
>>> clues needed to set the routeability of a given way. Plus   
>>> "access=???" and "<vehicle>=no" of course.
>>>
>>> Not just that, but those tags already exist. We should be using them.
>>> Steve
>>>
>> You don't seem to understand.
>
> No - I understand fine, thanks.
> I just disagree with the idea that this proposed new tag should be
> mkgmap-specific.
>> You can use them and the default style should use some of them.   
>> However there is no clear borderline of what is paved and what is   
>> unpaved, therefore it is best to use a new key.
>
> Well, a new key is one option, getting the entire OSM community to tidy
> up a bit on the use of existing keys is another option.
>
> IMHO, if use of the existing keys isn't feasable, then any new key
> should be more like "autorouter=avoid" or something. This is not
> mkgmap-specific, it would apply to all the other projects looking to
> use OSM data for in-car GPS navigators, and the browser-driven computer
> navigators too.
>
> But before adding a new key, we should be able to "prove" that no
> combination of the existing keys does it for us.
>
> Steve
I think you're talking at crossed porpoises.  The suggestion is that a  
mkgmap internal key is developed that takes existing OSM keys and  
simplifies them down to a specific tag in the style file rules that  
can in turn be used to help with routing.  No new keys are being  
introduced to OSM, nothing is being duplicated and nothing is being  
done that harms the efforts of other map projects (TomTom etc).  The  
new key only "exists" in mkgmap style file rules, and then only  
virtually during the compilation process whilst OSM tags are used to  
generate Garmin routable (or non-routable) objects.

Your suggestion of "autorouter=avoid" doesn't help because this key  
would never make it into the wider world of OSM data. And therefore  
won't be of use to any other projects.

Hope that helps.

-- 
Charlie