On Fri, 24 Apr 2020 at 10:05, Martin Koppenhoefer <dieterdre...@gmail.com> wrote:
> Am Do., 23. Apr. 2020 um 17:14 Uhr schrieb Paul Allen <pla16...@gmail.com > >: > > >> I've had to fix enough addresses >> (mainly incorrect postcodes but sometimes incorrect or missing >> street names and even cities) that having the same information >> in two places is undesirable. >> > > may depend on the kind of problem. For postcodes the situation may be > different than for housenumbers? > They're pretty much the same from the perspective of duplicated data. If it's wrong in two places there's a strong possibility that only one will get fixed. If it's noticed at all. In my context, it is also quite common to have distinct housenumbers like 1 > and 3 and 5, each as a node, each assigned to entrances that lead into the > same shop, while the business uses either an address by choosing one of > them (maybe the actual entrance, but maybe the entrance it used to use > years ago) or more commonly an address like housenumer=1-5 (or 1/3/5) or in > OSM syntax 1;3;5 > I've mapped a few of those. Separating walls were removed in most of them, leaving what I mapped as a single larger building. I could have mapped the address chosen by the business but instead went with 13-14 so that people wouldn't wonder why the sequence of house numbers was 12, 14, 15 (yes, they're all on the same side of the road). As for postcodes, it is a bank so it has its own individual postcode (assigned back in the days when there was no electronic funds transfer so banks received a lot of cheques for verification and clearance). Two house numbers applying to a single business in a case like that is not really a factor in deciding whether to use a single object for building and business, two coincident objects or a building with a node. More of a problem is when buildings get subdivided and retain the same address. I handled that as a building with two nodes, mainly to avoid somebody later assuming one of the addresses of two adjacent buildings was wrong. > > >> The more so when that same >> information is on coincident polygons that iD makes hard to >> manipulate, or even notice. >> > > let's not discuss the problems of individual software solutions, they will > adapt sooner or later. > Until they do then many mappers will tag things in the way that the software solution makes easiest. That's human nature. If we insist there is only one correct way to do it, and that the one correct way is very hard to achieve in a widely-used software solution, people will either do it a different way (contrary to our desires) or stop mapping. > When there are polygons with coincident information, there is not issue, > when they are different, it may indicate either a data problem (error) or > the node tags will override the polygon defaults. It is not completely > clear, both interpretations are around. > The problem is that, with one software solution, fixing those types of errors is hard. In fact, with that solution you may not even notice the discrepancy exists: if you want to change the business and you get the tags for the business when you click on the coincident objects then you won't see the different details of the coincident building. Until that changes, insisting on coincident objects is likely to result in data inconsistencies. > >> But there are cases where using a node rather than a building (not just an >> area but a building=*) for a POI means the name doesn't get rendered. >> Clubs >> and crafts, for example. >> > > it doesn't matter, as it is just refering to a single piece of rendering > software. Everybody can display any name they like. > But one particular rendering is intended for use by mappers to check their work. If something isn't displayed in that rendering then some mappers will find an alternative (but still valid) way of tagging the item. Purists will throw up their hand in horror, but that's the reality. > > That's just another reason why people tag the same object as both a >> building >> and a business rather than making it two objects. It makes clear that >> there is >> a relationship between the two rather than it possibly being an accident. >> > > problem is that the kind of relationship they are modelling (identity) is > incorrect. > >From the perspective of a purist, that is correct. From the perspective of a pragmatist, working with the tools we have right now, that's something that can be dealt with at a future time when we have better tools. I think the pragmatists outnumber the purists. I've tried not to advocate that any particular approach is the one correct way to do it. I'm arguing that, with the tools we have, there are alternatives with pros and cons. In an ideal world there would be one single method that handles all situations perfectly. We live in an imperfect world. -- Paul
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging