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

[Frederik Ramm]

Hi,

> 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

[...]

> 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.

[...]

There is definitely merit in thoroughly analysing if and how we could 
switch to another database system. Most people are complaining about 
MySQL, and we are already seeing integrity problems due to lack of 
transactions. My view is a bit of an outsider's, you'll have to talk to 
Tom Hughes for a first hand report, but it seems that MySQL, simple and 
easy as it may be for your everyday project, gives you more trouble than 
necessary in a "big" environment like ours is becoming. Not only do we 
lack spatial indexes and proper transactions, but the whole setup seems 
to be increasingly difficult to handle. For example, if you add an 
index, MySQL will copy the whole table and be more or less unusable 
during that time, which may be a day or so depending on the table and 
the index. And there are certain read-only queries that will also lock 
up the database. TomH has until now done a very good job at working 
around all these shortcomings so that the public doesn't suffer too much 
from them, but this can probably not go on forever.

What I don't know is whether other systems will be better! We used to 
have two people a week telling us to use PostGIS because "ya know it has 
all this geo stuff built in!", but nobody ever did it properly for us to 
have a comparison.

We also need something that scales well and ideally allows us to have a 
few "mirror sites"; what we currently do with the hourly diffs is (in my 
eyes!) another workaround that people can use to have a 
nearly-up-to-date database, but much better solutions are thinkable.


I don't, however, see all this in strict connection with change tracking 
and rollbacks. True, a system with proper spatial indexes/GIS support 
would make some things easier ("give me all changes in this bounding 
box"), but that can be done with our current workarounds as well.

I think we should start with change tracking and rollbacks *now*, based 
on the current system (also see 
http://wiki.openstreetmap.org/index.php/Monitoring_and_Rollback_Hack-a-thon_London) 
- and still, in an unrelated, parallel move - analyse our options to 
switch to another system.

 > And one
> technical question: Where in the SVN is the code of the API?

/sites/rails_port

(That's because it was not rails originally, so it has been ported to 
rails.)

Bye
Frederik