[OSM-dev] OpenStreetMap Carto release v3.1.0

2017-01-28 Thread Paul Norman

Dear all,

Today, v3.1.0 of the openstreetmap-carto stylesheet (the default
stylesheet on openstreetmap.org) has been released.

Changes include

- Added coffee shop rendering
- Added health clinic rendering
- Adjusted place label typography
- Road shield rendering improvements
- Internal code cleanups

Thanks to all the contributors for this release.

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v3.0.1...v3.1.0

As always, we welcome any bug reports at
https://github.com/gravitystorm/openstreetmap-carto/issues.


___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev


Re: [OSM-dev] size of postgresql database - without flat file

2017-01-28 Thread Paul Norman

On 1/28/2017 3:00 PM, Walter Nordmann wrote:


i'm just installing my brand new server to get my applications 
(missing boundaries and many more) running again. The server has 2x 
960GB SSD and 1x 2TB SATA disk installed.


I'm doing a full planet import using osm2pgsql 0.92. This time i'm 
doing the import without flat file, because i would like to use the 
nodes in planet_osm_nodes for some new queries.


But: planet_osm_nodes got an actual size of 785 GB, which is much much 
more than i exspected. Is that the usual size or may be, i'm doing 
something wrong? 


With the version of osm2pgsql you have when --extra-attributes is 
specified then tags are added to each object with the username, uid, 
version, timestamp, and changeset. This adds about 100 bytes per node to 
the table, which should add about 350GB. I would expect the size of 
planet_osm_nodes with a plain --slim import to be about 175GB, plus indexes.


Does your 785GB figure include indexes? If so, this sounds about right.

The latest versions of osm2pgsql do not have this issue because the node 
slim table schema has changed to no longer store tags, because they are 
never needed.


It's worth noting that 100 bytes per object for metadata is remarkably 
inefficient because it gets stored in a text[] array like 
"osm_user,lokejul,osm_uid,2034065,osm_version,11,osm_timestamp,2015-04-12T18:39:22Z,osm_changeset,30169891". 
This uses more bytes because it stores "tag" names, and because there 
are more efficient ways to store numbers and timestamps than as text.


___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev


[OSM-dev] size of postgresql database - without flat file

2017-01-28 Thread Walter Nordmann

Hi,

i'm just installing my brand new server to get my applications (missing 
boundaries and many more) running again. The server has 2x 960GB SSD and 
1x 2TB SATA disk installed.


I'm doing a full planet import using osm2pgsql 0.92. This time i'm doing 
the import without flat file, because i would like to use the nodes in 
planet_osm_nodes for some new queries.


But: planet_osm_nodes got an actual size of 785 GB, which is much much 
more than i exspected. Is that the usual size or may be, i'm doing 
something wrong?


my import batch:

-

# no more Flat File
# + extra_attributes

set -x
cd /osm/db/$1/create
OSM2PGSQL=/usr/local/bin/osm2pgsql

$OSM2PGSQL --verbose \
   --create \
   --slim \
   --exclude-invalid-polygon \
   --style /osm/db/wno_2017.style \
   --port 5432 \
   --database $1 \
   --latlon \
   --username postgres \
   --hstore-all \
   --hstore-add-index \
   --tablespace-main-data  $1_ttmp \
   --tablespace-main-index $1_is1 \
   --tablespace-slim-data  $1_ttmp \
   --tablespace-slim-index $1_is2 \
   -C 25000 \
   --cache-strategy optimized \
   --extra-attributes \
   --number-processes 12 \
   --keep-coastlines \
   --multi-geometry \
import/$2

--

called: do_import planet3 planet-latest.osm.bz2

any hints?

Regards
walter


___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev