[Tagging] Mapping nonexistent paths
Bert -Araali- Van Opstal
bert.araali.afritastic at gmail.com
Tue Mar 23 12:44:56 UTC 2021
Thanks for this example, it gives us the opportunity to look at it from
the perspective of what we have, and how this can be used, even if it is
for the renderer.
If you allow me I like to clarify in relation to a very similar
situation, a large junction with the same number of six streets, no lane
markings, as we have thousands across the world, where vehicles cross
this big asphalt surface as they please or guided by a traffic officer,
mostly taking the shortest route.
On 23/03/2021 14:14, Sinus Pi wrote:
> Take a large plaza with, say, six different streets entering. In
> practice, the whole area is open for pedestrians, so they'll cross it
> however they please, probably taking the shortest routes between
> streets. What choices are there to make a router's job easier?
> - Draw a "spider" of streets, connecting at the center of the plaza:
> easiest for routers, horrible for renders.
Yes, easy for router. Horrible for a renderer ? I am not so sure. What
is the intend or purposes of the renderer: render routes or mimic a
satellite imagery ? Or both ? If the surface of the square is mapped, it
looks awful if you want to mimic imagery. However if the square is not
mapped as an area, it will look even more awful because the renderer
will show a big void in between our six streets. Is a "virtual" tag
going to solve this, no. Because in either situation the routes are
equally virtual, as in our standard tagging. The renderer should check
if the area containing the routes is available in OSM to make that decision.
On my junction example it's exactly the same. It also looks horrible if
you try to mimic imagery. However, although not commonly practised, we
have landuse and landcover tags to map the areas occupied by highways
and junctions. So for a router, no need for additional info, for a
renderer, look for the area to decide if you want to render the route or
> - Rely on the plaza shape to be routable: line-of-sight optimization
> is supported by some routers, so the dreaded around-the-perimeter
> routing isn't the only way, but it could take ages for routers to
> adopt a proper algorithm.
> - Draw virtual highways: easiest for routers, but now the renders
> would have to know not to draw them.
I think this is addressed in my answer above. Adding a tag "virtual"
will not address this rendering problem, in the contrary, will create a
lot of voids in the rendering. A renderer that wants to mimic imagery
only must look at areas, a rendering serving both routing and physical
appearance should render both. In that case it would be easiest for the
renderer to just adopt the "organised" highways provided by OSM, being
it spider or a seperate highway tagged way along the perimeter.
> As for Bert's approach, that ALL highways are essentially virtual the
> way we use them - it's one thing to draw a line along a street,
> resembling it in real world pretty accurately, and another to draw a
> virtual river across a lake or a canal across a sea, resembling a
> route that doesn't physically exist at all.
I completely disagree.Most rivers and canals are very distinguishable
physical ways. Visible on the water with buoys, under water by dredging,
deeper "canals" by use, river flows into the lake with deeper areas ,
avoiding fishery zones etc.. It's not that their is some water on the
surface instead of air that you can't recognise it. On clear water
lakes these routes are even very distinguishable on satellite imagery.
Can be perfectly mapped without a virtual tag, because waterway is for
mapping virtual routes. Rivers wide or small, map the waterway along the
deepest part of the river.
So, still my conclusion: what we have works fine, both for the renderer
and the router, what you propose has no added value, in the contrary
will cause even more complexity for a renderer.
> On Tue, 23 Mar 2021 at 11:37, Bert -Araali- Van Opstal
> <bert.araali.afritastic at gmail.com
> <mailto:bert.araali.afritastic at gmail.com>> wrote:
> I am sorry but I am still not seeing the advantage or added value
> to introduce keys or values to indicate that something is "less
> visible" or "less verifiable" or virtual or whatever you call it.
> I can't fit it in the model that exists in my mind how we map
> things, especially ways in OSM.
> All highways, all their connections, all rivers are virtual in
> OSM, all routes are virtual. We map them by drawing and connecting
> ways across surfaces. A pavement that stops "early" doesn't mean
> the path, the route people walk stops there. That is insufficient
> completeness in the mapping. Every highway or lane is mapped with
> a "virtual" line in the middle, the "virtual" route people or
> vehicles follow across a surface, be it asphalt grass or whatever.
> Ferries and boats move across a lake on "virtual" routes, they
> just follow a path on the water surface, in many cases not aligned
> by buoys or other means.
> The same for coastlines, the "virtual" coastline is where the
> median is between the salt and fresh water. In cartography many
> times just a straight line. You want to indicate the river
> connects to the water body and which route boats or ships follow,
> you map it, with our present complete "virtual" waterway schemes.
> I still have to see the first example where that doesn't apply or
> is not described nicely in our wiki.
> What does adding an additional tag add to this concept ? Makes it
> more complex to the mapper, because he has to add a tag for
> something considered more virtual in an already virtual scheme ?
> What is the added value for the mapper, I see none.
> What is the added value for the router ? I can't imagine even
> one? Do you think routers will evaluate the virtual tag, no they
> just look at the ways, the routes in general that are already
> there. Knowing that it is perceived as more virtual by some has
> no added value for the router.
> For the renderer, other data users ? Any added value for a virtual
> or invisible tag in comparison with what we already have ? I can't
> find any.
> Please show me an example where the current tagging would be
> considered less favourable to be used as is ?
> So, thank you for making this proposal, you made some nice
> examples which we could maybe add to the highway page. But it's
> just examples how OSM provides a bright and consistent way to map
> complex realities and behaviour, AS IS. It works, use it as
> intended, don't make it more complex by adding tags without added
> Bert Araali
> On 23/03/2021 12:38, Martin Koppenhoefer wrote:
>> sent from a phone
>>> On 23 Mar 2021, at 10:23, Niels Elgaard Larsen<elgaard at agol.dk> <mailto:elgaard at agol.dk> wrote:
>>> Can anyone give an example of such a sophisticated router available to OSM users?
>> the routers don’t have to be sophisticated if you connect highways to polygon highways, it’s sufficient for most cases to route around the borders (will be a little bit longer, but mostly not have practical consequences for the suggested route)
>> Cheers Martin
>> Tagging mailing list
>> Tagging at openstreetmap.org <mailto:Tagging at openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/tagging <https://lists.openstreetmap.org/listinfo/tagging>
> Tagging mailing list
> Tagging at openstreetmap.org <mailto:Tagging at openstreetmap.org>
> Tagging mailing list
> Tagging at openstreetmap.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tagging