Milestones are public domain but not in OpenStreetMap

Just wondering, is there a layer that shows the milestones?

Can anybody explain why we even would like to have these markers at an accuracy of 25 cm, when even possible? Emergency services do not need that at all.

Do not only ask yourself the question what is possible, but think about the added value. Hectometermarkers is imho too farfetched.

We have talks with the emergency people of different safety regions (Veiligheidsregio’s) about using OSM for emergency handling. We have asked them what is important. None of them have mentioned milestones.

The Roadside Assistance (Wegenwacht, “triple A”, Pannenhilfe) might have use for it, but if that is the case, they should at the same time build it into their applications and organize the maintenance and quality assurance of the data. My guess is they already use an application of their own, showing a layer with “official” data on top of a background map which might even be OSM. Probably only whole kilometers, not hectometers.
Callers don’t need them because they are on the road and can see them live.

I think this use case is very weak. That said, there are a lot of those in OSM: no use case, but it’s a visible thing, so it can be mapped. If anyone thinks it’s important* and makes work of it, fine, map it, import it with the usual doc / prep / check, maintain it. Provided that the geolocation data is accurate enough, so we don’t get milestones all over the roadway. If that happens (not incidental but structural), I say revert and clean up the data before retry.

  • I micromap underground waste containers. No use case at all, I just do it. My quirk.

I’ve been accused that removing a non-used road (i.e. tags connected by a line) would cause too much server load: https://forum.openstreetmap.org/viewtopic.php?pid=834541#p834541
Please never use this excuse again, if someone decides that importing milestones would be a great idea.

In the german Bundesland Thüringen mappers did the effort and mapped all milestones with Mapillary (Overpass for all Milestones in Thüringen, Example for one milestone).

Hi dktue, I don’t get it, it looks like the Dutch community has any appetite to take the task you’re carrying and advertising.
Even adding the use of Mapillary is not a well thought option since there are less and less users over here, even the hardest fans of the system are leaving it behind. Since the buy out of idealism has brought another captain to serve Mapillary.

Let’s say, while there are no principle objections, there is no enthousiasm either.

https://www.pdok.nl/geo-services/-/article/nationaal-wegen-bestand-nwb-#bf11140565845b93050fa872fdcb2e3b

Bedoel je deze wms?

https://geodata.nationaalgeoregister.nl/nwbwegen/wms?request=GetCapabilities

Voor wat het waard is: deze materie was ook in Vlaanderen aan de orde. Op de BE-mailing list las ik volgende, blijkbaar afkomstig van de bevoegde Vlaamse overheid “Agentschap Wegen en Verkeer”:

I am enthusiastic. The coordinate information from the milestone signs has a variety of applications (also non-safety-critical). For ordinary road users, the most popular use-case is locating mobile speed limit enforcement. More generally, this information is a useful anchor for data fusion with other data sources, and locating incident reports on the map. Within OSM, it also allows internal verification of ref and carriageway_ref tags on ways.

I would prefer to avoid gluing the milestones to the ways, and instead put the milestone nodes at the actual location of the milestone. This practice is also accepted for traffic signs, and is less annoying if you simply want to edit the ways without editing milestones.

I think it would be most convenient if there is some sort of BAG-like synchronisation process, so that after the initial import, we can re-import a particular road segment upon request, e.g. after major infrastructure changes.

(Short: we don’t use that anymore for practical reasons.)
We can regret such developments but telephone boxes have also disappeared because no one uses them anymore (well, they were disabled).

MOD EDIT: politiek geladen opmerkingen verwijderd

Onze zuiderburen hebben of hadden hetzelfde probleem (betrouwbaarheid) als gemeld in # 4.
Jeroen, ik verwacht dat de geschilderde km markeringen die als los staande platforms, de werkelijk juridische onderliggende waarde vertegenwoordigen, vooral zichtbaar voor helicopter bemanningen. Die kunnen als markering dienen en zijn ook standvastig en staan verder van de weg.
Commodoortje, kijkend naar de WMS laag vindt ik het geen verbetering van de onderliggende kaart, maar ik kan geen duidelijk beeld vormen zonder zooming.
Geldt voor deze objecten niet hetzelfde als de Utrechtse bomen, importeer niet alles wat geimporteerd kan worden zonder dat het beheer goed is geregeld !

