Source was https://t-doitsumura.co.jp/wp/wp-content/uploads/2024/11/xmas2024-map.png

I did reduce the detail level on one restaurant, as (protein)x(dish) combinatorics we're a bit much.

Main downside is app queries like "Chicken Tikka Masala" need to infer that independent food:chicken and food:tikka_masala hits should still cause the restaurant to be shown as a search result.

changeset/171794977#map=19/45.233319/-122.811043

Thus seems not the place to debate the use of food:* and drink:*.

Perhaps on the forums https://community.openstreetmap.org/t/new-tag-structure-food/99638 or wiki food:*=* or osm.wiki/Proposal:Food_declaration?

In either case usage seems fitting with food:*=*. And this allows searchability for food/drink products, whereas a menu link does not. How else would an app have data that piroshki is served at From Russia with Love cafe way/1428332092.

Oh, I see. I try to remember to add both tags.

In general, I prefer the structure of `drink:*=` so in theory the renders can just group and display all `drink:*=` and `food:*=` keys. Otherwise the renders need to know all the possible names of drinks/foods.

Thanks for your edit.

Looks like the right tag is osm.wiki/Tag:drink:cocktail=, as per drink:*=*.

You removed osm.wiki/Tag:drink:cocktails=; I'll add back the right tag (no 's').

Well, the city is being physically recreated, starting next week.

To the larger question of why keep it on the map the rest of the year? Few reasons (just my opinion): It's easier than recreating from scratch; folks like to look at it the rest of the year; the land isn't reused for other purposes the rest of the year; precedent of OSM and other maps keep it on the off season.

Year to year, there are a variety of things needing to be deleted/re-positioned/updated, like specific camps, and art work; and updates to the naming of streets, the man pavilion, and temple.

There is a bit of a hierarchy in the neighborhoods of Seattle.

Next one I was thinking of was Queen Anne, which is a superset of North Queen Anne, East Queen Anne, West Queen Anne, and Lower Queen Anne. Less wishy-washy.

Unsure if 'quarter' is the right level; 'suburb' might be better, to match Ballard: node/150940157. Impact is choosing a larger level down-weights matches in the geocoder.

Wikipedia lists the "district" each neighborhood is within:
https://en.wikipedia.org/wiki/List_of_neighborhoods_in_Seattle#List_of_districts_and_neighborhoods. For example Whittier Heights "neighborhood" is in Ballard "district": https://en.wikipedia.org/wiki/Whittier_Heights,_Seattle.

For areas vs. points, the points are much easier to create. When creating the area for the quarter/suburb, you have to have include the individual ways, as you can't have a relation (e.g. West Queen Anne, East Queen Anne, ...) in a type=boundary relation, to easily make a union of the individual neighborhoods.

For example, Ballard Sculpture Garden is in the east part of Ballard, but Nominatim, by necessity, makes an assumption about how large the POI point for Ballard is, so lists it in Fremont instead of (neighborhood=West Woodland, suburb=Ballard): https://nominatim.openstreetmap.org/ui/details.html?osmtype=N&osmid=3211770267

Overall goal is to help searchability for locations, like "Coffee in Queen Anne", by giving a better bounds to the geocoders.

All is well. Thanks for all your fixes.

Thanks Matheus. I see that you posted that iD has an open issue for auto-correcting the dashes.

Thanks for the mass replacement fix. Too easy to copy/paste non-standard dashes from websites.

Can you tool say which editor was used to add the non-standard dashes?

ID/rapid/etc may want a verifier on the hours field to warn of alternative dashes --https://www.compart.com/en/unicode/category/Pd.

Yeah. It was a bit 50/50 on which duplicate I removed.

Background was the use of https://osminedit.pavie.info to do indoor tagging; that site failed on upload but lets you download the changeset as geojson, which then failed to merge in JOSM. Mistakes were made.

I'll do another round of cleanup to drop the extra tags. Main impact I see is loss of history on some of the elements on this one city block.

Thanks for fixing. I find plural/singular difficult to guess on OpenStreetMap.

Keys seem pretty consistently singular. Values less so; for example: A shoe store is shop=shoes, the same as a beverage store is shop=beverages, and a toy store is shop=toys.

Sub-keys have some odd plurals mixed in, like payment:credit_cards=*.

Agreed. Phone app wasn't logged in, and apparently aggregates old changes to a single changeset.