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 [email protected] http://lists.openstreetmap.org/listinfo/talk
