[OSM-talk] The future of bugs in OSM

[Andy Robinson (blackadder-lists)]

Shaun McDonald [mailto:shaun at shaunmcdonald.me.uk] wrote:
>Sent: 17 July 2009 4:20 PM
>To: Andy Robinson (blackadder-lists)
>Cc: 'SteveC'; 'Frederik Ramm'; 'Talk Openstreetmap'
>Subject: Re: [OSM-talk] The future of bugs in OSM
>
>
>On 17 Jul 2009, at 16:00, Andy Robinson (blackadder-lists) wrote:
>
>> Shaun McDonald [mailto:shaun at shaunmcdonald.me.uk] wrote:
>>> Sent: 17 July 2009 2:30 PM
>>> To: Andy Robinson (blackadder-lists)
>>> Cc: 'SteveC'; 'Frederik Ramm'; 'Talk Openstreetmap'
>>> Subject: Re: [OSM-talk] The future of bugs in OSM
>>>
>>> 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
>>>
>>
>> Can you elude as to why you take this point of view?
>
>Data users shouldn't have to deal with bug tracking data in the
>planet. The planet export script should not be doing any tag
>inspection to selectively dump data to the planet.

Agreed, but I still think since bug tracking is part of the core of what we
do it should ultimately be part of the database somewhere. I don't care how
its achieved so long as its available via the same api call setup. If it
uses the same syntax for data as the rest of the database for objects then
we don't have to lean something new just for bugs.

>
>Editing will be harder and more confusing if you have bug data around
>with no easy way to switch it off. I see the bug tracking as an added
>extra, rather than a core part of OSM.
>

It will only be confusing if it's displayed to the use with the rest of the
data and I wouldn't want that either. The editing software just needs to
display bugs on a separate layer or whatever. Or perhaps even ignore them if
it's not an ap that needs to know about bugs.

Cheers

Andy