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 thewhole dataset for the bbox.It seems daft to me to go reinventing everything when we have all the tollsalready. Cheers Andy-----Original Message----- From: [email protected] [mailto:talk- [email protected]] 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 etcHow 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 orOSB, it's easy to write things to do that, so long as they have APIs. Best Steve _______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk_______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk
