User:Valor Naram/validation

There are all the Overpass QL queries that I use for validation and correction of the OSM database. You can add #repairOSM to the changesets that tend to fix objects found by my queries if you decide to use them.

Validations inspired by Babykarte

Badest couples

'diaper' and 'changing_table'

/*
This has been generated by the overpass-turbo wizard.
The original search was:
“diaper=* and changing_table=*”

This checks, if 'diaper' and 'changing_table' keys are both mapped on one object. Both keys are used to indicate that the object provides a facility enabling changing nappies. The 'diaper' key has been deprecated and shouldn't be used anymore. The specification of key 'changing_table' can be found here: https://wiki.osm.org/Key:changing_table
*/
[out:json][timeout:500];
// gather results
(
  // query part for: “diaper=* and changing_table=*”
  nwr["diaper"]["changing_table"]({{bbox}});
);
// print results
out body;
>;
out skel qt;

This checks, if 'diaper' and 'changing_table' keys are both mapped on one object. Both keys are used to indicate that the object provides a facility enabling changing nappies. The 'diaper' key has been deprecated and shouldn't be used anymore. The specification of key 'changing_table' can be found here: https://wiki.osm.org/Key:changing_table . I recommend to remove the 'diaper' key in favor of the more up-to-date 'changing_table' key. An easy to understandable table that shows how to convert the 'diaper' key and its subkeys to the 'changing_table' domain and its subkeys can be found here

'contact:phone' and 'phone'

/*
This has been generated by the overpass-turbo wizard.
The original search was:
“contact:phone=* and phone=*”

This checks, if 'contact:phone' and 'phone' keys are both mapped on one object. Both keys are used to map telephone numbers under which the operator or the staff can be reached. The 'phone' is a historical tag and currently the most used one but is not wanted and shouldn't be used. The specification of key 'phone' can be found here: https://wiki.osm.org/Key:phone
*/
[out:json][timeout:500];
// gather results
(
  // query part for: “contact:phone=* and phone=*”
  nwr["contact:phone"]["phone"]({{bbox}});
);
// print results
out body;
>;
out skel qt;

This checks, if 'contact:phone' and 'phone' keys are both mapped on one object. Both keys are used to map telephone numbers under which the operator or the staff can be reached. The 'phone' is a historical tag and currently the most used one but is not wanted and shouldn't be used. The specification of key 'phone' can be found here: https://wiki.osm.org/Key:phone . I recommend to remove 'phone' in favor of 'contact:phone'. The specification of 'contact:phone' is the same as for 'phone'.

'contact:website' and 'website'

/*
This has been generated by the overpass-turbo wizard.
The original search was:
“contact:website=* and website=*”

This checks, if 'contact:website' and 'website' keys are both mapped on one object. Both keys are used to tag the website address the POI operates. The 'website' is a historical tag and currently the most used one but is not wanted and shouldn't be used. The specification of key 'website' can be found here: https://wiki.osm.org/Key:website
*/
[out:json][timeout:500];
// gather results
(
  // query part for: “contact:website=* and website=*”
  nwr["contact:website"]["website"]({{bbox}});
);
// print results
out body;
>;
out skel qt;

This checks, if 'contact:website' and 'website' keys are both mapped on one object. Both keys are used to tag the website address the POI operates. The 'website' is a historical tag and currently the most used one but is not wanted and shouldn't be used. The specification of key 'website' can be found here: https://wiki.osm.org/Key:website I recommend to remove 'website' in favor of 'contact:website'. The specification of 'contact:website' is the same as for 'website'.

'contact:email' and 'email'

/*
This has been generated by the overpass-turbo wizard.
The original search was:
“contact:email=* and email=*”

This checks, if 'contact:email' and 'email' keys are both mapped on one object. Both keys are used to tag the e-mail address under which the operator or the staff can be reached. The 'email' is a historical tag and currently the most used one but is not wanted and shouldn't be used. The specification of key 'email' can be found here: https://wiki.osm.org/Key:email
*/
[out:json][timeout:500];
// gather results
(
  // query part for: “contact:email=* and email=*”
  nwr["contact:email"]["email"]({{bbox}});
);
// print results
out body;
>;
out skel qt;

This checks, if 'contact:email' and 'email' keys are both mapped on one object. Both keys are used to tag the e-mail address under which the operator or the staff can be reached. The 'email' is a historical tag and currently the most used one but is not wanted and shouldn't be used. The specification of key 'email' can be found here: https://wiki.osm.org/Key:email I recommend to remove 'email' in favor of 'contact:email'. The specification of 'contact:email' is the same as for 'email'.

