[OSM-talk] The future of bugs in OSM
Christoph Böhme
christoph at b3e.net
Thu Jul 2 15:07:44 BST 2009
SteveC wrote:
> On 1 Jul 2009, at 19:58, Frederik Ramm wrote:
>
>> Hi,
>> SteveC wrote:
>>> But, and this is key, it also has a RESTful API for mass uploading
of bugs.
>>> We need to do two things - unify the various bug systems and expose
more of the bugs.
>> I believe that the types of bugs one can look for are quite
>> different. You'd have to build a very good system if it is to be able
to capture all kinds of bugs - don't think that simply having
something like lat/lon/text is enough, because some bugs might be
relevant for a whole area, or you might have a "two nearby streets
share the same name" bug which points to two ways rather than one
location, etc etc
>
> How about we borrow tags from OSM? Bugs have lat,lng,text and keyvals?
What you think?
> They main thing I want to say though - is lets just build something
simple and iterate. Absolutle minimum feature set is a RESTful API
plus a OSB-like interface.
After the last discussion about an improved OSB, I had a go at building a
system that had tags, file uploads and could also handle different
geometries of errors (basically a Swiss Army knife for osm metadata). This
system never reached a point were it became usable. However, I learned a
couple of things while programming it:
For bug-*tracking* you need to have a history of changes made to a bug.
While for some tags only the current value is relevant (e.g. a status tag)
for others each version of the tag is important (e.g. if comments are
implemented with tags). Since the server is agnostic about the meaning of
tags all semantic knowledge need to be implemented in the clients. This
makes client implementations quite complex. Also searching for bugs
becomes a task of its own as you need something like XAPI or O3S to build
queries unless you want to filter the bugs on the client-side.
I also realised during the develeopment that tags are a concept which is
very similar to the fields/columns in a database. Their advantage over
fields is that each object can have a different set of tags and that the
database does not need to be changed to add new tags. The disadvantage is
that the database has no knowledge on how to handle the data and that
clients cannot make many assumptions about the data that is available for
an object.
In the osm database the flexibility offered by tags is need because every
mapper needs to add new types of objects and tags quite regularly. However
IMHO the situation is a bit different in a bug tracker: First, the range
of different object types is much smaller as bugs are not that different
from each other. Second, the server needs to know about the information it
holds in order to search it properly. And third, users are probably not
going to manually add tags to bugs, only developers of bug tracking
application might want to add additional information to a bug.
To conclude: IMO tags can be a nice add-on to allow applications to
provide additional data for a bug the basic stuff should be managed in a
normal database in order to allow easy client implementations. After all
its just a bug tracker which should people tell where the OSM data needs
improvements. If you want to do something completely different you can
always set-up a database and build another tool. And this might be easier
in the end than using an extremely flexible bug tracker.
I might not be seeing the bigger picture here, but my experiences with my
"bug tracker" idea led me to the conclusion that a restricted tool might
do a better job than something very flexible.
Cheers,
Christoph
More information about the talk
mailing list