Opened 4 years ago

Last modified 4 years ago

#1122 new enhancement/feature request

add explanation of the possible item types navit can use and their osm tag relation to the wiki

Reported by: ah be Owned by: KaZeR
Priority: minor Milestone: version 0.5.1
Component: core Version: git master
Severity: Keywords: maptool, binfile, osm


this is an enhancement request for the wiki:

please add an entry on what osm tags are used and what their names are in the xml file:


eg to what osm tag does street_nopass correspond to?



Change History (8)

comment:1 Changed 4 years ago by usul

As Navit supports multiple map data backends, there is the maptool that converts OSM files into so called binfiles, that can be read by navit. AFAIK this the mapping between OSM and bifile is defined in itemdef.h and is already at the wiki: But do be honest, I don't if it's outdated. You are welcome to help us to keep the things in sync: source:/trunk/navit/navit/item_def.h

Find more infos here:

Please give me a ping, if that answers your questions.

comment:2 Changed 4 years ago by ah be


thanks for the quick reply. the wiki link already looks quite promising. Now what I figured out from that that only highway = track may have different surface types (paved, gravelled, ...). and the the osm tag surface is apparently not implemented. the problem here is that some streets (not tracks) have cobblestone as surface, which makes bike riding hell(!). I have looked into item_def.h (svn) but I haven't quite understood the connection between the wiki page yet. would is item_def.h be the right place to add the surface tag? I also looked into item.h but haven't quite understood what it is doing exactly.

comment:3 Changed 4 years ago by tryagain


Regarding your question on navit<->osm type correspondence, I would recommend looking up to the code near the line 386 of navit/maptool/osm.c, where the attrmap is defined.

The idea is as following: first char is navit item kind (node/way/both), next non-space sequence is pattern used to match to actual osm item attribute set, next word is navit item type as it's referenced in navit.xml. If there are multiple matches found, shorter ones are skipped in favour of the longer ones. If there are a few matches of the same length, multiple navit items will be produced from the same osm item. To count pattern length, it is split into subpatterns on commas, then length of each subpattern is summed together. Length of *=* match is counted as 1, length of something=* or *=anything is 2, length of something=anything is 3.

Regarding street_nopass, it's not produced from osm data at all. This item type can only be returned by the mg map driver.

To make a road inaccessible with bike, you may try to put bicycle=no tag in osm, maptool in turn should set bike access flag to false at line 1048 of navit/maptool/osm.c.


Last edited 4 years ago by tryagain (previous) (diff)

comment:4 Changed 4 years ago by ah be

so would it actually be that easy to add something like:

"w surface=paved surf_paved\n" "w surface=asphalt surf_asphalt\n" "w surface=cobblestone surf_cobblestone\n"

to have the possibility to include them in the xml via item_types="surf_paved" ?

comment:5 Changed 4 years ago by ah be

@tryagain. the things you mention are all in maptool; now if I download a .bin file via the navit planet extractor will this be automatically be run through maptool to have the new tags available so the bin file would have the tags included?

comment:6 Changed 4 years ago by tryagain


to add your example lines you need definition of surf_paved, surf_asphalt, surf_cobblestone in item_def.h. As these items are supposed to be routable, you also have to define their default flags in item.c

Furthermore, your suggested rules are going to produce some duplicate ways together with existing rules like "w highway=secondary street_3_land\n", so you'll get two ways on the top of each other, and routing will be broken. For example, suppose you have osm way tagged with highway=secondary and surface=cobblestone. Then navit will route your bike through street_3_land, regardless there's surf_cobblestone generated for the same way.

And no, you can't just download .bin file and expect that your own maptool will do some work for you. Maptool cant reprocess binfile, it expects osm plain data as input in .osm, .pbf or .o5m format. So you should get your own [partial] copy of osm data and process it with your own maptool.

If you still want to make your personal map from osm data, I think I can suggest a solution.

Change osm.c by adding something like

  if (! strcmp(k,"surface")) {
    if (!strcmp(v,"cobblestone")) {
      flags[0] |= AF_RESERVED1;

to osm_add_tag function of osm.c, to mark ways inaccessible by your bike, with AF_RESERVED1 flag (which has value of 0x80).

Compile your maptool, build the map. It should be working without any differences.

Then change your bike vehicleprofile start tag from default

<vehicleprofile name="bike" route_depth="18:25%,18:40000" flags=
"0x40000000" flags_forward_mask="0x40000000" flags_reverse_mask="0x40000000" max
speed_handling="1" route_mode="0" static_speed="5" static_distance="25">


<vehicleprofile name="bike" route_depth="18:25%,18:40000" flags=
"0x40000000" flags_forward_mask="0x40000080" flags_reverse_mask="0x40000080" max
speed_handling="1" route_mode="0" static_speed="5" static_distance="25">

Thus you'll make AF_RESERVED1 roads inaccessible by your own bike profile.

I think, it would be better if we could not simply adjust road availability with surface-dependent flag, but better be able to tune estimated speed in dependence of road surface, slope, or some other attributes. So you'll have an option to run 100m by cobblestones when the only alternative is asphalt road having 10km detour. But this would require a bit of routing code change.


comment:7 Changed 4 years ago by usul

  • Keywords maptool binfile osm added
  • Milestone set to version 0.5.1

I created an script that analyses at least which OSM tags are used by maptool and styles map rendering. Maybe I can extend it, to create a bot that updates the wikipage:

Will this be a solution to this ticket?

comment:8 Changed 4 years ago by ah be

that solves the issue.

thanks a lot. the other part regarding two parameters which may be used in combination to calculate time needed for a segment should maybe be part of a new ticket with the appropriate name.

would you mind posting your script?



Note: See TracTickets for help on using tickets.