[Tagging] Deprecation of associatedStreet-relations

[moltonel 3x Combo]

On 25/01/2015, Andreas Goss <andig88 at t-online.de> wrote:
> Fully borken or not. In my opinion a assiciatedstreet relation that does
> not include every element is broken. At that point all the advantages
> are gone.

To me "breaking the relation" would mean that all the addresses it
contains are now unusable. In your example you've only broken one
address.

To break all addresses at once, you either have to remove the street
member from the relation, or (in the case of addr:street) rename the
street.

>> * Add a new addr:housenumber but forget/ignore to add addr:street
>> (would be no different with associatedStreet, except the local
>> newbie's work will have been prepared by the armchair veteran)
>
> Why would it have been prepared?

I often do that when I Bing-trace buildings. I consider adding the AS
relation part of my armchair-mapping workflow, unless I know I'll
never survey that particular area and there already are addresses
tagged using addr:street (meaning there's a local mapper there who
prefers addr:street).

> And why with AS but not with addr:street?

It's impossible to add an addr:street tag before you know the name of
the street.

> Most associatedStreet-relations I found in Germany did only
> include houses where someone actually mapped the housenumber. I did not
> find a single one where all houses in a street were included, but lacked
> other addr: tags.

Again, I create such relations and it seems I am not the only one. No
idea of frequent this is, anyone has a good overpass query to measure
this ?

Note that "this house corresponds to this street" is valuable
information even if the house has neither a number nor a name. Also,
in my region (Ireland) it's not rare for housenumbers to be so messy
that I have no idea what number a particular house has, even after a
survey. But I *do* know which street it corresponds to.

>> * Change the name of a street (btw, newbies often use iD and dont know
>> how to search objects by tag). Much more common than you think if you
>> consider street that have not been named yet or that have been split
>> at the wrong spot.
>
> If a street is split several times and a user knows he can find all
> parts in a relation I would no longer consider that user a newbie.

Not sure what you mean here. I was describing an addr:street usecase,
not a relation usecase. And updating all the addr:street after
renaming a street is so easy to get wrong that even veterans can let
an error slip in.

>> The point is not that associatedStreet relations are unbreakable, but
>> that there are less opportunities for breakage than there is with
>> addr:street.
>
> And that's where I disagree. Removing a object for a relations is as
> likely as missing a addr:street tag.

We're all relying on feelings here to figure out what error scenario
is more common and more likely. We're biased by what editors we use,
and by the workflows we're more comfortable with. It's safe to say by
now that both schemes can break pretty easily. But until somebody can
study the actual, world-wide, cross-editor frequency of each failure
modes, I fear we're just not going to convince each other.

> In addition the consequences are
> worse for the associatedstreet relation, because you assume it's
> complete when it actuall isn't, which makes it kinda pointless.

I really don't see a difference here. An incomplete/missing address is
just as bad whatever scheme it was mapped with. Nobody assume a
relation is "complete" just like nobody assume that any data in OSM is
"complete". The QA tools can spot the incomplete address just as
easily in both cases.