Talk:Tag:highway=milestone

distance=* instead of pk=*

pk=* is French and not intuitive. I propose to use distance=* instead. See also: http://lists.openstreetmap.org/pipermail/tagging/2013-May/013539.html --Skyper 19:31, 20 June 2013 (UTC)

pk=* was older description in france (every 1km), it's now PR distance=* since years

Kilometre as default unit

We should use the metric system as default. For milestones kilometre seems the right choice. --Skyper 19:31, 20 June 2013 (UTC)

- I think we should use whatever number is printed on the milestone and record it verbatim. If the units of that number is not the default (km), then we should add an explicit unit designation. T99 (talk) 20:53, 24 August 2019 (UTC)

How to specify two distances?

Most of milestones in Russia looks like two-sided metal flag. Each side of these flags have own distance, for two directions. For example milestones placed on Russian road M-5 “Ural” contains distances to Chelyabinsk and to Moscow.

Which of distance should I put to distance=* tag? Which tag should I use for distance of opposite direction?

I also wondered this. I think a schema like distance:zero-point=* would work. F.e. distance:London=15.8 for the distance to London (with localised names, as they appear in the place node name=* tag).

I ran into such milestones on a cycleway (it used to be a railway connecting Roeselare and Ieper, so it's very straight and long). Every crossing had a milestone, with the distance to Roeselare on one side, and the distance to Ieper on the other. --Sanderd17 (talk) 16:27, 21 November 2014 (UTC)

There is some idea on http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Milestones - use "milestone:forward" or "milestone:backward" attributes. But what direction is "forward" or "backward"?--Zlyh (talk) 08:36, 28 October 2015 (UTC)

There is some old discussion about milestone:

Talk:Proposed features/Milestones

http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Milestones

Lithuania has similar signs (probably descending from the same Soviet-era design). The ones I have seen have two “faces” at a 90° angle, each tilted 45° from the road. Each side shows the distance from one end of the road, so the driver will always see ascending numbers.

However, there does seem to be a “primary” direction for each road: Roads are generally referred to by their route, such as “Vilnius–Prienai–Marijampolė“ (always in that order), which is usually also the content of the name=* tag. The national road directorate uses the distance from the first place (Vilnus in that case) for kilometric point references. In situations like these, I would see a point for tagging distances in the same manner (i.e. from Vilnius rather than Marijampolė in the example quoted). --Stanton (talk) 21:25, 10 July 2020 (UTC)

Node on the way or in the mark position?

What position should be the node with the information highway=milestone? --LucFreitas (talk) 15:25, 12 December 2016 (UTC)

Real position. → ViriatoLusitano Portugal (Talk | Contribs) ← 00:05, 13 August 2017 (UTC)

I would say on the highway. Otherwise we won't be able tell which highway it belongs to when we have 2 or more nearby highways. By using it as a separate node it will suffer the same problems from Key:traffic_sign#As_a_separate_node --naoliv (talk) 21:14, 24 October 2017 (UTC)

Isn't this corrected by having a ref tag on the milestone with the highway ref it belongs to? → ViriatoLusitano Portugal (Talk | Contribs) ← 21:23, 24 October 2017 (UTC)

And if the highway doesn't have a ref? :-) But "ref" in milestones has another meaning: "is optional, only to be used if the milestone actually has a reference number written on it." --naoliv (talk) 21:27, 24 October 2017 (UTC)

Real position +1. And about the relation between milestone and highway...Why not using a new relation type? BTW, this page is changed to "The node should be part of the way that represents the highway." https://wiki.openstreetmap.org/w/index.php?title=Tag%3Ahighway%3Dmilestone&type=revision&diff=1493715&oldid=1437923 --Yellowsoar (talk) 09:52, 21 March 2018 (UTC)

On the highway, because the sign has a property of a road. It is useless otherwise. The same as for traffic_sign=city_limit and highway=give_way. --Zverik (talk) 18:32, 29 March 2018 (UTC)

Milestones mark a position on a road, as a distance from a reference point. Distance is usually measured along the center line of the road, which coincides with the way for a single-carriageway road. I would assume the majority of use cases to be about translating locations such as “km 36 on road A43” (frequently used by road administrations) into a coordinate pair, whereas few would care about where the physical milestone is located. Taken together, that would mean placing the node on the way for a single-carriageway road, and between the carriageways for a road with two separate carriageways. --Stanton (talk) 13:57, 30 June 2019 (UTC)

I changed the text of the article to allow either option, similar to traffic signs. I suppose in practice the difficulty of matching separate signs to the corresponding highway depends on the information tagged both on the sign and on the highway (e.g. if both have the same ref=* and carriageway_ref=*, they are easy to match). In general I expect the physical location is less annoying to OSM editors who just want to edit a highway and don't care about the milestones. There are also going to be edge cases where a single milestone sign applies to multiple OSM ways, and where a single OSM way has multiple milestone signs with different information. --JeroenvanderGun (talk) 22:11, 27 September 2021 (UTC)

IMHO, the marker should be at its *actual* location (left side or right) - 1) where the traffic department sign person would go to find it, maintain it, replace it if it was destroyed 2) where it actually appears on aerial images and 3) where you would look for it on street-level image (Mapillary example: US36 bikeway MM 6-1/4 between Louisville and Broomfield on a hill above concrete ditch). Don't screw with the integrity/actual location of physical objects! As someone else suggested, there should be a means of associating marker with the way/centerline. DougGrinbergs (talk) 05:53, 29 May 2021 (UTC)

