Hi Jon,
I just tried your patch but now I always get the following error when doing
an import:
node_changed_mark failed: ERROR: prepared statement "node_changed_mark"
does not exist
Any ideas?
Thanks,
Jason
On Fri, Jan 22, 2010 at 8:48 PM, Jason Beverage <jasonbever...@gmail.com>wrote:
> Hi John,
>
> Thanks for the patch, I will give it a test this weekend! I think it would
> be a decent option on the command line if it works out well.
>
> Jason
>
>
> On Fri, Jan 22, 2010 at 6:38 PM, Jon Burgess
> <jburgess...@googlemail.com>wrote:
>
>> > > I'm working with osm2pgsql (latest trunk version) to import OSM into
>> > a
>> > > PostgreSQL/PostGIS database. The issue I'm having is that if I use
>> > > the --slim option I'll occasionally get an error similar to:
>> > >
>> > > Going over pending relations
>> > > COPY_END for COPY osm_rels FROM STDIN;
>> > > failed: ERROR: duplicate key value violates unique constraint
>> > > "osm_rels_pkey"
>> > > CONTEXT: COPY osm_rels, line 1207: "284132 0 323
>> > >
>> >
>> {42198453,20559277,20559273,20558263,20494565,40702583,19846737,19826462,20582455,20585..."
>> > >
>> > > If I don't use slim mode, it seems to always work. Right now I'm
>> > just
>> > > testing with state snapshots from http://downloads.cloudmade.com/,
>> > but
>> > > I'd like to be able to import the whole OSM planet database and I'd
>> > > really like to be able to use slim mode so I can do incremental
>> > > updates and reduce the memory requirements for importing.
>> >
>> > If I remember correctly this error occurs when you try to import two
>> > data sets which contain some overlapping data. In your case it appears
>> > that relation ID 284132 appears in both the data extracts. Only the
>> > slim
>> > mode keeps a copy of this node/way/relation data and triggers this
>> > error.
>>
>> You could try the attached patch to osm2pgsql. This makes it treat all
>> new data as a modify operation which should avoid problems caused by
>> duplicate data. Unfortunately this makes the data import process
>> significantly slower so I won't be applying this change to the trunk
>> code.
>>
>> I will think about adding this as a new command line option and try to
>> figure out if there is something that can be done to reduce the
>> performance penalty.
>>
>> Jon
>>
>>
>>
>>
>
_______________________________________________
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
