[OSM-dev] OSM Notes API, Issue Tracking (was: "See Data", a UI for browsing OSM data in the main map)
tom at compton.nu
Wed Apr 23 23:00:04 BST 2008
2008/4/23 Frederik Ramm <frederik at remote.org>:
> > You do realise that there are people already working on adding this
> > to the main site? There is a code branch in the repository with some
> > preliminary work already.
> I think that Martijn van O had a prototype of an OL based issue
> tracker as well - is the one in SVN based on that, or an entirely
> different thing?
It's separate as far as I know.
> What I like about Richard D's variant is that you can apply a note to
> an *area*, while the code in our SVN seems to assume that notes always
> relate to a *point*.
I think that is to some extent an open question, although I personally
have tended to reach the conclusion that sticking to a point is
probably sufficient and that the additional complication of allowing
areas is probably not necessary.
> 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.
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.
> 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. 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.
> I haven't studied the notes branch in SVN closely, and have probably
> missed the discussion about it on the lists (pointers anyone?), but if
> the plan is to add some kind of <note> objects to OSM data then I
> would like to register mild opposition. Let the core do the core
> tasks, and do everything else elsewhere. Otherwise you'll end up with
> geotagged images in the central database sooner or later ;-)
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
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
Tom Hughes (tom at compton.nu)
More information about the dev