Hi,
I was asked to assist in rendering some special purpose maps for a referendum coming in Bavaria. I looks like I ended up doing all the work ;)
http://de.wikipedia.org/wiki/Volksbegehren_%E2%80%9EF%C3%BCr_echten_Nichtrau...
Currently I'm using an overlay that can not be minutely updated. I would like to switch that to toolserver.
http://toolserver.org/~stephankn/?zoom=7&lat=49.0436&lon=11.32592&am...
Is there an infrastructure in place that makes it easy to add a new style to the tiles being rendered?
Or is it neccessary that an admin manually edits renderd.conf?
Can I simply provide a style file in my home dir? Do scripts exist to expire tiles of my style in case I adjust the style?
Stephan
Stephan Knauss schrieb:
http://de.wikipedia.org/wiki/Volksbegehren_%E2%80%9EF%C3%BCr_echten_Nichtrau...
Currently I'm using an overlay that can not be minutely updated. I would like to switch that to toolserver.
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. The toolserver offers everything you need to do this:
Is there an infrastructure in place that makes it easy to add a new style to the tiles being rendered?
Or is it neccessary that an admin manually edits renderd.conf?
It is. And it is also necessary that this list decides if a style is beeing accepted or not. This sounds more bureaucratic then it is, it just means that I think that your style could be rendered far more easily with openlayers.
Peter
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.
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? 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.
Or is it neccessary that an admin manually edits renderd.conf?
It is. And it is also necessary that this list decides if a style is beeing accepted or not. This sounds more bureaucratic then it is, it just means that I think that your style could be rendered far more easily with openlayers.
Is there a specific reason why it's so difficult to get a custom rendering besides the scripts needed not existing?
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.
Stephan
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
Peter Körner schrieb:
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.
Clustering seem difficult (http://docs.scipy.org/doc/scipy/reference/cluster.hierarchy.html#references) and I found no PostGIS function for it. So it seem necessary to work with random and a limit.
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.
STOP. I can't see a different between the existing surveillance layer and the smoking layer. Both have a lot of point objects and both are political maps. Our "sponsor" the "Verein" is political active and support democracy processes, you can see this on the Wahlprüfsteinen ( http://blog.wikimedia.de/2010/05/05/wahlpruefsteine-landtagswahl-nordrhein-w... ) and so on.
The old surveillance website (http://osm.vdska.de/?zoom=14&lat=52.40252&lon=9.7162&layers=B0TF... dangerous!) works with vector layer and kills my browser very often. Now we have an working solution and should use it in other situations if we can't provide a better way. The smoking layer is also IMO a use-case where OSM can show that it can more than other systems.
I see only two problems: *I think the maps on toolserver should be political neutral. (green, yellow, red is it not.) *The surveillance layer is relative stable. To compare the smoking layer will have a rapid change at beginning. So I have no idea to run efficient tile caching or so.
Greetings Kolossos
Am 16.06.2010 21:33, schrieb Tim Alder:
Peter Körner schrieb:
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.
STOP. I can't see a different between the existing surveillance layer and the smoking layer.
Okay, I'm sorry I brought up this discussion the way I did. the surveillance overlay was created as part of a tutorial on how to use the hstore column but of course you're right, there is no real difference.
I see only two problems: *I think the maps on toolserver should be political neutral. (green, yellow, red is it not.)
Stephan, could you think of another type of symbolizing this, maybe using some icon like [1].
*The surveillance layer is relative stable. To compare the smoking layer will have a rapid change at beginning. So I have no idea to run efficient tile caching or so.
I see this problem explicitly as we don't have a tile expireing strategy atm. I think we should give it a try and see how it runs.
Stephan, could you please put the style on your TS home-dir and post a link or send the style here otherwise.
Just as an idea, you could also just place a database-query script in a programming language you like on the TS and use this to serve your vector map. The vector map would not suffer from any caching or expiring problems nor from any neutrality problems. PS. i just saw that you're already do this. @Tim would it be ok hosting the vector layer on TS as it's done already [2]?
Peter
[1] http://de.wikipedia.org/wiki/Datei:D-P001_Rauchen_verboten.svg [2] http://toolserver.org/~stephankn/?zoom=7&lat=49.0436&lon=11.32592&layers=BTF
Peter Körner schrieb:
@Tim would it be ok hosting the vector layer on TS as it's done already [2]?
We didn't has such a problem on toolserver in the past, so I don't have a rule to handle this. My idea for a solution: If stephankn could also provide such a funny map opposed for smokers (lucky smooking smilis or [3] and more negative icons like [1]) Everything would be also neutral and fine. If not, I could also live with it, but perhaps we should discuss this than with the admins.
Greetings Kolossos
[1] http://de.wikipedia.org/wiki/Datei:D-P001_Rauchen_verboten.svg [2] http://toolserver.org/~stephankn/?zoom=7&lat=49.0436&lon=11.32592&layers=BTF
[3] http://commons.wikimedia.org/wiki/Category:Cigar_smoking
Tim Alder wrote:
Peter Körner schrieb:
@Tim would it be ok hosting the vector layer on TS as it's done already [2]?
We didn't has such a problem on toolserver in the past, so I don't have a rule to handle this.
It was suggested to better use a vector layer instead of a custom style. That was a main factor for me implementing a similar rendering using a vector layer.
If stephankn could also provide such a funny map opposed for smokers (lucky smooking smilis or [3] and more negative icons like [1]) Everything would be also neutral and fine.
I'm no expert in graphic design and more interested in solving technology challenges. If you can provide icons and the data in OSM I have no problem in providing a layer for a visualization of e.g. http://de.wikipedia.org/wiki/Verein_zum_Erhalt_der_bayerischen_Wirtshauskult...
It's all about supporting wikipedia with maps. So why not having a map visualizing the members of this verein on the wikipedia? A bit google stated they have 2.000 full members, usually bars and restaurants.
Does someone contact them and asked to import the data into OSM? With smoking=yes there exists a tag to mark such places. vebwk=yes might also be used for this.
Stephan
Tim Alder wrote:
Clustering seem difficult (http://docs.scipy.org/doc/scipy/reference/cluster.hierarchy.html#references) and I found no PostGIS function for it. So it seem necessary to work with random and a limit.
After a bit of research and thinking I'm now able to cluster POIs together using Postgres. This will save server CPU and bandwidth as it's no longer needed to transfer all features to the client. Even worse for POIs that are in numbers of 10k or more it would be simply too much for a client to do the clustering in Javascript. Openlayers recommends not more than 2.500 [1]
I think this mechanism could be used for other Vector layers as well. Maybe visualize the amenity=post_box? In germany there is a law requiring a post_box in maximum 1000 meter distance to houses.
An open issue is that I need some way to tell the server the current zoom level of the map. In case someone knows a way to do so in Openlayers it would be great.
Stephan
[1] http://trac.openlayers.org/wiki/FrequentlyAskedQuestions#Whatisthemaximumnum...
Stephan Knauss schrieb:
An open issue is that I need some way to tell the server the current zoom level of the map. In case someone knows a way to do so in Openlayers it would be great.
I read a post about this some time ago: http://lists.openstreetmap.org/pipermail/talk-de/2010-June/069395.html
Peter
Peter Körner schrieb:
Stephan Knauss schrieb:
http://de.wikipedia.org/wiki/Volksbegehren_%E2%80%9EF%C3%BCr_echten_Nichtrau...
Currently I'm using an overlay that can not be minutely updated. I would like to switch that to toolserver.
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. The toolserver offers everything you need to do this:
A vector layer without a system to reduce the number of elements at lower zoom levels is often a way to kill the browser of the user. That's not good. On the other side make a tile cache for higher zoom level no sense, because there will be a rapid change in the dataset if the project take off. So perhaps a hybrid system is perhaps the best way or running the layer with a limit as vector layer.
I see no reason to use a special local bavaria dataset for this layer, we should have everything fast enough in our database.
Greetings Kolossos