Is it possible to tag non-permanent/short term road alerts like an accident or a police vehicle similar to how there is in Waze. For example an accident might be listed for an hour from the moment it was initially reported and a police vehicle for 10minutes but after that period of time the tag would expire.
I read the wiki page and I understand that there are tags for construction but are those permanent or do they get deleted automatically after a certain period of time unless another user reports them?
That does not make sense. Nothing get’s delete automatically, OSM is not a real-time database in the sense you suggest here.
Many data consumers like routing engines, … do not update from OSM very often, once a week, once a month.
I understand the sentiment and certainly agree accidents and police should not be in OSM, but I often see this extended to “a road is closed for a week, don’t map it since data consumers don’t update that frequently. To me, that’s inaccurate. If a road is closed it should be reflected on OSM. Similar to how we don’t map for the renderer it makes sense not to consider how frequently data consumers take in data.
If I understand your point correctly it would load the OSM database with information that most other apps would not make use of.
I had OsmAnd app in mind that uses plugins, such as online maps and weather, that connect online and get live information. So I guess it would have to be done through a plugin and using a different database, not the OSM one.
The problem with this is that with data consumers bringing in data day every month, if you were to mark a road as closed for a week and they did their import during that week, they’ll reflect the road as closed until they next do an import. OSM isn’t designed for information that changes that frequently.
I disagree. Of the data consumer suffers inaccurate data due to their decision to only use data refreshed after so long, that’s on them. OSM is creating a database that should be accurate. Introducing inaccuracies on account of a data consumer is much like tagging for the renderer. I have OSMand for instance. If I make an edit, a few hours from now it’ll be there. That’s good and useful for users of OSM to have accurate and up to date data.
OSM isn’t meant to be a live database, trying to use it as such would introduce more inaccuracies. The better option for something like this would be another layer on top of OSM to handle these kind of changes, allowing for temporary changes with start/end dates.
Not necessarily. Someone who updates the data on a Garmin handheld and then disappears off into the wilderness for a month or so doesn’t have the opportunity** to update every X minutes to keep up to date with OSM data as it reflects something like (say) “bridge XYZ is closed on 12th March, but open all other times”. Obviously as the length of a closure gets longer the argument for it being in OSM as closed gets longer. I’ve certainly mapped bridges as closed for a few months - I think that that makes sense. However, mapping temporary road closures due to roadworks taking less than a day (as someone in the UK tried to do a few months back) makes no sense at all. There’s a happy medium in there somewhere - maybe a couple of weeks or a month?
** this also applies to other devices such as regular phones in areas where there’s no internet connectivity for reasons of coverage or cost.
There’s an example of that here**. That’s OSM data, but overlaid with information about current flooding based on river levels obtained from the UK Environment Agency. See here for more information about it. You could use the same sort of process to deal with “road closed data” - you’d need an external feed of closed roads (with some identifiers) and some sort of mapping between those roads and way IDs in OSM. None of the “very short term road closure data” needs to be in OSM.
** at the time of writing, that’s dry, because there has not been much recent rain upstream of there.
Are we building a map for people who download once every few months or are we building an accurate database of what’s on the ground when surveying / analyzing aerial imagery? My understanding was the latter and that the former would have to accept that data gets stale the longer you don’t update. What was true on the ground months ago may not be so anymore.
Edit: that sounded harsher than I meant, but I agree a intra-day change isn’t appropriate. Everyone has their minimum timeframe I imagine, mines somewhere around a weekend or if I have enough notice to be useful.
Absolutely agree if it’s traffic / road closure due to accident / etc. a separate layer is best on top of the OSM map but I suppose everyone has their minimum length of time they see appropriate to update. For instance, I saw a local business will be closed this weekend due to a family matter. I added those dates closed to the map so someone looking at it this weekend can see they’ll be closed. It’s only 2 days but still useful.
The general idea for how long is okay to put into OSM in my area at least (Australia) is around the 6 month mark. Some tags are fine (i.e. opening_hours) since they already have ways to handle specific dates, but even then the issue of how often consumers refresh their data can make that useless for their users if they don’t catch it in time.
Why is how often a data consumer refreshes their data a concern of OSM? Genuinely, it seems equivalent to saying “don’t tag that way, it renders weird” which is universally considered wrong and “tagging for the renderer.”
In this case the closure has a definite end date/time, so presumably you tagged the specific dates in opening_hours. So if someone pulls the data now and then doesn’t update it, in two weeks their data won’t be incorrect.
The analogy for tagging roadworks would be to tag it as conditional access with the expected dates. That’s probably fine (although runs the risk of being incorrect if the expected finish date is delayed). But changing the road to highway=construction and then changing it back next week is a different situation.
Offline map data is a major use case for OSM (perhaps a headline use case) so casually disregarding it will not be popular. I am a happy OsmAnd~ user but also a happy Organic Maps user.
The “tagging for the renderer” guideline discourages incorrect tagging to get a rendering effect, but in no way prohibits correct tagging behaviour aimed at specific data consumers or use cases.
Changing to highway=construction for a week is correct, but not changing a road closed for a week is also correct, and it’s fine to advocate for it for practical reasons.
Another example of technically correct map data that is nevertheless discouraged out of concern for technical limitations of OSM data users would be mapping a curved feature (a road, or a building) using a million nodes to achieve millimetre precision.
Real live data will likely not be a thing in OSM simply because most of that is these days based on mobile location data that is an Google/apple duopoly.
But everything that changes slower aka road closures etc is technically easy, just build a database with OpenLR segments with some meta information that users can submit closures etc too. It has even been done at least once before (and there are OSM apps that use commercial services for this), just without the involvement of the wider OSM community.
I would go as far as to state that this isn’t a technical issue (and might be doable in GSoC project), but more a social (avoiding vandalism) and policy (the OSMF historically being unwilling to expand its scope) one.
Temporary closures can be added by using access:conditional=*
this way a time frame can be set and routers that pull data irregualry won’t be an issue.
But as others have mentioned other things like accidents and such are not a good match for OSM. Such things are better stored in a separate database.
If you are looking for an app that has the capability to tag traffic jams and accidents, I can recommend MagicEarth. It has live traffic and you can report the things you mention and all of that based on routing with OSM data. Not sure where they store the short term data but it’s not OSM database an therefore not an issue.
I agree, short term road-related alerts should be stored in a separate database. I wonder if there is a public database that OsmAnd could tap into or if this is a project that could be developed.
