Israel Hiking map

As there are some hiking routes being added to the map recently, I thought it would be great to have them rendered on Lovnia’s Hiking map. The only thing we have now is INT rendered as local route (!!) We would have all the ITC routes rendered with their color, as well as have special rendering for the long trails (right now the INT is rendered as blue strip on white background).

All we need to have is a description of our tagging scheme in the wiki and a general description of how we want the rendered trails to look like. This will also be good for us as the wiki is somewhat outdated and incomplete, lots of info is in the forum (and in talkat’s head).
When I have time, I will set up such a page. In the meanwhile, please add to this thread any standards/conventions you’ve been using (apart from what is specified here, I didn’t find any additional guidelines).


Hey! You ruined my surprise!!! :slight_smile:

User DoK and me have been working in the last few days on standardizing this.
Lonvia’s Hiking Map isn’t the only one. There’s also which have a nice rendering, and also capable of showing Lonvia’s layer, as well as hill shading. This is pretty impressive.

Now, as for Israel…
Actually, this is general info, so anyone can chime in.

There are 2 things that needs to be done in order to have a route rendered on these maps:

  1. Use the way in a relation.


  1. Add the osmc:symbol tag in the relation.

The relation should be of type=route, and preferably route=hiking as well.
Then one could add tags like network=itc, and ref=TheRefNumber, name=NameOfRoute, name:en=NameOfRouteInEnglish, etc.

And also the osmc:symbol tag, which tells the renderer how to render the shield.

I’d like to elaborate a little to what’s in the wiki, as the wiki is pretty bare boned.
The osmc:symbol tag has values for colors and how the shield should look like.

I’ll do that by an example:

A route marked in red (i.e. white-red-white) should have the value of:

black = color of the way, Ignored by both Lonvia’s map and hikebikemap.
white = background of the shield
red_bar = foreground of the shield.

This will render the route’s shield as white, with a red bar (stripe) in the middle of it.

There is an open question what should the 1st color be.
There are 2 options:

  1. The color of the shield’s bar, so the above example would be: osmc:symbol=red:white:red_bar
    But I don’t like it for several reasons:
    1.1) Sometimes the same way is used in 2 routes, so which color should be rendered?
    1.2) A colored way looks different than the non-colored ways, and that might lead to ambiguous understanding (is it a path or a track?)
    1.3) If a renderer really wants, they could take the foreground color and use that to color the route.

  2. Preferably, the way should be rendered the same way as non-colored ways, and only shields sho on the map.
    This is the standard in online topographic maps, like Mapa.
    However, the 1st color isn’t optional, so black is a good default value (the same as hikebikemap), so the above example would be: osmc:symbol=black:white:red_bar

I prefer option 2: osmc:symbol=black:white:red_bar

Lonvia’s and lag about a day after the OSM DB, which means updates should take roughly 2 days to show on the map.

Let the questions begin… :wink:



  1. The several osmc:symbol tags I’ve browsed through seem to me wrong. In particular, a bar is a horizontal line while (AFAIK) the trails on the ground are marked with vertical bars facing the direction of the trail. This corresponds to “strips” - see here. So, perhaps it should be something like this (for, say, a regular trail colored red):


For the INT, it should be IMHO:

Can we somehow test the rendering in advance?

  1. Different parts of some long trails (again, AFAIK), for instance the Emek Ha’Ma’ayanot trail are marked differently depending on whether it is a part of an existing trail or a new section. In the former case, a small circle is added at the top, while in the latter an entirely new color is introduced. Should we in this case attach the corresponding osmc:symbol tag to the corresponding way rather than to the whole relation?

  2. Are the “color=*” tags being removed?? This is contrary to existing guidelines… I think we should have them, as it provides a “shortcut” human-readable description.

  3. The INT is right now tagged “network=nwn” instead of the usual “network=itc” (last time I checked).

We should converge to some standard as soon as possible.


What if a route goes east-west?..
Examining the world’s usage, *_bar is the most common. By far.
I say we stick with that.

My guess is black:white:blue_bar:orange_drop_line
You see, there’s no *_stripe_right, nor *_stripe_left
But there is a *_drop_line.
This is another indication why *_bar should be used.

AFAIK, there’s no way to test the rendering in advance.

Each small section that is atomic, should have its own relation(s).
There is no limit to the number of relations a way can belong to.

They were removed. There’s no need for duplicate data,
and the osmc:symbol tag is pretty readable, and give more information than just the color.
Also, a way can have only one color tag. What if the same way is used by different routes with different colors? What about different shields? Small routes are denoted with a dot (or a circle) and the color tag doesn’t cover that.

Check again… :wink:

Seriously now,
OSM specifies that the network tag can be e.g.
nwn / rwn / lwn
which stands for: NationalWalkingNetwork, RegionalWalkingNetwork, LocalWalkingNetwork.
Israel is a small locality compared to large countries (which are divided to smaller states)
And Israel has only one trail network, the ITC, so I say we have network=itc.
If we really want to abide the OSM standard, then it should be network=nwn, but I don’t believe it’s necessary.

Checking osm tag usage, the nwn/rwn/lwn isn’t so widely used,
but other values (similar to Israel’s ITC) are more widely used.


Hi guys,

talkat pointed me to this discussion, I don’t normally follow the forum…

