I noticed that user @tracestrack-edits has begun creating route relations automatically in Belgium, apparently using a Claude Code and Overpass based approach to find all highways with a certain “ref” and merge them. I have requested that they stop doing this and seek consensus from the community first, as required by the automated edit guidelines - see Changeset: 187692031 | OpenStreetMap. I will point them to this post so they can explain their approach and seek consensus.
5 Likes
Thanks, Frederik.
Tbh I don’t see the point in these relations. Route relations are always a pain to maintain, so imo they should only be used when they actually provide useful information, such as for bicycle routes.
These relations that merely group roads by ref are redundant, so I would rather go the other direction: delete them.
5 Likes
Hi,
- road route relations contain useful properties such as from/to/network/name, which are not captured in road ways.
- ref on highway ways can break or have gaps. it’s hard to spot without using overpass or other QA tools
- there is already a master N-road route relation which still misses a lot of routes: Relation: N-road network of Belgium (14636645) | OpenStreetMap
- the ground truth of ref should be route relation IMO. ref on way is tagging for render.
the reason why tracestrack is spending token on this is because the highway shields rendering is based on route relations, which are still incomplete in many countries. We have internal route reconstruction based on ref but it would be nice to share this back.
4 Likes
Besides Tracestrack, a number of data consumers also depend on route=road relations to varying degrees. (GNOME Maps, OSM Americana, and Tilezen all include support for N/A/B/R routes and the specially marked Antwerp ring road.)
4 Likes
There’s a lot of non-arguments to unpack here…
- From/to is not too hard to analyse in software (as you are doing now).
- The network is just the first letter of the
ref, no? - The Belgian roads (and especially N-roads) don’t have names besides the street names, as far as I know? Some motorways have names, like E411 Autoroute des Ardennes, but those are easily added on the ways.
Even more so for the route relations, which have less eyes on them… Besides, ref=* on roads is not going away any time soon, so that just means two things to QA and fix!
No problem, it can be deleted too! 
Both ground truth and tagging for the renderer have nothing to do with the principled choice for on-way or relation. This is just a decoy mentioning some of our core guidelines, not an argument.
But it’s just been your choice to start doing that…
Subtle wording issue: “support” does not imply “depend”. As far as I see, the only ones who are trying to depend on them are Tracestack.
I reiterate the non-negligible maintenance of relations, which means that I’m looking for at least some tangible benefit before I can agree, and imo none has been provided so far.
2 Likes
Hello everyone, thanks for your feedback! In Tracestrack we have internal post import processor to convert highway ref into route relations. One of the extreme example is Norway, where almost all roads don’t have road relations. At least for country specific road shield rendering use case, using road relation is more stable and reliable than using highway ref.
This work is merely to add missing road relations on existing networks, not invent them, with the intention to contribute something back. But indeed it can be debatable. It’s also not scalable to cover all countries, as I’d need to request for consensus for each country’s OSM communities. As a result, I think it’s more reasonable to park this automated editing work.
1 Like
I mean both support and depend. If the route relations go away, the numbers will go unmarked in the renderers I mentioned and others like them. I regularly contribute to one of those renderers, so this isn’t speculation on my part.
There’s little appetite to implement the sort of heuristics you’re describing on a global scale. Belgium is lucky to have a system that you can describe so simply. But there are too many simple systems in the world to expect a data consumer to guess them all correctly, let alone the more complicated ones.
Lots of networks have a naming convention that begins with an N. Just today I was editing near some N routes marked by a flint arrowhead with the word “Indian” on it. Not to be confused with a different N route system to the north that’s marked by a Conestoga wagon in a trapezoid.
Relations aren’t categories, so I don’t think we should keep this one around. A type=network relation is reasonable when a network is signposted but it isn’t organized into linear routes. Belgium’s N routes are organized into individual numbered routes.
The benefit has already been proven all over the world. We started modeling routes as structured route relations to solve some problems that strained the way-based model:
- Route concurrencies, such as at this junction of the A4/E411 Autoroute des Ardennes and the N89/E46 Avenue de Bouillon
- Obscure networks, such as the R1, which looks different than the other R roads
- Extraterritorial routes, such as the Bundesstraße (B 258) in Liège
- Stylistic disagreements about way ref prefixes that are written but not signposted, which sometimes tore communities apart
- Uncertainty about whether a gap in way refs was intentional or unintentional
Uptake of route relations was slow at first, but we’re already at the point where we need to consider backwards compatibility. Deleting valid relations because you don’t use them would be unfair to the mappers who put them together and developers who came to rely on that coverage.
Route relations need maintenance like anything else. If they suffer from a lack of visibility, that’s because we’re still coddling renderers that haven’t upgraded yet. More robust tools exist for detecting gaps in route relations than among way refs. If the relations represent a significant burden to the Belgian community, I’m fairly confident we can recruit mappers from abroad to assist you. An automated LLM-powered process seems like overkill for this purpose.
5 Likes
Thanks for the arguments. All in all, I’m personally okay with these road route relations now. I think it’d be nice to document these reasons somewhere discoverable, but I wouldn’t know where.
Tilezen/Nextzen does show N307, which doesn’t have a relation. Perhaps this change isn’t live yet. Americana indeed doesn’t show N307.
But if this is really the direction the international communities and renderers are taking, it has my agreement to have Belgium follow suit (not that this is my decision alone of course).
Well, I learned something about the Antwerp ring road today! It’s completely bonkers, with R1/R2 (northern/southern part) ≠ Ring 1/2 (clockwise/counterclockwise).
The same problem still exists with relations, no?
ACK, and it crossed my mind now that it would probably be easy to cross-reference the two and find mistakes both ways.
I’m also concerned with the maintenance. I don’t think it’s so dire that we’d need outside help for Belgium, it’s just that I’m looking to avoid extra work where it’s not useful.
If Suggestion for editors: better relation editor were implemented, that would make route relation editing a lot easier.
3 Likes
Yeah, I vaguely recall that Nextzen has some logic to sniff out networks by administrative area as a fallback strategy. Protomaps, which is based on that infrastructure, recently implemented something similar using a geocoder, but they’re running into the limitations already. (That said, the geocoder approach is pretty useful for things like currency symbols on bank icons, which thankfully do correspond pretty well to countries!)
Yes, in my experience, that redundancy has been very helpful, if for nothing else than an opportunity to take another look. For example a handful of relations helped the U.S. community finally uncover a massive series of tagging mistakes even on routes that hadn’t gotten relations yet.
It’s pretty straightforward to load a route relation in JOSM or the OSM Relation Analyzer and detect any gaps. Doing the same with ways requires more analysis that’s possible but error-prone in Overpass. (Granted, a route relation can have legitimate gaps. The world never fits in neat boxes after all.)
By now, it seems we have established it is actually useful work. Could you tell us a bit more about the workflow? I think I saw a few relations where you had to make several versions before landing on something finished, but then all the ones I checked just now seem to be created in just one version. Do they only have fixme’s if there are in fact some issues? I saw one where a roundabout was missing from the relation because it was used by two N-roads. Having a list or overpass query to clear those kinds of gaps (or better yet, report them back so you can look if it’s worth automating for edge cases like this) would be useful.
Thank you guys for the clarification. I was using a complete agentic workflow with an overpass-api mcp (with our own instance) for missing route analysis and route member detection.
There is some one off script but in general, the agent:
- list all N-road network relations in BE
- find refs starting with N. got the diff routes to add
- when adding route member, try to add in order so ways are connected. add fixme if there are gaps or member order needs double checking.
- add one route per changeset. only create relations and don’t change existing ways.
I saw one where a roundabout was missing from the relation because it was used by two N-roads
That roundabout issue was spotted during random manual verification. That roundabout has a typo ref N85 (should be N58). When creating N85 (Relation: N85 (21252619) | OpenStreetMap) relation, that faraway roundable was included. It was fixed manually.
Since we got green light, I’ll finish up all N:roads relations.
The work is done. See full summary: tracestrack-edits's Diary | Filling in Belgium's N-road route relations: approach and results | OpenStreetMap
1 Like
Copying across my comment on the diary post for visibility: (tl;dr I am concerned this automated edit has not followed the editing guidelines and there are errors in the created relations which could take a long time to check for due to the large number of changesets made in a short period of time)
Can we get something written by a human rather than a massive post spewed out by an LLM please? It sounds like these automated edits were made by an ai model without prior discussion - this is very concerning. I note that the user page does not contain any documentation or links to wiki pages explaining the methodology of this automated edit - in violation of the automated editing guidelines. There are no mentions that this is an automated process on the changesets either. There are cases where duplicate relations with the same ref= are being created such as N610c (osm.org/relation/21284099 and osm.org/relation/21284102) - how is the community supposed to verify these edits when almost 900 changesets have been made in a single day? These sorts of errors in the process may have been identified if the planned automated edits were discussed and documented before beginning. 400 relations being created with a fixme= tag is a very high percentage (almost 50%). What is the merit of creating all this extra work for human contributors to validate and clean up afterwards? Without human review in the creation of these relations, errors within ref=tags may be carried forwards into the new relations, which may have been corrected had this process been done manually.
11 Likes
Looking at this post, it seems like the tagging/use of relations was given a green light, but your automated edit was not discussed - Automated Edits code of conduct - OpenStreetMap Wiki. Your account should be probably also be called tracestrack_bot (or tracestrack_agent?) if the majority of the edits made from that account are automated.
It seems like you didn’t even check the fixmes before uploading, clearly the “human checked” label on your account is not true. Relation: N21 (21252431) | OpenStreetMap (edit: this was from 8 days ago! You’ve been making automated edits this whole time?)
The lowercase typo LordGarySugar linked seems like an incredibly basic thing, and there are 10 of these issues - should have been picked up as well.
6 Likes
I have recently, in another context, quoted @gravitystorm’s 15-year old post The Pottery Club which explains how much more fun it is to build things, rather than to “fix up” crappy things that someone else created.
If the community should come to the conclusion that this automated creation of route relations was too sloppily done then we can always revert the lot.
If there should be any plans to repeat this in other countries, let me request (with my DWG hat on) that for every country this is run in, a full and proper automated edit discussion be held beforehand, with a full explanation (or source code) about the logic to be applied and a minimum of 14 days between announcing the plans and starting to execute them.
12 Likes
Are there any indications that Tracestrack will be fixing all the fixme issues or are they simply washing their hands of any non AI derived work? If there is no intended followup to the 400 fixme’s then I am all for a revert.
5 Likes
Perhaps it would have been better if the agent created a script that fixes/creates this type of relations. Why?
- A script has predictable outputs. It can be tested and do a dry run and…
- … that dry-run can then be loaded into JOSM to be inspected before uploading.
- It can be run automatically every once in while, making sure the maintenance is kept up with - effectively turning it into a Q/A tool. IMHO, that is more durable then having an agent fixing it once.
(And additionally: yes, this should have been discussed as automated edit too)
5 Likes
FWIW, the new relations make it easy to spot errors like here Changeset: 188047843 | OpenStreetMap and I for one would much more like to fix up relations with a few minor issues rather than creating them from scratch.
2 Likes
Sorry if this has not been communicated well. I wrongly assumed that it’ll be viewed as a positive improvement.
Two options for me to make this up:
- fix all issues related to my created routes until the BE community is satisfied
- revert all my created routes (this will be easy as I only create routes, no modification)
Please let me know which one is preferred. Apologies for this trouble.
Best regards
Quinn
1 Like
Your script incorrectly adds road segments from neighbouring countries, sometimes far apart.
Here is an example for N564, in the South-Western part of Belgium. The script found 7 ways in this area (which is correct) + one road in the Netherlands (the first node is on the border) and bundled them all into the new relation.
Your script spawned a fixme tag to mention a gap. There is a 140-km gap between those two parts, which a human reviewer should have spotted (and fixed) immediately.
4 Likes