NOTE: This forum is only allowing me to embed one image in the post, so I will put the other images in the comments and reference them as figures in this post.
I would like to map the area of a crosswalk similar to the following:
The crosswalk would already be mapped as follows
Fig 2
Green
Way
highway=footway
Yellow
Way
highway=footway + footway=crossing
Blue
Node
highway=crossing
Red
Way
highway=<some_road>
For micromapping, I want to start mapping the areas that the footways, and roads physically occupy. For example
Fig 3
Orange
Area
area:highway=<some_road>
Pink
Area
area:highway=footway
What I’m confused with is how to map the area of the crosswalk itself. I’m not sure how to tag it. For example, if I had something like the following
Fig 4
should I map the Purple area as area:highway=footway + footway=crossing? Or should I do something else?
I haven’t mapped crosswalks as areas, but if I were to do so, that’s what I’d do.
I’m not sure though if that would mean splitting the road area (orange outline), or overlapping it. I don’t have strong opinions but my first instinct would be to overlay the crossing area on top of the road area. Curious to see what others think.
Interesting. I can definitely see the appeal of tagging as area:highway=crossing; however, area:highway=X has typically been used to provide the “width” of a linear highway=X that already has its own “length”.
In the case of a highway=crossing node, I’m not sure the scheme would extend logically in the same way, as the node has no length and no direction; I would instead consider the area:highway=* for the crosswalk as providing the “width” of the highway=footway+footway=crossing way (which I’d expect to exist anyway if one is already at the stage of mapping the area of the crosswalk).
I had replied below at that time Tagging methods when the entire area is a crosswalk(영역 전체가 건널목인 경우) - #7 by Kovoschiz
I see the reason of using =crossing (the area is both a crosswalk, and a roadway) as the same as =junction (different roads intersecting). There is both a footway=crossing , and a highway= road contained inside. The area:highway=footway would still represent the width of the roadway at a crosswalk.
Aside from existing though unneccessarily constrained use of junction=yes, using junction= for the intersection still ends up with having to choose an arbitrary area:highway= conventionally the highest class highway= intersecting, which causes needless decisions when different highway= class intersects, in various route continuity on each side. This doesn’t solve =turning_circle , =turning_loop , and =mini_roundabout either. Besides, junction=jughandle specifically doesn’t get used on the intersecting area.
As is before, I mentioned the question of whether overlapping area:highway=footway on the area:highway= roadway is worth considering. This might represent how it is crossing better. A supporting reason I thought for it is reducing splitting of the area:highway= roadway mid-block. The better issue I realize now is neither area:highway=footway nor area:highway=crossing may not cover the case of =footway crossing a =cycleway yet. If overlapping areas is done, that would be a simple spatial query of what the area:highway=footway is inside.
Furthermore, what about railway==level_crossing and =crossing ? Recently I have to suggest area:railway=station to compromise on how railway=station can’t be agreed to be used on areas to replace points. And then, the area:railway=tram majority use suggests interaction of =tram and =light_rail needs to be taken into account area:highway= as well, if not also US =rail street-running. Railway=station as an area? - #181 by Kovoschiz
Even more complicated, consider scramble crosswalks. Should the intersection be split into a area:highway=footway + footway=crossing X-shaped cross, with the area:highway= road triangles in the gaps? Or filling up the whole intersecting area in the original question of the linked post. These don’t show the intersecting roadways nicely.
To conclude here, I believe my perspective depends on how the areas should be drawn. This is for crosswalks only.
No overlapping areas: area:highway=crossing
Overlapping areas: area:highway=footway + footway=crossing on the area:highway= road. Scramble crosswalks could be solved by area:highway=footway + footway=crossing on the area:highway=junction , treating intersections and crosswalks differently as they are different modes.
I have mapped overlapping area:highway=footway + area:highway=primary areas for crossings like this in the past. The area is actually both at once, so it’s not incorrect. Some of the examples in one of the the original area:highway proposals [1][2] actually have overlapping area:highway=* areas and the proposal mentioned this:
Areas for lanes (e.g. area:highway=bus and area:highway=shoulder) should be drawn inside the area of the highway they belong to. Parallel ways should each get their own area (e.g. dual carriageways, cycleways if drawn as separate ways).
Afaik this practice is currently not really in use however and shouldn’t be seen as the definitive way and is still open for debate. (The original proposal was never actually officially adopted and area:highway=* is so far mostly just used in the obvious cases with a single highway type.)
Combining both highway types in the value using the usual semicolon notation would be another option: area:highway=primary;footway. I would much prefer this over trying to find single tag values (e.g. area:highway=crossing, area:highway=junction, …) for every possible combination. The details like ‘crossing’ or ‘junction’ can be added with additional sub-tags. (area:highway=primary;footway + junction=yes + crossing=marked) This also solves the issue of an area being both a crossing and a junction simultaneously. It also keeps the values for area:highway=* corresponding to the underlying highway=*.
I’ve always assumed certain area:highway=* areas would overlap others. In addition to crossing areas, I can imagine people wanting to micro-map the areas of vehicle lanes, bike lanes, shoulders, medians, are probably more. I’d imagine the eventual mapping structure would end up something like how building:part=* and indoor=* areas overlap the building=* area they are part of. Similarly, it makes sense to have an overall road area and then smaller areas within it for specific parts of the road.
The difference to building:part=* is that there you have no spatially overlapping objects. Every point of the building volume is defined by one and only one building:part=*. This is not the case for highway areas, which can be multiple highway types at once (e.g. for crossings as illustrated here in this thread).
Semicolon multival for a feature should absolutely be avoided. It’s only acceptable for attributes. Might as well use area:highway=yes + footway=crossing + something road, then it’s not better than area:highway=crossing .
Carto already renders how areas stack on each other by size. Can anyone explain its complexity and efficiency? area:highway= is meant to be a detail. It doesn’t need to be the most general purpose. I’m interested what difficulties you see for editing software. For rendering, can’t crosswalks be overlaid on top of roadways?
Another advantage is the modularity: if you aren’t interested in crosswalks, you can directly drop them, and still have a complete set of roadway areas; otherwise have to patch them up, do simplification, dissolving, etc, all by yourself.
You haven’t considered the life cycle of editing. Overlapping allows easier iterative refinement. First draw the entire section between 2 intersections. Others then simply draw the area:highway=footway + footway=crossing on top. No need to split it further. When it needs to be modified, is it truly more difficult? Eg, when a certain crosswalk is closed, overlapping allows it to be changed then finally deleted easily, all separate from the roadway. No need to fill in a potential gap from it.
For surface= , when it doesn’t change, the area:highway=footway + footway=crossing could be argued as only materialized by the crossing:markings= . No need to have a small area of the same surface= cut out.
The consideration can be extended to traffic_calming= , as raised crosswalks are common now, and there are often questions about raised intersections. When a raised intersection is cut out, non-overlapping will result in an additional area between the flat roadway outside, and the crosswalk, on each arm. Similarly, a raised crosswalk will have an extra extra on both side between the flat roadway, and the crosswalk at top.
To reiterate, I prefer non-overlapping. But it still issues, eg scramble crosswalks I realized today. Ultimately, it depends on how they are conceptualized to me.
“only acceptable for attributes” is not really true. Sure, it should be avoided if other alternatives are possible, but so far I’m not convinced that better alternatives exist that have the same expressivity. It adds a bit of additional complexity, but the concept of semicolon separated values is well known in OSM and has existing software support. Having to calculate area intersections to figure out the actual properties of a point is orders of magnitude more complex and almost completely unsupported.
Afaik the areas are simply ordered by size and then drawn in that order. [1] That is fairly easy to do and doesn’t require any geometric operations involving multiple objects, just a relatively easy size calculation for each area individually and then a trivial scalar number comparison. The individual area sizes are precomputed on import. [2]
Simply rendering overlapping things on top of each other is not the issue. That can be done without even knowing that they are overlapping as seen in the osm carto example above. The difficulty stems from having to detect that things are overlapping, finding the geometry of the overlapping parts and then treating those overlapping parts different from the rest with combined information from both sources.
You will have to combine and patch up areas in all cases. That is not a substantive difference between these approaches. If your program assumes that a roadway area always consists of just one single large object then it is fundamentally broken. Areas can be split up for all kinds of reasons, be it simply because a road is joining another at an intersection, they are becoming too large and unwieldy or simply because the surface changes. All that’s different for combined values is that your query changes from value equals x to value contains x, that’s it.
Splitting objects/areas is a really common operation in OSM for all kinds of things. I would not consider that a significant complication for editing.
Regarding the tagging of e.g. surfaces, where do you actually put them in the overlapping approach? Say you have a crossing with a footway intersecting a road. If you have two overlapping objects for the same area, where do you put the surface=* tag? Duplicated on both objects? That’s redundant and error prone. Only on one of the objects? Which one? Then what if you are interested in the surface property of the other untagged object, do you always first need to look for potential other overlapping objects to figure out the information for the object you are actually interested in?
What’s difference between them?
A. area:highway=primary + footway=crossing : I’m assuming the wiki now is mistaken in adding junction=yesTag:footway=crossing - OpenStreetMap Wiki (original proposal didn’t consider crosswalk separately)
B. area:highway=footway + footway=crossing
C. area:highway=crossing + foot=designated / footway=crossing
D. area:highway=primary;footway + footway=crossing
I didn’t assume anything unnecessary. I have always mentioned as far as how one can draw separate area:highway= + surface= for the case of surface:lanes= when the road is repaved differently. What I envisioned is you can ignore the area:highway=footway + footway=crossing directly if not interested.
The difference of chopping up areas here is you have to split it twice. More critically, iD still doesn’t support splitting yet, not to mention the possibility of some people using =multipolygon which is only a recent supported functionality in JOSM . In all seriousness, I don’t care about iD, but this is something to consider in the short term.
35% of footway=crossing already has a surface= , which is likely the same as the highway= roadway in most cases. Is this similarly “redundant and error-prone”?
Potentially less splitting of areas required
Splitting into smaller areas required for each section with different properties