clay_c's Comments
| Changeset | When | Comment |
|---|---|---|
| 102822095 | over 4 years ago | Reverted. Please do not merge stop_area relations that are already contained within a stop_area_group relation. |
| 102817553 | over 4 years ago | Reverted. Please do not merge stop_area relations that are already contained within a stop_area_group relation. |
| 100583063 | over 4 years ago | Hi goldenking05, What is your source for the translations of these street names? It seems unlikely that these streets in small-town Indiana would have signage posted in Arabic and Chinese. Did you do these translations yourself? |
| 103061742 | over 4 years ago | No big deal. Each state has its own conventions for how it signs roads. ODOT is pretty consistent in signing them as "State Road" and mappers in Ohio have come to the consensus that refs should match signage. Likewise in Indiana. |
| 101357998 | over 4 years ago | I have already reverted the fictional railway features. See changeset/102436763 |
| 101944142 | over 4 years ago | Track numbers are not names. I don't think they belong in the name tag. That said, it's a pretty small issue and I don't care if you re-add them. If you're looking for a renderer that surfaces track numbers, check out OpenRailwayMap. |
| 88800826 | almost 5 years ago | So here's what it looks like happened. I had been using JOSM to review MBTA rail and I must have thought I had finished, so I moved on to reviewing Pittsburgh's light rail. Turns out I had some unsaved changes in Boston and accidentally rolled those into the same changeset. The changes in Boston seem to be only tweaking layer=* and level=* tags. The changes in Pennsylvania are aerial review of the T line between Library and Washington Junction, for example, changing service tags, or moving switches to more accurate locations. At any rate, I no longer have the same workflow and now avoid having two different areas loaded into one JOSM layer, so this kind of mistake won't happen again. |
| 88800826 | almost 5 years ago | Well that's weird. Thanks for calling this to my attention; I'm taking a look |
| 100806157 | almost 5 years ago | Hi Darrell, This isn't quite how light rail tagging is done. A node should not have both `public_transport=stop_position` and `railway=station`. What needs to be done here is the existing `railway=tram_stop` nodes should be retagged with `railway=stop`, and a new node with `railway=station` (and the other implied tags) should be placed at the visual center of the station. Do you want to take care of this or should I go ahead and do it? -Clay |
| 100929252 | almost 5 years ago | changeset comment should actually say Seattle Streetcar |
| 87106048 | almost 5 years ago | Well, `service=spur` remains in wide use and there is no indication on the wiki that it has been deprecated. It strikes me as odd that such a heavily used tag with a generally clear definition would be deprecated all of a sudden. Could you find the discussion and link it here? |
| 87106048 | almost 5 years ago | Where was the discussion on this deprecation? As a rail mapper that is news to me. IMO, the segment of railway in question should certainly be `service=spur` or `usage=industrial` at best. It is not a main track of a branch line. |
| 99717551 | almost 5 years ago | Reverted in changeset/100662307. Why did you undo my revert? This is not the agreed-upon way to tag temporally restricted railroads. The Escondido Subdivision is already mapped thoroughly and correctly. The source for this is derived from the California Rail Schematics document [1]. Please do not change any more tags along the Escondido Subdivision without first consulting the talk-us@ mailing list [2], the tagging@ mailing list [3], or the #rail channel in the OSMUS Slack [4]. Best regards, Clay [1] PDF download: https://dot.ca.gov/-/media/dot-media/programs/rail-mass-transportation/documents/f0009927-ca-rail-schematics-a11y.pdf [2] https://lists.openstreetmap.org/listinfo/talk-us |
| 55825797 | almost 5 years ago | I upgraded most streets that pass through stoplights to at least tertiary. In retrospect, that particular street probably shouldn't have been upgraded and I probably wouldn't have done the same today. Goof on my part. |
| 99797891 | almost 5 years ago | It doesn't matter whether you authorize it or not. That has no bearing on whether other people may add a driveway and buildings to OpenStreetMap. If you don't want these structures mapped, you are free to demolish them. |
| 83910377 | almost 5 years ago | No, it's in the correct place. |
| 98889136 | almost 5 years ago | Reverted in changeset/99695147. Tagging the track segments that support freight trains as railway=light_rail is incorrect because those particular tracks are built to a higher standard and support heavier trains. Light rail trains (route=light_rail) may travel on railway=rail in certain cases such as this one. |
| 98029750 | almost 5 years ago | Train station names are often, you guessed it, the same as the name of the locality they serve. I couldn't find any info on whether these future stations would have more catchy monikers (like maybe "Rockland Waterfront" or "Wiscasset Gateway") so I went with the safe assumption that they'd be named the most prevalent and obvious way. And of course these train stations don't exist yet; that's why they're tagged with the `proposed:` prefix. Is there any data consumer that mistakenly treats these as active train stations? |
| 99138996 | almost 5 years ago | Public transit route names on OSM are sort of a gray area right now. Generally they're given names that follow the format "[vehicle] [ref]: [origin] => [destination]" mostly for the convenience of maintaining them, despite this being a description and not a name. That said, the ref tag is substantially more important for matching up public transit data between OSM and an external source. Ideally we'll get to a point where The Name Is The Name Only. In some cases this would mean the name tag would actually be blank, since the route may have only a ref and not a name. |
| 98936849 | almost 5 years ago | Diary entry here: @clay_c/diary/395781 |