OpenStreetMap
CAM-Gerlach's Comments
| Changeset | When | Comment |
|---|---|---|
| 175766843 | Hi Thomas, unfortunately this changeset further compounded the problem introduced in changeset #175766539 changeset/175766539 as it added a _third_ layer of nested building inside the building:part multipolygon (turned building), itself inside the actual building multipolygon. Namely, it added another `building=yes` tag to the inner way of the original building:part, making for three buildings in the same space (two with identical outlines), and again conflicting with the more precise building tags on the outer building. As such, I once again had to revert the change.
|
|
| 175766539 | Given many of your other changesets share the same basic issue, I'd really advise consulting the OSM wiki to help you understand how building tagging works in OSM, particularly the simple buildings schema: wiki.openstreetmap.org/wiki/Simple_3D_Buildings , and I'd be glad to explain further if there is anything you still aren't clear on. Thanks, and happy mapping.
|
|
| 175766539 | Hi Thomas, I'm not really clear what you were trying to do with this changeset (a descriptive changset summary, like you did on changeset #176142278 , goes a long way toward that). The multipolygon you modified, which itself was one part of a larger building (with a single overall name, address and properties), was already correctly tagged as such with `building:part`, with the encompassing overall building tagged `building=university`. This changeset tagged the central part of that that latter building as a nested building (which is not considered valid OSM tagging; two entirely buildings cannot physically occupy the same space, unlike a building:part). Furthermore, it tagged it as `building=yes`, which is less precise and conflicting tagging with the outer building. Therefore, given it was strictly a regression from the existing correct tagging, I reverted both changesets.
|
|
| 175766843 | Changset reverted due to triple-nested and conflicting tagging of building=yes on a way and two levels of multipolygon, when the original building:part tagging on the part multipolygon and building on the full building was entirely correct, and more precise. |
|
| 175766539 | Changset reverted due to triple-nested and conflicting tagging of building=yes on a way and two levels of multipolygon, when the original building:part tagging on the part multipolygon and building on the full building was entirely correct, and more precise. |
|
| 174478608 | Also, if I understand you correctly that you are mapping on behalf of or for a benefit of a client, or your mapping is otherwise connected to what you are paid to do, this is allowed but you will want to carefully consult OSM's Organized Editing policy: osm.wiki/Organised_Editing and follow the relevant guidelines https://osmfoundation.org/wiki/Organised_Editing_Guidelines |
|
| 174478608 | And more importantly, it is even more strictly prohibited by OSM policy (above and beyond what the law specifically requires); any such contaminated or potentially contaminated changeset will need to be purged. Could you please confirm that you understand this and will take care to abide by it, and whether it was used for any of your other changesets? Thanks, and happy mapping.
|
|
| 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.
|