[OSM-talk] Server slowness

[SteveC]

* @ 15/01/07 10:12:58 PM Martin.Spott at mgras.net wrote:
> As I already wrote in an earlier EMail using comparable wording: Show
> me the description of a representative load scenario and I'll run it on

I'll let nick handle this, index bit representations and detailed speeds.

> spent to import TIGER or shoreline data into the OSM database. For
> PostGIS-based backends everything is already there, no need to reinvent
> the wheel.

By this logic we should be using mapserver and geoserver too. WFS-T
anybody?

> For a start simply look at the "What tools work with data in a PostGIS
> database?" topic at this page:

Sigh. We're building a wiki, not a 1970's GIS. Most of them just don't
apply. We have fundamentally different problems. Nobody cares what
format the nodes are in right now. We want them in and out of the db
fast, yes, but really we're mesmerised by having an open map of our
countries first. Technology second.

> And there's a third item that should not get overlooked: Sooner or
> later people will group to work on a global road network and landcover
> layout that complies with the needs of OGC-compilant, GIS-related
> software. The incompatible storage format at OSM will prevent OSM from
> taking part in the play and potential committers will have to decide
> between participating in OSM or "the other" project - which certainly

HA! I thought that _was_ openstreetmap.

I fail to see one, why OSMs internal storage format matters a damn and
two, why people can't use a converter to get from its external format to
their favourite form.

> results in a waste of community resources because of duplicate effort.

I look forward to seeing this 'other' project, it's kafka-esque... please
use geoserver!

> Don't get me wrong: I don't insist of building my own road network, I

phew :)

> explicitly wish to cooperate with OSM here. Yet I hardly can see how
> this could be accomplished as long as OSM rejects to agree on common
> standards of data exchange.

There _is_ a standard and lots of people are using it to do lots of
things, just browse subversion or the wiki as I'm sure you know.

OSM has always gone for the simplest approach to JFDI. It's worked
remarkably well.

> Dealing only with OSM _export_ covers only a part of the problem. The
> other part is getting data into the OSM database.
> See, there's a lot of global road data floating around. There's very
> coarse VMap0 data. There is much better VMap1 road data (and coastline

VMAP1 is still pretty dire

> and everything) but this is limited to the US and very few parts
> outside the US. There is TIGER for the US only and there are other
> datasets for other parts of our world.

Are you in the US?

I ask because people in the US tend to see OSM as a technical problem
but in the EU we (or I, at least) see it as a social problem.

If I can try to come up with an analogy for what OSGEO standards people
drone on about... it's like telling jimbo wales et al. not to start
wikipedia because we have open office.. it doesn't quite do the job, but
it hooks up to Solaris and can run BASIC macros! Oh, Sun and IBM support
it and you can share with this ISO standard format that took 400
man-years to create. He'd still be sitting there.

And so would I. I've heard this standards for standards sake stuff since
the project began. I have an allergic reaction to much of what you say
because it's going down the path to committees, WFS-T, shapefiles,
strong top-down ontologies and everything else wrong with 'open' gis
right now.


I really am all for moving the entire db over, tomorrow, to geo columns.
But qGIS or mapserver compatability isn't going to sway me. If it does
all the history stuff we do, if it's faster. No problemo, but please
please just prove it and stop with the vague threats about forking
effort or the mapserver compatitibility.

Nick has a bunch of good arguments why spatial columns are slow, just
disprove him and we'll move on. :)

have fun,

SteveC steve at asklater.com http://www.asklater.com/steve/