Could this be solved adding the marker in its real position to the road relation with a specific role? --AntMadeira (talk) 22:13, 15 June 2023 (UTC)

Use of ref=*

The wiki page currently states:

ref=* is optional, only to be used if the milestone actually has a reference number written on it.

Recently, I had a discussion with someone who maintained that this tag should be the reference number of the milestone, not of the road.

I currently have the following use case: I get location indications such as “km 36 on road A43” (a notation frequently used by road administrations) and need to translate them into a coordinate pair. (I can handle cases in which results are a few meters off the road, and am also prepared to deal with ambiguous kilometric points.) For this I need to match milestones to their roads, which is very easy to do when there is a tag indicating the road reference number—whether that is ref=* or something else, as long as it is uniform. Without such a tag, matching becomes quite complex. It is still doable if the milestone tags are on the way, but for roads with separate carriageways common practice seems to be to place milestone nodes in the middle, between the two ways.

Also, I am not sure how frequent reference numbers for milestones are (apart from the reference number of the road being indicated on the milestone)—in which case the ref=* tag would hold something other than the road reference number. In the case of Poland, however, mileages are usually indicated on delineators with no road reference number, yet over 90% of the 35,000+ milestones in Poland have the ref=* tag set (87 milestones do not; of those that have, 97 are my own edits).

If we are talking about the road reference number, I wonder if it is that important to know that milestone 1 has the road’s reference number written on it while milestone 2 doesn’t.

I would therefore gravitate towards one of the following two alternatives:

• Use ref=* to indicate the road to which the distance refers, regardless of whether or not is is indicated on the milestone itself. This seems to be widely used already, even if it slightly deviates from the definition of ref=*.
• Introduce a new tag, say road_ref=*, to indicate the road to which the distance refers, regardless of whether or not is is indicated on the milestone itself. This does not clash with any usage I am aware of, but is not currently being used anywhere. (According to taginfo, road_ref=* is currently used 1,295 times, 99% of those cases are for TMC data.)

Opinions? --Stanton (talk) 15:22, 30 June 2019 (UTC)

@Stanton: For comparison, in the United States, reference location signs only indicate the mileage, while enhanced reference location signs indicate the route number and direction too. If any such sign bears a sign inventory number, it would be in minuscule print in the corner or on the back of the sign, intentionally hidden from view. That said, it is confusing that ref=* identifies something other than the feature it's tagged on. (Maybe it would be less confusing if a milestone were added to a route relation in the same manner as a highway=* way?) route_ref=* is currently being used for a similar purpose in public transportation tagging; I think it would be more accurate to use that key, rather than road_ref=*. – Minh Nguyễn ^💬 09:03, 31 July 2021 (UTC)

