[OSM-talk] Mappers and apps should focus on relations at the very start

Fernando Trebien fernando.trebien at gmail.com
Sun Jun 28 18:34:57 UTC 2015


On Sun, Jun 28, 2015 at 4:03 AM, Richard Fairhurst <richard at systemed.net> wrote:
> What is unacceptable is the relentless, harrying, dismissive, abusive manner
> in which you and others advance the former view over the latter. That is why
> we cannot retain developers.

We really need to be careful to target the philosophical standpoint,
not the people. As I said (now countless times), iD is awesome. I
don't think I've been criticizing developer talent or code quality. I
wouldn't have provided most of its translations into my language if I
thought differently. Anyway, should this conversation be about iD? In
a way yes, but not only. Other editors (except JOSM) seem to have the
same aversion of relations. Relations are valuable and are not going
away, several of them (the most critical being "route") have been
approved long ago by the community (by consensus, by public voting),
so I believe fighting them only make things worse. Fighting them is
fighting the community. Others, such as boundary, are de facto
standards. They have to be properly tamed. One way is to hide them so
that only "clever" people can deal with them. Another is to teach
everybody in the simplest possible manner so that they become widely
accessible.

Cliché quote: "Make things as simple as possible, but not simpler,"
some attribute to Einstein.

When people are deleting and combining ways, they are editing
invisible data - tags and parent relations. In a world without
relations, combining different tags would still be an issue. For
instance, the "sidewalk" tag is not visible. It should be visible. If
it ever becomes visible, there is still a huge repository of approved
tags that won't be. The current approach - concatenation - is
essentially invisible in many situations (the user must pay a lot of
attention at the result). I would like to see a scenario where a
casual mapper (the target audience of all editors besides JOSM) would
prefer not to be notified about a potential mistake. I do mapping
sprints very often, I'm knowledgeable, and even so I prefer to get
interrupted in my mapping whenever I do something potentially
damaging. Without that, even with my experience, I would have broken
data multiple times. How is that casual mappers would prefer not to
have that? It is a contradiction to design the application for casual
mappers and still place fastest mapping at utmost priority. A casual
mapper is not aware of the data model, and should not be expected to
be so.

Back to the problem that motivated me into this discussion: I see that
the problem in iD is really easy to solve (much easier than in
Potlach). If there is an objection to an interaction-blocking modal
window, other non-blocking visual cues can be used, such as a
distinctive alert bar at the bottom, an alert icon at the action
button, and an alert log on top after an action breaks something.
Anything that informs the user is fine. It is not done only due to a
philosophical opinion, which I think is negative to OSM as a whole.
The opinion is negative, not the people that hold it. Maybe people are
also being idealistic: instead of implementing a little workaround,
they'd rather wait and see if a cleverer, less intrusive solution
emerges. It is clearly not happening, after two years of waiting and
wondering by the most involved minds in the project. Getting a simple
alert when deleting relation members was a huge struggle. Since
"combining" implies "deleting" I don't think the current issue should
need to be so widely discussed. The only reason I don't set out and
try writing my own editor (which is a pretty big undertaking) is that
my country's map still needs lots of data, and my country's community
still needs lots of support. Potlatch, iD and JOSM have solved that,
mostly. All I ask for is a minor refinement, which I believe is good
not only here but in the whole world.

-- 
Fernando Trebien
+55 (51) 9962-5409

"Nullius in verba."



More information about the talk mailing list