OpenStreetMap logo OpenStreetMap

Changeset When Comment
138632413 over 2 years ago

I've driven under and over that bridge many times over the decades. Bernal goes over both Monterey and the railroad. Both Monterey and the railroad are at the same grade and are unfortunately too easy to cross by foot. You can also use Mapillary or StreetView to confirm that the Bernal Road bridge crosses all of it. The 2 bridges to the north and the next bridge to the south use the same layering scheme. Monterey, the sidewalk and railroad are at the same level and should be considered layer 0.

People have been known to cross this railroad and highway instead of the bridge at this area. In fact, Xander's Crossing to the north of here is named after a young child (Alexander Arriaga) that was killed by a train that was crossing the railroad in 2005 exactly where that bridge is located now. It was a tragic accident and all over the news. That area is pretty similar to this area.

There are not 3 layers here, and I'm sure of it.

138521986 over 2 years ago

Thanks I made the update.

137939861 over 2 years ago

This is a sign where the max speed is only when taking the left track instead of going straight. The sign is yellow with a left arrow underneath the numbers on the pole on left side of the track. The tag is trying to follow the format described here: osm.wiki/Conditional_restrictions#Tagging

Though I do admit that it’s missing the @. The condition is when going left and nothing more.

I had originally deleted the FIXME for this issue, since the limit was already on the track, and I was having a hard time addressing the FIXME tag to tag the sign correctly. @impiaaa didn’t like that solution.

The previous discussion on this topic can be found here: changeset/137889032

138028539 over 2 years ago

If it's a foot path, access=no wouldn't work. Your argument also seems contradictory by saying that it should be marked with access=no, but still have it connected for a proper routing network.

In any case, I reconnected it, and marked it private. It shouldn't be used by normal lay people nor be proposed by apps for excessively trusting people to follow. It's obviously meant just for maintenance workers.

138028539 over 2 years ago

The stairs to road still exist. The non-existent “foot path” crossing lanes of the freeway were removed. I also marked it access private. It still connects to the off ramp.

137889032 over 2 years ago

After spending another hour on the topic, I think I can use maxspeed:left:conditional to achieve what was being requested. I’ve made that change.

137889032 over 2 years ago

Actually, it's not quite like that. The speed limit data is already in the map, but it's not in the form requested. The speed limit is already on the tracks and not to the sign. I looked elsewhere on the map for examples, and they were only on the tracks themselves and no signs were used. Putting the same speed limit data in 2 places (the sign and the tracks) seemed redundant and problematic to keep in sync in the future.

137809433 over 2 years ago

Actually it is already surface=dirt, just like SF Giants stadium too. Most other baseball fields don't mark the infield area. It made sense to mark the area as sand, since it's not like the hard clay dirt that you see in a typical field. It's easier to slide on without little rocks tearing into your clothing.

137630953 over 2 years ago

Thanks

137744312 over 2 years ago

Good point. I've added place=suburb just like the Buena Vista and Willow Glen neighborhoods in San Jose. This one seems to be in Campbell though.

137630953 over 2 years ago

Perhaps I misunderstood the issue. I have reverted the change for now, until I can look deeper into this issue.

changeset/137697192

137630953 over 2 years ago

I didn’t think I was blindly changing this. The tags were slightly different, and I merged them. I’d be happy to hear what I did wrong. As far as I can tell, only the self relationship was lost and the rest of the data was kept. I thought that the relationship was supposed to work with other parts of the building and not the bottom part relating to itself on the lower part. Perhaps the relationship of the bottom part was supposed to be for the top part instead?

137630953 over 2 years ago

Yeah, the error that I saw said that "An entity must be present only once, remove one and eventually merge the tags."

137617795 over 2 years ago

Thank you for confirming and fixing the issue.

137398257 over 2 years ago

Yeah, I agree. It was really hard to find any sort of classification for these buildings. If you have a way to note that it’s a warehouse or billiards room or other community entertainment room, I’d like to hear it.

137295524 over 2 years ago

Thanks. I’ll keep that in mind for the future. This building is a small 2 story building, and the labels would definitely overlay each other if put to the most precise location. In some of the other business locations that I fixed, some of the original locations seemed to be placed in a way due to the desire to show the label from a distance and not crowded out on the screen. I tried to get those close to the right location without crowding out the other businesses.

137146474 over 2 years ago

The KeepRight Issues in the Open Street Map Data showed me that exact message, and I marked it as fixed today. The Wiki page from abutters=* says, "This could be used for rendering if landuse=* area information is not available." So it seems to be saying that landuse around the road should be used instead of marking the road itself as abutters. Perhaps it's not deprecated, but it seems to be discouraged in this kind of scenario.

136807641 over 2 years ago

I reverted the change. The property maps do list SCVWD as the owners of the parcels in the creek. So this change wasn't "wrong", but also the properties do list the parcels being split between San Jose and Campbell. So it wasn't completely correct either.

136807641 over 2 years ago

Thanks, based on further review of the maps on https://santaclaralafco.org/resources/maps, I see that there is a more precise definition of parcels and boundaries. Though the previous location from a few days ago was *also incorrect*. So I'll revert this change soon, and reorient it to what is provided by that LAFCO website.

136807641 over 2 years ago

The previous boundary contradicts with San Jose's GIS Open Data at https://gisdata-csj.opendata.arcgis.com/datasets/CSJ::city-council-districts-2011-archive/explore?location=37.277603%2C-121.975624%2C18.00

So how do we resolve this contradiction? San Jose's own website says that it's north of the creek and not south of the creek.