How would you properly describe a road shape like this as a micromapper? (There’s a regular unmarked residential street under that snow).
Right now, the road’s mapped as a simple way diagonally crossing through the middle of this thing, which is fine for all intents and purposes. I still enjoy micromapping, though.
I thought about several possible solutions:
Highway areas would solve all of this, of course. However, I’m not sure how widespread and accepted they are at this point, as all their proposals are like more than 15 years old by now and I’ve never, ever seen one. I can imagine a lot of data consumers getting confused by a sudden highway area mapping; also, wouldn’t I have to do this consistently to all the roads around? It’d be weird to have one little residential road switch to a whole new mapping style.
Going for the width key and attempting to describe the widest point for the diagonal section. This would look very strange on a map and not accurately describe the situation.
Mapping the areas as parking areas or roadside parking. This would be a relatively easy way to solve it, but I’m not sure how accurate this is. Clearly you’re supposed to park there in some way, but is it a diagonal area? A single lot? Which orientation are those?
Mapping the sidewalks as their own ways, which I’m planning to do so anyway, and (probably futilely) relying on data consumers to connect the dotes.
Hopefully that wouldn’t be a problem; the idea is (for regular linear highways) that you’d map them exactly as you do now, and existing data consumers aren’t affected, but that you would also map the highway area as area:highway.
You can explore which projects currently process area:highwayhere. If you wanted to create your own project to show them, it needn’t be difficult: for vector tiles (the easiest approach) you could start with the code for an existing schema and modify it to also write your area:highway data, and also amend a display style for that schema to also show that data.
I was thinking that some naive data processors would assume the are to be a looping linear road, leading to ‘ghost roads’, but I admittedly have no data to support this worry.
That is actually really interesting, I guess that’s a regional thing. Over here, I haven’t seen a singular 2D road ever, so I wasn’t able to test what my go-to apps would do with it.
It might look like that with all the snow, but I’ve been there in summer and it’s actually just a bog-standard road under there. It’s not a marked parking space.
Even then, the shape of the parking space isn’t clear so it’d be difficult to map as an area. It’d probably have to be a node if at all, which wouldn’t be very helpful. Also, what’s the orientation? You could park in that area in almost any angle.
With some OSM data that is a genuine problem. As an example, running tracks and similar equestrian features are often mapped as leisure=track. However, sometimes people map the linear way and sometimes the area. Unless they add an area tag, or the feature is a multipolygon relation it’s sometimes not clear whether something is a closed linear way or an area.
However, this isn’t a problem for area:highway since that is by definition an area (and is expected to have a linear highway drawn through it).
Yeah, true; but I wasn’t sure if some data processors ignore key prefixes sometimes. I think I read something about that once, but I can’t recall where.
In particular, note the difference between area:highway=* and highway=*area=yes as supported by this poll – essentially a distinction between facilitating area rendering and facilitating area routing. The discussion was focused on pedestrian infrastructure but extends to other kinds of highways. Straw polls don’t necessarily explain database statistics, but the rare point of consensus is to be celebrated:
