popular unsupported values of major keys

[matkoniecz]

Based on taginfo with some filtering - so values on this list may require cleanup rather than support. Some have open PRs already, I tried listing them.

Generated with https://github.com/matkoniecz/taginfo_api_wrapper_in_python#listing-popular-tags-unsupported-by-id

It is usable for review. But using it requires some thinking. For example I like shop = estate_agent and is in my opinion preferable to office = estate_agent (as office=estate_agent and other office=* is used both for places inaccessible to general population such as internal offices - and for ones accessible to general population). But changing id presents requires some investigation what other mappers think.

Note that some highly used values, are from imports of a low quality. That would allow filtering out values discussed separately and/or rejected. Many values initially on this list were filtered out and skipped.

If that list is useful - then more systematic reviewing like JOSM is doing may be useful.

Other potential comparisons: list tags supported by JOSM or Vespucci and not supported by iD.

this replaces #529 listing and was created based on current taginfo data, with some keys not present in previous listing.

• traffic_calming = painted_island 2k
• attraction = historic 1k
• shop = estate_agent 4k
• shop = food 3k
• shop = convenience;gas 2k - looks like added by import/specific editing project: see chronology chart at https://taginfo.openstreetmap.org/tags/shop=convenience;gas
• shop = glaziery 2k
• shop = ice_cream 2k Add hidden preset for shop=ice_cream referencing amenity=ice_cream #2195
• shop = printing 1k
• shop = building_materials 1k
• shop = power_tools 1k Support shop=power_tools #1785
• shop = security 1k Add shop=security #1424
• shop = truck 1k Add shop=truck #1824 (note that there were complaints about that shop value, but there was not attempt to establish an alternative)
• craft = bakery 1k
• craft = printer 1k
• craft = welder 1k
• natural = shrubbery 71k – See Add preset for natural=shrubbery #406
• natural = hill 60k - https://taginfo.openstreetmap.org/tags/natural=hill shows it mostly imported or coming from some specific mass editing
• natural = landform 43k - from bad imports
• natural = earth_bank 18k
• natural = gully 11k
• leisure = schoolyard 6k Add support for leisure=schoolyard #578
• amenity = mobile_money_agent 11k - imported, no organic use
• amenity = health_post 7k
• amenity = waste_dump_site 7k comes entirely from an import
• amenity = feeding_place 6k Add support for animal feeding places #1166
• amenity = training 5k
• place = allotments 21k
• railway = stop 147k
• railway = platform_edge 11k Add preset for railway=platform_edge #1745
• railway = train_station_entrance 9k
• railway = signal_box 9k
• railway = junction 7k - highly internal and expert stuff
• barrier = sliding_gate 16k Add a preset for barrier=sliding_gate #1171
• barrier = avalanche_protection 7k, see Include man_made=snow_fence? #91
• barrier = debris 6k
• barrier = door 3k - https://taginfo.openstreetmap.org/tags/barrier=door#overview - no documentation
• barrier = field_boundary 3k - looks like import/narrowly used/failed experiment, not something with organic use: https://taginfo.openstreetmap.org/tags/barrier=field_boundary
• highway = priority 5k
• highway = via_ferrata 4k Support highway=via_ferrata #1821
• waterway = rapids 101k
• waterway = flowline 21k
• waterway = drystream 16k - https://wiki.openstreetmap.org/wiki/Tag:waterway=drystream claims it is a poor idea
• waterway = pressurised 10k
• waterway = link 6k
• waterway = stream_end 6k
• man_made = heap 46k
• man_made = kiln 32k - looks primarily imported
• man_made = pond 24k - bad duplicate, mass added
• man_made = avalanche_protection 14k
• man_made = snow_cannon 10k
• man_made = marsh_terrace 10k - just look at https://taginfo.openstreetmap.org/tags/man_made=marsh_terrace#chronology - and claimed "survey" as source for example in https://www.openstreetmap.org/changeset/165440047 is kind of dubious :)
• man_made = dolphin 9k - bad definition, see https://wiki.openstreetmap.org/wiki/Talk:Tag:man_made%3Ddolphin
• man_made = tar_kiln 9k - still mostly imported
• man_made = snow_fence 7k Include man_made=snow_fence? #91
• man_made = geoglyph 7k Consider adding man_made=geoglyph to presets #14
• advertising = sign 8k Add Advertising Sign preset #268
• advertising = flag 5k
• aeroway = navigationaid 199k add airport approach light preset #2188
• aeroway = taxilane 17k
• aeroway = airstrip 5k - some organic use, but mostly mass edit
• aeroway = stopway 3k
• aeroway = threshold 1k
• aeroway = tower 1k - looks like tagging is still not settled
• boundary = protected_area 122k
• boundary = postal_code 54k
• emergency = access_point 194k - imported, see https://taginfo.openstreetmap.org/tags/emergency=access_point
• emergency = suction_point 19k
• emergency = fire_water_pond 5k
• emergency = disaster_help_point 2k - mostly imported - I will also increase threshold for listing emergency= features in future editions of this list to 4k entries
• emergency = drinking_water 1k mostly imported
• cycleway = no 325k
• cycleway = lane 322k
• cycleway = shared_lane 86k
• cycleway = track 70k
• cycleway = separate 32k
• cycleway = shared 12k Formerly used, see https://wiki.openstreetmap.org/wiki/Key%3Acycleway
• cycleway = shoulder 10k
• cycleway:right = shoulder 9k
• cycleway:both = no 1716k - see Handle cycleway:both similar to cycleway #743 - and fix taginfo file not including base tags for directionalCombo ideditor/schema-builder#222
• cycleway:both = lane 79k - see Handle cycleway:both similar to cycleway #743 - and fix taginfo file not including base tags for directionalCombo ideditor/schema-builder#222
• cycleway:both = separate 39k - see Handle cycleway:both similar to cycleway #743 - and fix taginfo file not including base tags for directionalCombo ideditor/schema-builder#222
• cycleway:both = shared_lane 27k - see Handle cycleway:both similar to cycleway #743 - and fix taginfo file not including base tags for directionalCombo ideditor/schema-builder#222
• cycleway:both = track 13k - see Handle cycleway:both similar to cycleway #743 - and fix taginfo file not including base tags for directionalCombo ideditor/schema-builder#222
• cycleway:both = shoulder 11k - see Handle cycleway:both similar to cycleway #743 - and fix taginfo file not including base tags for directionalCombo ideditor/schema-builder#222
• route = tracks 3k
• route = share_taxi 2k
• route = emergency_access 2k - - highly local, in future edition of this list I will bump threshold to 4k to avoid listing such cases
• sport = rugby 2k
• sport = model_aerodrome 2k
• healthcare = centre 46k
• cuisine = international 14k
• cuisine = local 12k
• cuisine = bakery 5k mentioned at https://wiki.openstreetmap.org/wiki/Key:cuisine only as unwanted
• cuisine = italian_pizza 5k
• cuisine = tacos 2k
• cuisine = dumplings 1k
• cuisine = british 1k Add cuisine=british support (more than 500 uses) #2022
• cuisine = heuriger 1k
• cuisine = steak 2k
• cuisine = buschenschank 1k
• cuisine = poke 1k
• cuisine = hotpot 1k Add Hot Pot restaurant preset #1569
• cuisine = latin_american 1k
• cuisine = coffee 3k - looks like an undocumented and unclear duplicate of cuisine=coffee_shop (which already is dubious on its own)
• cuisine = cafe 1k suspect, listed as bad at https://wiki.openstreetmap.org/wiki/Key:cuisine
• cuisine = buffet 1k
• cuisine = deli 1k
• cuisine = lunch 1k
• cuisine = noodles 2k - listed as duplicate of =noodle
• surface = earth 152k - duplicate of surface=dirt - at the same time OSM community does not want to fix it by a bot edit - ¯\_(ツ)_/¯
• surface = rock 28k
• surface = stone 14k
• power = terminal 67k proposed in Add preset for power=terminal #653 and implemented in Add power terminal preset #1637
• power = insulator 38k
• power = heliostat 19k
• power = connection 10k - confusing expert internal stuff without clear wiki docs
• power = inverter 7k - confusing expert internal stuff without clear wiki docs
• power = compensator 7k - confusing expert internal stuff without clear wiki docs
• power = circuit 6k - confusing expert internal stuff without clear wiki docs - Add presets from Proposal:Power circuits routing #1744
• power = cable_distribution_cabinet 5k - Deprecate power=cable_distribution_cabinet? #90
• power = cable_distribution 5k - looks imported and without documentation
• telecom = antenna 7k
• telecom = line 3k
• landcover = mostly_rock 66k – tordans: Looks like imports and not well supported https://wiki.openstreetmap.org/wiki/Tag%3Alandcover%3Dmostly_rock

