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