On Mon, Jul 6, 2020 at 17:52 Tom Browder wrote:
> On Fri, Jul 3, 2020 at 12:56 Tom Browder wrote:
>
>> On Wed, Jul 1, 2020 at 15:18 Tom Browder wrote:
>> > Yesterday I took my first try at using osm2pgsql on a pbm file and,
>> > too late, I realized I didn't take full advantage of the server's
On Mon, Jul 6, 2020 at 23:52 José Juan Montes wrote:
>
> Entire Spain or Germany, imported into PostgreSQL with carto style,
> without history, range between 30-60 GB after import (the corresponding
> PBF files are 800MB-3GB). I'm speaking from the top of my head, but maybe
> that helps you
On Fri, Jul 3, 2020 at 12:56 Tom Browder wrote:
> On Wed, Jul 1, 2020 at 15:18 Tom Browder wrote:
> > Yesterday I took my first try at using osm2pgsql on a pbm file and,
> > too late, I realized I didn't take full advantage of the server's
> > large RAM and multi-core capability.
> ...
>
>
On Fri, Jul 3, 2020 at 1:44 PM Andy Townsend wrote:...
...
> If you get to the point where you've got something that could be turned
> into a Debian version of
> https://switch2osm.org/serving-tiles/manually-building-a-tile-server-20-04-lts/
I'll be glad to, Andy. You can follow my progress
On 03/07/2020 18:56, Tom Browder wrote:
On Wed, Jul 1, 2020 at 15:18 Tom Browder wrote:
...
Okay, I'm making progress, thanks to you all.
First, lesson learned (as suggested by all): I used Antarctica pbm as
a test bed for import which showed an immediate problem with
osm2pgsql.
Thanks to
On Wed, Jul 1, 2020 at 15:18 Tom Browder wrote:
> Yesterday I took my first try at using osm2pgsql on a pbm file and,
> too late, I realized I didn't take full advantage of the server's
> large RAM and multi-core capability.
...
Okay, I'm making progress, thanks to you all.
First, lesson
On Thu, Jul 2, 2020 at 02:41 Sarah Hoffmann wrote:
> On Wed, Jul 01, 2020 at 03:18:30PM -0500, Tom Browder wrote:
...
> > Should I compile those from source?
>
> Make sure to use osm2pgsql from backports. This always has
> the newest released version.
Thanks, Sarah!
-Tom
On Thu, Jul 2, 2020 at 02:01 Julien djakk
wrote:
> Hello Tom,
>
> About vector tiles : I have managed to render some vector tiles on
> heroku : https://github.com/djakk/openstreetmap-on-heroku
> The database is populated thanks to osm2pgsql. Rendering is done by mapnik.
> Maybe you can adapt it
On Wed, Jul 01, 2020 at 03:18:30PM -0500, Tom Browder wrote:
> I am running Debian Buster on a bare-iron dedicated server with 32 Gb
> RAM, 32 cores, and a single 4 TB spinning disk. I am running Pg 12
> (the version maintained by the Pg developers) with its default
> configuration.
>
> My
Hello Tom,
About vector tiles : I have managed to render some vector tiles on
heroku : https://github.com/djakk/openstreetmap-on-heroku
The database is populated thanks to osm2pgsql. Rendering is done by mapnik.
Maybe you can adapt it to your server ?
Julien "djakk" J
Le jeu. 2 juil. 2020 à
On 2020-07-01 3:28 p.m., Martin Koppenhoefer wrote:
sent from a phone
On 1. Jul 2020, at 23:26, Paul Norman via talk wrote:
In general, work_mem=128GB is good with most styles.
Paul, he wrote he had 32GB of RAM, should one assign more work_mem than there
physically is on the machine?
I
sent from a phone
> On 1. Jul 2020, at 23:26, Paul Norman via talk wrote:
>
> In general, work_mem=128GB is good with most styles.
Paul, he wrote he had 32GB of RAM, should one assign more work_mem than there
physically is on the machine?
I am asking because I thought that the value of
On Wed, Jul 1, 2020 at 16:26 Paul Norman via talk
wrote:
...
Thank you, Paul.
-Tom
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
On 2020-07-01 1:42 p.m., Frederik Ramm wrote:
+ I have seen a couple of different postgresql config suggestions. Is
there a one-size fits all or should I tailor it more to my server's
configuration.
Most configs you see will be for earlier Postgres versions and hence not
necessarily valid for
Hi,
On 7/1/20 22:18, Tom Browder wrote:
> Yesterday I took my first try at using osm2pgsql on a pbm file and,
> too late, I realized I didn't take full advantage of the server's
> large RAM and multi-core capability.
That's because the task is immensely disk intensive, and all the CPU and
RAM
Yesterday I took my first try at using osm2pgsql on a pbm file and,
too late, I realized I didn't take full advantage of the server's
large RAM and multi-core capability.
This morning I killed the import process and want to start anew. Some questions:
+ should I dump all the tables created
16 matches
Mail list logo
