> --> need to add all driveways? This is generally a good idea - and to make sure they share a node.
> --> need to draw virtual crossings at junctions? These aren't totally artificial/virtual. You can consider them 'unmarked crossings' and there's already tags on the wiki: highway=footway, footway=crossing, crossing=unmarked. Most, but not all, 'weird' routes can be avoided by adding unmarked crossings. One exception is routing between two POIs on opposite sides of the street, but: - This is not a primary use case for end user routing. If foot traffic can reasonably be expected to cross anywhere and it's just across the street, the end user can figure out their actual path easily. Users that aren't comfortable figuring out that path should most likely not be crossing at arbitrary locations, and would prefer crossing at junctions (and preferably marked crossings). - Routers can always fall back to using streets / ignoring footways for short distances. Routers that bake costs into their graph will need to create an extra graph, but that's an inherent limitation for extending that approach. > Throwing out the R word here - what about a relation that defines > which disconnected ways could be walked to or across from any point on a > current way? That would also include the road since there would be no > barrier. This is potentially tricky and should probably go in its own thread eventually (OpenSidewalks people and I have been meaning to do a good overview and RFC related to it). Example: - The left side of the street has 1 sidewalk line (sidewalk A) - The right side of the street has 2 sidewalk lines (sidewalks B, C), split right in the middle of the block Drawing: AAAAAAAAAAAAAAAAAAAA --------------------------------------- BBBBBBBBBCCCCCCCCCC I think this would imply needing 2 relations. And if the relation only contains the info 'sidewalk A', 'sidewalk B', 'street', the simple interpretation implies that one can always get from sidewalk A to sidewalk B via the street. However, not all crossings from A to B are orthogonal: the diagonal crossings may be impractical. So routers will need to incorporate spatial logic as well, essentially just adding unmarked crossings at various points. Totally doable, but not super simple, either, and that strategy doesn't actually require the relation.e A natural reaction is to revert to treating sidewalks as metadata of streets, but this is no good for accessible routing, and is also not a good description of the pedestrian transportation network. But for the most part, I have yet to see an example of a really bad route when unmarked crossings are added at appropriate locations. On Fri, Jul 14, 2017 at 6:50 AM Marc Gemis <marc.ge...@gmail.com> wrote: > Another typical case > > - no explicitly marked crossings > - sidewalk parallel to road > - kerb separating sidewalk from road > - hedge, interrupted for each driveway and at the junctions, placed on > sidewalk, parallel with road. > > --> need to add all driveways ? > --> need to draw virtual crossings at junctions ? > > m > > > On Fri, Jul 14, 2017 at 3:41 PM, Mike N <nice...@att.net> wrote: > > On 7/14/2017 8:14 AM, Marc Gemis wrote: > >>> > >>> but merge sidewalk with the road where the is no space/barier between > >>> them. > > > > > >> and that's were the discussion starts. When I asked when one has to > >> draw a separate sidewalk a few weeks ago on this mailing list someone > >> answered: as soon as there is a kerb. > > > > > > Similarly, I have been combining sidewalks with roads where there is no > > separation. But when there is a small grass separation from the > roadway, > > they are drawn separately. For those cases, it is usually allowed to > cross > > the grassy separation and the road to get to the opposite sidewalk. > > > > Throwing out the R word here - what about a relation that defines which > > disconnected ways could be walked to or across from any point on a > current > > way? That would also include the road since there would be no barrier. > > > > > > > > _______________________________________________ > > Tagging mailing list > > Tagging@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/tagging > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