[matkoniecz]

#743 is closed but cycleway:both got listed here as it is missing from taginfo

1. is it actually supported now?
2. is it listed in taginfo for iD?
3. if not, should it become listed? Or should I patch it in my script as a special case?

[k-yle]

1. is it actually supported now?

yes, as of openstreetmap/iD#9587. The docs very briefly mention that it's implicitly supported.

2. is it listed in taginfo for iD?
3. if not, should it become listed? Or should I patch it in my script as a special case?

nope, that's a bug. fixed in ideditor/schema-builder#222

[k-yle]

thanks for re-generating this! some questions:

• does your script consider key=*, for example historic=yes is included in the list, but it's covered by this preset with historic=*.
• do we need to special-case semiCombo fields like cuisine? for example, cuisine=western;japanese is supported because we have both western and japanese defined here
• seems like addTags are also not including in the taginfo file. for example, railway=stop is supported
• I didn't realise the order of the JSON object matters....... this is probably causing other fields to be missing from the taginfo file, and isn't documented anywhere
• (comment) some of these tags like waterway=flowline and boundary=protected_area have special rendering in iD but no preset. seems like these ones are worth prioritising?

[matkoniecz]

nope, that's a bug. fixed in ideditor/schema-builder#222

thanks so much!

do we need to special-case semiCombo fields like cuisine? for example, cuisine=western;japanese is supported because we have both western and japanese defined here

