Hi Daniel... just noticed that you tagged osm.org/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:
osm.org/node/2342949810
osm.org/node/6224367546
osm.org/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" ( osm.org/node/7213430987 ) located nearby inside the 33 Tinker Street building ( osm.org/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 osm.org/node/2552836849 with its tags being copied into the building osm.org/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

Never mind -- my mistake. I checked the wiki and it says we should use "st" for "short ton" to indicate USA tons for maxweight. I've never seen that abbreviation used that way before, but it's consistent with the wiki so I guess it's correct?

Anyway, happy mapping, J

osm.wiki/Key:maxweight#United_States

Howdy DovePod... thanks for your mapping around Fleishmanns.

I noticed you tagged the maxweight on this bridge as "20 st". That's 20 stone, or 280 pounds, far too low a limit for a vehicular bridge.

Similarly, the Main Street bridge you tagged as "22 st".

I'm guessing these maxweights are supposed to be tons -- can you confirm?

Thanks, J

Thanks, as I mentioned above I did browse through the Atlas Checks github page but short of building my own Atlas Checks instance populated with the map in its previous state, there's no way to be certain where this process went wrong.

My best guess is that the actual issue flagged by the ConnectivityCheck was non-connectivity between ways 60251535 and 60251535, which both ended at nodes overlapping at the same location, one of which was 765365658. A connection was needed, but not the Harlem River Drive motorway. I've fixed this now (joined 60251535 and 60251535 into a single highway.)

Ok, clicking through, to osm.wiki/Organised_Editing/Activities/Facebook from your user profile, I can see the description of the "Atlas Checks" project, and drilling down into the Atlas Checks github I can see there's a little blurb about the "Connvectivty Check" feature at https://github.com/osmlab/atlas-checks/blob/dev/docs/checks/connectivityCheck.md

None of this gives me any clue why you'd want to attach node 765365658 to the Harlem River Drive. I have to assume that your Atlas Checks instance flagged this spot for review, and you decided that this connection between the track the motorway was correct. Supposedly based on Bing imagery? If you can elaborate, I'd love to hear it.

I've left this alone hoping you'd find time to review this change and perhaps improve the quality of your QA initiatives. But I believe it needs reverting, so if you want to examine it in situ hurry up.

Thanks, J

Howdy... can you elaborate on the data source for this change, and the meaning of these hashtags?

Thanks, J

Ok fixed in 110238441

howdy ... just noticed that this changeset resulted in some very sharp angled roads in downtown BK. My guess is that osm.org/way/46121844 was unintentionally dragged a bit to the north. Happy to fix this but just wanted to check with you first in case there's something I'm missing. Cheers, J

Hi Ryan -- this is a real map used by real people. Please don't vandalize it. I've reverted this changeset. Thanks, J