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 ( 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 ( note/2073335 and note/2976722 ) ?

Not sure about the double addr:street (addr:street=State Route 28;Route 28) on the building 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 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?

Hi Daniel... just noticed that you tagged node/42497780 with highway=traffic signals, months ago.

My goal with complex intersections like one has been to tag so that routes through the intersection will pass through the correct number of traffic lights, to aid in routing calculation and description.

In this case, drivers will encounter a single stop light, no matter where a car is coming from or heading to. The only way I could figure to do that here was to use three different traffic_signals nodes:
node/2342949810
node/6224367546
node/7289701156
The first two are tagged with direction so through traffic eastbound or westbound on Atlantic will only be stopped by one of them.

With this design, the traffic signal tag at node/42497780 isn't needed. So I've removed that tag. Just FYI.

Happy Halloween! Jason

This is a just a quick way to tag the construction site with the BINs from the former buildings, which are sometimes an easier way to access the eventual new building's info than by address search.

It's worth noting that *all* of these imagery layers have alignments variations at different locations, and sometimes also at different zoom levels. (Not to mention changes over time, of course, when photography is updated.)

The example you've given in Staten Island certainly shows Mapbox and Bing close, ESRI a little less so. In my experience Mapbox is the least-consistently aligned layer in NYC, jumping around considerably across the city.

Back in this changeset (lower Manhattan), there are visible differences in alignment in all 3: https://ipfs.io/ipfs/QmTUXnh5eFgwXEv8sNEuNRaVF7YMZff2nVJxFCzkYhsxfp?filename=layerloop.gif

The NYS Orthos layer is a little south of all of these, indeed the outlier. That doesn't mean it's wrong, but returning to my source data I can't actually swear that it's better than the others, at least not here. My conclusion that it was best-aligned was based on older comparisons, and the current observations sew enough doubt that I'll eschew further evangelization on NYS Orthos' behalf. (OTOH NYC's orthos *were* in fact updated in 2020, so I'm not entirely delusional: https://gis.ny.gov/gateway/orthoprogram/lot20/index.html )

I haven't done enough analysis to have an opinion regarding the quality of, or need for, SH17's alignment changes. In general I agree that there's not a particularly pressing need for much road realignment in the city, except as required due to physical changes on the ground.

Mea culpa, it appears that the current NYS Orthos imagery is *not* from last autumn, it's from autumn 2018. This was a clerical error on my part and I apologize for the confusion and any subsequent damage to the map. Bing has been continuing to add fresh imagery and is now more up to date (2020) in most places.

But I'm still vouching for the alignment of NYS Orthos. I've done extensive comparison of the various imagery providers around here to my own GPS surveys, Strava, and the road traces we used to have from Juno.

(The claim that "4 different satellite images pixel-match in alignment with each other" doesn't jibe with my observation. At stock alignment, the only two current imagery layers that match in this way are "Esri World Imagery" and" Esri World Imagery (Clarity) Beta", and because they're both from the same provider I don't give that any additional weight.)

Hi there... I see you've removed the name "Victra Brooklyn" from this Verizon retailer. Is this name no longer associated with this location?

Hi there... there's already a shop node for "Woodstock Bring Your Own" ( node/7213430987 ) located nearby inside the 33 Tinker Street building ( way/772626997 ).

If the same organization has opened a bookstore here, I'm guessing it wouldn't have the address 33 Tinker Street, since the addresses in this building are 19 and 21 Tinker Street.

This seems to have been a hit-and-run account with some very specific opinions of tagging.

Among those opinions, it appears, were: "a power plant doesn't need to be tagged landuse=industrial if it's tagged power=plant" and "a factory doesn't need to be tagged man_made=works if it's tagged building=industrial." I've got no opinion about the former, but the later seems incorrect on its face so I've done a partial revert (changeset/112712422) that included restoring man_made=works to these factories.

Hi there... wondering about the deletion of node/2552836849 with its tags being copied into the building way/248507672 .

As far as I know this is a 4-story building and the Verizon store is only on the ground floor. Has this shop occupied the entire building? If not, we'd want to keep the shop tags on a separate element from the building, to best indicate that these are distinct features.

Thanks, J

Hi SH17, I've noticed you're working on road alignment in NYC.

As a longtime NYC mapper, I'd encourage you to align to the "NYS Orthos Online" imagery instead of Bing's. NYS Orthos is consistently the best aligned across the city, while Bing's alignment drifts.

The NYS Orthos imagery is from last autumn so it's also the most recent at the moment, though Bing is a close second in most parts of the city.

Thanks, J

Grüße Nico, wenn Sie auf Englisch schreiben könnten, wäre das einfacher für die Mapper in der Nähe, danke!

Hello! I'm guessing you used iD's Extract function to remove the gallery's tags from the building and add them to a POI node instead.

Unfortunately this feature is not aware of the "nycdoitt:bin" tag, which is NYC's reference code for the building. This is one the building's tags, not one of the gallery's, but iD removes it from the building and copies it to the newly created node.

I created an issue on iD's github 3 months ago but it hasn't yet gotten any traction: https://github.com/openstreetmap/iD/issues/8539

Until this is resolved, please manually copy the "nycdoitt:bin" tag back onto the building, and remove it from the new node, whenever using iD's Extract function.

I've already fixed this one!

Cheers, J

Hi Samm05, just to say -- there's no need to add turn restrictions here if the same information is conveyed by a oneway tag on the service roads. (I've already fixed this.) Cheers, J