whammo's Comments
| Changeset | When | Comment |
|---|---|---|
| 138782091 | Hi Beakerboy, what is the Bluegrass Region and where did you find this definition for it? |
|
| 156181105 | Ok, sounds good. Just as food for thought, is it not possible the boundary represents where the banks of the rivers were 120 years ago (and thus not necessarily where they are now)? |
|
| 156181105 | Can you point to where you see that definition of Houston County's border? I didn't check primary sources before making edits, and the state of Alabama doesn't provide any comprehensive county boundary data that I can find, but the Houston County parcel viewer (the only semi-official county boundary I can find online) that I'm looking at now doesn't match your description of the county border along that stretch as far as I can tell, in fact it appears to be identical to the TIGER line that I added. |
|
| 154674011 | Hi HonestMapper, as others have pointed out to you, deleting these roads is not the solution. All of these road are correctly marked as private, so I doubt that any rideshare drivers or strangers coming through this area are doing so because of OpenStreetMap data. You can peruse the explainer here, and let me know here if you have any questions: osm.wiki/Why_we_won%27t_delete_roads_on_private_property |
|
| 154533505 | Hi shortkim, thanks for helping to improve the map. Please add more descriptive and useful changeset comments in the future, so that other mappers can easily understand what you've done. Thanks!
|
|
| 154403536 | Hi Dylan, please use more descriptive changeset comments in the future. "Local knowledge" is a source, if anything. See here: osm.wiki/Good_changeset_comments Also, land landuse tags should not be used on nodes. |
|
| 151167316 | It looks like the full raw address string from ATP my tools had to parse was `9150 A Alcosta Blvd, Country Club Village S.C., San Ramon, CA 94583`, and it read S.C. as South Carolina :( Most Starbucks POIs don't have that place name in their address string, and even fewer abbreviate "shopping center" like that, but I will double check the handful of nodes I see that appear to be similar. Thanks! |
|
| 153904537 | I did not check before uploading, but it appears the ATP info was correct, and the existing `not:brand:wikidata` tag was not. Again, (as I mentioned here: changeset/153929369) this import is not meant to go through every POI to do cleanup, I'm just adding info. So I will try to look for this going forward, but this is an edge of an edge case (an erroneous `not:brand:wikidata` tag, of which there are <3,000 in the US to begin with) that I suspect I won't encounter again. |
|
| 153929369 | The rules I have check for `contact:website` and only remove that in favor of `website` if the two match exactly. The whole principle of this import has been "first do no harm," and because I'm not going through every URL on every node, I'm not gonna remove URL tags just because they are potentially duplicative. In this case it looks like the URL was broken by the `#` symbol (not sure how that got there in the ATP data), which also broke the matching. I've checked and this was the only URL for 7-Eleven that has that issue. |
|
| 153406066 | What do you need help with? |
|
| 153353887 | Hi PeterDesignTowers, thanks for improving OSM in Northern Virginia. Usually, there is no need to move highway nodes a meter or two as you've done here, as different satellite imagery providers might have slightly different alignments, and it's hard to know which is the closest to reality. |
|
| 153268450 | FYI I have reverted all of this user's changes around the Capital Beltway |
|
| 153014499 | Hi Tyler, I appreciate the work you've done to add this congressional district to OSM. However, we usually avoid adding electoral districts in the US because they change at least every 10 years and are not widely useful to data consumers. Is there a reason you think this (and the other couple congressional districts you added) would be an exception to that general principle? |
|
| 152937570 | Yeah, not sure if the closure is permanent or temporary, hence the lifecycle prefix and not deletion, but being closed every day suggests to me some state of disuse. If you have on-the-ground insight that would be great! |
|
| 151167285 | FYI, just fixed the `website` tag here: changeset/152920594. I was half hoping that they would reinstate the `/store/{ref}` url pattern that GMaps also relies on, but it looks like we're stuck with all the junk at the end of the url. |
|
| 151531033 | I think I've fixed it in this changeset: changeset/152919606. Let me know if I did not. Now that I know this quirk (thanks!), there seems to be a lot of objects with the direction at the end of the `addr:housenumber` field, see this Overpass query: https://overpass-turbo.eu/s/1N6u. This wouldn't be too hard to fix using JOSM. |
|
| 151531033 | Hi dknelson, I'm happy to take a look. I've built my own parser to turn raw address strings into OSM tags. Can you point me to an example so I know what you're talking about? |
|
| 151668196 | Hi cotesta, where there are no weekdays listed, the opening hours are the same every day of the week. This is standard formatting for the `opening_hours` tag. I left the "Mo-Su" weekdays on the `opening_hours:drive_through` tag because that tag is not nearly as common so I wanted to be extra explicit. |
|
| 151668196 | Hi SomeoneElse, this data import is part of the ongoing import of All the Places data onto existing OSM objects, as linked in the changeset tags. The discussion about this import is here: https://community.openstreetmap.org/t/proposed-import-of-all-the-places-data-onto-existing-fast-food-and-cafe-pois-in-the-us/112505. |
|
| 151668196 | This changeset was meant to fix bad ATP data I had accidentally imported from the broken Wendy's ATP spider. See here: https://github.com/alltheplaces/alltheplaces/issues/8373 |