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