[OSM-talk] Server slowness

[Martin Spott]

Nick Whitelegg wrote:
> On 1/15/07, Kristian Thy <thy at 42.dk> wrote:
> >> On Mon, Jan 15, Nick Hill wrote:

> >> Otherwise, I very much agree with the main parts of your post. A lot of
> >> OSM's potential usefulness to me is lost in the amount of work I have to
> >> do to make the data usable.
>
> >What would make the data more usable, aside from the UTF-8 problems in
> >the past?  I guess stuff like exporting as Shapefiles or GML, GeoRSS,
> >or a PostGIS SQL dump?
> 
> If people are interested in shapefiles, there is osm2shp in SVN. It takes 
> a "cleaned" OSM file (ways with logically ordered segments) and outputs a 
> shapefile for nodes and another for ways. Polygons are not done yet.

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

And there is OSM.
For example it would make a great start to merge the forementioned
datasets and develop OSM on _top_ of this. This approach would deliver
us a global road network whose accuracy constandly increases via manual
editing - _BUT_ this would require OSM to use a data storage that is
capable of handling large datasets like TIGER _and_ providing an
interface that allows import of such data without too much hassle.

>From reading these mailing lists and private communication I understand
that the import of TIGER was stopped due to technical and design
reasons. This does not make a good figurehead for a reliable and
well-designed data storage,

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------