Am 14.06.2010 21:07, schrieb Stephan Knauss:
Peter Körner wrote:
I don't think it's necessary to use a
tileserver for this style. You
could use the minutely updated postgis database to serve an openlayers
vector layer.
Hm, it does not sound like a good idea to transfer 15.000 or more
elements to be processed with openlayers. I saw this approach before, it
required each user to download 1.5MB of POI-data.
A lot more compared to the few kb of the bitmap layer that can also be
cached.
You're not supposed to transfer all POIs at once but only those in the
current viewport. In higher zoom levels you need to aggregate all POIs
that are close to each other (eg. >1000km on a world-map) into a single
POI. You may vary this POIs' size with the number of single POIs aggregated.
As in low zoom levels the POI symbols do overlap
(which is desired), is
there a possibility to reduce the amount of POIs already on the server?
You can do
any algorithmic work on the server by just writing your own
server software (php, perl, python, C - what you like)
That would save the transfer to the client.
How would I cluster the data using postgis? A simple LIMIT won't work as
it does not take the position of the elements into account.
Use the "way"
column. This is no PostGIS list.
Is there a specific reason why it's so difficult
to get a custom
rendering besides the scripts needed not existing?
It's that simple: we're
no style hoster.
CPU/storage space can not be the problem, as a style
rarely used is not
taking much resources. A style very popular is likely to be added anyway.
You
won't beleive how much it could be when rendering world wide with a
big number of styles.
Peter