On 04/16/2010 07:42 AM, Peter Körner wrote:
Kai Krueger schrieb:
On 04/15/2010 02:44 PM, Peter Körner wrote:
I'd suggest taking a look at tirex.
May I ask what the practical advantages to using tirex over renderd are?
I'm not sure if there are practical reasons but tirex seems beeing under active development while i'm not sure about this in renderd. It sounded to me like the next logical step.
It depends a bit on how you define active development. As far as I can tell, when ever there were any specific needs, it got extended and developed. At the moment things (at least on tile.osm.org) seem to be running quite smoothly though, so there isn't much need for further development from that point.
One of the things I think people have discussed as a nice to have feature of renderd was to be able to do more sophisticated rendering a la topOSM with layers of contours and hillshading and compositing it directly in renderd which might be easier to do with tirex, but I think that also hasn't been implemented yet.
So given that tirex still seems a bit experimental, it might not be a bad idea to experiment with it on dev.osm.de for the moment and continue to use renderd on ptolemy for the moment.
Okay, let's do so. I'm 50:50 about tirex & renderd as I just don't know enough about them.
I guess it would be interesting to hear from Jon Burgess (main person behind renderd) and Frederik Ramm / Jochen Topf (main developers behind Tirex) how they see the future of either of them and their relation.
In adition I don't think that the toolserver should host the 250+ language styles - this is in my eyes the job of the live cluster (ortelius& cassini).
Are there any plans on setting up the live cluster? It does in some way
Give me some access and I'll see what I can do.
sound like those services shouldn't necessary be on the toolserver, but then it makes sense to test it on the toolserver first and to me (not really knowing anything about the wikipedia side of things) it appears as if WMA and geohack are still running on the toolserver too, even though they have been "in production" for a while.
How about getting up the map rendering for the languages of the 10 (or maybe 25) biggest Wikipedias. This would not create as much load on the toolserver as 250 styles and we can test most multilingual rendering things.
That would be: en, de, fr, it, pt, nl, ru, pl, es, ja
That would sound like a reasonable compromise to me. It might in addition be good to include some more of the different scripts too like for example Arabic, Chinese, one of the Indian scripts, Greek and Hebrew.
Regarding the use of the hstore: osm2pgsql HEAD currently can do an hstore import, but it can only import all tags into one hstore and additionally some tags into their own columns. Our testings points out, that tag-lookups are getting really slow for often used tags.
The hstore features also sounds quite experimental still and that it might need more development, but as it fits well with the large number of extra columns with all the name: and wikipedia: tags and the more general nature of the toolserver setup it seems like it would be worth giving it a try and help iron out any potential problems with it.
So I would sugest a small osm2pgsql stylesheet with the most used tags (amenity, highway and such), especially those that are often uses for lookups. Columns that are used most the time for value-lookups (addr:*, name, name:*, wikipedia:*) sould be imported into the hstore.
Perhaps it can just use the keys that are in the standard osm2pgsql (plus perhaps the 10 most common name: tags) as columns and everything else in the hstore.
Do you know how performance compares between hstore and separate columns if your where clause doesn't touch the hstore, but the select pulls in data from there? The need for multiple accesses per data row might still slow things down, but that might not be a problem for features that are used less often.
Kai
I'd like to do this as well as I'd like to help out in getting the live cluster up.
Peter