[OSM-dev] OSM Notes API, Issue Tracking (was: "See Data", a UI for browsing OSM data in the main map)
frederik at remote.org
Thu Apr 24 00:36:15 BST 2008
> > Personally I always thought that notes could be usable not only for
> > people pointing out errors, but also for meta-info like: "drove around
> > this quarter for two hours. think I got all the roads but some
> > cycleways t.b.d.".
> I definitely disagree there - in fact one of the points I made to the
> author of the notesapi branch earlier on was that I was concerned that
> it was leaning to much in that direction. If we're going to do that
> then I would definitely want to have different classes of note (to be
> honest I'm not sure I like note as a name but I'm not that bothered)
> as I want to be able to subscribe to problem reports but I won't be
> interested in people's random wibblings in the same way.
I tend to think that these "random wibblings" may be a valuable tool
for communication among mappers. Agreed that a classification would
make sense - e.g. "something is WRONG", "something should be
IMPROVED", "something to NOTE".
You're thinking more along the lines of a feedback channel between the
broader public (non-OSM user surfing the web page) and our community.
That is unquestionably an important feature that we want to have But
what I would also like to have is some geo-located way of
communication between members of the community. I think there really
is demand for this - for example we here in Karlsuhe know each other
mostly, and we meet from time to time to discuss things; but still if
I see something strange on the map, I have to find out who did that
and then e-mail him and ask him whether he's still working on that or
why exactly he constructed the strange cycleway junction the way he
did or whatever. If I didn't know the people it would be even harder.
I would very much like to offer some way for people to comment on their
work. User diaries or Wiki "project" pages cannot play that role
because they're not related to the map. The upcoming change groups /
commit comments will perhaps offer something along these lines but who
> In particular I see these as things which can be marked as done, so
> that they have a limited lifetime and don't just build up forever
> more, cluttering things up.
If things can be marked as done, all the better. If they can't, and
clutter things up, well then we need filters. People always ask how we
keep clutter out of OSM, and my answer always is: we don't, we just
don't read the clutter. Just like the web ;-)
> > IMHO notes are very well suited for placing them *outside* of the
> > central OSM data base because they do not have to integrate tightly
> > with the rest; there's no reason I can see why notes should not reside
> > on an external service, with editors connecting that service through
> > appropriate plugins.
> I think they do need to integrate tightly - sure JOSM can get them
> from somewhere else via a plugin, but the whole point here is to lower
> the barrier to reporting issues.
*One* point I should hope, not *the whole point*.
> So we want people that see a problem on the map to be able to click
> and report it, not to have to go wandering off finding some external
> issue tracker.
Sure. When I said "does not have to integrate tightly", I meant that
there is no database reference between, say, a way and a note (or is
there?); there is no need of updating both in a transaction or
whatever. Of course they need to be integrated on the user interface -
JOSM can get the stuff from somewhere, OpenLayers can get the stuff
from somewhere, it doesn't have to be in the API. The NameFinder is
integrated very well without being in the API, is it not?
> Well currently the branch has a separate API call to get notes for an
> area, but I had always thought of it as something the main API should
> return (live, active notes anyway) and that was something I
Well I'm not the one coding this so I'll try to make this my last
comment on the subject, but rather than stuffing ever more
functionality into the API, I would like to see de-centralized
services whereever we can make it happen easily, and I should have
thought that a tracking system would be a prime candidate for this.
There are things which cannot be separated from the API, or only at a
high price of development time and/or bandwidth. The notes stuff could
> Sure there's a fine line about what should and shouldn't be in the
> main database, but in this case I think this is on the right side of
> that line.
My attempt at drawing this line would be: data about the world goes in
our database; data about our data can go somewhere else. Of course a
note that says "your data claims the road name is X but in fact it is
Y" sits exactly *on* that line... still, my mantra is anything that
doesn't have to be in the API shouldn't be.
(Does Flash have some sort of same-origin policy regarding network
connections? That would of course be a motive to install everything
that could possibly be accessed by Potlatch on the main API, or
alternatively set up all sorts of forwarders. In that case we must
pray that Potlatch never supports georeferenced photos...)
Frederik Ramm ## eMail frederik at remote.org ## N49°00'09" E008°23'33"
More information about the dev