[OSM-talk] The future of bugs in OSM

[Andy Robinson (blackadder-lists)]

Any reason why we don't just put the bugs in osm. They could be nodes, ways
or polygons and just have a suitable bug=description key value pair plus any
other tags need (date opened/closed etc). I accept that the editors would
need to handle the data a little differently and their might be a need to
track closed (visible=false or perhaps a new visible=closed). Plus the API
would need to able to deliver just the bug data for the API rather than the
whole dataset for the bbox.

It seems daft to me to go reinventing everything when we have all the tolls
already.

Cheers

Andy

>-----Original Message-----
>From: talk-bounces at openstreetmap.org [mailto:talk-
>bounces at openstreetmap.org] On Behalf Of SteveC
>Sent: 02 July 2009 1:16 PM
>To: Frederik Ramm
>Cc: Talk Openstreetmap
>Subject: Re: [OSM-talk] The future of bugs in OSM
>
>
>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.
>
>> Not saying it can't be done but if you want to replace the various
>> bug systems then you need to be able to do what they can do or it is
>> a step backwards.
>>
>> I'm also wary of the centralistic "let's set up a database and have
>> everyone upload their data to us" approach. Maybe keeping true to
>> your "clearinghouse" idea the central service should *only* know
>> that there is some other service that has found a bug in a certain
>> location, and when the user wants to know more, the other service is
>> interrogated through an API. The other service might, for example,
>> guide the user through an automatic fixing process for certain types
>> of bugs, or offer things like "find similar bugs in the vicinity" or
>> so. Plus, every coder could contribute to something like that in the
>> language(s) he prefers, and without having to ask for his
>> functionality to be included in some central service.
>
>Yeah so if you want it to just also aggregate things like keepright or
>OSB, it's easy to write things to do that, so long as they have APIs.
>
>Best
>
>Steve
>
>
>_______________________________________________
>talk mailing list
>talk at openstreetmap.org
>http://lists.openstreetmap.org/listinfo/talk