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

Andy Robinson (blackadder) blackadderajr at googlemail.com
Wed Apr 23 23:20:58 BST 2008


Tom Hughes wrote:
>Sent: 23 April 2008 11:00 PM
>To: Frederik Ramm
>Cc: OSM-Dev Openstreetmap
>Subject: Re: [OSM-dev] OSM Notes API, Issue Tracking (was: "See Data", a UI
>for browsing OSM data in the main map)
>
>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.

I was thinking along the same lines. We already uses a notes= tag for
general comments on feature in the db. This probably would be better under a
different name. postit is probably trademarked so how about "flag". (With
its condition is either raised or lowered ;-)  )

Cheers

Andy

>
>>  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/
>
>_______________________________________________
>dev mailing list
>dev at openstreetmap.org
>http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev





More information about the dev mailing list