Re: [Talk-us] [Tagging] Extremely long Amtrak route relations / coastline v. water
On Sun, Nov 22, 2020 at 11:12 AM Dave F via Tagging < tagg...@openstreetmap.org> wrote: > On 22/11/2020 11:24, Richard Fairhurst wrote: > > > I sincerely hope "I'm in favor of fixing" translates as "I'm planning to > fix", though I fear I may be disappointed. > > More broadly, we need to nip this "oh just fix the tools" stuff in the > bud. (etc) > > > Likewise we need to stop software developers from expecting contributors > to add data purely because they can't be bothered/not competent enough to > write a few lines of code. (OSM-carto demanding boundaries on ways & > numerous routers expecting multiple foodways to criss-cross pedestrian > areas, are just two examples) > > Contributing to the database (also *volunteers*) are expected to map to a > certain standard. There shouldn't be a reason to expect develops not to do > the same. > If it's so easy, why don't you write the "few lines of code" necessary to fix this issue? > Desiring relations to list in their entirety is *not* a "0.1% case". > Splitting them into 'super relations' should not be the desired, final > solution. > Amtrak routes, like many other public transit routes, are already split into super-relations (see [1], [2]). This is a non-issue. I've already decided to split up long-distance Amtrak routes into more manageable chunks, especially since I'm the one who takes on most of the work of managing them. My original question was *how* to split them up, not *whether* to split them. I'm not convinced that attempts to persuade me not to do so are helpful in any way, so I'm going to consider them off-topic and ignore them. -Clay [1] https://wiki.openstreetmap.org/wiki/Relation:route_master [2] https://wiki.openstreetmap.org/wiki/Amtrak ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Tagging] Extremely long Amtrak route relations / coastline v. water
Nov 22, 2020, 17:08 by tagg...@openstreetmap.org: > Likewise we need to stop software developers from expectingcontributors > to add data purely because they can't be bothered/notcompetent enough to > write a few lines of code. (OSM-carto demandingboundaries on ways) > [citation needed] for OSM-carto demandingboundaries on ways Also [citation needed] for OSM-Carto support for boundary relations being extremely easy to implement > & numerous routers expecting multiplefoodways to criss-cross pedestrian > areas, are just two examples) > Also [citation needed] for that reason is "can't be bothered/notcompetent enough to write a few lines of code" > If developers are offended at receiving suggestions on how toimprove > their software, or even have it criticized, then they shouldrescind it. > If you insult others, claim that something is trivial to implement (it is not), while something you demand is implemented already and suggest that anyone offended by your comments should stop releasing software I would say that it is quite poor way to encourage volunteer contributors to implement what you want. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] weeklyOSM #539 2020-11-10-2020-11-16
The weekly round-up of OSM news, issue # 539, is now available online in English, giving as always a summary of a lot of things happening in the openstreetmap world: https://www.weeklyosm.eu/en/archives/13975/ Enjoy! Did you know that you can also submit messages for the weeklyOSM? Just log in to https://osmbc.openstreetmap.de/login with your OSM account. Read more about how to write a post here: http://www.weeklyosm.eu/this-news-should-be-in-weeklyosm weeklyOSM? who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages where?: https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3 ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Extremely long Amtrak route relations / coastline v. water
[cross-posted to talk-us@ and tagging@, please choose your follow-ups wisely] Brian M. Sperlongano wrote: > It seems that we are increasingly doing things to simplify the > model because certain tooling can't handle the real level of > complexity that exists in the real world. I'm in favor of fixing > the tooling rather than neutering the data. I sincerely hope "I'm in favor of fixing" translates as "I'm planning to fix", though I fear I may be disappointed. More broadly, we need to nip this "oh just fix the tools" stuff in the bud. OSM optimises for the mapper, because mappers are our most valuable resource. That's how it's always been and that's how it should be. But that does not mean that volunteer tool authors should rewrite their tools to cope with the 0.1% case; nor that it is reasonable for mappers to make stuff ever more complex and expect developers to automatically fall in line; nor that any given map has a obligation to render this 0.1%, or indeed, anything that the map's creator doesn't want to render. The Tongass National Forest is not "in the real world", it is an artificial administrative construct drawn up on some bureaucrat's desk. It's not an actual forest where the boundaries represent a single contiguous mass of trees. Nothing is lost or "neutered" by mapping it as several relations (with a super-relation for completeness if you insist), just as nothing is lost by tagging Chesapeake Bay with the series of letters "c","o","a","s","t","l","i","n" and "e". Richard ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Extremely long Amtrak route relations
On Sat, 21 Nov 2020, at 18:06, Clay Smalley wrote: > Many long-distance Amtrak trains have route relations with 1000+ > members. If I split one way that happens to be a member of one of these > routes, I end up with a changeset with a gigantic bounding box, and > often get edit conflicts due to someone doing a similar change hundreds > of miles away along the same line. While mapping lots of little admin bounadaries in Ireland, I encountered this problem too, with splitting the "Ireland" admin boundary on the coast. It's a PITA, but if you upload & download/update as often as possible (even as soon as you make a change/split the way), then yous can alleviate as much as of the problem as possible. Essentiall "edit live" On Sat, 21 Nov 2020, at 21:58, Brian M. Sperlongano wrote: > Personally, I think if the world is complicated, the model should be > complicated. If the thing we're modeling is large in the world, it > should be large in the map. It seems that we are increasingly doing > things to simplify the model because certain tooling can't handle the > real level of complexity that exists in the real world. I'm in favor > of fixing the tooling rather than neutering the data. I 100% agree. Let's fix the tooling. Let's not map for database backend. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