I would suggest using unsigned_ref=*. These tags are already in use to indicate unsigned road numbers on the road ways themselves. --JeroenvanderGun (talk) 21:55, 27 September 2021 (UTC)

I would completely support the second option, to keep ref=* with the feature's ref. According to this proposal, it would be possible to describe the referenced feature's ref (here a road) with something like subject:ref=* (or whatever proposed in this fashion). Fanfouer (talk) 19:49, 9 August 2023 (UTC)

Yardage markers

I'm using this tag for distance markers on golf courses unless a more suitable tag can be identified. For example: highway=milestone + distance=150 yd (pictured). T99 (talk) 21:21, 24 August 2019 (UTC)

How about golf:course=yardage_marker or golf:course=distance_marker? Using anything highway=* looks plain wrong to me, as it implies a road-related feature, which is clearly not the case here. Introducing a new tag is a lot less headache-prone. --Stanton (talk) 19:44, 13 June 2020 (UTC)

Miles? Stones? Time for aliasing a new name

The average editor would think of adding a material=metal tag.

So I think this should be called distance marker etc. Anyway, please divorce

• Stones
• Miles

from its name, to make it more modern/neutral.

Or maybe make it a valid alias for a more modern name. Jidanni (talk) 06:24, 2 October 2019 (UTC)

https://en.wikipedia.org/wiki/Milestone --Zverik (talk) 06:43, 2 October 2019 (UTC)

https://en.wikipedia.org/wiki/Highway_location_marker Jidanni (talk) 08:26, 2 October 2019 (UTC)

The obvious conclusion would then be highway=location_marker. --Stanton (talk) 19:46, 13 June 2020 (UTC)

To go on this point, it should be said that actual stones can be described with marker=stone. We currently think about describing the subject of any marker in this proposal. We could free highway=* from markers by using the more theoretical subject=road (or whatever suitable in this fashion). Fanfouer (talk) 19:46, 9 August 2023 (UTC)

Disambiguations for duplicate distances?

Numbering of kilometric points is not always continuous. Such anomalies can happen where roads are rerouted, or stretches of a new road are built before the entire route has been planned in detail. This can result in duplicate kilometric points, e.g. when the new stretch of road is longer than the one it replaces.

The image shows one such example from the B 178 in Austria, a section of which was rerouted. The rerouted section ends at km 5.326, which corresponds to the existing 4.6 km point. The duplicate points are prepended with a letter, so the sequene now becomes: … – 4,6 – 4,8 – 5,0 – 5,2 – 5,326 / D 4,6 – D 4,8 – D 5,0 – D 5,2 – 5,4 - …

In Poland, when a national road is upgraded to an expressway, it usually inherits the old kilometric points. However, the first sections built are typically bypass roads around towns where the old national road cut through the middle of the town. Kilometric points on these sections tend to be numbered from 0 on. When referring to these kilometric points, an extra letter is appended to the road number. For example, when referring to a kilometric point on the S8 between Zambrów and Jeżewo, this is usually given as “S8n, km 12”.

Is there a standard tagging scheme for these kind of disambiguation identifiers? --Stanton (talk) 18:27, 7 June 2020 (UTC)

For Poland, I have now started tagging these sections with ref=S8;S8n, after seeing that some markers already use the extra letter in the road ref. Therefore, the road ref with the extra letter seems correct to me (especially as some delineators report it, while others do not). I would also leave the road ref without the extra letter, as that is the reference for the road as a whole, and it is easier to parse two refs than to guess a missing one. --Stanton (talk) 19:36, 13 June 2020 (UTC)

Rendering important for emergency reporting and rescue

See https://github.com/gravitystorm/openstreetmap-carto/issues/2577 for the importance of rendering milestones. Jidanni (talk) 15:31, 9 September 2020 (UTC)

