[Tagging] no_u_turn restrictions for every entry/exit into a roundabout when the way is split because of physical separation?

[Kevin Kenny]

On Fri, Apr 6, 2018 at 9:36 AM, Martin Koppenhoefer
<dieterdreist at gmail.com> wrote:
> defaults on areas are complicated because you can have an infinite number of them and while inheriting them in a routing db might be “easy” (unless they are contradicting), they are not directly visible on the elements they affect, hence troubleshooting could become a nightmare.
>
> We are already mapping “defaults” explicitly for example with maxspeed according to context.

Youŕe right that it's important to consider the effect of defaults on
troubleshooting, and Bryan is right about considering what they do to
runtime performance.

There's a naturat tension in play here. On the one hand, we want to
have a fully normalized representation wherein each fact about the
world is represented Once and Only Once. That's what database
theoreticians ordinarily advise, and that's what usually gives the
most robust results in practice. It is impossible for a fact that is
recorded Only Once to become inconsistent. On the other hand,
traversing a large and complex web of related facts can, both for
performance and for troubleshooting, become rather nightmarish.

The compromise that's often adopted is to have a second, operational
database, updated periodically or incrementally from the normalized
one. Inhorrible it, data can be denormalized for performance, recorded
redundantly so that they're physically associated with other data for
the same application objects, and otherwise represented for
convenience. The PostGIS rendering database on the main OSM site is a
good example of this. For instance, the renderer doesn't, for the most
part, see relations - routes are renormalized to linear features,
multipolygon relations are flattened to multipolygons with ways
duplicated as needed, tags on relations devolve into attributes of
their elements, and so on. It's not the master data model, and it
invites inconsistencies, but the master representation is simply too
slow and inconvenient to render from.

I would imagine that a router in practice would construct a similar
denormalized view of the data. The association with area labels and
the contained ways would happen as the operational database is created
or updated. It's not that hard to imagine a toolchain akin to the
osmosis/osm2pgsql combination that could accomplish this.task, and
with GIST indices and the like, it's surely not impossible to
construct one. In fact, I'd be moderately surprised if the available
routers aren't in part driven off this sort of auxiliary data store.
The query, "please return me aOn Fri, Apr 6, 2018 at 9:36 AM, Martin
Koppenhoefer
<dieterdreist at gmail.com> wrote:
> defaults on areas are complicated because you can have an infinite number of them and while inheriting them in a routing db might be “easy” (unless they are contradicting), they are not directly visible on the elements they affect, hence troubleshooting could become a nightmare.
>
> We are already mapping “defaults” explicitly for example with maxspeed according to context.

Youŕe right that it's important to consider the effect of defaults on
troubleshooting, and Bryan is right about considering what they do to
runtime performance.

There's a naturat tension in play here. On the one hand, we want to
have a fully normalized representation wherein each fact about the
world is represented Once and Only Once. That's what database
theoreticians ordinarily advise, and that's what usually gives the
most robust results in practice. It is impossible for a fact that is
recorded Only Once to become inconsistent. On the other hand,
traversing a large and complex web of related facts can, both for
performance and for troubleshooting, become rather nightmarish.

The compromise that's often adopted is to have a second, operational
database, updated periodically or incrementally from the normalized
one. Inhorrible it, data can be denormalized for performance, recorded
redundantly so that they're physically associated with other data for
the same application objects, and otherwise represented for
convenience. The PostGIS rendering database on the main OSM site is a
good example of this. For instance, the renderer doesn't, for the most
part, see relations - routes are renormalized to linear features,
multipolygon relations are flattened to multipolygons with ways
duplicated as needed, tags on relations devolve into attributes of
their elements, and so on. It's not the master data model, and it
invites inconsistencies, but the master representation is simply too
slow and inconvenient to render from.

I would imagine that a router in practice would construct a similar
denormalized view of the data. The association with area labels and
the contained ways would happen as the operational database is created
or updated. It's not that hard to imagine a toolchain akin to the
osmosis/osm2pgsql combination that could accomplish this.task, and
with GIST indices and the like, it's surely not impossible to
construct one. In fact, I'd be moderately surprised if the available
routers aren't in part driven off this sort of auxiliary data store.
The query, "please return me all the traffic relations containing (or
intersecting) this way" isn't all that bad if it's done once when a
way is updated, but it would be horrible if it had to be done every
time a router considers the possibility of traveling on that way.

Of course, as soon as one raises the possibility of an auxiliary data
store, the possibility arises of updating it from sources other than
OSM, and that OSM is the wrong place for the data. It seems, however,
that both data producers and consumers seem to think that traffic
restrictions are properly within OSM's ambit. If we can design an
appropriate operational data store, and describe how it would be
updated as the main OSM database changes, even notionally, I think
that would be a major step for deciding how to structure the tagging.

It could be that the technical work of arriving that that notional
design might all be for naught, because it is, of course, possible
that the broader community will reject it as being outside the scope
of the project. I suspect, however, that most of the objections
revolve around feasibility - people think that this information is out
of scope for OSM chiefly because they believe that the data model
cannot represent it properly, or that the representation will be too
awkward to be useful to mappers, renderers and routers. In such a
case, very few arguments work better than a feasibility study.ll the
traffic relations containing (or
intersecting) this way" isn't all that bad if it's done once when a
way is updated, but it would be horrible if it had to be done every
time a router considers the possibility of traveling on that way.

Of course, as soon as one raises the possibility of an auxiliary data
store, the possibility arises of updating it from sources other than
OSM, and that OSM is the wrong place for the data. It seems, however,
that both data producers and consumers seem to think that traffic
restrictions are properly within OSM's ambit. If we can design an
appropriate operational data store, and describe how it would be
updated as the main OSM database changes, even notionally, I think
that would be a major step for deciding how to structure the tagging.

It could be that the technical work of arriving that that notional
design might all be for naught, because it is, of course, possible
that the broader community will reject it as being outside the scope
of the project. I suspect, however, that most of the objections
revolve around feasibility - people think that this information is out
of scope for OSM chiefly because they believe that the data model
cannot represent it properly, or that the representation will be too
awkward to be useful to mappers, renderers and routers. In such a
case, very few arguments work better than a feasibility study.