Use of associatedStreet relations in Australia appears to be largely dead. Of the 633 relations in Australia, only 12 were created in the last 8 years! Most of them appear to be completely unmaintained - I’ve run into a few cases where mappers simply aren’t aware of them when dragging POIs for businesses that have moved, and half of the relations don’t actually have any objects other than streets in the relation.
Any thoughts on:
“officially” deprecating use of associatedStreet relations in Australia
making a mass edit to remove the 313 relations that only have streets as members
Just for interest I had a look at who has created a type=associatedStreet relation in AU during the last 10 years:
User
Count
Davie Dean
12
Chickenbok77
10
aharvey
8
Lockstar
6
lumacraft
6
jbhh12
4
radiotrefoil
3
dle0
1
Evad37
1
jxeeno
1
luiseih
1
RichieRRR
1
TheSwavu
1
@aharvey@Lockstar and @2hu4u will see this post. Chickenbok77 has 11 changesets in total and was only active for 7 days. lumacraft and jbhh12 are FR and DE based mappers. Which leaves David, who was active on talk-au so may get covered by the cross posting I did there.
I have no objections to this. I created a few back in the early days but I’d suspect any I’ve touched more recently have just been edits of existing ones.
I was quite fond of the concept back in the day, the idea that you don’t need to duplicate the street name as a tag for every address (which based on what I learnt from my uni computing courses that you should avoid duplicating code and instead put it in a shared function, and leaving magic values around and instead using a named constant), the approach also provides a neat way to link addresses to the street geometry without needing to do a string match in combination with a spatial nearby operation.
However overtime it’s become clear that addr:street tags have become the standard.
I’m okay to for addr:street tags to be added for those addresses which lack the tag, but which get it from the associatedStreet relation, but I don’t see any harm in leaving the relations there, but if the consensus prefers to remove them, we can.
The ones that only have streets were likely done as a way to group all the ways of a street together, which at one point could have been used as a way to place common tags on the relation rather than each segment, but again that approach isn’t favoured these days and relying on joining ways based on a common name=* seems to be the way to go.
I agree that they are relatively harmless and could probably be left to exist, but all of these relations are practically unmaintained.
Most of these relations are in Brisbane, and the user who did the 2018 Brisbane Address Import appears to have deleted most existing address nodes, breaking these relations. 289/303 currently existing empty street relations are in Brisbane. (I have already started cleaning up the areas that only have a few associatedStreet relations. There used to be 313)
Interestingly, I’ve just discovered that there is a similar kind of street relation that has similar use in Australia: taginfo, wiki - I’m not going to suggest these should be deleted as I haven’t run into issues with these (haven’t even noticed them!), and only one street relation has no address/house members.
I have now removed all empty associatedStreet relations (297) in changeset/186326704.
To assist with cleaning up remaining relations that have houses (227), I’ve developed a script that will add addr:street to house members if the relation is valid, which I will then load into JOSM and check against nearby data to make sure I’m not creating duplicate addresses (e.g. in Brisbane). This will be done in small areas to review individually instead of all at once.
I believe these relations are intended to represent the street itself, though maddeningly the street relation type is documented as essentially a synonym of associatedStreet. There’s even a proposal to extend it to serve as a relation-based replacement for is_in=* and, uh, “is near”. It’s enough of a problem that this is the only relation type that OpenHistoricalMap has forked so far, with the hope that OSM will someday abandon the more overwrought ideas about it.
I support the proposal. If these relations are largely unmaintained and current tagging practices already rely on addr:street, simplifying the data model seems reasonable. A well-documented mechanical edit with clear validation and an opportunity for community review should help avoid unintended issues.
There are a fair few that don’t seem to be doing anything more than what can already be done by just matching on street name, but at least they’re not messing with addresses I guess.
Using relations to link up road geometry purely to add a wikidata tag seems kind of strange/overcomplicated to me - the wikidata tag could have just been added directly. It looks like one of the relations discussed in that topic has been removed while another mapper made some changes, simply copying the wikidata tag directly to the road.
An interesting one is Relation: Roghan Road (18488584) | OpenStreetMap, I’m not sure what this relation is doing beyond linking roads that have the same name - which a data consumer could already do if it wanted.
(I’m not suggesting these are so problematic that they should be removed, just they’re unusual)
Yeah, OHM only adopted street relations (modeling the whole street but only the street as a single relation) because of the time dimension. It’s a necessary alternative to mapping the whole street multiple times over just because the name changed. (JOSM users particularly detest overlapping ways.)
I’ve been made aware that Australia also has cases of houses with extremely long driveways so that the house is very far way from the street it takes its address from. It might be useful to have an exception for these cases an use associatedStreet relations for making the explicit connection between house and far-way street.