'contact:facebook' and 'facebook'

/*
This has been generated by the overpass-turbo wizard.
The original search was:
“contact:facebook=* and facebook=*”

This checks, if 'contact:facebook' and 'facebook' keys are both mapped on one object. Both keys are used to map facebook profile urls under which the operator or the staff can be reached. The 'facebook' is a historical tag and currently the most used one but is not wanted and shouldn't be used. The specification of key 'facebook' can be found here: https://wiki.osm.org/Key:facebook
*/
[out:json][timeout:500];
// gather results
(
  // query part for: "contact:facebook=* and facebook=*"
  nwr["contact:facebook"]["facebook"]({{bbox}});
);
// print results
out body;
>;
out skel qt;

This checks, if 'contact:facebook' and 'facebook' keys are both mapped on one object. Both keys are used to map facebook profile urls under which the operator or the staff can be reached. The 'facebook' is a historical tag and currently the most used one but is not wanted and shouldn't be used. The specification of key 'facebook' can be found here: https://wiki.osm.org/Key:facebook . I recommend to remove 'facebook' in favor of 'contact:facebook'. The specification of 'contact:facebook' is the same as for 'facebook'.

'contact:fax' and 'fax'

/*
This has been generated by the overpass-turbo wizard.
The original search was:
“contact:fax=* and fax=*”

This checks, if 'contact:fax' and 'fax' keys are both mapped on one object. Both keys are used to map the fax number under which the operator or the staff can be reached. The 'fax' is a historical tag and currently the most used one but is not wanted and shouldn't be used. The specification of key 'fax' can be found here: https://wiki.osm.org/Key:fax
*/
[out:json][timeout:500];
// gather results
(
  // query part for: "contact:fax=* and fax=*"
  nwr["contact:fax"]["fax"]({{bbox}});
);
// print results
out body;
>;
out skel qt;

This checks, if 'contact:fax' and 'fax' keys are both mapped on one object. Both keys are used to map the fax number under which the operator or the staff can be reached. The 'fax' is a historical tag and currently the most used one but is not wanted and shouldn't be used. The specification of key 'fax' can be found here: https://wiki.osm.org/Key:fax . I recommend to remove 'fax' in favor of 'contact:fax'. The specification of 'contact:fax' is the same as for 'fax'.

'contact:mobile' and 'mobile'

/*
This has been generated by the overpass-turbo wizard.
The original search was:
“contact:mobile=* and mobile=*”

This checks, if 'contact:mobile' and 'mobile' keys are both mapped on one object. Both keys are used to map the mobile number under which the operator or the staff can be reached. The 'mobile' is a historical tag and currently the most used one but is not wanted and shouldn't be used. The specification of key 'mobile' can be found here: https://wiki.osm.org/Key:mobile
*/
[out:json][timeout:500];
// gather results
(
  // query part for: "contact:mobile=* and mobile=*"
  nwr["contact:mobile"]["mobile"]({{bbox}});
);
// print results
out body;
>;
out skel qt;

This checks, if 'contact:mobile' and 'mobile' keys are both mapped on one object. Both keys are used to map the mobile number under which the operator or the staff can be reached. The 'mobile' is a historical tag and currently the most used one but is not wanted and shouldn't be used. The specification of key 'mobile' can be found here: https://wiki.osm.org/Key:mobile . I recommend to remove 'mobile' in favor of 'contact:mobile'. The specification of 'contact:mobile' is the same as for 'mobile'.

'contact:sip' and 'sip'

/*
This has been generated by the overpass-turbo wizard.
The original search was:
“contact:sip=* and sip=*”

This checks, if 'contact:sip' and 'sip' keys are both mapped on one object. Both keys are used to map the sip id under which the operator or the staff can be reached. The 'sip' is a historical tag and currently the most used one but is not wanted and shouldn't be used. The specification of key 'sip' can be found here: https://wiki.osm.org/Key:sip
*/
[out:json][timeout:500];
// gather results
(
  // query part for: "contact:sip=* and sip=*"
  nwr["contact:sip"]["sip"]({{bbox}});
);
// print results
out body;
>;
out skel qt;

This checks, if 'contact:sip' and 'sip' keys are both mapped on one object. Both keys are used to map telesip numbers under which the operator or the staff can be reached. The 'sip' is a historical tag and currently the most used one but is not wanted and shouldn't be used. The specification of key 'sip' can be found here: https://wiki.osm.org/Key:sip . I recommend to remove 'sip' in favor of 'contact:sip'. The specification of 'contact:sip' is the same as for 'sip'.