Actually, no, there is a misunderstanding about what the first part of that value means. It’s not really “way color”, but “highlighting” like used further down on
The way itself is always colored in the color that is defined for the highway tag it has set (track, path, residential, cycleway, …). The highlighting should be the “main” color of the symbol and is drawn above the way between the shields (on only, not on When a way is in multiple relations with different such highlighting values, they are interleaved as in e.g.

So osmc:symbol=red:white:red_bar is quite fine (and also the only way I can render it on right now).

Glad you are finding the hikebikemap useful :slight_smile:


That’s actually because in former East Germany, those signs were used extensively (in Czech too AFAIK):
And they really are bars, i.e. horizontal, the route direction doesn’t matter when displaying them on a map.

I think you cannot correctly draw the Israel National Trail symbol with the currently pre-defined elements on - however Nop has extended that list continually, so it’s surely worth suggesting _stripe_left and _stripe_right to him.


Just to be sure, a isn’t a “drop_line” a symbol of a water drop with a hollow interior and a contour of specified color? I fail to see how this is related to the symbols on the ground.

What would be the meaning of the relation in this case? The “merged marking” is a physical property of the way, while every relation can have its own “default” marking regardless, and the renderer should use the marking from the way if it’s available.

I think that systematically removing data should be done by a consensus. I produce for myslef maps with the Maperitive offline renderer, and I would like to have the routes simply colored, without shields. Till now, I did this by matching “color=" property. Now it’s broken. Not a big deal, but still… Who knows, maybe someone else was using this as well.
Regardless, it’s better IMHO to have "color=
”, at least until we have some stable convention and we see that rendering is good.

Sorry, I meant


Based on Colin’s inputs above, I guess we need to think a little…

Here’s the thing. supports the standard only partially, with some limitations.
This is the best that we have now.

Should we “tag to the renderer”, or tag according to the standard, hoping that in the future it would be supported?

“tagging to the renderer” is considered a no-no, but I really don’t know, and am hoping for some collective wisdom.

I’ve gone over all the ways that have either “color” or “colour” tag (there should really be only one…), and there were around a hundred (about half of each)
Now that there are only relations, the number is lower, so one mapper can go over all of them in less than a day (I guess I did it before, I can do it again…)


I say tag to the renderer, writing a conversion script in the future shouldn’t be too difficult. But, I would also like to keep “colour=*”, and this will not depend on the renderer (after all, the majority of the trails are commonly referred to just by their color.)

Let’s try to look at the problem from another point of view. There are several types of ITC trails:

  1. INT
  2. Regional trails (Shvil Ezori)
  3. Long trails: Jesus, Golan, Emek Ha’Ma’ayanot
  4. Regular single-colored
  5. Urban (I haven’t actually seen these, but the ITC maps say they exist)

How would we like to see all of these on a map? IMHO, apart from the symbol (shield) specific to each route, these categories should be differentiated by a specific tag (then the renderer can assign to them different line styles , and maybe min-zoom setting).

One option: network=nwn/rwn/lwn. To keep the ITC designation, we can have “operator=itc”, like they did in Slovakia.

Another option: keep network=itc, and add itc:type=national/regional/long/standard/urban or something of this kind.

Ok, fair enough. I’ll try to go over all the relations today. Will post about my progress here.

As for the colour tag, we could use the standard of roads having several refs (or bus_stop with several lines etc.) and have something like colour=blue;red for ways like this bridge.

I vote for the 2nd option:
network=itc, itc:type=national/regional/long/standard/urban


As of this morning, there were 55 relations with the osmc:symbol tag.
I changed them all to have the way color be the same as the foreground color.

I also added colour=* tag to ways where applicable.
That means that we now have a standard colour tag on ways (and not as before where about half of the ways had the colour tag, and the other half had the color tag…)

Hopefully, tomorrow’s Lovia’s map will have all the changes.
It’s already updates to last night, and some of the routes show there nicely. :slight_smile:
e.g. in the Carmel. isn’t yet updated, hopefully it will update during the day, but all the changes should be there by tomorrow mid day.
Edit: is now updated. Here is an example. :slight_smile:


This is exciting some exciting stuff!
So are these our conventions now?
Talkat - Can you give provide a way ID that I can take an example and start marking some roads?

I guess…
Until dimka (or anyone else…) comes up with a better suggestion.

This is an example of a relation.
Notice it has the following tags:
network = itc
osmc:symbol = blue:white:blue_bar
ref = 10362
route = hiking
type = route

Meaning: The route is blue (1st parameter in osmc:symbol) and the shield is a blue bar on a white background.

And this is one of the ways which belong to the above relation.
Notice it has the colour tag which matches the color of the route.


It looks cool!

We also decided to add the itc:type=national/regional/long/standard/urban tag to the relation.

On second thought, since most of them are itc:type=standard, we can tag only the ones which are different, at first stage. Later we would have automatic scripts to check these conventions.


Not all are hiking routes (some are mtb, horse, etc.)
and not all are by the ITC.
For example, some are by KKL, or even the Nes Ziona Municipality.

So maybe have network=itc/kkl/… network:type=national/regional/long/standard/urban ?


I proposed “national/regional/long/standard/urban” in order to correspond to ITC definitions at the back of their maps, probably KKL has a different scheme (I guess we’ll find out soon :wink: So it would be then network=kkl and kkl:type=…/…/…

For some routes I guess we don’t have a clear network=* designation yet (such as Ness-Ziona scenic route).



Maybe in this case we could default to network=lwn? Which in this particular case is actually network=lcn.


In theory, it can be as quick as being only 5 minutes behind, but the server is quite loaded at the moment and so takes a while. I hope it will return to a better speed at some point.


I have summarized our conventions in the wiki, please feel free to comment/update.

Note that cycling routes are not covered yet.