While reviewing changesets I found relation 2621481 which was previously had the tag name=Gritting Priority 2 roads which paired with the operator=Highland Council tag seems to indicate it was meant to map a certain priority of gritting for these roads by the council.
It has since been updated to include the route=route and type=route tag which is very interesting given it very clearly isn’t a route, see the image below showing all of the ways that are members of this relation and how clearly they are not connected. The name=Gritting Priority 2 roads tag has also since been removed.
With a relation this large and not being a part of the local community in Scotland I didn’t want to just delete the relation as is my first instinct in this case. Hence this post to get consensus on what to do next about this relation. I’ve also left comments on changesets that have made changes to the tag of the relation, not the ones that happened to edit the members though.
I would recommend deletion of the relation. I don’t think the original concept of mapping the gritting priority is something of much value in OSM or that it’s particularly verifiable. I think this is evidenced by the fact that the relation has been broken for some time with seemingly nobody attempting to fix it. Please do let me know if there is something I have missed here though!
@tms13 : I saw you originally created the relation and still seem to be actively mapping in Scotland. Would appreciate your input on this topic greatly!
@klnkengi has since replied to a changeset discussion asking why they added route=route and type=route to the relation.
Hi, I am not really sure what happened there, as this was one of my first changesets. I think I wanted to change some cycle route relations, I don’t think I intended to edit this relation.
Given this I think we can safely rule out this relation being a route.
There are two separate questions here:
(1) is the “gritting priority” verifiable enough to justify inclusion into OSM?
(2) assuming the answer to question 1 is “yes”, is a relation the right tool?
The answer to question 2 is certainly no, because since any road will only have one specific gritting priority, a simple tag like gritting_priority=2 would be the way to go. You only need relations if a road could be part of many such groupings - if roads were frequently gritting priority 1 and 2, for example.
Good point! I will give this a week for people to raise any objections to deletion and then delete it at the end of the week if there’s nothing raised.
Knowing which roads are going to be gritted and to what extent is extremely valuable information in certain places and at certain times of year. Councils may be better at displaying this information themselves on an online map these days, but I think I remember a case where the Council only produced a list of the gritted roads, and putting that information into OSM and then producing a map was the only way people could get access to a map of the gritting routes.
The verifiability would have to come from data supplied by the council. There’s then the question of how up to date the current OSM data is, and whether anyone is maintaining.
While a relation might not be the obvious choice, technically the gritted roads are actually defined by the route that the gritting lorries take. So maybe a relation could make sense. Although here, the information seems to be gritting priority, rather than specific gritting routes.
Given the potential usefulness of the information, you shouldn’t delete the relation without broader consensus, and also a decision on whether the information should be retained with some other tagging. I’d suggest you at least try to track down the person who added the information in the first place to get their take on things.
gritting=priority_1/2/3 (gritting | Keys | OpenStreetMap Taginfo United Kingdom) already has 22,000 uses in the UK, admittedly almost exclusively in Birmingham. Agreed that tagging the gritting priority on the roads would be much more maintainable than the current mega relations, and doesn’t violate the ‘relations are not categories’ rule as mentioned above.
Looks like it would be worth contacting the Highland Council about the potential of importing these priorities into OSM or getting a list of roads released as an open data set under OGL or similar compatible license. I suspect that the details of which roads are gritted is not part of the copyrighted information but it would be best to err on the side of caution when it comes to OS given how antagonistic they seem.
@Robert_Whittaker setting aside the issue of potential usefulness of this information I still believe that the relation would be best removed in it’s current state. It has over 400 changes to it’s version history because loads of people end up editing it if they happen to touch one of the roads that is included. I cannot find any evidence that anyone was using the data for any purpose which is further evidenced by the lack of reply from those who have edited the tags on the relation and the fact that the relation has been left in disrepair for 7+ years at this point. The original creators seem uninterested and nobody has picked up maintenance for it. Checking against the information provided by the Highland Council it is also outdated in many areas which further erodes the current usefulness of the data as it may be misleading.
I very much get the want to preserve information rather than deleting but the info isn’t being used by any OSM consumer (that I was able to find) and the history still remains in OSM, it doesn’t vanish and can absolutely be restored in future or used to add tags like the aforementioned gritting_priority=* tag or even something like a gritting_hours=* tag to denote when each road is gritted.
I’m going to leave the relation for the aforementioned week, removing it on the 5th October, to give ample time for those directly effected to respond as well as a plan to be made for adding actually useful information or repairing the current relation but currently the relation is actively adding complexity to the maintenance of OSM with no current consumers for the data.
Please feel free to add information here if you happen to find someone who needs contacting about this, a data consumer or if you feel the deadline is too short but we do need to have reasonable cut-offs for these kinds of discussions so the issue doesn’t consume too much time that could be used elsewhere.
If you want to remove the relation, in the absence of any positive agreement here, then I think you should convert the information into gritting_priority=* (or whatever is appropriate) tags on the member ways. I don’t think it’s appropriate to simply remove data like this just because you don’t think anyone is using it, and you object to the current way it’s represented. (Yes, the data would be available in the history, but unless anyone knows to look there they’re not going to find it.) It may well be that the data is so out of date or incomplete that it’s not really worth keeping, but that’s a discussion we should have before anything is removed.
I’m not going to migrate this on my own. This is a relation that has 400+ versions and has been left in disrepair for 7+ years. Migrating this is not a small task and not something I am willing to do unless someone else is willing to take the lead. I also question if it’d be worth the time spent on it to restore something with known outdated information which we now have reason to believe may not have been compatible with the ODBL in the first place.
Regarding the relation being less visible in the history, it wasn’t visible to begin with! It had no name and completely the wrong tags. I only stumbled across it by accident and had to dig into the history. This forum post and the messages I have sent to mappers who edited the relation are the visibility for this relation and are how people know where to look. Deleting it will have little to no impact. If people reply after the deletion the discussion will still be here and a restoration or migration process can happen just as easily.
Given people have already attempted contact 3 years ago and gotten nothing back and the relation has no identified data consumers alongside being broken for 7+ years the burden is on people wanting to repair the relation to act. Hence the deadline for deletion on the 5th. It can still be restored later with minimal effort but it’s not acceptable to place the burden on people to prove something isn’t useful, requiring proof of non-usefulness is impossible to satisfy.
Thanks @CanopyFalls for pointing me here. I’m the original creator of this relation, and I have to confess that I haven’t been as diligent as I would like in updating annually when new data are published (and I apologise for failing to include a source_ref tag for verifiability).
I certainly agree that conversion to a Route relation is wrong for this and for the sister relation for priority 1 roads. Modern consensus seems to be that relations shouldn’t be used at all for collections or networks, so we should probably consider conversion to tags. I’d suggest something like gritting_priority=medium (to keep the tag self-describing and avoid the mistakes of e.g. track_type) - but would look to see how such information is represented elsewhere before making a mass edit.
Ironically, replacing the relation with tags would make it much harder to maintain using my current toolset (loading all members of a relation into Merkaartor is simple; performing a server-side search to identify them by tag isn’t a provided functionality), so in that case, I’d be much less likely to resume maintenance in future.
I’ll try and read the rest of the this thread if I get chance before I leave this afternoon. I should be back on Monday or Tuesday otherwise.
In which case, you should leave the relation as it is for someone else to deal with. It’s not as if it’s doing much harm at the moment. I’m not sure exactly what you think would be involved in migrating the data to a tag-based representation though. I was imagining that we’d simply add a common gritting_priority=* tag to all the way members, and then the delete the relation. That can be done with a couple of clicks in JOSM.
@tms13 if you’re able to get the current relations up to date and having a suitable name using your current workflow before they’re removed, I think that would be really helpful. Then a migration to tags will be starting with accurate data. In terms of maintenance going forward, have you looked at using JOSM? I’m not sure what features Merkaartor has, but JOSM will let you import an OSM snapshot from another tool, and you could fetch all the gritting_priority=* ways using e.g. Overpass Turbo. I’d be happy to try to find a workflow that works for you if you’re interested.
Thank you for getting back on this @tms13 ! Apologies for the slow reply on my part to this thread.
Have you had any chances to look into this further?
I’m going to postpone the deletion deadline for another two weeks till the 19th due to yourself coming back here and my tardiness in replying so don’t worry about that being imminent. It can always be extended as many times as needed.
Will also write some overpass scripts to help with maintenance of any future tags and take a look in more detail at the wiki as there are discussions on how to tag gritting that have been left unresolved on there for the Birmingham Gritting Priority page.
Would also be good to consider how broken the current relation is. I don’t have the energy to go through and check how outdated it is and how broken by other users it has become but would be good to know if it’s a good starting point for adding tags or if we should go straight to FOI requests from the local council.
Imposing a deadline on another volunteer editor to do something by is not cool. While tms13 may have created the relation in the first place, you can’t require people to maintain things they create forever. You are not their line manager.
If the relation is bothering you, but you don’t have the time/energy to check and migrate it to the right final format before deleting it, leave it alone and let someone who does have the time/energy do it all (including deleting the relation once they’re done). Don’t just skip to the satisfying end of the task.
To be clear, I agree that a relation is now considered to be the wrong way to approach this kind of tagging, and the data does need to be checked and migrated to gritting_priority=* as discussed — but I respectfully think you’re taking the wrong tone for trying to get this done.
This thread probably isn’t the best place to discuss whether deadlines are appropriate in situations like this. If you want to discuss the approach further, it might be worth opening another thread exploring methods for preventing issues from becoming stagnant and the drawbacks associated with them.
If you have concerns about the specific timeframe and believe more time is needed before the deadline, let me know and we can extend it. And if you’d like to take the lead on the relation migration, I’d welcome that. I’m happy to hand this over and just check if the thread becomes stale again in the background if you’re up for taking the lead.
if relation is extremely outdated than deleting it may be more helpful than migrating broken data to a more standard format
at some point data is outdated/mismatching reality enough that it is better to not have it at all
(not checked is it applying here! But I deleted in past for example detailed area:highway where road geometry completely changed since then and elaborate opening_hours where new one was elaborate in a completely different way - without replacement in both cases, this was still a good edit.)
deleting entirely and completely outdated things is also fine, and in this case it was rather about postponing already planned deletion
note also “It can always be extended as many times as needed.” - presumably if @tms13 is busy now but is supposed to have more time in January then it can be postponed to February 2027?
Update @Chris_Fleming has replied with the following comment on a changeset asking about why they deleted the name of the relation. Not a massively shocking update but still worth cataloguing here:
I 'm not sure! I did this change over 6 years ago. But having a relation for Gritting Priority 2 roads seems wrong to me, assuming thats what it is.
I had a serious network failure for the last week. But I’m back and I have updated the tags on these relations. Now to start on ensuring their member ways are up to date ready for the conversion.
