On Fri, Apr 6, 2018 at 9:36 AM, Martin Koppenhoefer <dieterdre...@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 <dieterdre...@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. _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
