I have a few questions about a possible import of these hectometer signs / ‘milestones’:
How accurate is the location of the signs? I think the best location to put these in OSM is at the exact location of the sign, next to the road. Would this import lead to a lot of signs spread over the roadway or would they be exactly on the location of the sign (e.g. accuracy of 25 cm).
How would you translate the information on the signs to OSM tags? They usually contain a distance in km with 1 decimal accuracy, a road number and a carriageway reference (Li, Re, or a letter).
The traffic sign code of a hectometer sign is BB07, so I think the tag traffic_sign=NL:BB07 should be added to the hectometer signs.
I would like to add to the people saying; survey it.
It’s practically impossible in my view to survey these signs with any degree of accuracy. The problem is that you can’t get close to them, and if you try anyway you’ll have Rijkswaterstaat stopping on the shoulder in no time asking what on earth you are doing!
Maybe with the new 7,5 cm aerial imagery combined with very high quality rapid automatically taken photographs from a car you could do it, but it would be a massive job.
So I think, either import them or don’t add them at all.
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.
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.
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).
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 !
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.
