I think this is in fact 2-way, could you provide documentation that this is currently one-way? According to the WSDOT project page (https://wsdot.wa.gov/construction-planning/search-projects/i-5-mounts-rd-steilacoom-dupont-rd-corridor-improvements), the I-5 SB exit 119 is now open and traffic heading to Lewis McChord Base (via Clark Rd) travels west on this segment to get to clark. see exit 119 diagram at https://s3-us-west-1.amazonaws.com/ehq-production-us-california/b022b1d2f16449c50f8423b25b491f4c1024bc71/original/1763405817/19cd4c9ec1fbfb2300780bb82d381f71_MountsRoad-map-Stage4SouthboundTraffic.jpg

I'm changing this back to two-way, and will look into changing the road classification. But please let me know if you have recent on-the-ground info or current data about this.

Filing obligatory feedback complaint that you added a duplicate building: way/1365202834

Thanks for your work on this, happy mapping!

Looks good, thanks for the contribution! Address data is pretty sparse in this area, so feel free to add addresses as needed. I'll look into pulling some data from any publicly-licensed county address data to see if I can get some of these in bulk.

Thanks again, and welcome to OpenStreetMap!

Fair. I believe I had tagged it that way because the flats are still "under construction". But I think it's close enough to completion that this is okay.

Thanks. The extra node ("point") is redundant—the tags on the way ("area") take care of that.

See osm.wiki/One_feature,_one_OSM_element for more info.

Thanks again for the contributions, and happy mapping!

Thanks. Is there any particular reason you used multipolygon relations instead of just a normal way-area? E.g. relation/20128685

If you don't know what that means, then it's just because the iD editor can be a little annoying about creating extra relations. Otherwise, I'd be interested to hear your reasoning.

Very unlikely that there's a camera at the center of this intersection, though I do see some cameras on a streetlight on the south side of this intersection. They look like normal city traffic or surveillance cameras though, I don't recognize them as Flock. Please don't tag cameras as manufactured by Flock unless you're sure.

I'm removing this camera for now, let me know if you have more details about which camera you're intending to map and I can correct the location and information.

A camera wouldn't be placed at the very center of the intersection (and it seems extremely unlikely that there would be a camera manufactured by Flock Safety in this area). Are you referring to the nearby emergency phone and camera (node/11924024811)? Or just a regular City of Seattle traffic camera? Please provide more details so we can get this added accurately.

I'm not too familiar with the Moses Lake area, but if the camera is manufactured to Flock Safety, these tags look correct to me. Thanks for the contribution!

Awesome, glad that you have a solid plan :)

KC imagery supposedly coming out in february... https://osmus.slack.com/archives/C1FKE1NCA/p1765578997254529

Happy mapping!

Awesome, thank you!

Feel free to reach out here or at https://slack.openstreetmap.us/ if you have any questions about OpenStreetMap, and welcome to the project!

Sound good, but I don't know how these could be mass-edited: i.e. how do you differentiate between proper tactile paving with tactile_paving=yes and ramps with surface treatment that are tagged (incorrectly, we've now decided) as tactile_paving=yes too?

Thanks for the contribution. The camera isn't part of the road, so it should be disconnected from the load line. Where exactly is the camera? In the median between the 2 directions? Or just north/south of this segment of Medina Circle road?

FYI it sounds like the general consensus is that this scored surface treatment (on node/8279999097) doesn't count as tactile paving--see note/5132105 etc.

Thanks for the contribution! The data is definitely lacking in this area, so thanks for this info.

This edit looks good, thanks for the contribution!

Thanks for your contribution. I have some notes on this edit:

* It looks like you decreased the precision of 126th St Ct E (way/225581519/history/5) Why? ESRI imagery licensed for use in OSM suggests that the way it was mapped was correct.

* oneway=no doesn't add any information. Roads are by default assumed to be two-way.

* A minor-road stop sign (highway=stop + stop=minor, you added 2 of these) should be located at the stop line on the minor road(s). Otherwise data consumers don't know which road the stop sign applies to.

* The lanes=* tag specifies the total number of lanes, both directions. lanes=1 could still be correct on 126th St Ct E, but be aware that this implies vehicles cannot pass each other in opposite directions, or would have to do so very slowly (which, again, *is* in fact the case on many residential roads)

* I can't find any documentation for crossing=stop_sign. the crossing=* tag is intended for describing pedestrian crossings. A highway=stop could be mapped here separately if there is a stop sign.

In light of these notes, especially the removed precision on 126th St Ct, I've reverted this changeset. Please don't take offense at that; I know that OpenStreetMap has quite the learning curve. Please reach out with any questions or comments.

Another helpful resource to learn more about OpenStreetMap is the OSM US Slack available at https://slack.openstreetmap.us/. There are lots of us on there happy to discuss questions.

Thanks again for the contribution, and welcome to OSM!

Actually, bus relations look fine.

oh okay, nvm about manufacturer tags then. thanks

Oh, huh. Well, let me add the manufacturer tags back then to indicate Flock. I was not aware Flock made cameras in this form-factor, so thanks for sharing!

Happy mapping!