My (Udarian) prefered way forward for pedestrian mapping

--- draft:10 posted:true version:0.5.0 --- # My preferred way forward for pedestrian mapping By Udarian It has come to my attention that some of my views on pedestrian tagging differ wildly from others within OSM and thus I am putting this together. The goal here is to first and foremost describe how I see these tags and exactly why I have these opinions and second of all to (hopefully) manage to change enough minds on at least one of these such that we can get a successful tagging change through the wiki. This will hopefully lead to a more coherent and (in my opinion) logically sound tagging schema for pedestrian features. A lot of my arguments for various parts of the tagging schema hinge on how I see and understand the tagging schema itself so I will explain that first and then proceed to argue the various changes I'd like to see made to the tagging schema. This is a work in progress and I will be updating it after I have made this public and will create and be linking other written pieces on tangentially related topics along similar lines to this. ## two different types of tags As the heading implies I see the tagging schema as having two types of tags, these being identifier and metadata tags[^1]. The two types of tags are as follows: 1. **Identifier tags** tell you what the nature of an object is and what aspect of this object makes it what it is, and thus by removing that information would make it a fundamentally different object. 2. **Meta tags** add more information about the object that is nonspecific to the object. The key here is that meta tags specify aspects of objects that aren't implied by the object type and are not core to what makes something what it is conceptually. So how do you then tell what should be identifier and what should be meta? Well, ideally the object type (identifier tags) would specify something so crucial about the object that without specifying that about the object you either have a fundamentally different type of object, or knowing this about the object leads to it being treated very differently when interacted with by people or more generally users of the data/object. Meta tags on the other hand specify information about an object that does not differentiate between object types, and thus is not fundamental to the object and usually many different object types can have the same meta tag. I have included a few examples below to hopefully clarify what I mean by these two further and give examples as to the logic I use to determine what should differentiate and what shouldn't: First, let's take the example of residential roads: 1. First we are looking at an area we are representing as a way, this way has no information (or at least only meta tags which tells us neither here nor there about what this is). So we ask ourselves what the most important attribute of this way is. - In this case, it is that this way is used for transportation aka `highway=*`. 2. Next we ask ourselves if there is some information that we could specify about this transportation way that would further distinguish it from other transportation ways - In this case, specifying that this perticular transportation way is only for (or at least intended mostly for) vehicles[^2] is rather important since depending on what it is used for it is treated very differently by data consumers and people in general (and from how I see it that fact makes it something fundamentally different). In this case, we don't really change tags (but that is a conversation for a different time), but in all the other examples we will, so at this point we have the tag `highway=*`. 3. Next we again ask ourselves if there is something about this particular road that is so fundamental that it would make it a different type of object - in this case there is, this is because the road (object) we are examining has comparatively low speeds and width and leads/connects to driveways of private homes and is in a residential area and doesn't have perticular high throughput (isn't a collector/distributor); aka its role in the wider transportation network is that of a residential road. Thus it's best tagged as `highway=residential`. 4. We once more ask ourselves if there is anything further that may differentiate this object from others like it. In this case, I can't think of anything else. There is a lot more information we could provide, for certain, but nothing that I can think of that would make one residential road fundamentally different then another. Next let's look at the example of American-style suburban single-family houses, and go through the above logic once more. 1. As with the above, we ask ourselves what about this object makes it special. - In this case, what we have is an area that outlines a building so `building=*`. 2. Then we ask ourselves if there is something about this particular building that is so fundamental about the object that not specifying this about the object would lead to a loss of information. Aka is there something about this building that is so fundamental about this object that specifying this about the object would make it something fundamentally different? - In our case, there is something, the fact that it is used by people as a residence, that people live in this building; rather, say, than containing retail or commercial businesses. Thus it is a home (`building=house`)[^3]. 3. Now we ask ourselves if there is something so fundamental about this residential building that specifying this about the building would make it a fundamentally different type of object. - Well this is a residential home that only one family lives in, a single-family home aka `house=detached`. [^4] 4. I cannot think of different types of detached homes and thus we don't have a `detached=*`. For the next example let's look at flush curbs (as ways): 1. First we ask ourselves what we are looking at? - Well this is a feature that separates one area and another, if only conceptually, and can at times impede flow from one area to another, aka it is a barrier (`barrier=*`). 3. Next we ask ourselves if there is something special about this particular barrier that distinguishes it from others. - The answer here is yes, this barrier serves to separate cars (if only conceptually) from pedestrians on the sidewalk and isn't tall enough for this to be a wall so this is a kerb [^5] (`barrier=kerb`). 4. Now we ask ourselves if there is something so fundamental about this object that not specifying this would make it a fundamentally different type of object, and the answer is yes. - What differentiates this object from others similar to it is its shape, while at surrounding points it is raised or rounded here it is at the same level/grade as the road, the raised/rolled kerb on either side comes to a sharp end at the point were it becomes flush and the path connected is flush all the way through (kerbs can be flush without all these criteria but I am being this specific for the example); that is what makes this `kerb=flush.` 5. Now we once again look if there is something that may distinguish one lowered curb from another, and honestly, I can't think of any. We already determined for roads that surface information doesn't constitute an identifier and is definitely a metatag.Next, we may look at tactile paving but that too isn't inherent to flush curbs because it can be found on basically all curb types and on non-barrier features like sidewalks in some parts of the world. So this is where the tree ends for this one. Before we continue to my arguments for or against various tags, I would like to point out that the identifier tags form an n-leaf tree. For visualization purposes, I have created a graphic of the tree that I tried to put all the tags I know of for ways (it’s missing vertex, area, and relation tags since those are essentially different trees that work slightly differently, so they aren’t all that relevant to what I’m writing here), but I may have missed some lesser-known ones that I wasn't aware of, so feel free to notify me if I missed any. As a final note here, I would like to explain why I put a "void" tag at the top of the tree. This is relatively simple, for increased readability/aesthetics. It is mainly there to further show and highlight just how much of a tree this forms, and we wouldn't want to break the tree (in my opinion)(hint, hint). I called the "tag" at the top of the tree void because, as with the "void", it's empty but still is "something" and IRL doesn't exist. (As a note the image I have attached below is a [work in progress](https://github.com/Udarthegreat/public-sources/tree/cdc81d8ad815f22cb3a53422552c59ae1f043a2e/opinions/why%20crossing%20should%20not%20be%20deprecated)) ![the OSM tree of tags.drawio](https://hackmd.io/_uploads/S1i4Q6RDel.svg) ## crossings The tagging of crossings is the place where I, from my understanding, have the biggest differences in how I see the tagging schema and where I would like it to go, so I will start by putting forward my simpler, and hopefully less controversial opinions first, and the big substantially more controversial, and larger in effect last. Ever since the introduction of `crossing:markings=*` I have felt like there have been some inconsistencies between various tags. So I am writing this to put forth my thoughts on how all of this can be harmonized. ### crossing vertices The first thing I want to talk about is the cases where a road crosses a sidewalk, in this case, we have a rare (at least in FL) case where the vehicle crosses through the pedestrians' domain instead of the opposite which is what usually happens with essentially every other crossing. In this case with existing tagging I would think that we add the `highway=crossing` without a more specific `crossing=*` value as we don't have a tag to describe the situation accurately as it is; ideally we would add a crossing value something like `crossing=vehicle` to clearly specify that this is a special type of crossing were the vehicle crosses the pedestrians domain. What is to me incredibly clear hear is that a tag of some sort should be **required** as this is a spot were vehicle and pedestrian traffic (even if it is an intersection between a driveway and a sidewalk), even if ever so slight, intersect and as such it should be tagged with the same tag used to tag every other crossing vertex, `highway=crossing` at minimum. ### kerb cuts Another case I would like to lend my voice to is that of the link between the sidewalk centerline and the crossing when both are within the same sidewalk area (basically, dealing with kerb cuts), there are meany ideas floating about on how to deal with this edge case with much conversation happening on this front recently so I would like to also throw my hat into the mix as I have some ideas here. My preferred method of dealing with this would be to [skunk](https://en.wikipedia.org/wiki/Skunked_term) [`footway=link`](https://wiki.openstreetmap.org/wiki/Tag:footway%3Dlink) a bit passed its current usage and alow it to be used to specify any link between a pedestrian feature and some other pedestrian navigable feature were the geometry of the centerline of the feature wouldn't otherwise allow for the connection without breaking some other rule. That would now include other pedestrian features such as crossings and would thus solve our problem. If this is sufficiently opposed then my second most preferred alternative would be adding a `footway=footway_link` that would be defined between pedestrian features, this was what I preferred before I learned of `footway=link` and would play the same role if implemented as by the skunked version of `link` from above, so it would be workable. As a final note here, I will acknowledge that we need more tags surrounding kerbs and kerb cuts, for example I would like to be able to ultra micro map lines in the concrete that make up the kerb cut, but I am ok with that being a topic for a future date as I have not thought about it enough to know how I would like that to look. Though the key here is that all of this would be meta tags and `footway=link` is an identifier tag and should be as it plays a different role than a sidewalk or other footways. In general, I feel like my skunking of `footway=link` would cover more cases that I would like to be able to map than something like `footway=kerb_cut` could but I would be amenable to it if that is the way the community swings. As a final note, until a consensus on [skunking](https://en.wikipedia.org/wiki/Skunked_term) `footway=link` or the creation of a new tag if it is between `footway=sidewalk` and`footway=crossings` (what would get this skunked link or new tag) it should be tagged as `footway=sidewalk` as these are still within the sidewalk area and thus it would be incorrect to map the crossing way into the sidewalk area. ### traffic islands and tactile paving/kerbs I also think that `crossing:island=*` should be partially deprecated or at least heavily discouraged. The reason for this is that the value of this tag would already be within a decently mapped section of pedestrian infrastructure, aka this is already available by looking if there is one or more ways with the tag`footway=traffic_island` directly between any two crossing ways since that conveys the same information. From my perspective the reason that physically mapping out the traffic island's location, is better than just tagging it on the crossing is that you can't easily assume where the traffic island may be by just looking at a crossing with the tag alone. So by mapping exactly where the traffic island is, data consumers (pedestrians) can more accurately tell where the island is and thus where they are to stop when crossing the road. Another reason is that crossing ways are only defined within the road area as they do not exist within the sidewalk or traffic island so should not be mapped in that area and thus `footway=traffic_island` mapped as a way is preferable in my opinion[^6]. Once the `footway=traffic_island` is already separately mapped there is no longer a need for the tag on the crossing ways and vertices as it becomes duplicate information that is rather trivial to determine. Similarly to `crossing:island=*`, `tactile_paving=*` should not, in my opinion, be mapped on `crossing=*` ways[^7] and vertices as that information should already be mapped on kerb vertices and thus is a duplicate. As mentioned above, there is also the fact that crossings mapped as ways only exist within the road area, and thus kerb vertices will exist at the two ends of a crossing way in the vast majority of cases. If an algorithm needs to know if a crossing has tactile paving it can just look at the kerb and determine that way; if there is `tactile_paving=yes` on either end vertex of a crossing there is tactile paving for that crossing, this way we stick to mapping what exists not what speeds things up for data consumers as we don't map for data consumers (an extension of not mapping for the renderer), also we thus are not unnecessarily skunking`tactile_paving=*` from "there is tactile paving here" to "there is tactile paving at the ends of this feature". There are a few exceptions to the above two (`crossing:island=*` and `tactile_paving=*`) that I can think of, first is the case of the mapper just getting into mapping pedestrian features and is thus mapping to a more bronze tier of geometry, in this case it can be useful to tag these in, but we should put an emphasis on moving to silver as quickly as possible once an area is done as bronze for the increased accuracy to what actually exists in reality, and in general more useful pedestrian network. Once an area is mapped to a more silver tier of geometry these tags should be removed from crossing ways and vertices. The second is the case were you are quickly mapping the infrastructure in an area (most of the time this will be when quickly surveying an area from the ground) or adding more tagging detail but don't have the time to split ways and add new information (like `kerb=*`) to vertexes; the important part here is that you or someone else do the necessary way splitting and vertex changes to put the tags in the correct place at a latter time. Ideally, this would happen within a few hours to a day or two and thus isn't that big of a deal as it won't be there for long and ideally QA tools like OSMOSE would find instances of these tags on crossings and show low importance errors so that they can be fixed. This also means that I would like to see tools like StreetComplete not suggest adding kerb, tactile paving, and traffic island tags to crossing vertices if the traffic island and kerb vertices are already separately mapped. ### unmarked and marked crossings Next is `crossing=unmarked` and `marked`, and why they should be deprecated or at least heavily discouraged. The reason I think that these should be deprecated is that they contain within them two pieces of information, they specify if a crossing is marked (and nothing more specific) along with the signalization of a crossing. Generally it is a good idea for one tag to specify one piece of information, and as these specify two, one of the pieces should be removed and the other remains in `crossing=*`. As `crossing=marked` means `crossing=uncontrolled` + `crossing:markings=yes` (and nothing more specific) and `crossing=unmarked` means `crossing=uncontrolled` + `crossing:markings=no` we should remove one of those meanings while keeping the other. So we must decide which to split and which to keep. Well since the one we keep in is going to be a value of `crossing=*` we should try and remove the information that is not specific to the type of object, and that would be the type of marking, so `crossing:marking=*`. Since `crossing=unmarked` and `crossing=marked` by the definition of their (of the words marked and unmarked) specify some amount of `crossing:markings=*` and one cannot define them with out that information these two tags should be deprecated in favour of `crossing:markings=*`. By doing this we are left with `crossing=uncontrolled` and `crossing=traffic_signals` were these by their values definitions mean a **crossing not controlled by signals** and an **crossing controlled by signals** respectively. Doing this will simplify `crossing=*` significantly and make it a better base to build future pedestrian tagging on top of, and feeds onto a different argument below nicely. ### uncontrolled vs controlled crossings Last is my argument as to why we should not deprecate `crossing=*`and how to deal with the inevitable outcomes of that. So then, why should we keep `crossing=*`, well simply put, because in my opinion there are two fundamentally different types of crossings meaning that there is a need for a crossing identifier tag and thus we shouldn't create a break in the tree of identifier tags by deprecating it. The logic for why this should remain is as follows (the example will go to a signalized crossing mapped as a way but the logic works the same for unsignalized and vertices): 1. As with the examples given in the beginning section, we ask ourselves what about this object makes it special. - In this case, this is a way used for transportation aka `highway=*` a property that distinguishes it from other ways. 2. Next we ask ourselves what about this transportation way distinguishes it from other ways with the same basic use - Here the particular kind of traffic is that of pedestrians so the correct tag would be `highway=footway`. 3. Again we look at this way and ask what makes this particular pedestrian way special as compared with others of the same type - This time what makes this way special is that this pedestrian way is used to cross roads as opposed to walking alongside a road or being within a traffic island so the tag to be used here is `footway=crossing`. 4. We again ask ourselves if there is something special about this particular crossing that if not specified would make it a fundamentally different type of object which thus would lead to it being treated differently by people. - In this case, in my opinion, there is. The fact that there are signals at this intersection makes it fundamentally different because that difference fundamentally changes how it is interacted with by pedestrians, something that cannot be said about different values of `crossing:markings=*` other then `no`, I cannot think of a situation were one kind of marked marking would change how it is interacted with but I think that signalized crossings, especially here in the US, are much preferable to unsignalized crossings due to higher safety to the pedestrian. This also holds purely on a object in a database level, not considering data consumers, as whether or not a perticular crossing is signalized leads to the shape and structure of the crossing usually changing significantly in physical shape and structure, in the real world as built and how it is thus represented in the database while the type of marking on a crossings does no such things. Also, just the fact that it is signalized means that there is more to this crossing than just, "well, it's a crossing". - In the case of our example the crossing is signalized so `crossing=traffic_signals`. 5. Now we once again ask our selves if there is something about this signalized crossing that differentiates it from others like it[^8], I would argue that there is a case for there being more values but that would require new tags, and I am internally unsure if those would be meta tags or identifier tags so I will leave that for another day, plus that would make getting this changed in the tagging through significantly harder. As a final note here the addition of `crossing:signals=*` doesn't just duplicate `crossing=*`, it also duplicates `traffic_signals:countdown=*` as, the `yes` and `no` values are given by the value of `crossing=*` and `shared` and `separate` are given by the value of `traffic_signals:countdown=*`. As to why I think we should keep it this way as described above in my opinion `crossing=*` is a identifier tag, but I also agree that it is important to know whether or not pedestrians cross based on which lanes of vehicular traffic are currently moving or whether the pedestrian has a separate signal or countdown timer that tells the pedestrian when to cross, the issue here is that I feel this perticular piece of info is a meta tag and thus needs its own tag which `traffic_signals:countdown=*` provides perfectly well. So, what's the solution here, well ideally we would deprecate (or change the meaning of[^8]) `crossing:signals=*` as a historical misstep in the history of the OSM tagging schema and build on top of what we have, the issue is that `crossing:signals=*` is used quite a bit IRL so this is not as easy as that. What I think we should do is create a new kind of soft deprecation were tag is mostly not to be used and eventually will be brought fully out of use, aka in something like $10$ years the tag will be fully deprecated with this fully documented everywhere possible so that it is basically impossible for data consumers and mappers to miss it giving data consumers using it time to fix their parsing and other algorithms that rely on this tag so that by the time we remove these tags fully there are no issues, this is also more then enough time to fix the editors and get mappers accustomed to the new correct way. Essentially what I am recommending here is that we use method often used by software, especially libraries used by meany (the example that first comes to my mind is [imgui](https://github.com/ocornut/imgui) were they will mark some part of their api as deprecated and create new api in it's place but keep the old code around so that new releases of the library don't instantly break everyone giving developers a few release cycles to change their codebases to use the new api, introduced with warnings popping up in your compiler if your using the old api; that is essentially what I want to do here, mark this as going away and thus moving forward only use the new tagging but keep all current instances of the old tag being used (`crossing:signals=*`) around for those that are currently using it giving them more then enough time to update their codebases to use the new tagging standard, then at the end of the $10$ (or how many ever we decide on as a community) years we use some kind of bot or manually remove all the existing tags from were ever they are currently mapped. That last part is something I would be more than happy to take on and lead myself. In the end, $\text{x}$ amount of data consumers use this tag and thus we shouldn't remove it isn't a good argument as OSM has never mapped for the data consumer, we have always decided tags based on what best describes the on the ground truth, not what some corporation want's, if you want to use the OSM data you use it as it's mapped, when deciding on tagging we should look at what's the best way to represent (tag) the on the ground truth rather than what some data consumer want's, not that they aren't important, they are, that is why I propose the gradual deprecation described above. I am aware that this means changing up some of the wording in some of the wiki pages (and (hopefully) eventually deleting (or changing[^8]) the `crossing:signals` page[^9]) but I feel as if this is necessary to clean up and better optimize the spec so we have a better foundation to build future parts of the spec upon. Though if the tagging proposals I will make out of feedback from this post fail it is what it is as the democracy of OSM is extremely important, especially in todays world. Happy mapping, Udar. [^1]: I am not very good at coming up with names for things, these are just the names I came up with on the spot, I'm sure someone else can come up with something better. If someone can come up with better terms I'd gladly update this to use those terms instead. [^2]:While this perticular transportation way is mostly intended for vehicular traffic others may have multiple uses, such as a living street and service roads. [^3]: I am aware that `building=detached` is valid but I am going to `house=detached` to better show the logic and because I personally feel that is the better of the two (the argument for that will come later). [^4]: This compared to cases where multiple people live in the same building such as `house=terrace` and cases where we map multiple parts of buildings to show the 3D structure. [^5]: and is also shaped as a kerb. [^6]: it also cannot be discounted that once mapped separately there is allot of meta tags that can improve navigation of pedestrians that would be hard to add if only tagged on crossings, such as the size of the traffic island, were longer traffic islands are preferable as stress levels when crossing the, are substantially lower and the ability to tag if the traffic island has a call button or if the call button is only on the sidewalks, so if the pedestrian is unable to make across the whole intersection in one go they may be at the mercy of the traffic signals. [^7]: tactile paving should only be tagged on crossing ways if there is tactile paving across the whole crossings area (and thus way) [^8]: The values of this would be the types of traffic signals involved, like traffic lights, pedestrian crossings, [RRFB's](https://highways.dot.gov/safety/proven-safety-countermeasures/rectangular-rapid-flashing-beacons-rrfb) as those are treated differently based on the value but I can also see this being a meta tag that repurposes `crossing:signals=*`, but again that would be a discussion for another day. As a note these values, while usually already mapped they are found on vertices of the road network and thus require navigating through the road network from the pedestrian network to find the value, which is significantly harder than finding values of the pedestrian network when in the pedestrian network, but again this is a discussion for another day. [^9]: There will also be significant code changes needed for editors like RapiD and streetcomplete, but again there would be time and I would be more than happy to make the necessary PR's to get this across the finish line.