Automated edits/Os-emmer
This page describes automated edits done or proposed by me.
Mechanical edit to correct addr:country=* to be ISO 3166-1 alpha-2
This mass edit was not yet executed. It is just a proposal. See here for discussion: https://community.openstreetmap.org/t/mechanical-edit-proposal-to-correct-addr-country-to-be-iso-3166-1-alpha-2/129569/1
Rationale
The wiki-page for addr:country=* is quite short but still clear. The value of addr:country=* should be the country-code according to ISO 3166-1 alpha-2. That means “DE” for Germany, “US” for the United States of America, “FR” for France and so on. These codes are always two-letters long and always uppder case. Instead of this correct use I noticed repeated occurances of clear but different values. That can be the whole name of the country in any language (addr:country=Germany, addr:country=Deutschland, ...) or inofficial/different abbroviations (addr:country=DEU, addr:country=de, addr:country=ger, ...). While some people argue that addr:country=* is redundant anyways and should be removed, others think that it is harmless or even useful. I just think that if we have addr:country=* in OSM we should use it in a unified way as described in the wiki.
Which objects?
Every object that has addr:country=* with a value not matching ISO 3166-1 alpha-2 if the following is the case:
- It is absolutely clear what the value of
addr:country=*means. That is the case when it contains the full name of the country in any language or a different but still clear abbroviation. - The meaning of the
addr:country=*-value is plausible. That is the case when the obviouse meaning of the value inaddr:country=*matches the location of the object.
What to cahnge?
Update addr:country=* to the correct coutry-code according to ISO 3166-1 alpha-2. The edit will be split into local changesets.
When to execute?
The edits will not be executed automatically but only manual. I will reexecute the edits any time I notice that similar mistakes reappear in the database and I feel the need to do so.
Discussion
Mechanical edit to remove squad=*
This mass edit was not yet executed. It is just a proposal. See here for discussion: https://community.openstreetmap.org/t/massenanderungsvorschlag-zur-loschung-von-squad/110531
Rationale
It seems that the key squad=* was intended to document the sub-units located in stations of the German Technisches Hilfswerk (THW). The arguments for removing this data are:
- The key is undocumented:
- No one knows what data exactly to store in this tag
- No one knows if this key is exclusive to the THW or if other organisations could possibly use this tag too
- The data is wrong:
- "Fachgruppe Bergung" (4x) never existed and is porbably a typo for "Bergungsgruppe"
- "Fachgruppe Notinstandsetzung” (1x), “Fachgruppe Notfallinstandsetzung” (1x) are both not existing, probably a typo for “Fachgruppe Notversorgung und Notinstandsetzung"
- The data is outdated:
- “Fachgruppe Beleuchtung” (38x) stopped existing years ago
- "2. Bergungsgruppe” (4x) stopped existing years ago
That makes the data unusable.
Which objects?
Every object tagged with squad=* and operator=Bundesanstalt Technisches Hilfswerk.
What to change?
Remove squad=* without an replacement.
Discussion
https://community.openstreetmap.org/t/massenanderungsvorschlag-zur-loschung-von-squad/110531
Mechanical edit to remove grouping relations of the German Technisches Hilfswerk (THW)
Rationale
The administrative structure of the Technisches Hilfswerk is currently mapped using the keys thw:rb=*, thw:lv=* and thw:ltg=*. "rb" is short for "Regionalbereich" (regional area), "lv" is short for "Landesverband" (state area) and "ltg" is short for "Leitung" (Leading). The organigramm of the THW explaining this structure can be found on this official webiste:
https://www.thw.de/DE/THW/Organisation/Bundesanstalt/Organigramm/organigramm_node.html
Additionally to these tags there are grouping relations:
https://www.openstreetmap.org/relation/1595756
They are redundant and outdated/wrong. The overall data quality in OSM would be better without these relations.
Which objects?
The relation representing the THW and the included ones for the "Landesverbände" and the "Regionalbereiche".
https://www.openstreetmap.org/relation/1595756
What to change?
Delte the relations defined above.
Discussion
Execution
The mechanical edit got executed with changeset 148519351. In total 75 objects got edited.
Mechanical edit to unify operator-information about the German Technisches Hilfswerk (THW)
Rationale
There is inconsistency in the operator=* of objects with context of the "Bundesanstalt Technisches Hilfswerk". "Bundesanstalt" means "Federal Agency". A poll in the German forum brought us to the consensus that objects of this organisation should be tagged operator=Bundesanstalt Technisches Hilfswerk and operator:short=THW (operator:short_name=* in the poll was a typo). Currently most of the objects use operator=Bundesanstalt Technisches Hilfswerk (THW) including the abbreviation. The operator:wikidata=* is often missing.
Which objects?
The mass edit includes all objects using operator=Bundesanstalt Technisches Hilfswerk (THW), operator=Bundesanstalt Technisches Hilfswerk and operator:wikidata=Q697698. The can be found with this overpass-turbo query:
[out:csv(::type, ::id, "name", "amenity", "emergency", "emergency_service", "operator", "operator:short", "operator:wikidata";",")][timeout:25];
(
nwr["operator"="Bundesanstalt Technisches Hilfswerk (THW)"];
nwr["operator"="Bundesanstalt Technisches Hilfswerk"];
nwr["operator:wikidata"="Q697698"];
);
out meta;What to change?
Set the tags as followed:
The only thing that gets overwritten is operator=Bundesanstalt Technisches Hilfswerk (THW). operator:short=* and operator:wikidata=* has no entrys different from the above meantined.
Discussion
Execution
The mechanical edit got executed with changeset 148437780. In total 909 objects got edited.
Mechanical edit to apply emergency=disaster_response to stations of the Australian State Emergency Services (SES’es)
Rationale
A few weeks ago a wiki proposal for tagging of disater response organisations was accepted, see here . The wiki page can be found here. In the past, the stations of the Australian State Emergency Services were tagged with emergency=ses_station. The proposal aimed to change this to emergency=disaster_response. Some of the stations are already retagged, but there are still over 200 missing.
Which objects?
All SES-Stations in Australia that are tagged with emergency=ses_station and have a name=* or operator=* including "SES" or "State Emergency Service". They can be found with this overpass-turbo query:
[out:json][timeout:25];
{{geocodeArea:Australia}}->.searchArea;
(
nwr["emergency"="ses_station"]["operator"~"(SES|State Emergency Service)"](area.searchArea);
nwr["emergency"="ses_station"]["name"~"(SES|State Emergency Service)"](area.searchArea);
);
out geom;
out count;What to change?
Remove emergency=ses_station. Add emergency=disaster_response as a replacement.
Discussion
Execution
The mechanical edit got executed with changeset 146793335. In total 224 objects got edited.
Mechanical edit to apply emergency=disaster_response to stations of the German Technisches Hilfswerk (THW)
Rationale
Recently a wiki proposal for tagging of disater response organisations was accepted, see here. The wiki page can be found here. As of now, there already is a big amount of data for the Germen Technisches Hilfswerk (THW) in OSM. The “Ortsverbände” (local stations) of the Technisches Hilfswerk (THW) now need to be changed according to the new scheme.
They are currently tagged as amenity=emergency_service or emergency_service=technical. Sometimes one of these tags is used, sometimes both. There is de facto no difference in the meaning of these two tags when they are applied to an object of the German THW. The proposal aimed to apply emergency=disaster_response to all local stations of the German THW as a replacement for the two tags meantined before. There are 668 “Ortsverbände” of the THW, see here.
Which objects?
All "Ortsverbände" of the German THW using amenity=emergency_service, emergency_service=technical or both. They can be found with this overpass-turbo query:
[out:json][timeout:600];
(
nwr["amenity"="emergency_service"]["operator"~"(Bundesanstalt Technisches Hilfswerk (THW)|Bundesanstalt Technisches Hilfswerk)"]["name"~"THW Ortsverband"]["ref:thw"~"O[A-Za-z0-9]{3}"]["thw:rb"]["thw:lv"];
nwr["emergency_service"="technical"]["operator"~"(Bundesanstalt Technisches Hilfswerk (THW)|Bundesanstalt Technisches Hilfswerk)"]["name"~"THW Ortsverband"]["ref:thw"~"O[A-Za-z0-9]{3}"]["thw:rb"]["thw:lv"];
);
out geom;
out count;The query uses these filters:
amenity=emergency_service/emergency_service=technicalto find relevant facilitysoperator~(Bundesanstalt Technisches Hilfswerk (THW)|Bundesanstalt Technisches Hilfswerk)to make sure only facilitys of the right operator are editedname~THW Ortsverband,ref:thw~O[A-Za-z0-9]{3}to only find the right kind of facility. The THW also runs facilitys that are only administrative and should not getemergency=disaster_response.thw:rb=*,thw:lv=*these tags are de facto used to implement the administrative structure of the THW into OSM. Filtering for them makes mismatches less probably.
What to change?
Remove amenity=emergency_service and emergency_service=technical. Add emergency=disaster_response as a replacement.
Discussion
Execution
The mechanical edit got executed with changeset 146793335. In total 661 objects got edited.
Mechanical edit to clean up street=* tag
Analysis of the usage
The tag street=* is used over 3500x despite being undocumented. According to addr:street=* it is a possible tagging mistake. Here is an overpass-query showing all elements with street=* and here is an overpass-query generating a corresponding table.
I did some analysis of the usage of street=*. The 3670x total uses are distributed as followes:
- 2844x
street=*is set butaddr:street=*is not set. - 206x
street=*andaddr:street=*are both set but have different values. - 620x
street=*andaddr:street=*are both set and have the same value.
Interpretation and solution
- For 1. most of the time
street=*is probably a synonym foraddr:street=*but as there is also for examplestreet=yes(89x) this can't be mechanically edited. For this I plan to create a MapRoulette-Chalange for checking everything by hand. - For 2. manual checks are necessary to determine the situation and what to do. For this I plan to include it into the MapRoulette-Chalange for checking everything by hand.
- For 3. ther can be an automated edit. This mechanical edit will remove
street=*from every object, whereaddr:street=*stores the same value.
Example
| object before edit | object after edit |
|---|---|
building=house
|
building=house
|
addr:housenumber=28
|
addr:housenumber=28
|
addr:street=Finsbury Park Avenue
|
addr:street=Finsbury Park Avenue
|
street=Finsbury Park Avenue
|
Discussion
The mechanical edit got discussed here:
https://community.openstreetmap.org/t/mechanical-edit-proposal-to-clean-up-street-tag/107515/17
Execution
The mechanical edit got executed with changeset 145806155. In toal 620 objects where edited.
Mechanical edit to clean up obvious typos in area=* tag
This edit has not been done and will not be done. Instead the clean up was done manually. See the discussion for details.
The only 2 documented values of the area=*-tag are yes and no. According to taginfo they make up about 99,7% of all uses of area=*.
As of now there are about 70 values where an area=yes got mearched with another tag, probably on accident. Here are some examples:
| Tag | number |
|---|---|
| "area"="yesaccess=private" | 12 |
| "area"="yesarea=yes" | 10 |
| "area"="yesaddr:housenumber=19" | 9 |
| "area"="yesamenity=parking" | 5 |
| "area"="yesfarmland=pasture" | 5 |
| "area"="yesaddr:housenumber=31" | 1 |
You can find these values in taginfo by searching for "yes".
As these tags are obviously typos I propose to do a mechanical edit to change tags like "area"="yesaccess=private" to "area"="yes" + "access"="private".
If the tag included in the value of area=* is already set to a different value I will not do an mechanical edit. For these objects I may message the original editor, add a fixme=* or open a note to resolve the confict.
In case I notice that tags like this reappear in the future I propose to repeat this cleanup.