yes, the question is: should I just specialcase cuisine in my script or is there sane way to get list of keys supported in this way?

I guess that in addition/instead of taginfo I can parse files like

id-tagging-schema/data/fields/cuisine.json

Lines 6 to 96 in 6b307dc

	"options": {
	"pizza": "Pizza",
	"burger": "Burger",
	"coffee_shop": "Coffee Shop",
	"regional": "Regional",
	"italian": "Italian",
	"sandwich": "Sandwich",
	"chinese": "Chinese",
	"chicken": "Chicken",
	"japanese": "Japanese",
	"kebab": "Kebab",
	"mexican": "Mexican",
	"american": "American",
	"asian": "Asian",
	"ice_cream": "Ice Cream",
	"indian": "Indian",
	"sushi": "Sushi",
	"seafood": "Seafood",
	"thai": "Thai",
	"french": "French",
	"german": "German",
	"breakfast": "Breakfast",
	"greek": "Greek",
	"steak_house": "Steak House",
	"fish_and_chips": "Fish and Chips",
	"korean": "Korean",
	"barbecue": "Barbecue",
	"donut": "Donut",
	"noodle": "Noodle",
	"vietnamese": "Vietnamese",
	"fish": "Fish",
	"turkish": "Turkish",
	"cake": "Cake",
	"pasta": "Pasta",
	"tex-mex": "Tex-Mex",
	"bubble_tea": "Bubble Tea",
	"ramen": "Ramen",
	"mediterranean": "Mediterranean",
	"spanish": "Spanish",
	"friture": "Friterie",
	"tea": "Tea",
	"grill": "Bar and Grill",
	"juice": "Juice",
	"salad": "Salad",
	"crepe": "Crepe",
	"hot_dog": "Hot Dog",
	"pancake": "Pancake",
	"dessert": "Dessert",
	"diner": "Diner",
	"tapas": "Tapas",
	"portuguese": "Portuguese",
	"beef_bowl": "Gyūdon",
	"russian": "Russian",
	"indonesian": "Indonesian",
	"wings": "Chicken Wings",
	"lebanese": "Lebanese",
	"arab": "Arab",
	"curry": "Curry",
	"malaysian": "Malaysian",
	"bagel": "Bagel",
	"georgian": "Georgian",
	"polish": "Polish",
	"african": "African",
	"western": "Western",
	"sausage": "Sausage",
	"filipino": "Filipino",
	"caribbean": "Caribbean",
	"soba": "Soba",
	"peruvian": "Peruvian",
	"brazilian": "Brazilian",
	"oriental": "Oriental",
	"fine_dining": "Fine Dining",
	"frozen_yogurt": "Frozen Yogurt",
	"argentinian": "Argentinian",
	"balkan": "Balkan",
	"bavarian": "Bavarian",
	"shawarma": "Shawarma",
	"persian": "Persian",
	"middle_eastern": "Middle Eastern",
	"pastry": "Pastry",
	"soup": "Soup",
	"fries": "Fries",
	"taiwanese": "Taiwanese",
	"bistro": "Bistro",
	"european": "European",
	"moroccan": "Moroccan",
	"hawaiian": "Hawaiian",
	"brunch": "Brunch",
	"udon": "Udon",
	"ukrainian": "Ukrainian"
	}

