Hi, if I remember correctly, anything on the corporate campus of Intel is private. I believe there are “private property” signs at various entrances.

The majority of streets do not have any posted speed limit. Many streets may be covered by the default speed limit of 25 mph or 20 mph. I prefer to map speed limits based only on posted signs as there is less potential confusion, but other mappers will fill in speed limits based on their knowledge of default speed limits.

This was using Bing streetside imagery to look at the signs.

osm.wiki/Bing_Maps#Streetside_imagery

For example, you can clearly see a 35 MPH sign here:
https://www.bing.com/maps?osid=c0bd08e3-d58d-4bbe-9e12-bdb9f30f5785&cp=44.983008~-123.026702&lvl=19&dir=189.13634&pi=-7.2134066&style=x&mo=z.0&imgid=588ad3ed-9c3d-4bd0-ba98-c9e3eb497a78&v=2&sV=2&form=S00027

From this, there is a Node created here:
node/5836862418

The maxspeed=35 mph tag is also added to the adjacent Way. A single speed limit sign is not enough to determine the speed limit for the whole road, so I did traverse the whole road looking for other speed limit signs.

Thanks for updating the map. Let me know if you have any questions.

Paul, I'm not sure what you are getting at here.

The purpose of this changeset was to update a TriMet Bus route. What used to be known as bus route 4 has been split into bus routes 2 and 4.

That being said, many of the roads that make up these bus routes have some bicycle lane or access tags on them. But again, the purpose of this changeset was updating public transportation bus route information in OSM.

These types of nearby nodes were originally created from the Portland building import

osm.wiki/Portland,_OR_Bldg_import

In the original dataset, the points were exactly the same and during the import they were automatically separated a little bit. In most cases it would make sense to separate them even more, or even possible terrace the building into sections (for example for row houses each with their own address).

I don't see any nodes that node/3386481617 is a duplicate node of. Which node do you think is a duplicate of 3386481617?

node/3386481617

I re-connected the transit route relations for bus routes 32, 33, and 99 based on your changes. I moved the bus stop and deleted road and sidewalk names with "Clackamas Community College Transit Center" as it looks like that no longer applies. It's hard to tell what is there without aerial photos through so hopefully I didn't mess things up.

It looks like you changed building=yes to building=commercial. These are all retail businesses, so shouldn't building=retail be better? building=commercial seems like it would be more like an office building. Or just leave building=yes and let the rest of the tags on the object describe its function.

I prefer operator="United States Postal Serivce" as well instead of "USPS". Also, I delete name tags on post boxes when that information is wholly contained on the operator tag. Also, I only edit post boxes while after verifying their location.

Ok, it looks like OSM was mostly up-to-date, except for 2 missing hair salons (Salon Muse and Malva), which I've now added. Here are the businesses that used to be in the Macadam Center:

Holliday Card Shoppe, 5115 SW Macadam Ave
https://www.facebook.com/Holliday-Card-Shoppe-192372230911084/
(permanantly closed)

Macadam Nail Boutique, 5119 SW Macadam Ave
https://www.yelp.com/questions/macadam-nail-boutique-the-fire-has-destroyed-the-salon-how-do-we-find-amy-and-hannah-i-would-lik/44VITgQnJtNXKy5LQTG0QQ
(some employees now work in Hair Architects, 8511 SW Terwilliger Blvd. Hair Architects has already been added to OSM)

