Hello Stugeb! This changeset added a large forest multipolygon osm.org/relation/13748742 but 1) a fair amount of this is cleared, not forest and 2) most of it is already covered by other landuse features osm.org/way/481481664 and osm.org/relation/7088071 .

I've removed this forest multipolygon (changeset 116920660.) If you'd like to map the areas that are wooded within the existing landuses, natural=wood would be a better tag. And try the "NYS Orthos Online" aerial imagery, which is the most recent here at the moment.

Thanks, jmapb

Yeah... I previously had an opening_hours tag on each gate. But some of the entrances now have different opening hours for vehicle traffic and foot traffic, so I thought it best to encode this with per-access-type conditional access tags on the gated road segments (eg osm.org/way/60548358 ) itself rather than on the gates themselves.

I have to confess: I'm not sure why I didn't just add the motor_vehicle=, motor_vehicle:conditional=, foot=, and foot:conditional= tags directly to the gates, replacing the opening_hours tag. I distinctly remember believing that it wasn't correct. But either the wiki used to say something else (😉) or I was advised by some other channel.. or I just imagined it.

Anyway, best I can tell, moving them to the gates would fine, and might well be preferable. My advice would be, if you want to add those access tags to the gates, then go ahead and remove them from the road segments -- we don't need to the extra headache of maintaining two versions of the rules for each gate.

Cheers, J

Well that explains your commit comment! Thanks. Let's hope J&S sticks around a while

(changeset comment should be: fix access tagging on cemetery entrances, source should include cemetery website)

Back to mapping... I went by this building yesterday and the name was "J & S Auto Repairs": https://i.imgur.com/oEZygDM.jpg

I couldn't see any trace of "Gotham Auto Body Collision" except for *maybe* some white graffiti that reads "goth 666" (only the "goth" part is visible in the picture.)

Normally I'd just assume the business had changed or rebranded, but because your changeset is so recent I thought I should check to make sure I'm not missing anything.

Cheers, J

Well here, we certainly agree! But why not both? Two differences: 1) changes to the wiki don't instantly propagate into editor warnings, 2) curation of iD's list is in the hands of a select few.

Hi bhousal, no offense intended, I respect your work.

In situations like this, where there's a close call on tagging, I feel it's important to give the benefit of the doubt to the mapper on the ground who can see the feature, read the wiki, and assign tags as the documentation suggests. If there are differences of opinion, they can be worked out cooperatively through conversation.

The design of iD's "outdated tags" warnings makes this sort of cooperation difficult. Many mappers will assume that the warnings in question reflect an official position or community consensus. iD's UI does nothing to hinder this assumption. Therefore, iD's list of outdated tags needs careful curation. If a tag that has not been deprecated by the community finds its way onto this list, it faces de facto extinction as mappers worldover begin to follow iD's "upgrade" recommendations. Amenity=dancing_school has not been deprecated (its status is "in use") so it's best to remove it from iD's list.

If I've convinced you then perhaps do the favor of opening an issue on github to remove this particular entry from deprecated.json. I could do so myself but I feel that an issue from me might be sitting around a while (see https://github.com/openstreetmap/iD/issues/8539 .)

Cheers, J

iD has become quite opinionated in recent years and throws a lot of dire warnings about what tags are "incomplete" or "outdated" or in need of an "upgrade". Unfortunately these warnings freely mix documented best tagging practices with the peculiar preferences of the iD dev team, with no distinction in the UI between the two.

The wiki definition of leisure=dance, depending on where you look, is:
- "a place to go dancing" ( osm.wiki/Key:leisure )
- "a reasonably well-maintained dance floor available on a regular basis" ( osm.wiki/Tag%3Aleisure%3Ddance )
- "a dance venue or dance hall" ( the sidebar of osm.wiki/Tag%3Aleisure%3Ddance )
None of these describe the Tutu School. It's a business that teaches ballet to children. It might be argued to be kindergarten or childcare, but it doesn't pass muster as leisure=dance. (The dance:teaching subtag only adds detail -- it doesn't widen the definition of leisure=dance to include things that wouldn't otherwise qualify.)

