> Unlike associatedStreet, which contains all street ways sharing the same name and can thus contain networks of essentially unbounded complexity, these relations should probably only span the stretch between two junctions, though.
Agreed. This was something I had in mind but forgot to say out loud. This might also help with naming, as it is very similar to the idea of a "block face". Drawing from that name as inspiration, a potential "blockFace" relation could be either "left" or "right" and only have to deal with one set of amenities at a time (on the left or right side of the street). This would cut down on the amount of features one would have to reference in a single relation. Re: kerb lines: you're right about potential duplication of data, but similar to the sidewalks situation, I'm firmly in the camp that this data doesn't get mapped with much specificity without its own intuitive home for detail. The coverage for barrier=kerb / kerb=* on roads is pretty scanty and definitely doesn't describe the actual curb interfaces for even a single small town. For example, kerb:right is used 300 times according to TagInfo, whereas I just looked at mapping kerbs around one block and found at least 25 kerb changes on kerb:right alone. This tells me that the kerb tag, when applied to roads, has not been mapped very specifically. tl;dr: I could beat that tag count in about 30 minutes *and* create a bunch of great data for pedestrian modeling + parking if I felt confident in the tagging schema. Best, Nick On Tue, Mar 5, 2019 at 2:32 PM Tobias Knerr <o...@tobias-knerr.de> wrote: > On 05.03.19 01:01, Nick Bolten wrote: > > What would you think > > of a new 'associatedStreet'-style relation that would organize the > > various features that should be associated between streets and the > > surrounding environment? > > That approach could work, yes – and it's one of the few practical > options I can think of at the moment. (The other would be drawing an > area:highway polygon around all the individual ways.) > > Unlike associatedStreet, which contains all street ways sharing the same > name and can thus contain networks of essentially unbounded complexity, > these relations should probably only span the stretch between two > junctions, though. > > While I would want to cobble together a proof of concept implementation > to be sure that I'm not overlooking anything, such a relation would > probably to solve the issue from a data consumer point of view. Of > course, it would have to actually be used by mappers to be helpful. > > > Just to clarify, the road can keep all of its same data as is currently > > mapped. This would be an additional piece of information that tends to > > go unmapped. > > In theory, the two approaches could peacefully coexist as long as tags > for kerbs, parking:lane etc. on the street ways themselves (and > highway=crossing nodes) remained available after drawing the separate > ways – at the cost of duplication and therefore additional maintenance. > > There are some hurdles, though. Even mapping just sidewalks as a > separate way tends to break stuff. For example, people understandably > connect incoming footways only to the sidewalk way, not to the street > way. So an application that filters out these separate ways, hoping to > instead rely on tags on the street way, will find itself with missing > connections to the pedestrian network. > > Of course, connecting the sidewalk to the highway with a relation would > likely offer a solution to that issue, too. > > Tobias > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
