Minh Nguyen's Comments
| Changeset | When | Comment |
|---|---|---|
| 101477458 | Take a look at Esri World Imagery (2022 vintage). This playground used to be marked with a baseball field and some sets of railroad tracks, all painted. All of it was replaced by a soccer field as of 2023, but I strongly suspect that the painted railroad tracks indicate the precise location of the subway lines below the playground. What do you say we move the subway lines there and delete the not:railways? |
|
| 167465187 | Yes, it looks like labels for other things are colliding with it and take precedence at other zoom levels due to limited space. Maps tend to prioritize labels based on size. A subdivision of this size is unlikely to be labeled very prominently, but you’ll have more luck with a larger subdivision, such as Chalets or Valley Lake Estates nearby. |
|
| 167465187 | Hey, I noticed this addition from your comment in https://github.com/gravitystorm/openstreetmap-carto/issues/104#issuecomment-2960676006. Is The Basin a residential subdivision? If so, consider retagging this way as landuse=residential instead of as a boundary. OSM Carto and some other maps will give it a nice background fill and label. |
|
| 166493926 | Addresses are from https://gis.countyofnapa.org/portal/apps/webappviewer/index.html?id=0bbafe490c58430da719ff851c78b7fa |
|
| 166460272 | Also added some traffic signs at the Napa County line about the glassy-winged sharpshooter. |
|
| 166451643 | Brave of you to rely solely on landuse=education instead of dual-tagging the grounds with amenity=school so that it still appears on OSM Carto. 💪 |
|
| 165698735 | This was also based on a field survey in 2022. |
|
| 162094261 | OK, thanks, I did a find-and-replace in changeset/164907952. If we can map enough of these, I think there’s a decent chance of restoring the American spelling as part of https://github.com/openstreetmap/id-tagging-schema/issues/1515 |
|
| 164907952 | See the discussion in changeset/162094261. |
|
| 162094261 | traffic_sign=neighborhood_watch is an American spelling; I’ve been using neighbourhood_watch instead, with an extra u. Do you think we should switch to that spelling, or use a different tag entirely? https://community.openstreetmap.org/t/neighbourhood-watch-signs/128215/5 |
|
| 163369601 | Ah, that makes sense. I hope eventually the community will coalesce around one of the tags so software can better support it. For what it’s worth, the uncommon tags warning is good at catching typos or opportunities to align to more common terms (especially British English terms that Americans don’t know), but I think there’s a more specific warning for deprecated tags. |
|
| 163369601 | Hi, I noticed that some service=shared_driveway got retagged as service=driveway. If you disagree with service=shared_driveway, can you pick one of the other tagging schemes at service=driveway#Pipestems or omit service=*? Some renderers and routers intentionally omit driveways, but they still need to show or route along these shared driveways because there are decision points along them. |
|
| 162592014 | Also, thanks for finally completing Warren County’s townships! |
|
| 162592014 | Hi, note that place=* tags intentionally don’t correspond to official designations as cities and villages, because they have to be harmonized globally or at least nationally. changeset/163881091 changes South Lebanon back to a place=village. The boundary relation already indicates the official designation via border_type=city. For more information: osm.wiki/Ohio/Map_features#Places
|
|
| 140452137 | Every member way of the Cary boundary relation has a name=* like “Town of Cary / Town of Apex” or “Town of Cary, Inner Boundary”. Is there a quirk of local law that calls for this naming practice, or was it only for convenience while doing this alignment work? Can we remove the names and the boundary=administrative tags from these ways? They interfere with geocoding, causing Nominatim (for example) to think each ring of the multipolygon geometry is a boundary in its own right. |
|
| 163261458 | Source was a survey back in November. |
|
| 163109218 | changeset/163139172 moves U.S.A. to short_official_name=*, which appears to be in use as well. |
|
| 163109218 | U.S. is the preferred abbreviation of United States in American English. U.S.A. is the preferred abbreviation of United States of America, which is much more common overseas. Domestically, native speakers only use United States and U.S. in most contexts. U.S.A. only occurs for nationalistic emphasis, like at political rallies or sporting events. Conventional abbreviations for countries and states in English aren’t defined by governments. Instead, dictionaries and style guides like the AP Stylebook (yes, the one that now includes guidance about a certain gulf) and Chicago Manual of Style include rules about these abbreviations and when to use them. These style guides differ on whether to include periods or not, even depending on context. Within the U.S. federal government, the Government Publishing Office has its own GPO Style Manual, which specifies U.S.A. as a conventional abbreviation for United States of America, but notably the guide itself consistently uses U.S. throughout as an abbreviation of United States, even though it isn’t listed. Nevertheless, this style manual is only used in legal and administrative publications. [1] The GPO dropped conventional state abbreviations decades ago in favor of ISO/ANSI/FIPS/USPS codes. On the state boundary relations, we’re putting those codes into dedicated keys or ref=*, reserving short_name=* for conventional abbreviations. Wikipedia has a good overview of the various authorities for English style. [2] I was considering swapping the short_name and alt_short_name keys, but I have no idea which one users are more likely to search for. Mainly I just wanted to correct the “U.S.A” which was missing a period. Unlike in some other languages, the last letter of an initialism needs a period too. But now that you mention it, we should list both U.S. and U.S.A. in short_name, since I don’t think
[1] https://www.govinfo.gov/content/pkg/GPO-STYLEMANUAL-2016/pdf/GPO-STYLEMANUAL-2016.pdf#page=261
|
|
| 163072059 | Reverted in changeset/163109297. |
|
| 163072163 | Reverted in changeset/163109177. |