[OSM-talk] The future of bugs in OSM

[Shaun McDonald]

Bug should be separate from the real data. The bugs should stored in  
separate tables, or a separate server using the same/similar stack as  
the real data.

Shaun

On 17 Jul 2009, at 14:05, Andy Robinson (blackadder-lists) wrote:

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2433 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20090717/b70ce27e/attachment.bin>