[OSM-dev] OSM Notes API, Issue Tracking (was: "See Data", a UI for browsing OSM data in the main map)

Tom Hughes 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
questioned.

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.

Tom

-- 
Tom Hughes (tom at compton.nu)
http://www.compton.nu/




More information about the dev mailing list