User:Mateusz Konieczny

From OpenStreetMap Wiki
Jump to navigation Jump to search

OSM account My website

Quick links

active sysops - deletion - blocks

Standard tile layer

make wiki easier to edit

Remove harmful templatification User:Mateusz Konieczny/improve editability

Remove Wikidata linking in infoboxes

Tags in proposal process

Proposal in RfC/vote stage.

  1. Proposed features/insulated


Undocumented tags I just use but are without formal proposal. Idea from User:Malenki/undoc tags

Proposals may be created for some that are useful, frequently used or likely to be complicated. Voting will be initiated for proposals likely to get support in voting.

edit this page

tag taginfo reasoning status (see Proposal process)
Tag:surface=rocks ???? See
Tag:amenity=bicycle_charging_station Charging station for charging solely bicycles. For charging station for both cars and bicycles use amenity=charging_station
Tag:shop=snack (also cuisine=regional + regional=polish + polish=obwarzanek) For shop selling special-purpose baked things that is neither shop=pastry (are not sweet) nor selling general purpose bakery products. Maybe shop=bakery_snack? Proposed features/shop=snack
Tag:cave_tunnel=yes, original natural=cave_tunnel was changed as apparently JOSM validator expects natural to be areas and to not be used with highway=*
fee=no + fee:conditional=yes @ (temporary_exhibition)
Tag:?=? mark disappearing path I just discovered that tractype=grade5 is not useful as it covers all pure dirt paths. Key:trail_visibility ?
Tag:tourism=carriage_ride_boarding ??????? tourism=attraction + attraction=carriage_ride lub amenity=carriage_ride_boarding. ???? marks departure point of tourism vehicles - vehicles wait for tourists and depart immediately with interested tourists. Possibilities include horse-drawn carriages, melex etc currently active and useful discussion on tagging mailing list
Tag:street_vendor=yes marks shop as a street vendor Proposed features/street vendor=yes (36 uses) - currently active and useful discussion on tagging mailing list
Tag:access:conditional=complex for situations where access:conditional is unreasonably complex in use - first at
Key:access:complicated_conditional:image for situations where access:conditional is unreasonably complex - link to photo with the rules in use - first at
Tag:amenity=traffic_park cases: Proposed features/scaled down streets that may be used for traffic safety education or as a type of a playground
Key:service_times:mass When mass is conducted testing sheduled, posted to tagging mailing list (mechanical edit)
Tag:natural=windthrow Remains of a forest destroyed by a wind testing in progress, posted to tagging mailing list
Tag:man_made=goal A football goal - object on a pitch testing in progress
Tag:man_made=hay_rack for hay racks placed in the woods to feed animals during winter testing in progress, see Proposed features/amenity=feeding place, consider Tag:man_made=manger, amenity=game_feeding is quite popular
Tag:dual_carriageway=yes for oneway roads representing roads that are not oneway, as these roads have more than one carriageway and each is mapped separately tested, waits for a proposal (weird cases: (1) (2) )
Tag:service=turning_loop testing in progress
Tag:ticket=public_transport combined with Tag:shop=ticket testing in progress
Tag:topic=public_transport combined with Tag:tourism=information Tag:information=office testing in progress
Tag:traffic_sign=no_stopping instead of Tag:traffic_sign=PL:B-36, combined with Tag:traffic_sign_code=PL:B-36 send to @tagging
Tag:traffic_sign=no_parking send to @tagging
Tag:traffic_sign=oneway send to @tagging
Tag:traffic_sign=crossing instead of Tag:traffic_sign=PL:D-6, combined with Tag:traffic_sign_code=PL:D-6 and Tag:traffic_sign_detail=pedestrian_crossing testing in progress
Tag:traffic_sign=give_way (see Key:traffic_sign) instead of Tag:traffic_sign=PL:something-something testing in progress
Tag:traffic_sign_contradiction=* freeform value, describes traffic sign inconsistencies testing in progress


Mechanical Edits

(edit), see Automated Edits code of conduct

My idea is that automatic edits are OK given edit where

  • human making such changes would not cause a reasonable protest
  • human would edit in the same way or human would make more mistakes
  • preparing program and discussing automatic edit will take less time than a tedious manual edit
  • probability that human during editing would spot major issues not detected by validators is not significantly higher than during normal editing (human will spot mistakes during any editing anywhere, automatic program not spotting problems during editing is harmful only if unusually many major issues not detected by validators would not spotted)
  • edit is accepted by OSM community in discussion (even if somebody is convinced that edit makes perfect sense one should not make if community opposes. it makes sense even if edit was really a good idea)

Overall my vision of automatic edits is that it allows to do incredibly tedious and boring edits, with less mistakes than humans. It allows humans to make more productive editing.

I consider importing addresses from high-quality sources, removing invalid objects imported due to poor processing of source data (importing objects marked as not existing), retagging building=building to building=yes to be good examples of such edits.

Assuming that address dataset is on suitable license and so good that after importing it OSM dataset will cause less mistakes than after surveying the area, why not import it? Except rare cases it will take less effort to do that and people can spend survey time on objects that are not easily importable.

Assuming that some large-scale retagging is clearly desirable - what is the benefit over doing it manually object by object over running scipt and spending hours of freed OSM time on something more useful like going on walk and surveying local area (or tracing forests or improving OSM editors or helping newbies or going through what JOSM validator reported).

Local communities

  • Poland
  • USA: talk-us mailing list and slack
  • Australia: talk-au mailing list
  • GB: talk-gb mailing list
  • Ireland: talk-ie mailing list


Waiting period to give time for response or processing of external issues

Waiting period - supported by discussion, all raised issues solved

Active tasks

Tasks active for a single run

Tasks active forever, until revoked by a community

Past, no longer active tasks

Ended without a single mechanical edit

Not listed here

  • Reverts of undiscussed mechanical edits - as explained by DWG - automated revert of an undiscussed mechanical edit may be done without any discussion and is exempt from Automated Edits code of conduct

Data quality issues

In some cases below mechanical edits may be useful. Many are fixable only by a manual review.

Rerun ideas