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

[Michal Migurski]

I'm revisiting the planet.osm stuff this week, from below.

If the planet.osm file is from 2008-08-27, do I start running daily  
diffs at 20080827-20080828 or 20080828-20080829?

I would assume the former, but I get duplicate key errors when I try:

	"ERROR:  duplicate key value violates unique constraint  
"osm_bayarea_ways_pkey"
	(7)
	Arguments were: 26580292, {26469086,11080906,165095606,11080816},  
{"ref","A232","highway","trunk","name","Croydon Road"}, f,
	Error occurred, cleaning up"

Am I correct to go in this order?

	create planet-080827.osm.bz2
	ignore  20080827-20080828.osc.gz
	append 20080828-20080829.osc.gz
	append 20080829-20080830.osc.gz
	etc.

-mike.

On Aug 12, 2008, at 12:30 PM, Jon Burgess wrote:

> On Sun, 2008-08-10 at 18:45 -0700, Michal Migurski wrote:
>>>> 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?
>>>
>>> Perhaps the slim mode is not taking the bounding box into account.
>>> I'll take a look.
>>
>> Any news?
>>
>
> The news is mixed. The slim mode code does correctly exclude nodes
> outside of the bounding box when reading them in from the file.
> Unfortunately all the ways and relations still make it to the
> intermediate tables. It isn't until the code tries to extract the
> geometries from the ways that it can discover if the nodes for the way
> are outside the bounding box.
>
> It may be possible to improve this but it would need to make the
> assumption that all the nodes are in the file. I don't have time to  
> look
> at this right now though.




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