On 01/-10/-28163 08:59 PM, Ian Dees wrote: > ... > I think a more useful criticism would include some specific ideas...
Well, if we are throwing around random ideas, I might as well chime in too... To state it upfront, I am not involved in any of the parts suggested, so I can neither fully judge the scope nor offer mentoring, but in case some one else finds the suggestions reasonable, they might make them into proper proposals. 1) Integrate a continuous integration framework into JOSM and write the appropriate unit and integration tests. JOSM seems to have a fair number of people contributing to its code base, which is great, but also potentially increases the likelihood of bugs, if people with less experience of the full code base contribute. So a good set of automatic tests, could help ensure JOSM doesn't break too often and hopefully attract even more developers, if, thanks to tests, one doesn't always have to fear breaking some remote part due to dependencies one didn't know about. The scope "write unit tests..." is fairly flexible and thus should be possible to make it appropriate for a 3 month student project. Also it probably can be considered sufficiently as "coding" to still qualify. It might not be the most exiting project ever, but I could imagine it being very useful to OSM and given the student is paid for it through Google, it might still attract someone. But people involved in writing JOSM would have to see if it is actually useful or just a stupid idea. 2) Optimize one of the existing routing engines to be a good quality assurance tool of suitability of OSM data for routing. Again, I am not entirely sure what exists already, but I don't think any of the routers (YOURS/gosmore, OpenRouteService, Cloudmade, pgrouting,...) work off of the minutely diffs yet. For quality assurance, a short turn around between trying to fix a bug and verifying that it has indeed been fixed is quite important. So getting down the update frequencies to ideally minutely diffs but perhaps at least hourly or daily would be very useful. If at the same time it is scalable enough to offer it to a large number of editors as a webservice (by e.g. using a better algorithm than the standard A* search), it could be a useful tool to help getting OSMs routability up to par. I can't really judge the scope of such a project, but again it feels like it probably should be possible to adjust the requirements to make it a feasible 3 month project. As said, it is just throwing in some ideas. But given that GSoC is probably the closest to "if only code would magically appear" we will get, I hope those suggestions don't harm anyone ;-) Kai >... _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