We zijn het gelukkig met elkaar eens dat er politiek wordt bedreven. :wink:

I’m up for that. How can we start a project? :slight_smile:

BAG works through a JOSM plugin. Alternatively to a plugin, we could also use an entirely separate programme that operates on JOSM XML files.

It would be good if we could somehow preview in JOSM what the imported milestones are going to look like in OSM (before actually submitting them to OSM), so we can seen if the quality is as desired and tweak the import process if needed.

I doubt if the Belgium situation sketched here is much representative of the Netherlands. Back in the days some 20 years ago, when I temporarily worked for the Meetkundige Dienst, with one of the tasks designing a new system to maintain and automate aerial photo coverage of the highways, they were responsible for maintaining this data.

I can assure you, this data was quite well maintained. Positions were digitized from stereoscopic analog aerial photo’s in a photogrammetry analog / digital system that allowed highly accurate positioning of the stereoscopic photo pair based on control points measured in the field and visible in the photos (photos were also scanned at 5 cm pixel resolution for ortho rectification), which in turn allowed high accuracy data capture in X/Y/Z.

This was enough to pick out the majority of the milestones from photo. Additional missing data could be gathered in the field, e.g. by DGPS, which also results in highly accurate data.

Horizontal accuracy standards for all data gathered (besides milestones, all road infrastructure (road surfaces, lamp poles, traffic signs etc.) was set at 5-10 cm for X/Y, and 10-15 cm for Z.

That said, it is true that in the Netherlands, milestones are also not necessarily 100 meter apart.

This is of no real consequence, as all measurements against milestones are done relative to their position: e.g. Milestone 10,2 + 20 meters. If you know the accurate, real world position of the milestone, you then also know fairly well where the absolute position of the registered object is.

In fact, from the perspective of Rijkswaterstaat, milestones were never intended nor designed to show accurate “miles-along-road / mileage”, but instead to allow an easy way to define and register accurate relative positions, potentially turning those in fairly accurate absolute positions if an absolute position of a milestone is known.

Hi mboeringa, Tja dan heb je naar ik verwacht ook kennis van het feit dat vroeger de kantonnier (wegbeheerder) maar tegenwoordig een aannemer een omvergereden paal herplaatst. Die herplaatsing vindt onder de hierboven genoemde argumenten herplaatst, wat er op neer komt dat de palen wandelen. Een groot wortel- of puinbed liggen daar aan ten grondslag. Of in gewoon Nederlands als het hier niet kan dan moet het elders. :slight_smile: En ja nameten kan, maar voor een enkele paal ? Het om en nabij principe blijft overeind.

Bij import komt altijd: controleren, verifieren, respectvol ontdubbelen, naast kwaliteitsaspekten zoals volledigheid, nauwkeurigheid en tagging.

Na import krijg je altijd onderhoud. Je kan niet zomaar een nieuwe import eroverheen gooien. Het komt dan uiteindelijk neer op handmatig bijwerken: ofwel door toevallige mappers ofwel door gespecialiseerde mapping op basis van een vorm van attendering of periodieke check.

Wat daarbij zou helpen (eigenlijk onmisbaar) is een verschillendetector: een programma of script dat het huidige OSM-bestand vergelijkt met het nieuwe bronbestand en de verschillen op een lijst en/of op een kaart geeft. In dit geval lijkt me dat haalbaar, omdat de geolokatie best een ruime tolerantie (geaccepteerd verschil in aantal meters) mag vertonen. 40 meter of zo? Moet je nog wel uitkijken met wegen die vlak naast elkaar liggen…

Er is in Nederland kennelijk ook een klein aantal hectometerpunten die gemapt zijn als nodes op de way zonder highway=milestone, maar inclusief hoogteligging (ele=*). Eén van die nodes blijkt tegelijkertijd ook het aansluitpunt van een afrit te zijn, waardoor het hectometerpunt vermoedelijk per ongeluk is meeverplaatst toen iemand het puntstuk van de afrit wou verplaatsen. Er liggen tevens enkele reservenodes in de berm?!