OpenStreetMap logo OpenStreetMap

Changeset When Comment
176142278 3 days ago

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.
---
#REVIEWED_BAD #OSMCHA
Published using OSMCha: https://osmcha.org/changesets/176142278

176142278 3 days ago

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.
---
#REVIEWED_BAD #OSMCHA
Published using OSMCha: https://osmcha.org/changesets/176142278

176142769 3 days ago

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.

changeset/176167535

176142639 3 days ago

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.

changeset/176167535

176142278 3 days ago

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.

changeset/176167535

175338357 22 days ago

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).
---

Published using OSMCha: https://osmcha.org/changesets/175338357

175338357 22 days ago

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.
---

Published using OSMCha: https://osmcha.org/changesets/175338357

175202002 26 days ago

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!
---

Published using OSMCha: https://osmcha.org/changesets/175202002

175006399 29 days ago

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.
---

Published using OSMCha: https://osmcha.org/changesets/175006399

175006399 29 days ago

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.
---

Published using OSMCha: https://osmcha.org/changesets/175006399

174904231 about 1 month ago

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!
---
#REVIEWED_GOOD #OSMCHA
Published using OSMCha: https://osmcha.org/changesets/174904231

174805694 about 1 month ago

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.
---
#REVIEWED_GOOD #OSMCHA
Published using OSMCha: https://osmcha.org/changesets/174805694

174805694 about 1 month ago

Thanks for the quick revert of the damage!
---
#REVIEWED_GOOD #OSMCHA
Published using OSMCha: https://osmcha.org/changesets/174805694

174799506 about 1 month ago

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?
---
#REVIEWED_BAD #OSMCHA
Published using OSMCha: https://osmcha.org/changesets/174799506

173645556 2 months ago

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 2 months ago

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!
---

Published using OSMCha: https://osmcha.org/changesets/173645556

173250739 2 months ago

(BTW, would be great to have you on there, as you're one of the most experienced and knowledgeable mappers in the area that's currently active :)
---

Published using OSMCha: https://osmcha.org/changesets/173250739

173250739 2 months ago

Overall, I don't have a strong preference, I just think we should be consistent either way, at the very least locally (per OSM principles) if not nationally or with OSM as a whole. Perhaps the #local-nrv channel in the OSMUS Slack, where several of the other most active NRV mappers hang out, might be a good venue to decide on this?

Just for reference, worldwide less than 20% of roundabouts have oneway= https://taginfo.openstreetmap.org/tags/junction%3Droundabout#combinations . On the other hand, in the US https://taginfo.geofabrik.de/north-america:us/tags/junction=roundabout#combinations and Virginia https://taginfo.geofabrik.de/north-america:us:virginia/tags/junction=roundabout#combinations that rises to over 50% (perhaps because of the lower familiarity and less consistent usage of roundabouts versus circulars and other types of junctions here versus in Europe and elsewhere, thus greater perceived need for explicit clarification).
---

Published using OSMCha: https://osmcha.org/changesets/173250739

173250739 2 months ago

Just FYI, I'd previously added `oneway=yes` here and elsewhere on local roundabouts (it generally wasn't present before) but later removed it as Osmose flagged it as redundant (FWIW) and per the wiki, `junction=roundabout` directly implies `oneway=yes` (and by definition a roundabout must be oneway), and in the prose it states:

> oneway=yes is implied and redundant. In specific cases, it can be added for clarity though.

If its "clearly" one way, seems like that second bit wouldn't apply here?

On the other hand, I do tend to prefer explicit over implicit tags, so there's that argument.
---

Published using OSMCha: https://osmcha.org/changesets/173250739

173120501 2 months ago

Long-term, seems this should be converted to the modern PTv2 schema to make it easier to work with, more widely consumable and follow current best practice, though as that's a major change to existing practice and should presumably be done in coordination with the order BT, etc. bus routes, I held off on that for now and just explicitly tagged it as PTv1. Any comments/input on that? You seem to be the local mapper with the most experience with public transport routes (its the one major area of OSM I haven't really touched before today), so I imagine there are considerations I haven't thought of here and I would propose this in a wider community discussion in e.g. the #local-nrv channel of the OSMUS Slack before going forward with anything.
---

Published using OSMCha: https://osmcha.org/changesets/173120501