[OSM-dev] SoC project idea: Wikifikation of OSM
frederik at remote.org
Sun Mar 30 15:45:15 BST 2008
> 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
> - 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
- 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?
(That's because it was not rails originally, so it has been ported to
More information about the dev