Did you see the patch posted a few days ago about making creates into modifies?
Otherwise I'll just commit it to SVN.
Have a nice day,
On Wed, Sep 3, 2008 at 7:00 PM, Michal Migurski <[EMAIL PROTECTED]> wrote:
> I'm revisiting the planet.osm stuff this week, from below.
>
> If the planet.osm fil
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 un
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?
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?
> Slim mode over the full planet won't work without the intarray module,
> but it's not included in contrib/ for postgresql-8.3 on Debian Lenny.
> Where should I be looking for this?
>
If anything like ubuntu then it is -- but freakily it's called _int
rather than intarray. So see if you can find
>> 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 accou
2008/8/5 Michal Migurski <[EMAIL PROTECTED]>:
>> 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
> vol
>> 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
On Mon, 2008-08-04 at 14:51 -0700, Michal Migurski wrote:
> > Nice, works very well.
> >
> > One hiccup I see is that if I run the executable from a directory
> > other than the one where it was built, it complains that default.style
> > can't be found. Otherwise works beautifully.
>
>
> So, two
> Nice, works very well.
>
> One hiccup I see is that if I run the executable from a directory
> other than the one where it was built, it complains that default.style
> can't be found. Otherwise works beautifully.
So, two frustrating things about osm2pgsql's --slim mode:
I first tried doing the
10 matches
Mail list logo
