BLUF: I strongly object to changing width= from minimum to average.
Kashish via Tagging <[email protected]> writes: > I recently purchased a laser distance meter, primarily for measuring > road widths so as to allow better routing for various vehicles. In the > process, I discovered that some roads can have a gradually > decreasing/increasing width. The wiki does not cover such situations, > so I brought it up in the #osm IRC channel. That's very cool that you are actually measuring width! > Some mappers (and the wiki) advise that one should map the width at > the narrowest part of the street. However, this is not always > desirable. If a vehicle can enter a street up to a certain point to > reach an address or POI, sufficiently smart routers should (given > sufficient data) route it along the street accordingly. True. > For such situations, I liked pbnoxious' suggestion of using the keys > width:start and width:end, applied to the concerned way. In addition, > pbnoxious suggested using width=* to specify the mean/median width. By > splitting ways and using width:start=* + width:end=*, complex changes > in width can be mapped. As always, I like to ask who the data users are and what suits them, and to think about tags in terms of how they would be read. My state government has a dataset of roads that includes width. Their approach roughly appears to be to split the segments when the width is substantially different. This is not particularly different from splitting when the speed limit changes, or the surface type. How often are you finding roads that have a linear decrease in width, such that you would need a start/end pair to represent it? If you instead said "split the way when it changes by a meter, and tag width= for the min", how often does that happen? Wouldn't it be simpler for everyone to have that increase in split ways and not have new rules that every router has to implement it? Or is this really common? I can see irregular widths, but your proposal doesn't help with those, only when the width can be well approximated by a line. > A question was raised about how such a width should be > rendered. Personally, rendering a gradually increasing/decreasing > width is not too important for my uses, but can be nice to have in > more detailed renderers. Sure, I think that's the least important part. > If there are no objections, I'lpl add a section about the above to the wiki. I strongly object, because a data router that uses just width will conclude that the way is usable when it is not. It is a basic principle of tagging that data consumers that read the basic tags rather than the more complicated tags that are less used should not be misled. If you want to keep "width=" as the minimum width over the way, and then add the other things, then I don't see that as really helpful in the grand scheme, but I don't see it as harmful. I expect very few circumstances where it is appropriate, almost no one to tag them, and almost no routers to implement it. Have to you talked to people that implement and maintain routers? What is their opinion about adding support for this proposal to their routers? What did they say about redefining width to be average rather than minimum? Have you prototyped a router that does this? How did it work? I think it would be great if you represented width better using the existing scheme, and experimented with width-sensitive routing. I think it would be fine for you to add the new start/end tags yourself on some roads near you and experiment with that. So I don't mean to sound all negative. I just don't see that we have evidence that this is going to make sense in the overall ecosystem. Greg _______________________________________________ Tagging mailing list [email protected] https://lists.openstreetmap.org/listinfo/tagging
