On Fri, May 24, 2019 at 8:49 AM Christoph Hormann <o...@imagico.de> wrote: > You should not assume just because people articulate all kinds of > strange views and opinions on these channels that are evidently flawed > that the discourse on a whole is pointless.
I'm not asserting that it is pointless - I'm still here, after all! I'm asserting that it provides little useful information about _current_ practice, since it chiefly devotes its attention to _future_ practice: it discusses an ideal world, rather than the real world that we inhabit. Case in point: When I was a novice mapper, too uninformed to know what the result would be, I made the mistake of asking here how to map a 2-way STOP sign. I'd seen 'direction="' on the Wiki, seen on the talk page that it had been controversial, and saw none near me in Overpass. I heard a cacophony of replies. One person insisted that a node cannot have a direction=* and that the only way to model such a thing would be to add a new type of relation that none of the tools support. Another person said that the only way to model it would be to place a node off the way to model the sign itself, indicate which way the node faced, and somehow expect routers and navigation software to deal with it. The discussion wandered off into the weeds of how to improve the data model to encompass various sorts of traffic restriction that were far beyond the scope of my question, for instance a STOP sign that applies only to certain traffic lanes or a particular turn direction. The one useful thing that came of it was that one person sent me a reply - off the list, no less - that I needed to cast my net a bit farther in looking for direction=*. I learnt that: - highway=stop direction=* is well accepted, with over 100000 instances in North America alone. - JOSM, at least, warns when splitting a highway at a highway=stop or highway=give_way, and when you reverse the direction of a way containing such a node, offers to reverse the node as well. - OSMand, at least, respects the direction of highway=stop in its spoken and on-screen warnings of approaching hazards. In short, what I had considered but was doubtful of on initial inquiry was widely used, well supported by at least some of the tools, documented on the WIki, and apparently agreed-to by a fairly broad community, pretty much everywhere but here. That's human nature too, really. Those who agree with the consensus have little incentive to speak up, and those who disagree will be highly motivated to seize the opportunity to argue for their ideas. Nevertheless, that's why a forum that supports the passionate advocacy of new ideas will be a poor place to get information about the current practice. > What i criticize > in case of iD presets and validations is not primarily that iD > developers make decisions the way they do (which i do but which i also > consider to be their legitimate decision) but that the OSMF endorses > this as the default way of editing OSM online via the website giving it > an unfair advantage over any competing system of presets and > validation. That adds on top of the pre-existing advantage of being > financially backed in a significant way (by paying developers) by > multiple (and in parts still anonymous) financiers. Fair enough, but what would we gain by taking it off the homepage? I suppose more could be done to present competing tools on an equal footing, but so far the only tool that appears to play in the same space is Potlatch. (JOSM, Meerkartor, QGIS, etc. are all stand-alone applications, not something that you can simply pull up in any web browser. Unless you intend to produce further evidence (to which I would listen), I consider the insinuation that the iD developers have a financial conflict of interest to be highly inappropriate. I say that as someone who's tried very hard to avoid any appearance of impropriety in other projects. (I'm a member of the core team on another project, and I have turned down a prize for a particular development effort because it might give rise to such an appearance - even though it was offered after the fact in appreciation, not before the fact in anticipation.) _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