'contact:xmpp' and 'xmpp'

/*
This has been generated by the overpass-turbo wizard.
The original search was:
“contact:xmpp=* and xmpp=*”

This checks, if 'contact:xmpp' and 'xmpp' keys are both mapped on one object. Both keys are used to map JID addresses under which the operator or the staff can be reached. The 'xmpp' is a historical tag and currently the most used one but is not wanted and shouldn't be used. The specification of key 'xmpp' can be found here: https://wiki.osm.org/Key:xmpp
*/
[out:json][timeout:500];
// gather results
(
  // query part for: “contact:xmpp=* and xmpp=*”
  nwr["contact:xmpp"]["xmpp"]({{bbox}});
);
// print results
out body;
>;
out skel qt;

This checks, if 'contact:xmpp' and 'xmpp' keys are both mapped on one object. Both keys are used to map JID addresses under which the operator or the staff can be reached. The 'xmpp' is a historical tag and currently the most used one but is not wanted and shouldn't be used. The specification of key 'xmpp' can be found here: https://wiki.osm.org/Key:xmpp . I recommend to remove 'xmpp' in favor of 'contact:xmpp'. The specification of 'contact:xmpp' is the same as for 'xmpp'.

Unnecessary complicated tagging/mapping

Playgrounds mapped as relation

/*
This has been generated by the overpass-turbo wizard.
The original search was:
“leisure=playground”

This queries for all objects tagged with 'leisure=playground` and created as relation.
*/
[out:json][timeout:500];
// gather results
(
  // query part for: “leisure=playground”
  relation["leisure=playground"]({{bbox}});
);
// print results
out body;
>;
out skel qt;

This queries for all object tagged with 'leisure=playground` and created as relation. The specification of Tag:leisure=playground says that playgrounds shouldn't be tagged as relations because normally a playground itself (without playground equipment) consist just of one object and not of many. Relations are just necessary, if you want to create new data out of in OSM already existing data, then you need a relation. But by creating a playground in OSM you do not use any already existing data in OSM, you create new data and therefore a playground should be mapped as node or way/closed area. Please verify if it can be mapped as a closed way instead.

Wrong key on playgrounds

/*
This has been generated by the overpass-turbo wizard.
The original search was:
“leisure=playground and playground=*”

This checks, if the key 'playground' has been tagged on playground objects with 'leisure=playground'. By specification the key 'playground' must be mapped on playground equipment and not on the playground itself.

But if a play equipment takes up the whole space of the playground's area leisure=playground, then tag it on the playground area itself with 'Key:playground' key.
*/
[out:json][timeout:500];
// gather results
(
  // query part for: “leisure=playground and playground=*”
  nwr["leisure"="playground"]["playground"]({{bbox}});
);
// print results
out body;
>;
out skel qt;

This checks, if the key playground has been tagged on playground objects with leisure=playground. By specification Key:playground must be mapped on playground equipment and not on the playground itself. To map playground equipment on the playground itself see playground: (Note the double point at the end of key name). There is an exception on this I added to Key:playground spec page based on my little usage research: If a play equipment takes up the whole space of the playground's area leisure=playground, then tag it on the playground area itself with Key:playground key.

Deprecated tags

Diaper

/*
This has been generated by the overpass-turbo wizard.
The original search was:
“diaper=*”

This queries for all objects with key 'diaper`
*/
[out:json][timeout:500];
// gather results
(
  // query part for: “diaper=*”
  nwr["diaper"]({{bbox}});
);
// print results
out body;
>;
out skel qt;

I proposed the deprecation of Key:diaper and it has been approved by the community. I did this because the old key lacked good specification and caused some problems in interpretation and schematics. My new invented Key:changing_table solves these problems and its wikipage shows also how to convert the old tagging of changing tables to the new one. So it should be easy to switch, an easy start for mappers of the old key.

Wrong use of tags

'website' used for linking to facebook

/*
This has been generated by the overpass-turbo wizard.
The original search was:
“website~"facebook"”
*/
[out:json][timeout:25];
// gather results
(
  // query part for: “website~facebook”
  node["website"~"facebook"]({{bbox}});
  way["website"~"facebook"]({{bbox}});
  relation["website"~"facebook"]({{bbox}});
);
// print results
out body;
>;
out skel qt;

This checks, if 'website' contains the string "facebook". Mostly it catches tagging like `website=https://facebook.com/...`. We do not use the key `website` to tag facebook sites. We use the key `contact:facebook` instead.