[OSM-talk] OSM the mediocre alternative (was: don't like you etc.)
Frederik Ramm
frederik at remote.org
Sat Apr 21 19:21:32 BST 2007
Hi,
> Wikipedia had to create their mediawiki software too. Wiki's are so
> normal now that you can't even think about a web without them, but
> when wikipedia started this wasn't the case. In the same sense we've
> to develop our own software and compared to wikipedia, I think we've
> got a more complex problem. I don't think that it's very hard to do,
> but it will cost a lot of time to write. And I think that's a problem
> at the moment, we need more developers with time to write that
> software.
And we would also need a climate where such developers are actually
encouraged to think ahead and design the software they want to write.
In is blog post at http://www.opengeodata.org/?p=198, Steve defends the
simplicity - or naivety, as others might have it - of OSM, saying it was
designed to be so, and that at the heart of the project there are not
technical issues, but community issues.
I have mixed feelings about this.
As a programmer, I am frustrated with may aspects of OSM. Neither the
data nor the software measure up to what I would like. I would like to
write a renderer that can draw bridges properly, but for that I'd need a
data model that supports this *and* the editor that allows people to
actually feed that kind of information into OSM *and* I would also have
to educate people to actually use that feature and not draw two distinct
bridges (or no bridges at all, which is the most common way to deal with
it).
I would like to write routing software that knows about turn
restrictions, but for that I'd need a data model that supports this
*and* the editor *and* people who actually enter the information...
Arguably the "people" part is the most difficult in all these
situations. I can rewrite the ruby server and the major editors to
support a new data model on my own in the space of a few weeks - there's
not really that much code at the core of OSM. But never ever can I visit
even a fraction of junctions already in our database and check them for
turn restrictions!
So in a way, Steve is right, the community is the more important aspect.
On the other hand you won't attract capable programmers if the only use
you have for their talent is writing workarounds and fixes for problems
that arise from the technical simplicity of the core - the very same
simplicity that may attract community members. It's like sitting in a
ramshackle boat and saying: "Look, all the other stupid guys are still
on shore building their mega ships, and we're already miles out! Ha! By
the way, we'll need more capable seamen with buckets to get rid of the
water in here..."
So maybe OSM is in fact destined to be the project that creates a lot of
free data in a short amount of time and brings a lot of people into the
fold of free geodata, and at some later time, one of the mega ships with
ISO standards, headstrong design and hordes of programmers overtakes us,
imports our data and lures our community away with faster servers and
cooler features. But then again - while that could spell the end of OSM
the project, we'd still have produced a lot of seed data for them to
use, in the end helping the cause of free geodata a lot more than if we
were just sitting idle and waiting for one of those mega ships to leave
dry dock.
Bye
Frederik
--
Frederik Ramm ## eMail frederik at remote.org ## N49°00.09' E008°23.33'
More information about the talk
mailing list