[OSM-talk] Abandoned Rails
moltonel 3x Combo
moltonel at gmail.com
Tue Aug 25 14:24:44 UTC 2015
On 24/08/2015, Richard Fairhurst <richard at systemed.net> wrote:
> cycle.travel's rendering is 1300 lines of CartoCSS, 1400 of .mml, 300 lines
> of Lua preprocessing, and 350 lines of Ruby/PostGIS postprocessing.
> Of this, the code required to show only operational railways is 100
> characters - a rounding error. It's a detail in a 1400-character line of
> .mml and it was copied directly from OSM-Bright, the base style used by
> switch2osm. In other words, anyone setting up an OSM tileserver from the
> canonical instructions already gets this for free.
Fair enough, it's easy to get a bootstrap (for the record, I was
talking about knowledge, not lines of code). The bootstrap might not
have been used or might not be available for a particular usecase, but
I get your point. Sorry for placing the principle of least surprise
bar too high.
> There are plenty of issues with OSM railway tagging that make decent
> rendering, routing and analysis hard. (railway=station covering both
> mainline stations and preserved heritage attractions is the first that
> springs to mind.) railway=dismantled is not one of them.
> As to whether utterly dismantled railways belong in the OSM database, I
> couldn't really care less. In terms of doctrine, they probably don't, though
> let's not overstate the issue: I suspect more bytes have been spilled in
> this thread than it would take to encode a dump of current
> railway=dismantled in .pbf format.
I'm aware of that (and skewing the ratio even further as I write
this), but this is about more than just railways. Sorry for the
fearmongering, but letting one kind of nonexistent objects into OSM
opens the door to more. Countering with "existing crap in the db
doesn't justify adding more crap" hasn't worked well in the past.
To be honest, I too could live with a few railway=dismantled in the
db. The bigger issues are the idea of allowing some data in even when
you agree it shouldn't be there, protecting that data for political
rather than technical reasons, and the precedent this would set.
> But Gregory, Greg and Jason have it
> right. This is not about some precious notion of purity, it's about
> Outside the two fundamentals of "openly licensed" and "crowdsourced", OSM is
> characterised by its pragmatism. We do what works. What works is a community
> of people who feel respected and empowered.
By preventing contributors to fix errors in the db (as miscommunicated
as they were, I'm sure the deletions that started this thread were
meant as fixes) just because they come from some kind of Most Valued
Contributor, you're disempowering the community as a whole to empower
a fraction of it. I'm not going to pull statistics out of my magick
hat, but to me this looks like a net long-term loss.
> And bearing in mind that we're
> talking about the US here, we need all the community we can get.
> Read Minh Nguyen's excellent new diary post
> (http://www.openstreetmap.org/user/Minh%20Nguyen/diary/35646). Even in the
> super-affluent, super-educated Bay Area, OSM is barely at the stage that
> Europe reached five or more years ago. It is "an endless parade of outdated
> street configurations, missing landmarks, test edits".
> But, he notes, there is "plenty of rail and bike infrastructure".
> This is what characterised OSM adoption here in Britain. The enthusiasts are
> the first to "get it": the railfans, the cyclists. Widespread take-up comes
> later, once the enthusiasts have built something good.
> The last thing we want to do in the US is drive away the few enthusiasts we
> currently have.
I know :( I'd hate to see someone leave because of that discussion.
I'd love to see improvements in the OSM tooling and/or schemas so that
we can properly map historical features. So that dismantled railways
(amongst other no-longer-existing features) can be mapped without
hurting present-day mapping, which was initially OSM's only usecase.
So that entering that kind of data isn't a deletion-worthy error
anymore, but a normal usecase.
More information about the talk