Hi everyone, I have been an (extremely passive) user of OSM for quite a while. Now Ive seen OSM on Google SoC and that triggered the thought that I might be able to help you guys with this very cool project. Heres what Id be interested in doing and a few questions about related things.
I would like to contribute to wikifying OSM, that is building the features that are typical for a wiki. As is pointed out in the wiki these are mainly: - tracking of changes with user comments - enabling rollback of changes - a reputation system I came up with loads of great ideas just to realise that Frederik Ramm has written pretty much the same on the wiki page Changesets and Reverts. Obviously the topic of wikification is pretty closely related to the question which database software is used (especially when considering the use of transactions) and I gathered that there is a demand to investigate different databases and extensions for geographical data. For example MySQL can (or could in early 2007 when I last tested) only use the geospatial data type with MyISAM, transactions are only supported by InnoDB. Putting this all together I think the following steps are required: 1. Writing a detailed specification what we want in terms of Wiki functionality. 2. Based on this and established knowledge specify what a database needs to be capable of (considering predicted traffic, etc). 3. Investigate database softwares and extensions. I think a review over what is out there and what people are using would be a pretty interesting paper that we could publish in a journal. The above is the research bit of the project and will include results that cannot and will not be achieved during the SoC. Nevertheless, they might be helpful in giving guidance for future developments. To get some visible changes the following two routes are possible: Either do the entire job in one big stab: Setting up a new database (if it turns out the current solution is not the best), then writing the API to work with it and at the same time introducing the new features. Or, alternatively, modify the existing database and API to support the proposed new features as much as possible and later porting this all to a new database. While the first solution would give a more complete result the management effort and risk associated is higher because there are no intermediate solutions. I would prefer the latter because there is a constant stream of intermediate results possible wile still having the vision of where to head thanks to the initial research. So here is how I would continue: 4. Make changes to the existing database layout to enable tracking, rollback and reputation. 5. Update the API to enable the new features with the existing database as a first step to move towards new functionality. 6. Make changes to JSOM and/or Potlatch to make the new functions visible to the user. So these are my ideas, here are my questions: What is the general feeling in the community about database systems? Do most people think something different would suit OSM better? Or would you rather stick with what you have (never touch a running system)? And one technical question: Where in the SVN is the code of the API? And finally: Do you think this would make a good SoC project? Any feedback would be greatly appreciated. Regards, Jonas _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