DocuMart, 5121 SW Macadam Ave
http://documart.com/locations/portland/5103-2/
(DocuMart website is out of date. They have various other locations around the country. It's not clear that any of the other locations are specifically replacing this location.)

5123 SW Macadam Ave
(I believe this shop was vacant last time I checked)

Picture Perfect, 5125 SW Macadam Ave
https://www.facebook.com/Picture-Perfect-PDX-124113261026362/
(Looks like there is no new physical location for the business but the owners may be offering some sort of delivery service from their home).

Finicky's Bagel Cafe, 5127 SW Macadam Ave
(I can't find anything posted online from the business owner, so I guess permanently closed.)

Roberts of Portland, 5131 SW Macadam Ave
http://www.robertsofportland.com/
(employees have moved to other hair salons in the Portland area:
Studio One, 4380 SW Macadam Ave Ste 160
Chachi Hair, 1740 NW Marshall St
Salon Muse, 18750 Willamette Dr Ste E, West Linn, OR
Malva, 18081 SW Lower Boones Ferry Rd Ste 3, Portland, OR 97224)

MedData, 5125 SW Macadam Ave Ste 140
https://www.meddata.com/contact-us/
(The MedData website is out of date. MedData has offices throughout the country and it is unclear if they have set up an office elsewhere in Portland.)

another option besides landuse=construction would be landuse=brownfield for a vacant lot that used to have a building (both are shown as a brown area in the default map). Based on the other construction around this area, I suspect that something new will be will be built here fairly soon.
I do wonder if any of the businesses at this site were able to relocate to different locations nearby or if they closed for good.

Rather than using a name "construction site", which is a general description instead, I've changed this to remove the name tag and changed landuse=retail to landuse=construction. Once the construction is complete, there may be a sign posted with an actual name on it.

A lot of new Nodes created with this changeset are overlapping existing Nodes. This triggers the JOSM warning "Nodes at same position" and breaks things like routing and transit route relations. Can you merge all of these duplicate Nodes with existing Nodes?

For example:
Old Node:
node/1376372929
New Node at same position:
node/5796297710

Note: I've reverted this changeset fully in:
changeset/60597789

First of all, this section of road is not a dual-carriageway. There is no physical separation between the forward and backward direction. I'm not sure how you came to the conclusion to make this a dual-carriageway.

However, if this were correct to separate this into a dual-carriageway, then this changeset still would have had problems:

Transit Route Relations:
There were errors in the relations for bus route 4. If you are not familiar with transit route relations, these are setup so that there is a separate relation for each route variation. Most bus routes have at least 2 route relations (one for each direction of the route). The ordering of the members in the relation is significant (Nodes for bus stops, followed by Ways for the route to be followed in order). After your edit, the Ways for the route were not in the correct order. The editor iD does not fully support relation editing. Specifically, iD does not allow you to re-order the members of the relation to be in the correct order. If you are editing route relations, please use JOSM as if you can download the whole route relation and verify that the members are in the correct order. JOSM will also warn you if you try to upload a transit route relation that contains a gap.

Admin boundaries:
In this area, we have setup admin_level=10 admin boundary relations for neighborhoods. In some cases, the roads themselves are used in the admin boundary relation. However, if there is a dual-carriageway, then the roads are not used in the admin boundary, but instead a separate Way is drawn in between the road Ways. This separate Way for the admin boundary does not have tags as the tags are already on the relation. In your edit you have both sides of the dual-carriageway as part of the admin boundary, creating a gap in the admin boundary relation. Again, please use JOSM for tasks like this as it lets you download the entire admin boundary and verify that there are no gaps.

Sidewalks:
Sidewalks are tagged as attributes of the road, with one of:
sidewalk=no
sidewalk=left
sidewalk=right
sidewalk=both
For a single carriageway with sidewalk=both, this indicates that there are sidewalks on both sides of the road. When creating a dual-carriageway, this usually changes to sidewalk=right to indicate that there is a sidewalk along the right side of the dual-carriageway (and no sidewalk in the area between the dual-carriageway). Also, to indicate that pedestrians can cross the dual carriageway at a crosswalk, mark the ends of the crosswalk Nodes using highway=crossing and draw a Way connecting them with highway=footway and footway=crossing.

Bicycle Lanes:
For bicycle lanes, the tags may also need to be altered when converting from a single to dual carriageway. In this case, it was correct to leave it as cycleway=lane, but on a single carriageway there may be tags like cycleway:left=lane or cycleway:right=lane. These is a slightly more elaborate tagging scheme from sidewalks.

Turn restrictions:
In this case, there is a turn restriction only_straight_on indicating that you cannot make a left turn from Southeast Division Street heading east to the northbound onramp onto I-205. When splitting this into a dual carriageway, you have retained this turn restriction, but it should have been deleted. Care needs to be taken that the members of the turn restriction are correctly assigned roles "from", "via", and "to". If there was a traffic island separating the road directions on Southeast Division Street, then you would not be able to make a turn across the median traffic island. In general, turn restrictions should not be used when the road geometry and the oneway tags already imply the turn restrictions. Typically, at the start and end of a transition from single to dual carriageway, there is either an only_straight_on turn restriction of a no_u_turn turn restriction to indicate that you have to continue on the road and are not allowed to turn around after the traffic island ends. Note that local laws dictate that you are not allowed to make a U-turn unless there is a sign specifically allowing it. Check out the Bing streetside images here for additional verification.

Lanes:
This area has detailed lane tagging, including tags lanes, lanes:forward, lanes:backward, turn:lanes, turn:lanes:forward, turn:lanes:backward. Typically, when converting from a single to dual carriageway the lanes:forward and lanes:backward tags are removed and the lanes tag takes on the respective values. In this changeset, you have not paid attention to these tags and you have this showing as 4 lanes in one direction and 5 lanes in another direction. For editing turn:lanes, I use the JOSM plugin turnlanes-tagging (I believe developed by MapBox). See this informative blog post:
https://www.mapbox.com/mapping/mapping-for-navigation/adding-turn-lanes/

If you can elaborate on the rationale for making this section of Southeast Division Street a dual-carriageway, then I can assist you in making these types of edits correctly. Again, I recommend JOSM as it has a warning system built-in that would alert you to a lot of these problems.

I switched these from "ref=OR 141" to "unsigned_ref=OR 141" since there are not any 141 route shield signs posted. I also filled in the rest of the route from ODOT's website and created route relation objects

I've delete the relation for only_left_turn heading south on NW 9th Ave onto NW Hoyt St. The left turn sign only applies to the left-most lane. The right lane can go straight or turn right. I've updated the data.

Regarding
note/1019262

Generally, a shop that sells and rents bicycles would be tagged as shop=bicycle with service:bicycle:rental=yes. A place strictly for renting bicycles could be tagged as amenity=bicycle_rental (that is used for those Biketown PDX stations).

Generally in OSM we still use the same bike shop tagging to describe shops that deal with electrically assisted bicycles.

shop=bicycle

amenity=bicycle_rental

Based on the GenZe website, I could also see this as being tagged as a shop=motorcycle as they do sell scooters

shop=motorcycle

It makes sense that the router would tend to prefer other routes that don't go through highway=living_street as you would be required to drive really slowly on that section. However, in reality there is no such restriction (apart from the fact that you are more likely to have to slow down to avoid hitting cyclists).
You seem to be making these edits all over including places not local to yourself. Are you interfacing with local communities at all? I'll post on the talk-us email list to get some more feedback.
I live in Portland, Oregon and I think the tag bicycle=designated has been use quite a bit on roads around here that some government agency has determined should be better for bicycles (as such they are often signed with a "Bike Route" sign). However, bicycle=designated doesn't really say that cars should be discouraged from using the road at all. Also, I think the "greenway" designation goes above and beyond the regular bike routes, but cars are still allowed on those roads and still allowed to drive up to the speed limit where conditions permit. I could go along with adding a "bicycle:designated=greenway" to the roads.

Greenways should not be tagged as highway=living_street.

Rather than changing the highway tag on the Way objects for the roads, look at tags like sidewalk=* and cycleway=lane where sidewalks and bike lanes exist as part of the road.

The Greenway designation should probably best be captured with a bicycle route relation. For editing relations, it's best to use JOSM instead of iD.

Living Street is a concept that is mainly used in Europe for residential streets where pedestrians and cars share the road. In order to be safe, the speed limit is typically "walking speed" or about 3 mph. Most minor roads in the USA have speed limits between 20 and 30 mph so would not be characterized as a highway=living_street but rather highway=residential or highway=unclassified.