Re: [OSM-talk] The future of bugs in OSM
On Tue, Jul 14, 2009 at 03:15:44PM +0200, Mitja Kleider wrote: I would like to see a bugtracker like this on the main page. My first attempts to get in touch failed and I lost interest. Candid Dauth is currently working on a client that can easily be added as a layer in OpenLayers. How far is that code? I am interested to include an OSB bug layer into the maxspeed map. Flo -- Florian Lohoff f...@rfc822.org Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
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-boun...@openstreetmap.org [mailto:talk- boun...@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@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
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 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-boun...@openstreetmap.org [mailto:talk- boun...@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@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk smime.p7s Description: S/MIME cryptographic signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
Am Freitag, 17. Juli 2009 schrieb Florian Lohoff: On Tue, Jul 14, 2009 at 03:15:44PM +0200, Mitja Kleider wrote: I would like to see a bugtracker like this on the main page. My first attempts to get in touch failed and I lost interest. Candid Dauth is currently working on a client that can easily be added as a layer in OpenLayers. How far is that code? I am interested to include an OSB bug layer into the maxspeed map. It is not finished yet and is delayed until October or later. You may check out his older implementation in the meantime: http://osm.cdauth.de/ by http://www.openstreetmap.org/user/Candid%20Dauth Regards, Mitja ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
Shaun McDonald [mailto:sh...@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? Cheers Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
On Jul 17, 2009, at 8:00 AM, Andy Robinson (blackadder-lists) wrote: Shaun McDonald [mailto:sh...@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? I'm curious also. We already have meta-metadata (FIXME= or note=). Why not metameta-data? -- Russ Nelson - http://community.cloudmade.com/blog - http://wiki.openstreetmap.org/wiki/User:RussNelson r...@cloudmade.com - Twitter: Russ_OSM - http://openstreetmap.org/user/RussNelson ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
On 17 Jul 2009, at 16:00, Andy Robinson (blackadder-lists) wrote: Shaun McDonald [mailto:sh...@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. 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. Shaun smime.p7s Description: S/MIME cryptographic signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
Shaun McDonald [mailto:sh...@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:sh...@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 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
On Fri, Jul 17, 2009 at 9:05 PM, Andy Robinson (blackadder-lists) ajrli...@googlemail.com 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. -1 I see bugs data as similar to the GPX traces. It should be on a separate layer with separate database tables, etc. I agree that we don't need to reinvent everything (we can reuse components of the OSM stack) but as Shaun said, bug data should be separate from the real data. Existing tools should not be retrofitted to ignore such bug info. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
2009/7/17 Andy Allan gravityst...@gmail.com That's practically an argument for keeping them separate in the first place. For the same reason that we have trac for software bugs (we don't get people to add new bug reports in comments into the source files) we shouldn't put bugs directly into the geodata. Next thing we'd be doing something horrid to the tags so that I can reply to a bug saying bug:151234:gravitystorm:20090715=I've been there, but it looks fine to me and then building tools to parse all that stuff. The geodata tables are for geodata. We're already trying to prise the non-geodata tags out of the geodata (e.g. putting created_by on changesets). Lets not take five steps backwards by putting bugs in as nodes/ways/relations. I agree that we should not start putting the bugs into the geodata. It will make the database even heavier for no real advantages. Keeping a separate database is a much saner option and much manageable. It also allows the use of workflow which is always useful when managing a bug. If you put this inside the geodata, you lose that kind of flexibility. Emilie Laffray ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
Eugene Alvin Villar [mailto:sea...@gmail.com] wrote: Sent: 17 July 2009 4:56 PM To: Andy Robinson (blackadder-lists) Cc: SteveC; Frederik Ramm; Talk Openstreetmap Subject: Re: [OSM-talk] The future of bugs in OSM On Fri, Jul 17, 2009 at 9:05 PM, Andy Robinson (blackadder-lists) ajrli...@googlemail.com 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. -1 I see bugs data as similar to the GPX traces. It should be on a separate layer with separate database tables, etc. I agree that we don't need to reinvent everything (we can reuse components of the OSM stack) but as Shaun said, bug data should be separate from the real data. Existing tools should not be retrofitted to ignore such bug info. Very happy to have these recent responses to my question. I was really only stirring the honey pot a little. What appears to fall out for me is that: 1. A separate database is desirable. 2. We could reuse a lot of the stack, including the tag structure. I suspect however that those who have experience of software bug track might have a different perspective. Am I correct? Which is the simplest approach, since it's the simplest working method that's likely to be what will sit best with the rest of the project. So what else is important? Are points sufficient for marking bugs? I'd say not. I'd like to be able to set a polygon as well and possibly even a line. No different from a node/way/poly in geographical terms. How can I link a bug to an object in the main db? I'll want to do that too, but not always. Sometimes I'll want to effectively make a feature request (a bug for an unmapped object/area) Cheers Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
On Fri, Jul 17, 2009 at 4:24 PM, Andy Robinson (blackadder-lists)ajrli...@googlemail.com wrote: 1. A separate database is desirable. [...] Are points sufficient for marking bugs? I'd say not. I'd like to be able to set a polygon as well and possibly even a line. No different from a node/way/poly in geographical terms. How can I link a bug to an object in the main db? I'll want to do that too, but not always. Sometimes I'll want to effectively make a feature request (a bug for an unmapped object/area) I'd prefer to be able to file bugs that have referential integrity with the main database, e.g. to file a bug with a given relation or other object. But maintaining that sounds more like a separate table rather than an altogether separate database. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
On Tuesday 14 July 2009, Florian Lohoff wrote: On Tue, Jul 14, 2009 at 03:15:44PM +0200, Mitja Kleider wrote: There is kind of an API, it is already used by the JOSM openstreetbugs plugin. You can use it to create, comment, close or fetch bugs. If other API features are needed, they can be added. The source code and database structure is available. I would like to see a bugtracker like this on the main page. My first attempts to get in touch failed and I lost interest. Candid Dauth is currently working on a client that can easily be added as a layer in OpenLayers. I am in favour of including OSB in its current state in a bugs tab on the OSM frontpage for everybodys consumption. If it turns out to be tooo simple for us - make it a little less simple. But we should start gathering user feedback as soon as possible which currently is not an easy task for Aunt Tilly ... Flo I'd like to ask anyone interested in this to also look at http://wiki.openstreetmap.org/index.php/My_Account/Improvements where people are discussing the web user interface. Wouldn't want the bugs feature to end up feeling like another random separate feature bolted on. robert. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
On Tue, Jul 14, 2009 at 03:15:44PM +0200, Mitja Kleider wrote: There is kind of an API, it is already used by the JOSM openstreetbugs plugin. You can use it to create, comment, close or fetch bugs. If other API features are needed, they can be added. The source code and database structure is available. I would like to see a bugtracker like this on the main page. My first attempts to get in touch failed and I lost interest. Candid Dauth is currently working on a client that can easily be added as a layer in OpenLayers. I am in favour of including OSB in its current state in a bugs tab on the OSM frontpage for everybodys consumption. If it turns out to be tooo simple for us - make it a little less simple. But we should start gathering user feedback as soon as possible which currently is not an easy task for Aunt Tilly ... Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
Frederik Ramm wrote: That's the point I was trying to make - do not hog all the bugs in one central place and allow users to do only what you have coded; instead open this up so that anybody can hook their app into the user interface to offer functionality. I'd kind of taken that as read - if you're going to have a REST API for it, then of course there's going to be read as well as write operations. Just as with the rest of OSM. cheers Richard -- View this message in context: http://www.nabble.com/The-future-of-bugs-in-OSM-tp24290706p24303254.html Sent from the OpenStreetMap - General mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
Frederik Ramm wrote: And if the user indicates that he just wants to add a PoI, redirect him to http://ae.osmsurround.org/ so that he can add it directly to the database. That's the point I was trying to make - do not hog all the bugs in one central place and allow users to do only what you have coded; instead open this up so that anybody can hook their app into the user interface to offer functionality. Is the bugs database really so different in character to the map database though? Provided there was a planet-style dump of the bug database, anyone wishing to build an external system could easily do so. It's true that lat/lon/text wouldn't be sufficient for all bugs, but how many would that model work for - 75% or more? Most bugs are either for a specific location (name is wrong, street is missing, etc), or a fairly well defined area (all the footpaths in this park need doing, there's a place=hamlet|village|etc node but there's no ways within 5km of it). There are meta-bugs too (are imported political boundaries really in the correct place, is a blank area of the map really blank or just unmapped?), but how best to track them will depend on what they are (so you might as well collect a few examples and look for patterns first). Worst-case you could simply use a lat/lon/text entry as a link to some external tracker until such time as its model could be supported (either directly, or by better integration with external trackers - although I would hope the former). But however it works behind the scenes, it gives you one place that bug reporting/visualisation can coalesce around - you go to www.* to see the map, wiki.* to see the wiki, and bugs.* for bugs. -dair ___ d...@refnum.com http://www.refnum.com/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
Hi, Richard Fairhurst wrote: Frederik Ramm wrote: That's the point I was trying to make - do not hog all the bugs in one central place and allow users to do only what you have coded; instead open this up so that anybody can hook their app into the user interface to offer functionality. I'd kind of taken that as read - if you're going to have a REST API for it, then of course there's going to be read as well as write operations. Just as with the rest of OSM. If Steve's intention is to set up something without any user interface, just a clearinghouse for machines to dump their data and other machines to access them, then you are right. If the plan is to create something that actually interfaces with humans who want to check their area for bugs, then what you would need is something where an application can not only upload the bug to the clearinghouse but also say something like: And please if someone views that bug, offer them the following link that leads back to my application so the user can use my cool functionality which I have implemented in MUMPS for assisted bug fixing, or even click that link to be directed to the application which created this bug to read more about it. Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
Hi, Dair Grant wrote: Is the bugs database really so different in character to the map database though? Provided there was a planet-style dump of the bug database, anyone wishing to build an external system could easily do so. As I tried to point out in my other message, if there is to be a central interface then this is not so. We have this situation now - while anyone can set up their own slippy map of course, the normal thing for people to do is to go to openstreetmap.org where their choice of what they can do with the data is limited by what TomH puts on there and what others have coded - a Data layer, the Potlatch editor, maybe the external Cycle map - but we do not have an infrastructure that allows third party apps to tie in. With the multitude of bug applications that currently exist, no application can do it all, but each has a chance to offer to the user specific functionality that is *not* limited to just finding and flagging the bug, but also means presenting the bug in a specific way or even offer help in fixing it. This is something that must not be lost. Yes, any application can upload their bug via the REST interface, but they can hardly upload an algorithm on how to deal with the bug. So in order not to lose the flexibility of the ecosystem we currently have, we should make an effort to tie in all that coder creativity out there, rather than saying do it in Rails and check in in to SVN, and I might perhaps run it on the central web site if I like it. That's my whole point. Many many words for a small concept. (Matt I'll try to be on IRC tonight. Quite busy right now.) Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
Frederik Ramm wrote: This is something that must not be lost. Yes, any application can upload their bug via the REST interface, but they can hardly upload an algorithm on how to deal with the bug. So in order not to lose the flexibility of the ecosystem we currently have, we should make an effort to tie in all that coder creativity out there, rather than saying do it in Rails and check in in to SVN, and I might perhaps run it on the central web site if I like it. I don't understand why you think the application that reports the bug should dictate how it will be fixed. Surely the job of the person or application that reports the bug is just to document the problem. It's up to the person that decides to deal with it to decide what to do about it and what application they want to use to fix it. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
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@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
On 1 Jul 2009, at 21:15, Frederik Ramm wrote: Hi, Nic Roets wrote: And if the user indicates that he just wants to add a PoI, redirect him to http://ae.osmsurround.org/ so that he can add it directly to the database. That's the point I was trying to make - do not hog all the bugs in one central place and allow users to do only what you have coded; instead open this up so that anybody can hook their app into the user interface to offer functionality. Yeah - that's what a trivial API would do I think. an OSB-like interface would be one way, JOSM could talk to the API too, so could potlatch (no Richard, no special weird binary protocols)... and so on. Best Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
On 2 Jul 2009, at 11:19, Frederik Ramm wrote: Hi, Richard Fairhurst wrote: Frederik Ramm wrote: That's the point I was trying to make - do not hog all the bugs in one central place and allow users to do only what you have coded; instead open this up so that anybody can hook their app into the user interface to offer functionality. I'd kind of taken that as read - if you're going to have a REST API for it, then of course there's going to be read as well as write operations. Just as with the rest of OSM. If Steve's intention is to set up something without any user interface, just a clearinghouse for machines to dump their data and other machines to access them, then you are right. If the plan is to create something that actually interfaces with humans who want to check their area for bugs, then what you would need is something where an application can not only upload the bug to the clearinghouse but also say something like: And please if someone views that bug, offer them the following link that leads back to my application so the user can use my cool functionality which I have implemented in MUMPS for assisted bug fixing, or even click that link to be directed to the application which created this bug to read more about it. That could just be a tag that we agree on? application=mumps url=mumps.blah.com/bug/3737347373 or something? Best Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
Hi, Frederik Ramm wrote: Nic Roets wrote: And if the user indicates that he just wants to add a PoI, redirect him to http://ae.osmsurround.org/ so that he can add it directly to the database. That's the point I was trying to make - do not hog all the bugs in one central place and allow users to do only what you have coded; instead open this up so that anybody can hook their app into the user interface to offer functionality. I don't quite understand how http://ae.osmsurround.org/ fits into the bug-tracker idea. The amenity editor is an osm data editor that works directly on the osm database. It does not create a special type of amentiy bugs that need to be distributed. I could see that it makes sense to be able to add bugs to the map while editing amenities but this is functionality which can easily be done with the current osb. Cheers, Christoph ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
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 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
Christoph Boehme schrieb: Hi, Frederik Ramm wrote: Nic Roets wrote: And if the user indicates that he just wants to add a PoI, redirect him to http://ae.osmsurround.org/ so that he can add it directly to the database. That's the point I was trying to make - do not hog all the bugs in one central place and allow users to do only what you have coded; instead open this up so that anybody can hook their app into the user interface to offer functionality. I don't quite understand how http://ae.osmsurround.org/ fits into the bug-tracker idea. The amenity editor is an osm data editor that works directly on the osm database. It does not create a special type of amentiy bugs that need to be distributed. I could see that it makes sense to be able to add bugs to the map while editing amenities but this is functionality which can easily be done with the current osb. I think the idea is, if you have a bug saying POI=xy missing, than the bugwebsite (it must not be bugs.osm.org) could provide you a link to the amenity editor for fixing it directly. Personally I think we should try to make a good API with a database behind it and should try to have the different functionalities made by different client-developers (i would say you can compare this with twitter, the original webinterface doesn't provide very much options, but with the api we see a lot of cool twitterclients adding all kind of functionalities and they also integrate with other services (facebook etc., in our case this would be JOSM..) very often. Of course we should also add a bug-tab to the website then, but the API and the database is the most important thing. Jonas ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
I think there was some talk about that last year (march or june) when OSB appeared. If I remember, people liked the interface because it's rather nice and it lowers the entry level. So more people submit bugs and eventually also fix them, we get a better map and all is well. But it has also been said that we need advanced features, similar to a software bugtracking application. There was even some suggestions to adapt Trac to map bugs tracking but it sounded awkward and probably a bit complicated. Anyway we need the same core features but we could also have feeds so people can monitor new bugs in their area and then go fix them, things like that that will make people take action because they feel pride in keeping their area bug free. Pretty much like people monitoring articles on Wikipedia. The API is essential in my view so we can have one day applications running on car GPSes that will help people report bugs when travelling. So then we beat Tomtom's Mapshare on the very same idea they ripped off from OSM :) Renaud. P.S.: Steve sorry for double post. On Wed, Jul 1, 2009 at 4:22 PM, SteveCst...@asklater.com wrote: I've been thinking a bit about how bugs work in OSM. I really like the way OSB works http://openstreetbugs.appspot.com/ But it's closed source afaik and doesn't have an API. It uses human input. new OSB is cool and tries to fix some of this http://wiki.openstreetmap.org/wiki/User:Emka/new_OSB I like keepright http://keepright.ipax.at/ But it's more automated. Here's my vision for how bugs should work. You go to http://bugs.openstreetmap.org/ There's a big map of bugs which looks similar to OSB. It doesn't know who you are and drops you in to beginner mode which shows bugs that are relevant to you - human entered stuff say. There is an intermediate mode which shows a slide which, when slid, shows more bugs. So at the low end human entered stuff, but at the high you get every single fixme from OSM. Then there is expert mode which looks like keepright, and you can click various things on and off. How do you enter bugs? There are two ways. As a human on bugs.osm.. www.openstreetmap.org you can click a little green plus like OSB has on the map, or potlatch will let you do it too. 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. To give you an example there are tons of bugs in the US, but there is no systematic way to fix them, or even begin fixing them. There are some good HOWTOs on the wiki on the actual individual details of how to fix a bridge connected to the road beneath it, but no big list of such bridges or where they are. We need to make this systematic. http://wiki.openstreetmap.org/wiki/TIGER_fixup/Over_Connectedness Why is my system better than OSB or keepright? OSB with a simple API might fly, but it's not open and not quite part of OSM. Keepright kind of gets there but the barrier to entry is high. If I want to do an import and list bugs to check, or I want to write my own little maplint utility to check for X or Y or Z I have to learn whatever language keepright is in and start hacking against a large codebase. Instead, bugs.openstreetmap.org would offer a really simple REST api to throw bugs at. I envisage it as a sort of clearing house for bugs. It will quickly become very useful for lots of people writing small, loosly-joined tools. The barrier to me writing a small bug app is low. I imagine all sorts of little apps writing things to submit bugs much as keepright or maplint sort of do now. All they have to do, is run a script to report the bugs from planet every week (or whatever) and keep track of the bug IDs and see if they're closed yet. Now on the output side I think there is a huge amount of potential. Right now people don't know where to start fixing things. You can point people at OSB but that is human only, or you could point them at keepright or maplint but then you have to fight to maintain those things. Instead, bugs.openstreetmap.org would be a central clearing house which everyone can submit to and use. To go back to that example, if someone writes a script to find all freeways in the USA which connect at right angles to residential roads and submits them through the api to bugs.openstreetmap.org then you have a big dataset. It becomes super fun, cool and easy to motivate the community and say - hey lets fix all those bugs in the US. You can draw graphs of the number of bugs being eaten up, show progress, make a leaderboard... all the things that will motivate a *lot* of people to fix these things. It will be so cool to be able to have many people working on closing bugs, I'd make it my number one slide in every talk I go to, saying go to bugs.openstreetmap.org and enter or fix a bug maybe I should already with OSB. Now, you can of course
Re: [OSM-talk] The future of bugs in OSM
Steve, All good ideas, as data becomes ever more densely and confusingly packed (just open Potlach in a completed Germany city!) the OSB site offers a nice way for Human Beings to get involved. Three thoughts: 1 - Being able to show which logged-in users submitted bugs would be a great help for me. I have a couple of people who add OSB bugs for street numbers and other minor fixes and since I trust them I put that data straight in when they put their name to it without having to go out and check, but accounts of course make it much more trustworthy. 2 - Further down the line people should be able to attach photos, as I'd love to do something like a call for random people to submit cycle parking / street numbers where I can't trust their word but could trust a well taken photo, and (related to 1) could contact them if it's unclear. 3 - Make it easy to integrate with other web sites, e.g. we nicked the Mappa Mercia OSB stuff for http://map.oneplanetsutton.org/openstreetbugs.html Cheers, Tom On Wednesday 01 Jul 2009 15:22:32 SteveC wrote: I've been thinking a bit about how bugs work in OSM. I really like the way OSB works http://openstreetbugs.appspot.com/ But it's closed source afaik and doesn't have an API. It uses human input. new OSB is cool and tries to fix some of this http://wiki.openstreetmap.org/wiki/User:Emka/new_OSB I like keepright http://keepright.ipax.at/ But it's more automated. Here's my vision for how bugs should work. You go to http://bugs.openstreetmap.org/ There's a big map of bugs which looks similar to OSB. It doesn't know who you are and drops you in to beginner mode which shows bugs that are relevant to you - human entered stuff say. There is an intermediate mode which shows a slide which, when slid, shows more bugs. So at the low end human entered stuff, but at the high you get every single fixme from OSM. Then there is expert mode which looks like keepright, and you can click various things on and off. How do you enter bugs? There are two ways. As a human on bugs.osm.. www.openstreetmap.org you can click a little green plus like OSB has on the map, or potlatch will let you do it too. 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. To give you an example there are tons of bugs in the US, but there is no systematic way to fix them, or even begin fixing them. There are some good HOWTOs on the wiki on the actual individual details of how to fix a bridge connected to the road beneath it, but no big list of such bridges or where they are. We need to make this systematic. http://wiki.openstreetmap.org/wiki/TIGER_fixup/Over_Connectedness Why is my system better than OSB or keepright? OSB with a simple API might fly, but it's not open and not quite part of OSM. Keepright kind of gets there but the barrier to entry is high. If I want to do an import and list bugs to check, or I want to write my own little maplint utility to check for X or Y or Z I have to learn whatever language keepright is in and start hacking against a large codebase. Instead, bugs.openstreetmap.org would offer a really simple REST api to throw bugs at. I envisage it as a sort of clearing house for bugs. It will quickly become very useful for lots of people writing small, loosly-joined tools. The barrier to me writing a small bug app is low. I imagine all sorts of little apps writing things to submit bugs much as keepright or maplint sort of do now. All they have to do, is run a script to report the bugs from planet every week (or whatever) and keep track of the bug IDs and see if they're closed yet. Now on the output side I think there is a huge amount of potential. Right now people don't know where to start fixing things. You can point people at OSB but that is human only, or you could point them at keepright or maplint but then you have to fight to maintain those things. Instead, bugs.openstreetmap.org would be a central clearing house which everyone can submit to and use. To go back to that example, if someone writes a script to find all freeways in the USA which connect at right angles to residential roads and submits them through the api to bugs.openstreetmap.org then you have a big dataset. It becomes super fun, cool and easy to motivate the community and say - hey lets fix all those bugs in the US. You can draw graphs of the number of bugs being eaten up, show progress, make a leaderboard... all the things that will motivate a *lot* of people to fix these things. It will be so cool to be able to have many people working on closing bugs, I'd make it my number one slide in every talk I go to, saying go to bugs.openstreetmap.org and enter or fix a bug maybe I should already with OSB. Now, you can of course just write a standalone app to do that freeways in the US a bit like
Re: [OSM-talk] The future of bugs in OSM
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 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. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
On Wed, Jul 1, 2009 at 4:22 PM, SteveC st...@asklater.com wrote: You go to http://bugs.openstreetmap.org/ There's a big map of bugs which looks similar to OSB. It doesn't know who you are and drops you in to beginner mode which shows bugs that I like this. If it's idiot proof and it does not slow the web browser down, it can even go onto http://openstreetmap.org/ And if the user indicates that he just wants to add a PoI, redirect him to http://ae.osmsurround.org/ so that he can add it directly to the database. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
On Wed, Jul 1, 2009 at 3:59 PM, Nic Roetsnro...@gmail.com wrote: On Wed, Jul 1, 2009 at 4:22 PM, SteveC st...@asklater.com wrote: You go to http://bugs.openstreetmap.org/ There's a big map of bugs which looks similar to OSB. It doesn't know who you are and drops you in to beginner mode which shows bugs that I like this. If it's idiot proof and it does not slow the web browser down, it can even go onto http://openstreetmap.org/ And if the user indicates that he just wants to add a PoI, redirect him to http://ae.osmsurround.org/ so that he can add it directly to the database. Using Mapnik tiles as an indicator of what's in the database could lead to a lot of unnecessary bugs or points of interest being added. For instance, in downtown Clemson, SC [1], the Subway has been mapped, but doesn't appear on the map because of the labling of T.D.'s. One shouldn't always have to be removing duplicate bugs/POI. Before the interface adds a POI to the database, perhaps it should query a bounding box around the reported area and see if there's a similarly placed node that they'd like to edit the position of or tagging instead of creating a new node. Cheers, Adam [1] http://ae.osmsurround.org/?zoom=18lat=34.68343lon=-82.83641layers=BTT ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The future of bugs in OSM
Hi, Nic Roets wrote: And if the user indicates that he just wants to add a PoI, redirect him to http://ae.osmsurround.org/ so that he can add it directly to the database. That's the point I was trying to make - do not hog all the bugs in one central place and allow users to do only what you have coded; instead open this up so that anybody can hook their app into the user interface to offer functionality. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
