[OSM-dev] SoC project idea: Wikifikation of OSM

[jn at jonemo.de]

Hi everyone,

I have been an (extremely passive) user of OSM for quite a while. Now I’ve
seen OSM on Google SoC and that triggered the thought that I might be able
to help you guys with this very cool project. Here’s what I’d 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