[OSM-talk] Bug in using osm2pgsql to keep up with dailies

[Michal Migurski]

>> It would be nice if it were possible to do the initial planet.osm
>> import without --slim for speed and space, and still import  
>> subsequent
>> diffs.
>
> I'm afraid that is not possible. The conversion from OSM to postgres  
> is
> lossy. It converts all the node references on the ways into linestring
> geometries referencing the individual lat/lon of the nodes without any
> reference to the IDs. This makes it impossible to update this data
> without storing a copy of all the raw nodes and ways in the extra  
> tables
> generated by the slim-mode import.

Gotcha.


> An alternative way to do this is to use osmosis to update the planet
> file with the daily diff and then reload this into postgres.
> Unfortunately this may take too long to be a practical solution.
>
> Another way to save more disk space is to filter out the data you  
> don't
> require. Either by applying a bounding box or by removing items from  
> the
> default.style.


So I'm definitely doing the bbox thing - I ran out of space on the  
volume when doing a slim import of planet.osm with a box that covered  
only the extended SF Bay Area. Seems like that should be fairly  
reasonable, right?

Probably the right thing to do would be to get the import done once  
with a larger volume available to Postgres (EC2 does give you a  
secondary disk at /mnt that's over 100GB), then keep up with  
incrementals moving forward after the initial inconvenience.

-mike.

----------------------------------------------------------------
michal migurski- mike at stamen.com
                  415.558.1610