[OSM-talk] Reporting bugs (was Re: What do you wish you'd known?)
tirkon33 at yahoo.de
Mon Mar 22 05:11:59 GMT 2010
Richard Fairhurst <richard at systemed.net> wrote:
>Serious point: if you find a bug or issue or what-have-you in any editor,
>you need to actually tell us about it rather than just mithering unhappily.
As I wrote above: Not every editor is usable with the OSM-account.
Possibly in future (or at present?) you have to pay for it. Thus you
cannot find out, whether the user is the problem or the editor.
>I honestly didn't know that the relation ordering issue was the case until
>last week when Frederik pointed it out on this list. I'm now told there'd
>been some prior discussion of it on talk-de but that doesn't really help a
>whole load. I'm very happy to fix the bug (although I don't use ordered
>relations myself, nor in fact did I write Potlatch's excellent relations
>code) but I do need to know about it first!
Thank you for fixing and your detailed answer. :-) Did you fix the
changing direction of a way within a route-relation described above as
well? Which version do we have to await?
At present you have to use both editors. Potlatch to make the faults
and JOSM to find them. But nearly nobody does this.
The problem seems to be, that the more expirienced users use JOSM and
the Potlatchers are rather hushed within the community. I experienced
that the answers to questions concerning editing complicated objects
with potlatch are not known in the community. The only answer I hear
is: "Use JOSM".
My general impression is, that potlatch is near at the map. This is
much better as in JOSM. But if you come to the complicated objects, it
lets you alone. A potlatch with the possibilities of JOSM would be
really good. That would also help to notice the potlatch bugs
concerning complicated objects. At present you have to use both
editors. Potlatch to make the faults and JOSM to find them.
The problem of damaging unwanted things without being aware, is a big
one. The most beginners seem to start with clicking to "edit", without
being aware, that this is Potlatch. I think, this applies to many
users coming from Wikis like Wikipedia, where clicking "edit" has no
Every node, where a relation (or a tag) begins, ends or changes or is
itself the member of a relation could be such a critical point. Moving
or deleting such a node could harm the data without being aware,
because the user only sees it as a node, that describes the route of
the way and nothing more. Possibly there are more critical cases
concerning relations, that do not come to my mind at the moment. Some
of the problems may be handled automaticly. others not. Possibly it
could be helpful, if every critical node is marked similar to the
Would it be useful, to initiated a kind of "collecting-basin" at the
wiki, where all the "unawares" are collected in order to be a
guideline for all coders of editors? Possibly togeteher with a list,
which editor can handle it an which not.
By the way: The problem shows, that it seems not to be possible, to
write an editor, that does not support relations.
>The place to submit bugs is http://trac.openstreetmap.org/ . If you don't
>know that - "trac" is a bit of an obscure name, after all - then you can
>just search for 'Bugs' on the wiki and it'll direct you to the right place.
By the way: The trac is not made for users without coding experience.
It asks questions, you do not know i.e. task, milestone, priority,
kayword, cc, assign to. Many people will be lost and deterred. Further
the answer "I dont know" should be possible at "component" and
"present" and "I dont know" at "version", "I dont know" preselected.
"Present" would be useful for applications provided by the Web,
because you are not aware of the version. i.e. at mapnik.
>We're a _collaborative_ project, but that only works if you collaborate!
Many non native persons will be able to survive, if they have to speak
english. But to describe (or read) such complicated stuff only with
school-english and with nearly no experience in the dayly life is
another dimension. That is where the collaboration will end for many
More information about the talk