[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