On Fri, 24 Apr 2020 at 10:05, Martin Koppenhoefer
wrote:
> Am Do., 23. Apr. 2020 um 17:14 Uhr schrieb Paul Allen >:
>
>
>> 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
