OpenStreetMap
CAM-Gerlach's Comments
| Changeset | When | Comment |
|---|---|---|
| 176142769 | Just to clarify, the changset was reverted per the above; please see my comments on changeset #176142278 changeset/176142278
|
|
| 176142639 | Just to clarify, the changset was reverted per the above; please see my comments on changeset #176142278 changeset/176142278 Also, please be sure to take a second to provide a useful changeset summary per the OSM guidelines: osm.wiki/Good_changeset_comments , or at the very least a meaningful one, to allow other mappers like myself to easily understand what you've done and why. Your previous changeset was in fact fine example of a useful one, that helped me at least start to understand what you were trying to do there. Thanks.
|
|
| 176142278 | As others have previously reminded you a couple times now, OSM is a production database relied on in some form by perhaps billions of people across the world, so it is important to take at least basic care when making changes that could disrupt the map. Unfortunately, many if not most of your other changesets so far have consistently caused similar breakage and disruption that needed to be fixed or reverted by other mappers, several of which were previously pointed out to you. While mistakes happen, I would strongly encourage you to take advantage of the many knowledge resources available (the wiki, forum, Discord, Slack, other mappers like myself, etc.) and take care when mapping to make sure this pattern doesn't continue. Thanks, and happy mapping. |
|
| 176142278 | I can see from the changeset metadata that your editor, iD, detected and warned you about several of the most critical issues across multiple changesets, but these warnings were dismissed and the changeset uploaded anyway. While not every validator warning always needs to be fixed before submitting a changeset, especially as a new contributor using a beginner-focused editor it is important to pay careful attention to likely mistakes, and not dismiss a warning unless you fully understand it and are reasonably sure it is a false positive (and indeed, the particular issues it flagged are basically always errors that will break something), especially if it was introduced by your changeset. |
|
| 176142278 | Given the degree of the damage over multiple changesets, the only viable option here to repair it was a complete revert, which I've gone ahead and done. I've additionally gone ahead and performed the split properly in a followup changeset, #176167974 changeset/176167974 , along with other additions and fixes to the building tagging.
|
|
| 176142278 | Hi Thomas, It seems generally reasonable to split AJ into East and West AJ, since they have separate addresses, VT building refs and other properties, and (in my experience at VT) were often referred to separately. However, unfortunately this changeset and those that followed left the building and its surroundings with a number of instances of broken geometry (unclosed multipolygons, crossing ways, invalid polygons, duplicated and stray nodes, unconnected footways and entrances, etc) as well as conflicting tags and left the central part of the building missing entirely. Furthermore, it does not actually accomplish the intended objective of splitting split the building--both parts are still part of the same building= multipolygon with the same name, now with two unnamed, nested "buildings" inside of it.
|
|
| 176142769 | Changesets left the building and with broken geometry (unclosed/invalid multipolygons, crossing ways, dupe nodes, unconnected footways/entrances, etc), conflicting tags, was missing the center of the building and didn't actually split the building. |
|
| 176142639 | Changesets left the building and with broken geometry (unclosed/invalid multipolygons, crossing ways, dupe nodes, unconnected footways/entrances, etc), conflicting tags, was missing the center of the building and didn't actually split the building. |
|
| 176142278 | Changesets left the building and with broken geometry (unclosed/invalid multipolygons, crossing ways, dupe nodes, unconnected footways/entrances, etc), conflicting tags, was missing the center of the building and didn't actually split the building. |
|
| 175338357 | I've fixed this in changeset #175376236 https://osmcha.org/changesets/175376236 as well as refined the Price's Fork eastbound positioning to better align with reliable imagery and reduce the skew in that direction, as well as using `placement` to displace the turn lane to the motorway link to its correct position. (I considered merging the two Price's Fork westbound ways, but as that would modify a bunch of bus route relations ballooning the changeset size, I decided against it).
|
|
| 175338357 | Hey, so just FYI as this changeset neglected to update the corresponding tags when changing the modeling/geometry, it resulted in broken tagging and route guidance, with an incorrect `lanes` and missing `turn:lanes`, `destination:lanes` and `destination:lanes:ref` on the Price's Fork Road westbound way leading in to the junction, and spurious `turn:lanes`, `destination:lanes` and `destination:lanes:ref` that lead to nowhere on the way before that. Also, while given the lack of physical separation the modeling change is justifiable per OSM conventions, the new motorway link positioning is displaced well off the physical carriageway centerline it should be following, leading to skewed turn geometry for Price's Fork westbound.
|
|
| 175202002 | Welcome to OpenStreetMap. We're glad you're here (or perhaps returning, judging from your name?). Thanks for adding the details on this cafe! As a quick tip, its really helpful to fill out the `source` field on your changset, so other mappers know how you collected the data (in-person survey? Website? Something else?). Also, any chance you can check and add the unit number (`addr:unit`), and merge this node with the existing address node with that unit number, to avoid duplication? Finally, per national convention its a good idea to include at least the addr:state (VA) and addr:city (Blacksburg), and perhaps addr:country (US) per local convention. Thanks, and looking forward to your future contributions!
|
|
| 175006399 | Thanks, just fixing my own mistake :) I'd broken it a few changesets before in #174938202 https://osmcha.org/changesets/174938202 while splitting up a landuse multipolygon into finer chunks, and somehow missed that the VT boundary also used the same way. JOSM's validator didn't catch it somehow, perhaps because the relation wasn't fully downloaded (although it usually warns on modifying an incomplete relation too which would have flagged the issue, so not sure what happened there). In any case, all fixed.
|
|
| 175006399 | Thanks, just fixing my own mistake :) I'd broken it a few changesets before in #174938202 https://osmcha.org/changesets/174938202 while splitting up a landuse multipolygon into finer chunks, and somehow missed that the VT boundary also used the same way. JOSM's validator didn't catch it somehow, perhaps because the relation wasn't fully downloaded (although it usually warns on modifying an incomplete relation too which would have flagged the issue, so not sure what happened there). In any case, all fixed.
|
|
| 174904231 | Thanks for the catch! One of my new custom presets had a typo that my bevy of validators didn't catch, sorry--in the process of further expanding my custom validator suite. Preset fixed going forward and also double-checked there were no other instances of it across the areas that I map. Thanks again!
|
|
| 174805694 | I'll keep monitoring the user and report to DWG if necessary if there's no response after a reasonable amount of time or they do further damage in the meantime.
|
|
| 174805694 | Thanks for the quick revert of the damage!
|
|
| 174799506 | Given the spammy changeset comment, the lack of any intentional valid content to upload and the blatantly damaging nature of the change, it appears this may have been intentional (or at the very least severely misguided), and may need further escalation. But first, Nicomarvin, would you care to explain what motivated this change?
|
|
| 173645556 | I see, then indeed there was something I was missing there. Sorry about that; my sincere apologies for the inadvertent mistake and failing to meet my usual standards of due care and diligence. Not sure how I somehow missed it the first time—might have had too many custom map styles enabled, or neglected to check as I normally would with wireframe mode off after aligning that way. I'll ensure I do so next time. In any case, thanks for the catch, and for taking the time to explain. Cheers. |
|
| 173645556 | Hey Frank, I'm curious on the source for the sign being removed? As far as I could tell, it was present on the ground in KartaView imagery from 2017, Streetside from 2020 and Mapillary from 2021, and I _think_ I can just spot the shadow in late-2022 VBMP (and its obscured by trees in early-2023 Bing, which was the only source cited in the changeset). Did it just get removed recently per an uncited in-person survey? Or is there something else I'm missing here? Thanks!
|