Minh Nguyen's Comments
Changeset | When | Comment |
---|---|---|
94935084 | over 4 years ago | The source for hazmat classes was https://dot.ca.gov/programs/traffic-operations/legal-truck-access/restrict-list , which is in the public domain as a work of a California state government agency. |
94917704 | over 4 years ago | …added traffic lights, crosswalks; upgraded tracks to cycleways |
94224037 | over 4 years ago | Please take the time to learn more about the roads you’re editing before making changes to their classification. Recently you’ve changed several roads in the region to trunk or motorway, both of which have safety implications for routers. If these changes are motivated by wanting the rendered map to look more coherent, please understand that the highway network is often messy and incomplete in reality, so it’s important that our rationale for classifying roads be thoughtful and well-researched. I encourage you to join slack.openstreetmap.us to discuss these topics with the local mapping community in more detail. |
92965498 | over 4 years ago | Hi, thanks for the attention you paid to this part of the map. Changeset 94805058 changes this section of El Camino and The Alameda back to a primary road. I can see how this road might look from the air like a convenient connection between San Tomas and I-880, but I can assure you it’s anything but. A common-sense road classification scheme for the South Bay would classify El Camino and The Alameda the same way as other low-speed, uncontrolled-access roads (such as Stevens Creek and De La Cruz), as opposed to the county expressways (Lawrence, Central, San Tomas), which are high-speed and limited access with occasional grade-separated interchanges. If you have any questions or concerns, I’d be happy to explain further here, or please feel free to join OSMUS Slack’s #local-ca-sfbay channel, where we can discuss the topic with other local mappers more easily. |
68003191 | over 4 years ago | Hi, I think you mistakenly assumed that the CVS drugstore had been taken over by the Whole Foods Market, but in fact it was just misplaced. The drugstore and its pharmacy are next door. (This was the time I finally gave in and mapped the pharmacy counter separately because the pharmacy counter and drugstore have different hours.) Changeset 94798119 restores the drugstore, and changeset 94798245 moves both CVS POIs to the correct location next door, consistent with the DCGIS address node. |
94733422 | over 4 years ago | By the way, changeset 94727436 had originally attempted to place the monolith in the valley, but using Esri imagery. The monolith’s shadow is pretty clear in Esri imagery, but that layer is offset from Bing imagery. |
94409132 | over 4 years ago | Thanks for resolving these notes. By the way, if you haven’t seen it already, the OSIP 6in layer is much crisper and better aligned than NAIP, though it isn’t quite as up to date in Southwest Ohio. Bing is reasonably up-to-date in Greater Cincinnati, but somewhere in between OSIP and NAIP in terms of resolution. |
90052628 | over 4 years ago | Sorry to hear about harishwr’s situation – best wishes to him, and thanks to your team for the attention you’ve lavished on this part of the map. |
94093155 | over 4 years ago | The coastline ways shouldn’t be named. The name on way 591823494 seems to be an error left over from when osm.org/changeset/57065106 introduced osm.org/relation/8099409 . |
94093155 | over 4 years ago | (Correction: the San Francisco Bay relation, 9451753, includes ways redundant to the coastline ways, but not the coastline ways themselves. I’m unsure about the history behind that approach, but it does seem to result in a correct representation of the bay.) |
94093155 | over 4 years ago | Which application did you check? The San Francisco Bay Area relation at osm.org/relation/9451753 includes all the coastline ways as members, so it forms a polygon. If the application represents it as a point, it’s probably calculating the centroid automatically. |
94093155 | over 4 years ago | Is it possible to have it both ways? I realize it isn’t an exactly analogous situation, but San Francisco Bay appears to be mapped as both a bay and as a series of coastlines, and it seems to have been that way for a long time without breaking renderers and other data consumers: osm.org/relation/9451753
Nothing about the coastlines explicitly claims that the San Francisco Bay is part of the Pacific Ocean, so the only semantic challenge might be some redundancy between the bay and its coastlines. But that could be resolved by making the coastline ways part of the bay relation. In the case of the Chesapeake Bay, that would just be a matter of adding the coastline tags back to the ways surrounding the bay, but otherwise retaining the (useful!) bay relation. |
90052628 | over 4 years ago | Reverted in changeset 94184842. |
90052628 | over 4 years ago | Hi, please use an orthorectified imagery layer such as OSIP 6in when realigning roads. This bridge is straight, not crooked as in the Esri imagery. Thanks for your attention. |
92496491 | over 4 years ago | Hi, it looks like you accidentally changed a county border to a road. It probably happened because the border goes down the middle of Fields Ertel, which was already mapped as a road. The border apparently got selected when you tried to click on the road. To avoid accidentally editing borders in the future, you can filter them out by opening the Map Data panel on the right and deselecting Boundaries in the Map Features section. Let me know if you have any questions or run into any problems mapping something. |
94008245 | over 4 years ago | https://transportation.ky.gov/DistrictSix/Pages/Brent-Spence-Bridge-Update.aspx tracks reopening for both the bridge and the river. |
34297390 | over 4 years ago | No, I didn’t need to because the road geometries were already in good shape. I recorded voice notes from a trip to this area and entered all the details after I got back. |
93339866 | over 4 years ago | If I’m interpreting the changeset tags correctly, you’re citing osm.wiki/Special:PermanentLink/2045889#Multiple_names as justification for listing only one name in name=* (the Spanish name). But that page doesn’t preclude the inclusion of multiple names in name=* in exceptional cases. Did you have another page in mind? Here, the Spanish and English names roughly in the same ballpark in terms of international geographic relevance, even if the Spanish name is slightly more prominent in terms of coastline. Other North American bodies of water that straddle official linguistic boundaries, like the Gulf of Saint Lawrence or the Bering Strait, are still tagged with multiple names. There’s also this lengthy thread about (among other things) the prospect of applying multiple names to name=* on international bodies of water: https://lists.openstreetmap.org/pipermail/talk/2020-January/thread.html#83774 . It doesn’t seem to have arrived at a consensus, but it does highlight that the issue isn’t cut and dry. |
93515210 | over 4 years ago | Sorry, I won’t do it again. If it helps, https://overpass-turbo.eu/s/ZQ8 returns elements that were added or changed in this changeset. A more sophisticated attic query could return deleted elements as well. |
84850873 | almost 5 years ago | More context about boundary=census at osm.wiki/Tag:boundary%3Dcensus#United_States . It’s important to maintain a distinction between administrative boundaries and CDPs because these boundaries are determined and used very differently. As Elliott pointed out, your apparent desire to be ranked based on a CDP would be useful feedback to the developers of CityStrides. boundary=census relations should be straightforward for them to process just like boundary=administrative relations. |