<div dir="ltr">On Sun, Aug 31, 2008 at 1:50 PM, Martijn van Oosterhout <span dir="ltr"><<a href="mailto:kleptog@gmail.com">kleptog@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Umm, yeah. There's that. The way I solved it was with the patch below,<br>
which is a gross hack but it works. Basically it turns every create<br>
into a modify so it deletes any conflicting rows before inserting. It<br>
may be the only way, but I'm still thinking on it...<br>
<br>
Have a nice day,<br>
<br>
Index: osm2pgsql.c<br>
===================================================================<br>
--- osm2pgsql.c (revision 10079)<br>
+++ osm2pgsql.c (working copy)<br>
@@ -278,6 +278,7 @@<br>
         xmlFree(xtype);<br>
     } else if (xmlStrEqual(name, BAD_CAST "create")) {<br>
         action = ACTION_CREATE;<br>
+        action = ACTION_MODIFY;<br>
     } else if (xmlStrEqual(name, BAD_CAST "modify")) {<br>
         action = ACTION_MODIFY;<br>
     } else if (xmlStrEqual(name, BAD_CAST "delete")) {<br>
<div class="Ih2E3d"><br>
<br>
On Sun, Aug 31, 2008 at 7:50 PM, Matt Amos <<a href="mailto:matt@matt-amos.uklinux.net">matt@matt-amos.uklinux.net</a>> wrote:<br>
> Martijn van Oosterhout wrote:<br>
>><br>
>> On Fri, Aug 29, 2008 at 5:23 PM, Robert (Jamie) Munro <<a href="mailto:rjmunro@arjam.net">rjmunro@arjam.net</a>><br>
>> wrote:<br>
>>><br>
>>> Great progress - that's now about 14 times real time.<br>
>>><br>
>>> How much disc space does the whole operation require?<br>
>><br>
>> On this system 42.5GB. Transient may be more, not sure.<br>
><br>
> on this system it took 22.8h for the initial planet import, and it is<br>
> currently consuming 44Gb. from munin graphs it seems that max usage was<br>
> roughly 9Gb more.<br>
><br>
> when i try to load the next day's osc i get the following error:<br>
><br>
> Reading in file: /home/osm/planets/20080827-20080828.osc.gz<br>
> Processing: Node(50k) Way(0k) Relation(0k)insert_node failed: ERROR:<br>
> duplicate key value violates unique constraint "planet_osm_nodes_pkey"<br>
> (7)<br>
> Arguments were: 291466881, 6319926.5639616642, -13695169.0319488477, (null),<br>
> Error occurred, cleaning up<br>
><br>
> the node with that ID seems to have been created just after midnight and<br>
> appears in the both the planet dump and daily diff. is there any way around<br>
> this, or should i just import the hourly diffs from 1am instead?<br>
><br>
> cheers,<br>
><br>
> matt<br>
><br>
</div></blockquote></div><br>I'm curious why the planet dump doesn't cut off at midnight, so you wouldn't get these duplicates. Is it because it's way more expensive to compare timestamps? I doubt it, because the minutely diff generation can run through the timestamps in the entire database in a few seconds. Am I missing something, or is it for hysterical raisins (as TomH likes to say) and nobody ever bothered to change it?<br>
<br>Karl<br></div>