I understand that amenity=dancing_school is not as popular as these tags, but this isn't a popularity contest because they're not synonymous. We wouldn't tag a vending machine as amenity=fast_food simply because it's a more common tag. That said, the relative rarity of dancing_school may well be due to iD pressuring well-meaning mappers to eliminate it in favor of less accurate tagging.

Since you have no objections, I've restored dancing_school to osm.org/node/8011537449 and also used it for the new location osm.org/node/2494243514 (changeset 116590526). And you're right, this may be a fool's errand -- the next iD mapper in the neighborhood who examines the Issues list will presumably be asked to "upgrade" them to leisure=dance. It's a risk I'll have to take ;)

Happy mapping, J

Re: osm.org/node/8011537449 , you don't like amenity=dancing_school? This place opened another location so I'd like to tag them the same, but I'm not convinced that your new tagging is more correct.

Best I can tell, this building did in fact have a "spiky" problem -- a repeat segment, I think. Not sure exactly how I managed that, but this is one I drew with all the individual 3D building parts, so there are a lot of nodes and ways in there.

Changeset 116442435 addressed that problem, but somehow took the building out of square at the same time. I imagine that it's hard to manipulate complicated buildings like this using iD. Anyway the original problem was certainly worse than the cure, and everything's fixed up now.

J

Hello! What's the thinking behind moving POIs from the building ways into their own nodes?

Thanks, J

Well the land's wet, innit? ;)

This is a little hollow that's been reliably swampy in years past. At the moment, though, it's merely muddy, so I've removed the wetland feature for now.

Cheers, J

Hi Hiausirg, please reconsider these continent-scale changesets. Changesets should be small enough that your fellow human mappers can comprehend what's been done. These are so large that not only are they incomprehensible to humans, they also break QA tools like achavi and osmcha.

Furthermore, the changeset comments are unhelpful. What are you deleting, and why? Referring us to a third-party site (and not even linking!) is poor form.

Thanks, J

Howdy... I just checked this out & the bollard in the middle of the road really isn't there at all. The other bollards do exist, four on each side, but the central gap is big enough (over 11 feet) that I don't think it's actually a physical obstacle to vehicular traffic.

So I deleted that middle bollard. And I added a width to the section of road right around the bollards, which I'll double-check next time I'm by if I remember to bring a tape measure.

Cheers, J

Hi, never heard back from you on this. I still don't know if you surveyed/otherwise researched these pois, or simply added them on the strength of the text of the above notes (both of which I wrote.)

Regardless, I surveyed both of these locations today and these *are* both in fact going concerns, and correctly positioned on the map.

Going forward, if a note mentions the need for a survey (as both of these did) please don't close it without a survey! Thanks, J

As far as "mapping both terms"... when a building actually has two distinct addresses, it's common to map two address nodes inside the building perimeter instead of adding the addr: tags directly to the building way. But this is not the case here -- this is just a single address, with two different valid styles of writing the street name. In this case, we just need to pick one or the other. I've already updated the building and changed "addr:street=State Route 28;Route 28" to just "addr:street=State Route 28".

Of course, it's still possible that users might search for this place using the short version of the highway name. OSM handles this by tagging the road itself with the name variations. The highway here ( osm.org/way/48207234 ) is tagged name=State Route 28, short_name=Route 28, and alt_name=State Highway 28. You can find Kingston Collision by searching on any of these three variations:

osm.org/search?query=960%20Route%2028%20Kingston%20NY

osm.org/search?query=960%20State%20Route%2028%20Kingston%20NY

osm.org/search?query=960%20State%20Highway%2028%20Kingston%20NY

Happy Boxing Day! J

Hi CurlingMan13 -- do you have any data source for these edits, other than the contents of the notes you closed ( osm.org/note/2073335 and osm.org/note/2976722 ) ?

Not sure about the double addr:street (addr:street=State Route 28;Route 28) on the building osm.org/way/862114186 -- I've never seen this tag with multiple values, and I doubt that software will handle it well.

Thanks. As a local NYC mapper & fellow note closer, I'm happy to see the interest.

I've researched this area myself (I'm the author of osm.org/note/1869557 ) and I'm curious about what specific information you've based these changes on.

Hi gpserror, can you share the source of these building names?