[OSM-dev] OSM Notes API, Issue Tracking (was: "See Data", a UI for browsing OSM data in the main map)
tom at compton.nu
Thu Apr 24 00:47:53 BST 2008
In message <20080423233614.GA14909 at lochewe.mathy.remote.org>
Frederik Ramm <frederik at remote.org> wrote:
> > > 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".
I was trying to follow a KISS principle here and have as few fields
as possible to avoid haveing a bugzilla grade barrier to entry when it
comes to reporting things. That's why I was kind of hoping to avoid
having multiple ticket types.
> 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
Well maybe we need to find ways to link those things to the map
Notes like "so and so needs rechecking in this area" seem entirely
sensible to me, or even "I'm working here - please let me know if
you are too". So long as it is closed when you move on.
What I would rather not see is people using it to add permanent
notes about places - if that information is worth having then it
should probably be properly encoded as tags on some object.
> > 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 ;-)
You're now designing something much larger and more complicated
that I had in mind I think. I'm trying
> > > 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*.
Well it's certainly what I see as the main point ;-) Though I am a
little concerned about how well it will work and what sort of number
and/or quality of notes/tickets/whatever we will get.
> > 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?
No, there is no direct relationship to specific objects, and no need
for transactional integrity in updates like that.
The namefinder is a little different in that it's a one way interface
where we get data and display it. In this case we need to be able to
add/update/remove records, and that is exactly what rails is good at.
> > 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.
> 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
> easily be.
Well my starting point is that anything which appears to be an
integrated part of www.openstreetmap.org should be running under
our control and preferably on our servers.
> > 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.
That is exactly the sort of thing that I see this as being for of course ;-)
> (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...)
Yes, flash has a same origin policy, but it can be overridden with
a crossdomain.xml file.
Tom Hughes (tom at compton.nu)
More information about the dev