Maybe start with the Humanitarian map style? --JeroenvanderGun (talk) 22:19, 27 September 2021 (UTC)

U.S. milemarkers/default miles

how about 1) units for United States are miles by default 2) perhaps silently converted, stored in non-U.S. but OSM-centric metric units? 3) appear when you type "milemarker" in object/attribute search (milestone totally not intuitive here) DougGrinbergs (talk) 05:59, 29 May 2021 (UTC)

California postmiles

distance=R144.44 mi?

A few U.S. states, most notably California, post coded distances called "postmiles" that contain information about how the distance was measured. These is an official distance, not a reference number for the marker itself. In an attempt to make the distance machine-readable, this article specifies that the distance must be a number followed by a unit. But this would make it incompatible with California postmiles. Should we put the postmile prefix in distance=* anyways, to avoid dataloss, or find some novel scheme to represent the various things that these prefixes mean? The distance may include not only a prefix but also an equation. [1][2] – Minh Nguyễn ^💬 20:20, 23 August 2021 (UTC)

They better be separated. The reference or measurement isn't a unit. Including it would impair processing this data. Allow me to give an example in ele=*: It's common to indicate the datum in the quantity (eg Japan has the Tokyo Peil standard written as TP+5m, TP5m, or 5mTP, etc), translating to OSM as ele:*=*. You could use inscription=* for the original, even possibly something like distance:inscription=* if it's too long and complicated. ---- Kovposch (talk) 00:10, 24 August 2021 (UTC)

@Kovposch: A postmile formula would be even more desirable to parse than the formats otherwise used in distance=*, so it would be best to keep the entire reference together, even if it means omitting distance=* or setting it to something lossy alongside a more accurate key. I don't think it should be generalized as far as distance:inscription=*, because this is a systematic syntax, not a freeform inscription. I think for now MUTCD/California/G can recommend distance:postmile=* unless something better comes up. – Minh Nguyễn ^💬 07:25, 24 August 2021 (UTC)

That's a filler solution. Ok, how about distance:US-CA=* for this state format? *:postmile=* isn't obvious what it is. ---- Kovposch (talk) 09:56, 24 August 2021 (UTC)

I don't know if the format used by Caltrans is specific to California, or specific to Caltrans within California, or common among multiple states. I think the format originated from railway postmiles. It raises the question of whether any data consumer sophisticated enough to parse postmiles ought to parse it differently depending on the region, similar to some other navigation-related keys, rather than relying on the key to name the format. (After all, a given road wouldn't have multiple conflicting postmile systems associated with it.) – Minh Nguyễn ^💬 02:35, 25 August 2021 (UTC)

@Kovposch: Apparently it's quite common for railway:position=* to contain postmile equations, which makes sense, since postmile equations originally came from railroad engineering. That key led me to highway:position=*, which is undocumented but in use. I think it would be elegant to use it for California postmiles, though the mi: value prefix rankles me somewhat for being the opposite of the standard unit syntax. – Minh Nguyễn ^💬 01:30, 24 June 2022 (UTC)

35.0 mi

Maybe change 35.0 mi to mi:35.0, to give newer advice. Jidanni (talk) 11:24, 6 December 2022 (UTC)

Which point are your referring to please? Fanfouer (talk) 13:23, 6 December 2022 (UTC)

Mention about adding to relation

Mention that the milestones should be added to the relation of the highway, railway line, trail, etc. involved.

Or mention why not. Also mention that they should be ordered by sorting on their distance field.

Also mention this on the highway, railway, etc sub pages. Jidanni (talk) 11:28, 6 December 2022 (UTC)

I was thinking about doing this but I didn't find documentation about it. Do you know if there's already any discussion about adding road markers to the road relation with its specific role? --AntMadeira (talk) 22:15, 15 June 2023 (UTC)

I found today that the milestone is referred as a member of the route relation: Link So I think this should be added to this wiki. --AntMadeira (talk) 00:26, 13 August 2023 (UTC)