On Tuesday 27 October 2009 06:01:05 Marcus Wolschon wrote:
> I wasn´t aware that mapnik did not actually render the coastlines
> we have in the database.
It does render the OSM coastlines. It's just that the coastline data goes
through a different preprocessor.
--
m.v.g.,
Cartinus
On Mon, Oct 26, 2009 at 1:24 PM, Peter Körner wrote:
>> Looks interesting but only for high zoom-levels.
>> What queries can be supported to e.g. render a map of the world?
>> That would at least require all coastlines but not in full resolution.
>
> This is only true for the coastlines, as mapnik
Hi,
I was just wondering what the space requirements were for loading the whole
planet file. I have about ~50GB free and am running out of space when running
osm2pgsql in slim mode.
i.e
nohup ./osm2pgsql -s -d osm -m -v /data/planet-091014.osm.bz2 &
...
...
Committing transaction for planet_os
>>> A better data format for
>>> rendering would contain only point of interest nodes, with ways
>>> represented as polylines of points, with no need for the client to
look
>>> up
>>> the coordinates of the way's constituent nodes by ID.
>
>> What you're talking for is a xml/json frontend for a
This is directly possible within DBSlayer.
Stefan
Op 26 okt 2009 om 13:05 heeft Peter Körner
het volgende geschreven:\
>> A better data format for
>> rendering would contain only point of interest nodes, with ways
>> represented as polylines of points, with no need for the client to
>> look
> Looks interesting but only for high zoom-levels.
> What queries can be supported to e.g. render a map of the world?
> That would at least require all coastlines but not in full resolution.
This is only true for the coastlines, as mapnik is doing the same
(coastlines from shapefile, everything e
Hi,
2009/10/26 Peter Körner :
>> A better data format for
>> rendering would contain only point of interest nodes, with ways
>> represented as polylines of points, with no need for the client to look up
>> the coordinates of the way's constituent nodes by ID.
>
> What you're talking for is a xml/j
On Mon, 26 Oct 2009 13:05:07 +0100, Peter Körner
wrote:
>> A better data format for
>> rendering would contain only point of interest nodes, with ways
>> represented as polylines of points, with no need for the client to look
>> up
>> the coordinates of the way's constituent nodes by ID.
>
> Wh
> A better data format for
> rendering would contain only point of interest nodes, with ways
> represented as polylines of points, with no need for the client to look up
> the coordinates of the way's constituent nodes by ID.
What you're talking for is a xml/json frontend for a postgis-db. The
As part of an experiment with WebGL (3D in browser rendering of OSM data)
I'm planning on doing, I've developed a quick read-only OSM API and data
format optimised for rendering. The rationale was, that if the front end
is doing only rendering of OSM data (no editing), the standard OSM XML
form
10 matches
Mail list logo