Why was this feature not removed?! There's blatantly no parks here!
---
#REVIEWED_BAD #OSMCHA
Published using OSMCha: https://osmcha.org/changesets/130130051

Hello.
If we have a fully structured street address tagged, addr:full is rather unnecessary, especially since that's not the official, full address of that library.
---

Published using OSMCha: https://osmcha.org/changesets/130887436

Hello.
If this is a street/road crossing, it has to be tagged as such...
If this is not an actual crossing, it shouldn't be mapped.
---

Published using OSMCha: https://osmcha.org/changesets/130877445

Hello.
tobacco shop with tex-mex cuisine and no smoking?🤔 Is that accurate?
---

Published using OSMCha: https://osmcha.org/changesets/130875868

What kind of osmose correction?

Hello.
Could you please elaborate what are you trying to map here? Archeological site in the middle of East River?🤨
---

Published using OSMCha: https://osmcha.org/changesets/130840157

Hello.
There's bitcoin atm inside of costco?🤨
paydepot's website doesn't show this location. As a matter of fact their website doesn't show ANY locations in NYS, so where is this data coming from?
---

Published using OSMCha: https://osmcha.org/changesets/130838475

Hello.
Could you please elaborate on this edit? Your changeset shows that you used Bing imagery to map it, however, this building doesn't appear on it on any zoom level..
---

Published using OSMCha: https://osmcha.org/changesets/130834224

"not:" prefix is a completely different thing. Same with lifecycle prefixes.
However here they just straight up invented a new category and used this prefix to define that category. That is wrong. This is now how features are tagged in OSM. If it works as a shop only during certain season then it should be tagged with correct opening_hours, not with xmas:.

A business that functions 2 months out of 12 is temporary business. A business that doesn't have a permanent physical presence in a given location and dependant on a whim of the city during that season is not a permanent feature.

I'm well aware of the xmas: prefix and I find it ridiculous. I think making xmas: prefix on every single tag is redundant, unnecessary and even detrimental. This only complicates object parsing for data consumers to handle yet another edge case for a small number of another type of POIs.

Putting xmas: prefix in front of other tags makes them invisible to data consumers.

What benefit does it give to put these features behind this namespace?! Just to get around the rules of not allowing temporary features? Any data consumer that doesn't know to support this prefix will simply ignore it and not use it. This prefix actually hides the data and makes it less discoverable.

The fact that there are maps specifically to display these Xmas: objects only further confirms that this is nothing but osm.wiki/Tagging_for_the_renderer Intentionally using nonstandard tagging for specific renderers.

What's the point of having "xmas:feature:shop=christmas_tree" instead of just "shop=christmas_tree"? And the same with all the other tags that wiki says to use. They should be standardized and be in schema with rest of OSM tags. Just because it's old doesn't mean it should exist and be in use.
With this kind of misguided prefix tagging we might as well have school: prefix for everything education-related. And have retail: prefix for everything related to stores. How about street: prefix for every road?
It is ridiculous and unnecessary. It doesn't add anything to the map that can't be expressed using existing tagging styles.

Somebody invented this Xmas: prefix 10+ years ago without putting much thought into it and it is most definitely not how people map in OSM now. Continuing to use it only does disservice to the OSM data integrity.

Xmas: prefix is just as ridiculous as if you would put "road:" prefix in front of every single tag of every street. Or put "building:" prefix in front of every single tag on houses. This is just not how it's supposed to be mapped in OSM.
Somebody invented this Xmas: prefix 10+ years ago without putting much thought into it and it is most definitely not how people map in OSM now. Continuing to use it only does disservice to the OSM data integrity.

What benefit does it give to put these features behind this namespace?! Any data consumer that doesn't know to support this prefix will simply ignore it and not use it. This prefix actually hides the data and makes it less discoverable.
The fact that you created an overpass query or a map specifically to display these Xmas: objects only further confirms that this is nothing but osm.wiki/Tagging_for_the_renderer

What's the point of having "xmas:feature:shop=christmas_tree" instead of just "shop=christmas_tree"? And the same with all the other tags. They should be standardized and be in schema with rest of OSM tags.
With this kind of misguided prefix tagging we might as well have school: for everything education related. And have retail: prefix for everything related to stores.
It is ridiculous and unnecessary. It doesn't add anything to the map that can't be expressed using existing tagging styles.

I think making xmas: prefix on every single tag is redundant, unnecessary and even detrimental. This only complicates object parsing for data consumers to handle yet another edge case for a small number of another type of POIs.
opening_hours= tag can already accommodate seasonal POIs that operate only during certain hours.
Putting xmas: prefix in front of other tags makes them invisible to data consumers.

It might be so, but in reality it's not open to public. Ps370 is a school for kids with developmental difficulties and the school keeps things area under strict control. It's always locked up not to allow public access(even during the summer break) and during the school day when kids are there security guards stand by the exit/entrance to ensure that kids don't wonder off or someone unknown get in.

I live 2 blocks away from this school and whenever I walk by it's always chained up. The only time I see people there is during school gym class or after school football clubs. It's not open to public.

Hello.
Could you please elaborate why did you create this relation?
---

Published using OSMCha: https://osmcha.org/changesets/130806852

Hello.
Please note that this feature is going to be deleted since it's already mapped and goes against osm.wiki/One_feature,_one_OSM_element guideline.
---
#REVIEWED_BAD #OSMCHA
Published using OSMCha: https://osmcha.org/changesets/130804248

Hello.
The football field here is not part of the publicly accessible playground. It is used only by Grady HS.
---

Published using OSMCha: https://osmcha.org/changesets/130768231

Hello.
Please note that NE section with the running track and 2 basketball hoops is not part of century playground. There's no public access to that area. It is part of PS370.
---

Published using OSMCha: https://osmcha.org/changesets/130768021

Hello.
Why did you create way/1126339959 when way/170589186 already exist with the same tags?

Also unless it's proper name, and some very few other exceptions, all tag values should always be in lower case, and instead of space they should be separated with _. As such "American Football; Soccer" should be "american_football;soccer".
---

Published using OSMCha: https://osmcha.org/changesets/130760261