Usage of curve:name and curve:ref

I would like to improve how curve numbers are tagged in my local region, as of now many are indicated as place=square + name=*, which seems sub-optimal to me. Here is the traffic sign that is typically found in such places (tornante=curve in Italian), often also paired with the elevation.

I searched through the wiki and found the tags curve:name and curve:ref, which, associated with curve=*,seem perfect for my use case. The only doubt I have is that they do not seem to have gone through a formal approval process, plus their current usage is very low. So the question is whether you are ok with the two tags and if they can be freely used.

At least in Italy, this same feature is tagged in a lot of different ways. Some of them include place=*, information=board/route_marker and highway=milestone, here an example nominatim search. I would then propose to add curve:name and curve:ref to the “similar tags” category of such pages, so to help in standardizing the usage.


I did not know about named curves, but your plan sounds quite relevant.

Don’t forget to raise the question with your local community though.

Best regards.

You don’t actually have to go through a formal approval process to creae a new tag (see here), but it is generally a good idea to at least discuss them to see if it is likely to cause confusion.

In this case it seems rare enough that I personally don’t think a vote would be terribly useful.

Tagging the traffic sign might also be useful as it would give an additional pre-existing reference (the sign number) that can be searched for in the event that we do end up with multiple conflicting tagging schemes.

I created the curve:name wiki page after surprisingly not finding anything about curves. We had a discussion in the Austrian forum before:

I think this is a good idea in principle. I saw 13 of these hairpin bends between Bozen/Bolzano and Klobenstein/Collalbo. These are mapped there as information=board. But I have comments and concerns about the use of the tagging curve:…=…

This is not an exact translation. Every tornante is a curve, but not every curve is a tornante.
Better translations would be hairpin bend, hairpin curve, hairpin corner or hairpin turn. And a hairpin turn is more than just a curve.

Tagging as curve:* together with hazard* should probably be used to indicate dangerous curves. Yes, all hairpin bends can be dangerous curves, but certainly not every dangerous curve is a hairpin bend.
These hairpin bends also have a tourist aspect: they are particularly interesting for motorcyclists.

To mark the hairpin curve on the highway=*, you often have to split the highway. I find this unnecessary. I think it is sufficient to mark the traffic sign. I only learned today that these are traffic signs. I have never doubted the touris=information with information=board in my case near Bolzano/Bozen.

Correct, but nevertheless if such a tornante = hairpin turn has a name and a number I’d say it should be ok to use curve:name + curve:ref for those because - as you said yourself - a tornante is a certain kind of curve. For clarification the tag curve=hairpin oder curve=loop should be added anyhow.

If the curve has a name and/or number, wouldn’t it be better to add these tags to the curve (as part of the highway) itself or would you add the name/ref tag to the traffic sign as well?

1 Like

I initially thought this might apply to raceways, but apparently not. It certainly could be applied to something like Copse at Silverstone (although straights are also named). Well known turns on downhill ski races also often have names of this kind.

The ascent to Alpe d’Huez has a similar use of information=guidepost which whilst not tagging for the renderer is still suboptimal tagging. So in general there is a clear desire to map this kind of info, but no consensus at present (probably because each case has been mapped from scratch).

I’m curious, do you have any idea why people have tagged them as place=square?

This reminds me: there’s an OSM-based router for motorcyclists that prefers windy roads over straight ones (Kurviger). It could be worth checking the documentation to see if they have anything to say about mapping curves. The usual caveats about mapping for the router apply of course. Also, it may be that they don’t care about this tag and just base it on road geometry.

Here such are mapped as place=locality on a node somewhere in the middle of the curve, one of the highway nodes or even a separate one. Some of those curves are signposted, some not, so only available to locals or people reading construction calls for bids. I consider that mapping fine.

1 Like

I’ve occasionally used curve:name for some well-known named curves on highways. These names aren’t signposted but are familiar to locals. Traffic reporters on the radio are fond of rattling off such nicknames as landmarks instead of referring to a highway at such-and-such milepost. The etymologies for these names can get pretty colorful.

A bend or meander in a river can also be named but unsigned. When I’ve come across a named river bend, I’ve tagged a name on the natural=water water=bend area. (Normally, natural=water water=river areas don’t have name tags.) I suppose it wouldn’t be wrong to split up a small segment along the river to give it a curve:name or bend:name, but the routing use case isn’t as obvious for a river bend.

The Thames has a lot of named parts at least in part because of rowing, this for instance is Cliveden Reach.

In the special case of numbered italian tornante I would prefer to add the number to the traffic sign.

In other cases where there is no specific traffic sign, I would still not split the highway. But I could accept to use a node of the way for curve:ref / curve:name.

I agree, could also be refined with locality=curve or be replaced by place=curve (when tagged on a point or area) or curve_name when tagged on a highway or racetrack

1 Like

I agree, for the Erbsenzähler among us, adding locality=curve to a place=locality that maps a curve will certainly add value to the mapping :slight_smile:

There is some truth to:

Some of the curves are railway here. Does not matter much. Traffic infrastructures are the localities of our times.

I don’t like place=locality in this case. Place=locality is unnecessary unspecific and would be tagging for the renderer. It does not fit the wiki definition as there is an extant feature to which the tag could be associated.

Citing from the wiki:

The place=locality tag is used to name an unpopulated location for which there is no extant feature to which the tag could be associated

Curves are infrastructure features like junctions, bridges or tunnels. We tag their names with other tags than place=locality.

If mapped on a highway (or railway) node or way, does it even need a tag stating “here is a (named/numbered) curve”? I’d say no, curve:name and/or curve:ref are sufficient.


Thanks for the many replies. Thanks @Nielkrokodil for pointing out the original discussion, I tried but couldn’t find it.

I agree that the situation is quite specific, but nonetheless quite common in mountain areas, particularly in roads leading to a mountain pass. In my region there are around ten such streets I can think of, so my intent was exactly to discuss and then document the best approach before causing a spike in the usage of the two new tags.

I think we all agree on the usefulness of the number/name, as it serves a number of street users, including motorcyclists and cyclists. It also acts as a location indicator (e.g. “at the third curve there’s a parking/café/etc.”) and, as someone also mentioned, is often used in traffic bulletins. In this sense I see why place=locality or even place=curve were suggested.
By the way, in my local area the data was incrementally added by an employee of the emergency service, I guess place=square was chosen so to have something visible on the map also at low zoom levels. This is formally wrong but understandable, given that there’s not yet a clear consensus.

As for where to add the information, I see someone prefers putting it on the traffic sign node, while others suggest using a node of the highway or even splitting the highway. I’m not really sure what could be the best solution, maybe both are fine. I think the analogy is similar totraffic_sign=city_limit and place=city which share the same name, anyhow I would make sure that the data can be be useful to users.

As a final note, the first approach is how some curves in my region were re-tagged, while splitting ways would be a little unpractical for roads like this.

I oppose, there is no definite start or end of a curve, in comparison to bridges (Widerlager) or tunnels (Portal).

  1. It is not too difficult to define the start and end point of a curve even if they don’t have an abutment or a portal.
  2. Junctions do not have anything like that as well.
1 Like

The discussion if a curve has a start or end is irrelevant in this case. The curve is a feature of the highway. Without the highway there would be no curve. Therefore place=locality is not the right tag.


The curve is a feature of the terrain. Without the the terrain, there would be no curve. Therefore place=locality is the the right tag.