Hi folks,
I'm proud to announce the availability of a new osm database that holds all nodes, ways and polygons with all used tags used in osm.
It uses the postgresql hstore extension to form a "tags" column which is an indexed hash array of all tags. despite that it has the "ways"-column known from regular osm2pgsql databases and the normal tag-columns that are listed in osm2pgsql's default.style.
Because of this combined scheme it is adequate for a lot of queries. To take use of the indexes you'll need to follow some rules. I'll point out some of them and also give some examples on how to use the new scheme.
I'll switch the diff-update process from the classic scheme to the new combined scheme in the next days and drop the old scheme (tables starting with planet_osm) in about two weeks if no one protests. I'll take some days to catch up.
== a query in a (relative) small area == in this case the geometry-index is the most important one and you can use the tags-column as you wish:
SELECT tags FROM planet_point WHERE (tags->'man_made' = 'surveillance') AND way && ST_Transform(ST_SetSRID(ST_MakeBox2D( ST_Point(8.17,50.04), ST_Point(8.36,49.95) ), 4326),900913);
== a query on a rarely used tag in a large area == in such a case you want to use the index on the tags-column to identify the nodes. the index only knows "which node has which tag", means it doesn't know anything about the values. So to take use of the index you need two different conditions: one to filter for the tag and a second one for the tags value:
SELECT tags FROM planet_point WHERE (tags ? 'club-mate') AND (tags->'club-mate' = 'yes')
== a query on a heavy used tag == in the case of a heavy used tag (eg. amenity), the gin-index on the hstore column does not work very good, especially when the tag has a such huge number of different values, because (as we learned before) the index doesn't know anything about the value. In such a case its better to use the regular columns. anyway such a query is always a bad idea, if you don't specify a small enough bounding box, so don't run this query, please:
SELECT tags FROM planet_point WHERE amenity = 'restaurant'
== live statistics == a very cool feature of the hstore column is that you can get live tag usage statistics from it. please don't run this on the whole planet before talking about it on this list, as it will may drive the database-server down, but for small or medium sized regions, it's really cool:
SELECT key, count(*) FROM ( SELECT (each(tags)).key FROM planet_point WHERE way && ST_Transform(ST_SetSRID(ST_MakeBox2D( ST_Point(8.17,50.04), ST_Point(8.36,49.95) ), 4326),900913) ) AS stat GROUP BY key ORDER BY count DESC, key LIMIT 20;
== rendering == thanks to river we have a quite nice rendeing stack on willow. You can use the command line tool /home/project/o/s/m/osm/bin/render to test your own styles and if they're ready you can mail them to this list so we can configure renderd to render tiles for them.
To show the capabilities of the new hstore scheme in conjunction with the rendering system, I created a style that renders surveillance cctvs on a transparent overlay. It's a quite simple style but it shows how to do things. It's located at /home/project/o/s/m/osm/data/styles/surveillance/surveillance.xml and should be redable for everyone.
to render a map of germany in this style, just log on to willow and call
render --bbox 5.56,55.04,15.35,47.15 --style /home/mazder/styles/surveillance/surveillance.xml --size 2000x2000
it will create a map.png if the current directory. Call /home/project/o/s/m/osm/bin/render --help to learn about the possible parameters.
You'll want to add /home/project/o/s/m/osm/bin/ to your PATH in your .bash_profile so you can just all render without a path.
I also added the style to the renderd config and you can take a look at it under http://toolserver.org/~osm/styles/?zoom=12&lat=52.50546&lon=13.42461... The style is not perfect, the icons are too big but hey - its just a sample.
Thank you for reading. I'm happily looking forward in seeing cool map styles and useful tools. If you got questions, just ask at maps-l@lists.wikimedia.org.
Peter
2010/5/11 Peter Körner osm-lists@mazdermind.de:
I'm proud to announce the availability of a new osm database that holds all nodes, ways and polygons with all used tags used in osm.
Thanks very much for working on this.
[...]
To show the capabilities of the new hstore scheme in conjunction with the rendering system, I created a style that renders surveillance cctvs on a transparent overlay. It's a quite simple style but it shows how to do things. It's located at /home/project/o/s/m/osm/data/styles/surveillance/surveillance.xml and should be redable for everyone.
I used the one in your home directory, didn't see a styles directory (neither as cmarqu nor as osm).
So, yeah, thanks to that example, I was able to successfully modify the SQL select for one of the map features I use - one that likely will come from hstore ("lit" that is). What's a bit special is that I'm using cascadenik for my styles, and in general, that works ok.
However... with a Cascadenik style, you have an mml file where you collect your SQL statements and define layers etc., and one or more mss files where you define the actual styling of the map elements (in a CSS-like syntax).
A simple mss element could look like this: .area.lighting[lit=yes]{ polygon-fill: #ddc96a; } You can also restrict things further though, like .area.lighting[lit=yes][building!=yes]{ polygon-fill: #ddc96a; } and there, things begin to break:
ERROR: column "building" does not exist
I'm not sure what to do now. Even supposing Cascadenik can be modified to support hstore selects (not by me for sure), this breaks the separation of getting the data and styling the data, as you now have to know *where* to get "building" from. I might as well switch to raw Mapnik in that case.
Cheers Colin
Am 13.05.2010 01:07, schrieb Colin Marquardt:
Thanks very much for working on this.
Thanks to river fo making this possible.
I used the one in your home directory, didn't see a styles directory (neither as cmarqu nor as osm).
ähh, yes. I moved it and didn't remember that I posted an absolute path. so its new location is now /home/mazder/styles/surveillance/surveillance.xml
What's a bit special is that I'm using cascadenik for my styles, and in general, that works ok.
I don't really know cascadenik but isn't it generating mapnik xml output? What does it generate in your problematic case?
ERROR: column "building" does not exist
The table "planet_point" does contain the building-column, but no lit-column. It would be very interesting to see what SQL cascadenic uses for mapniks table-parameter
as you now have to know *where* to get "building" from. I might as well switch to raw Mapnik in that case.
You can get all tags from the hstore and just don't use the classic columns if you don't want to.
Peter
2010/5/13 Peter Körner osm-lists@mazdermind.de:
Am 13.05.2010 01:07, schrieb Colin Marquardt:
What's a bit special is that I'm using cascadenik for my styles, and in general, that works ok.
I don't really know cascadenik but isn't it generating mapnik xml output? What does it generate in your problematic case?
The generated mapnik xml for /home/cmarqu/tools/mapnik-utils-sandbox/cascadenik/hike_n_bike/lighting.mml is /home/cmarqu/lighting_pre.xml.
The SQL from that file is <Parameter name="table"> (SELECT tags->'lit' AS lit, way FROM planet_polygon WHERE (tags ? 'lit') AND (tags->'lit' IN ('yes', 'no'))) AS areas</Parameter>
So I suppose I need to select * in some way? (I know next to no SQL.)
But even if this example can be made to work, in general this will only work as long as whatever I filter on is not in hstore.
You can get all tags from the hstore and just don't use the classic columns if you don't want to.
This probably comes with a speed penalty, right?
Cheers Colin
Am 13.05.2010 16:30, schrieb Colin Marquardt:
The SQL from that file is <Parameter name="table"> (SELECT tags->'lit' AS lit, way FROM planet_polygon WHERE (tags ? 'lit') AND (tags->'lit' IN ('yes', 'no'))) AS areas</Parameter>
So I suppose I need to select * in some way? (I know next to no SQL.)
no, never select *. if you need 'building', just select tags->'building' AS building:
SELECT tags->'lit' AS lit, tags->'building' AS building, way FROM planet_polygon WHERE (tags ? 'lit') AND (tags->'lit' IN ('yes', 'no'))
But even if this example can be made to work, in general this will only work as long as whatever I filter on is not in hstore.
No that is no problem, I think. From the sql-clients point of view, SELECT foo FROM .. just the same as SELECT tags->bla AS foo FROM .. The AS construct makes it transparent for the client if the tag comes from the hstore or from a normal column. This is why you can just write <Filter>[lit] = 'yes'</Filter>, no matter where 'lit' comes from.
You can get all tags from the hstore and just don't use the classic columns if you don't want to.
This probably comes with a speed penalty, right?
There is no penalty for fetching data from the hstore. There is a small penalty when using the hstore in the where clause but this highly depends on the usage of the tag.
Peter
No that is no problem, I think. From the sql-clients point of view, SELECT foo FROM .. just the same as SELECT tags->bla AS foo FROM .. The AS construct makes it transparent for the client if the tag comes from the hstore or from a normal column. This is why you can just write <Filter>[lit] = 'yes'</Filter>, no matter where 'lit' comes from.
Ah, thanks. I have now switched the live lighting.xml file to use hstore, yay. The hikebike style is to follow, but that will take a lot more time.
Cheers Colin
Am 13.05.2010 19:45, schrieb Colin Marquardt:
I have now switched the live lighting.xml file to use hstore, yay. The hikebike style is to follow, but that will take a lot more time.
Can we stay with the original plan of dropping the old planer_osm-tables in about two weeks or do you expect to need more time?
Peter
2010/5/13 Peter Körner osm-lists@mazdermind.de:
Am 13.05.2010 19:45, schrieb Colin Marquardt:
I have now switched the live lighting.xml file to use hstore, yay. The hikebike style is to follow, but that will take a lot more time.
Can we stay with the original plan of dropping the old planer_osm-tables in about two weeks or do you expect to need more time?
It should be possible, though the next weekends are pretty much booked out on my side. But then, I never made a claim of a level of service, so some downtime will just remind people of that.
Cheers Colin
Colin Marquardt schrieb:
It should be possible, though the next weekends are pretty much booked out on my side. But then, I never made a claim of a level of service, so some downtime will just remind people of that.
Okay, just tell me if you need more time. I don't want interrupt a working system if I don't have an important reason.
Peter
2010/5/13 Peter Körner osm-lists@mazdermind.de:
Am 13.05.2010 19:45, schrieb Colin Marquardt:
I have now switched the live lighting.xml file to use hstore, yay. The hikebike style is to follow, but that will take a lot more time.
Can we stay with the original plan of dropping the old planer_osm-tables in about two weeks or do you expect to need more time?
Alright, I now switched the hikebike style to use the new tables, and hopefully made it a bit more efficient in that process. So as far as I'm concerned, the planet_osm_* tables can go.
Cheers Colin
Colin Marquardt schrieb:
I have now switched the live lighting.xml file to use hstore, yay. The
What makes me wonder is, that the server seems to deny rendering some tiles, eg.
http://toolserver.org/tiles/lighting/3/4/3.png or http://toolserver.org/tiles/lighting/4/7/5.png
while http://toolserver.org/tiles/lighting/4/8/5.png
gets rendered. I requested those tiles days ago but they're not there yet. mod_tile did not even create the directory /osm/tiles/lighting/3 so I guess there's sth. going wrong.
Peter
2010/5/14 Peter Körner osm-lists@mazdermind.de:
Colin Marquardt schrieb:
I have now switched the live lighting.xml file to use hstore, yay. The
What makes me wonder is, that the server seems to deny rendering some tiles, eg.
http://toolserver.org/tiles/lighting/3/4/3.png or http://toolserver.org/tiles/lighting/4/7/5.png
while http://toolserver.org/tiles/lighting/4/8/5.png
gets rendered. I requested those tiles days ago but they're not there yet. mod_tile did not even create the directory /osm/tiles/lighting/3 so I guess there's sth. going wrong.
Well, at this zoom, I could imagine that something times out before a tile can be rendered if there is much data to be pulled. 4/8/5.png maybe just made it. OTOH, I also saw very different tile rendering times even for zooms 14 and 15, some were rendered almost instantly, while others took in the order of 30 mins. I didn't see a common pattern there yet, for instance a boundary or relation with many members to be drawn on the slow tiles.
I will add this !bbox! thing from http://trac.mapnik.org/ticket/415 at some point, maybe that makes a difference.
Cheers Colin
Colin Marquardt schrieb:
2010/5/14 Peter Körner osm-lists@mazdermind.de:
Colin Marquardt schrieb:
Well, at this zoom, I could imagine that something times out before a tile can be rendered if there is much data to be pulled.
Well then we should upper this timeout, I think.
It seems not to be a renderd configuration, though. I don't know where to look for the mod_tile configuraion. do you?
Peter
2010/5/14 Peter Körner osm-lists@mazdermind.de:
Colin Marquardt schrieb:
2010/5/14 Peter Körner osm-lists@mazdermind.de:
Colin Marquardt schrieb:
Well, at this zoom, I could imagine that something times out before a tile can be rendered if there is much data to be pulled.
Well then we should upper this timeout, I think.
It seems not to be a renderd configuration, though. I don't know where to look for the mod_tile configuraion. do you?
No, I don't, sorry. Timeout is also just a hunch, nothing based on fact.
Cheers Colin
On Fri, May 14, 2010 at 2:19 PM, Peter Körner osm-lists@mazdermind.de wrote:
Colin Marquardt schrieb:
2010/5/14 Peter Körner osm-lists@mazdermind.de:
Colin Marquardt schrieb:
Well, at this zoom, I could imagine that something times out before a tile can be rendered if there is much data to be pulled.
Well then we should upper this timeout, I think.
It seems not to be a renderd configuration, though. I don't know where to look for the mod_tile configuraion. do you?
Any timeouts configured in mod_tile should not be effecting this, as they only controll serving and not rendering. Those tiles that don't get rendered in time for serving, will still continue to render in the background and when finished be written to disk so that they are available the next time you try and view them.
I am also not aware of any timeouts in renderd that could explain this.
Just a thought, but is it possible that renderd some how chokes on some other resource limit? I haven't looked at the lighting style, but the hikeandbike style looked fairly complex seemingly pulling in alot of data at low zooms. Might renderd even crash on these tiles and automatically get restarted?
Kai
Peter
Maps-l mailing list Maps-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/maps-l
2010/5/14 Kai Krueger kakrueger@gmail.com:
Just a thought, but is it possible that renderd some how chokes on some other resource limit? I haven't looked at the lighting style, but the hikeandbike style looked fairly complex seemingly pulling in alot of data at low zooms. Might renderd even crash on these tiles and automatically get restarted?
The lighting style is not as bad in that regard, but can certainly be made better still. Note to self: pull from the roads table in low zooms.
Cheers Colin
2010/5/14 Peter Körner osm-lists@mazdermind.de:
Colin Marquardt schrieb:
I have now switched the live lighting.xml file to use hstore, yay. The
What makes me wonder is, that the server seems to deny rendering some tiles, eg.
http://toolserver.org/tiles/lighting/3/4/3.png or http://toolserver.org/tiles/lighting/4/7/5.png
while http://toolserver.org/tiles/lighting/4/8/5.png
gets rendered. I requested those tiles days ago but they're not there yet. mod_tile did not even create the directory /osm/tiles/lighting/3 so I guess there's sth. going wrong.
I was tweaking lighting.xml a bit tonight, and restarted renderd once, before noticing the other things going on (https://jira.toolserver.org/browse/TS-609 - I might have been the source of the SIGTERM). Something may have changed things, because those lighting tiles are now rendered - or it was just a coincidence...
Cheers Colin
Hi
I just finished setting up the minute-replicate diff import. It's running on willow because ptolemy can't connect to planet.osm.org.
You can monitor the state of the import process by calling
/home/project/o/s/m/osm/bin/replag -h
Currently it's 9 day(s) and 5 hour(s) behind the main database.
I'm not sure how the default mod_tile expiring rules are. As we're not actively expiring tiles as part of our update process, it'll depend on them when new features will appear on the map.
Peter
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Peter Körner:
It's running on willow because ptolemy can't connect to planet.osm.org.
$ http_proxy="http://ha-proxy.esi:8080" $ export http_proxy
- river.
River Tarnell schrieb:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Peter Körner:
It's running on willow because ptolemy can't connect to planet.osm.org.
$ http_proxy="http://ha-proxy.esi:8080" $ export http_proxy
Thank you. I just ported the replication to ptolemy but it will run willow as well. We'll have to look what's better when the load gets higher on ptolemy. Atm it should not make any difference despite having all core configurations and tasks in one place.
Peter