but just adding special processing for cuisine seems easier

even if few more keys like this will appear in future

I didn't realise the order of the JSON object matters....... this is probably causing other fields to be missing from the taginfo file, and isn't documented anywhere

I admit that from the first look it is not obvious to me what this code is doing and what implications are

does your script consider key=*, for example historic=yes is included in the list, but it's covered by this preset with historic=*.

not really - and in this specific case I would probably add historic=yes to ignored tags and drop it from list

after all there is also preset for amenity= - https://github.com/openstreetmap/id-tagging-schema/blob/6b307dc2791f4e770787089b8316cd40656257f0/data/presets/_amenity.json - which does not really make amenity=specific_value really supported

on the other hand amenity= preset is unsearchable, maybe it is a meaningful difference?

[k-yle]

should I just specialcase cuisine in my script or is there sane way to get list of keys supported in this way?

hopefully this list with shrink not grow, so maybe special-casing cuisine is fine 🤷 but if you want to get the other 44 semiCombo fields, this javascript would work:

const fields = await fetch('https://esm.sh/@openstreetmap/id-tagging-schema/dist/fields.json').then(r => r.json());

console.log(   Object.values(fields).filter(field => field.type === 'semiCombo').map(field => field.key)  )

---

I admit that from the first look it is not obvious to me what this code is doing and what implications are

Some presets match on multiple tags (for example climbing=area + type=site). However, only the last tag in the object is added to the taginfo file, so the taginfo file is missing climbing=area.

This is suprising, because usually the order of keys in a JS object does not matter¹

---

historic=yes

makes sense. it's the only one with =yes anyway

Footnotes

1. this is a bit of a generalisation, but if we're doing unusual stuff with object-ordering, it should probably be documented ↩

[matkoniecz]

historic=yes skipped, cuisine regenerated with values being split

[matkoniecz]

cuisine=fast_food and cuisine=cafe are claimed to be bad by https://wiki.openstreetmap.org/wiki/Key:cuisine#Discouraged_values

is wiki right or wrong here? Complaints there seem reasonable, I plan on adding them to ignored and dropping them from list unless someone protests (and ideally they would also edit wiki)

[matkoniecz]

Some presets match on multiple tags (for example climbing=area + type=site). However, only the last tag in the object is added to the taginfo file, so the taginfo file is missing climbing=area.

oh, that explains why https://taginfo.openstreetmap.org/tags/emergency=water_tank#projects is missing iD entry despite https://github.com/openstreetmap/id-tagging-schema/blob/v6.0.0/data/presets/emergency/water_tank.json