Also Wolfe is more similar to Homestead.

Yeah, demoting Wolfe between Stevens Creek and Homestead seems reasonable. It’s more like Vallco, Homestead and this segment of Tantau. That Wolfe segment seems lesser than Stevens Creek.

Though South Tantau should be more than a residential road, like a tertiary road. This segment of North Tantau seems more significant than South Tantau. I’d also classify this segment to be like a lot like Bollinger, Miller, Moorpark, Campbell and Stelling.

That’s my opinion.

I would say that it's similar to Vallco and Miller Ave. It has more lanes than Pruneridge. The Apple Park Store at the corner of Pruneridge and Tantau is a popular tourist destination. The east entrance to Apple Park is on Tantau. Apple Park probably has more than 12,000 employees and 14,200 parking spaces (source: https://en.wikipedia.org/wiki/Apple_Park).

Stevens Creek, Lawrence, Wolfe are very busy roads. It's safe to say that employees are using both entrances in large quantities in cars, buses, bicycles and other forms of transportation. The equivalent of a population of a town is entering and exiting the place on many days of the week. I think the traffic was modeled for the area when it was being built, which I believe the city of Cupertino and Apple had to do a study for.

A lot of the traffic from South Tantau is diverted onto Stevens Creek to go onto Lawrence and 280 (see recent turn restriction discussion). It's also frequently used when Wolfe is closed or restricted for construction, like for that big pipe being put in now.

Apple Park is a very large source and destination of traffic. This segment of the road is frequently used.

So apparently in the editor, here is what I had to do:
1) Select all relevant nodes and lines. You will have to use the shift key when selecting them.
2) Select "add to a relation".
3) Sort all nodes and lines from start to finish. A member may be included more than once, and those should be deleted.
4) Add member type "from", all of the "via" in the middle, and a final "to" to all of the members.

I didn't know that I could do #1, since it was only allowing me to select 3 members by default. This intersection has been updated accordingly.

How do you apply the restriction on a path through 2 nodes instead of a single node? The only alternative that I could think was to merge both Stevens Creek connections on Tantau into a single point, but that makes the route no longer follow the flow of traffic. The current paths do model the flow of traffic.

While that is true, I couldn't find a restriction that could leave the left turn lanes alone on Stevens Creek. The only restriction is that you can't have a vehicle go from North Tantau to South Tantau. The bicycle route goes both ways. You can turn left and right from Stevens Creek on to South Tantau. There is also an island blocking this only vehicle route from north to south Tantau. All other routes are unblocked.

Also you don't go through 2 traffic signals when going between north and south. So those were moved to their respective streets at the stop line.

If you have a more specific suggestion on how to model this very specific restriction, I'd appreciate to know a different solution.

I moved the loading_zn information to the actual segment of the road where there is a loading zone. At least I've seen people parked there waiting closest to the light rail in front of the buses. I added the bike rack back, but I can't verify it because I didn't see the location of the rack. It's hard to prove the non-existence, unless I scour the area more thoroughly.

Based on that information, I’ve switched it to ele:ft. I’ve done that for the following reasons.
1) The ele key is meant for the elevation of the object in meters. This value is not for the sign, but for the written contents.
2) The proposal said that ele:ft should be deprecated. That implies that it’s not deprecated yet, and it is used elsewhere. The unit is explicit, and easy to write.
3) It’s fairly common for editors in various operating systems to turn ASCII quotes to one of the various curly quotes. People also have a tough time remembering whether ‘ or “ means feet. If you need a hilarious example, watch the movie “This is Spinal Tap” with the Stonehenge discussion.

Thanks for that information. I moved the bike locker information to the bike locker in this changeset. The disabled capacity seemed wrong based on satellite imagery. I couldn't find the bike racks, even when I went there last time. I couldn't find the meaning of kiss_n_rid, and 0 didn't have meaning in my mind.

I'll look into adding loading_zn information, but I'll try to map it to more appropriate tags. I'll try to look into that later, perhaps today or tomorrow.

That's a fair point. I had not considered that view. The description of the key at ele=* says that the value is in meters. So the value seems invalid in that regard. Other objects use this value to note the elevation of the tagged object and not the contents of the sign. So what would you suggest from these options?
1) Leave it as is.
2) Revert it to the previous value.
3) Remove the tag because the value on the sign probably shouldn't be represented as this tag.
4) Convert the value on the sign to meters.

I was matching the same relationship style as the California and Santa Clara County subarea relationship.

I thought they were play structures or temporary sun shades. After reviewing the streetside view, they do look like permanent roofs. I've added roofs that seem to exist in the most recent imagery.

The topographic map is decent for names of trails and streams, but it tends to simplify a route and makes it too smooth. The GPS routes for roads and trails that I've seen traced provide a rough path, but they can easily be off under dense woods. For example, the vast majority of Mapillary routes are pretty good at being within a road route, but occasionally some routes go straight through homes and boulders. Some GPS routes waiver around a trail.

The USGS 3DEP routes align very well with the satellite imagery. It's pretty common to move a route to a perceived location with 3DEP, and when you cross check it with the satellite imagery, you can see the trail peeking out between the trees sometimes. So far so good.

The USGS 3DEP data can also highlight interesting cliffs, canyons and crevices in parks that look so flat and bland in satellite imagery.

That’s a fair point. I’ll try to resolve that this evening. Thanks.

Why did you switch these areas from wetlands to water features? I think the website at https://www.southbayrestoration.org/page/maps is much more accurate on the status of these areas than the course grained information in the USFWS. Did you get a chance to view that website listed in the notes?

When I edited this with the OpenStreetMap editor, it merged the points automatically. I assume that is the desired behavior, since the editor merged them. There were previously warnings about the points overlapping. The first attempted fix was to add layer values to each sign, but this merging seemed acceptable too.

When I looked at the documentation about signs on a pole, they should be on the same point. Here is that documentation: traffic_sign=*#Tagging

Separate signs should be separated by a semicolon and related parts of a sign should be separated by a comma.

This “tourist attraction” called a DUMP is of questionable accuracy. There is no path to it. It’s really hard to see it from satellite imagery or from the road. This is being removed. If it is a valid point of interest, please add it back with more information about what kind of attraction it is so that others understand what it really is and can navigate to it safely.

Good point. I've switched it to disused:shop=yes

I see that the hours for the park were updated. Unfortunately, the format of the provided open hours was invalid. The format was just fixed for the park with changeset/139775577. If you're using the web browser editor, you can click the "i" next to a field to see more information about that field. In this case, more information can be found here: opening_hours=*

Thanks for your contribution.

Thanks