Am So., 30. Sep. 2018 um 05:01 Uhr schrieb Bryan Housel <bhou...@gmail.com>:
> On Sep 29, 2018, at 6:56 PM, Paul Johnson <ba...@ursamundi.org> wrote: > > I honestly don't understand why, ten years since it's introduction as > OSM's third basic primitive, there's still this weirdly unnatural aversion > to relations, even though they're quite a powerful primitive in our toolbox. > > > From my own perspective as the main developer on the main editor for OSM, > the reason I don’t like relations very much is because: > - every type of node basically works the same. > - every type of linear way basically works the same. > - every type of polygonal area basically works the same > *- every type of relation is an edge case that requires special code in > order not to break. * > > This is somehow misrepresenting the status quo, in particular as there is no such thing as a "polygonal area" or a "linear way" object type. Not sure what "type of node" means, is this to be read as differently tagged nodes, or nodes in different context? A node on a way has different implications than a POI node inside a polygon, than an isolated tagged node without an enclosing polygon for instance, or place areas within a place node inside (this is currently discussed) might have to be treated differently than place ways where no place node is inside. Ways can be either linear objects or polygonal features, and we can only guess about this, or rely on explicit area=yes/no tagging in the few cases where it is present (980 561 times on ways, or 0.2%, one third of them in combination with highways), linear ways with direction dependent tags (retaining wall, coastline, oneway, incline, forward/backward/left/right ....) have to be treated more complexly than those ways without them, etc. Yes, every type of relation is a new datatype (with some being very similar, like multipolygons and boundary relations), but all of those which are widely in use, are required to map a certain kind of thing. Unlike the interpretation of nodes and ways which is more complex than what it might seem at first glance, the interpretation of relations seems more straightforward because they are explicit about how they should be read (tag "type", roles) and they are taylored around the specific usecase for which they are intended. I would expect from any editing software that aims to be an universal OpenStreetMap editing tool, that it strives to handle (at least) the most used relation types reasonably well, or has good arguments why it doesn't for a specific type. For reference: https://taginfo.openstreetmap.org/keys/type#values multipolygon restriction route boundary associatedStreet public_transport site destination_sign waterway route_master > > Anyway, I’m not totally against them, but every one of them is different > and I can't spend weeks or months supporting every kind of relation or > public transport schema people dream up unless it’s super critical for > building a useful map (like turn restrictions). They are really best for > features that can not be mapped any other way. > Yes, relations should only be used to map relationships that otherwise cannot be represented. And of course nobody is asking you to implement all of these on your own. Cheers, Martin
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
