This can sometimes be a challenge with OSM, if the way you want to structure data doesn’t align with the way the community has decided to structure data.
I was looking into building a canoeing map based on OSM data. An important thing to map is “is a particular stream between two lakes navigable by canoe?” OSM has a defined canoe=yes/no tag, but it’s supposed to be used for legal access, not navigability.
In the place I wanted to map, canoeing is basally legal everywhere, but there are many streams that no one ever canoes down, because it would be an enormous pain. There isn’t a way to represent this is OSM today, and community tends to be resistant to adding tags that map “subjective” data.
The solution would probably be for me to keep my own database of navigable streams with references to the OSM features, except that OSM features don’t really have stable ids. If another mapper comes along and decides to map an existing stream in more detail, they might choose to delete an existing stream feature and replace it, split it up into multiple features, or join several existing features together — all of which will result in id changes.
What makes a stream navigable and what hinders it? Is it water depth? Is it width? Can those be mapped? Are there edge cases that some people might be able to navigate those waters and others not? Or during certain times?
It sounds like the real issue is the "stable ids" one. You need a Single Point of Truth that matches up stretches of waterway with an ID that won't change. You can then sprinkle .isNavigable and such onto your record along with a reference to that magic ID. But yeah, if they don't provide is, they're not a very good point of truth.
I have to deal with this in my little bouldering database as well, since the source I mentioned does in fact change or reuse its IDs every so often. There's already a periodic update that has to happen on any given boulder problem, to pull down changes from the other end. That also needs a way to self-heal if a record at the other end splits off into two pieces, and my ID now points to the wrong half of it.
It's all stuff you have to keep on top of, but your idea of keeping your own table with each record pointing back to OSM seems like the only path that avoids madness. Even it it does take some work to keep those references up to date.
OpenStreetMap does not and cannot offer permanent IDs. An entity might be mapped in more detail, resulting in something being split in two parts, or change from node to way, with wildly different IDs.
At the same time, a point might be repurposed as something else entirely.
Comments
This can sometimes be a challenge with OSM, if the way you want to structure data doesn’t align with the way the community has decided to structure data.
I was looking into building a canoeing map based on OSM data. An important thing to map is “is a particular stream between two lakes navigable by canoe?” OSM has a defined canoe=yes/no tag, but it’s supposed to be used for legal access, not navigability.
In the place I wanted to map, canoeing is basally legal everywhere, but there are many streams that no one ever canoes down, because it would be an enormous pain. There isn’t a way to represent this is OSM today, and community tends to be resistant to adding tags that map “subjective” data.
The solution would probably be for me to keep my own database of navigable streams with references to the OSM features, except that OSM features don’t really have stable ids. If another mapper comes along and decides to map an existing stream in more detail, they might choose to delete an existing stream feature and replace it, split it up into multiple features, or join several existing features together — all of which will result in id changes.
Had you considered `canoe=discouraged`?
https://wiki.openstreetmap.org/wiki/Key:canoe#Access_values
What makes a stream navigable and what hinders it? Is it water depth? Is it width? Can those be mapped? Are there edge cases that some people might be able to navigate those waters and others not? Or during certain times?
If you work this out, you'll get there
It sounds like the real issue is the "stable ids" one. You need a Single Point of Truth that matches up stretches of waterway with an ID that won't change. You can then sprinkle .isNavigable and such onto your record along with a reference to that magic ID. But yeah, if they don't provide is, they're not a very good point of truth.
I have to deal with this in my little bouldering database as well, since the source I mentioned does in fact change or reuse its IDs every so often. There's already a periodic update that has to happen on any given boulder problem, to pull down changes from the other end. That also needs a way to self-heal if a record at the other end splits off into two pieces, and my ID now points to the wrong half of it.
It's all stuff you have to keep on top of, but your idea of keeping your own table with each record pointing back to OSM seems like the only path that avoids madness. Even it it does take some work to keep those references up to date.
OpenStreetMap does not and cannot offer permanent IDs. An entity might be mapped in more detail, resulting in something being split in two parts, or change from node to way, with wildly different IDs.
At the same time, a point might be repurposed as something else entirely.
You could store the ID in a tag. They already do this for e.g. wikidata[1] and gnis[2].
Though I kinda doubt they want to support maintaining these for every single project that wants one.
[1]: https://wiki.openstreetmap.org/wiki/Key:wikidata
[2]: https://wiki.openstreetmap.org/wiki/Key:gnis:feature_id