Re: [OSM-dev] Tirex - Rendering jobs stucked in the queue
I'm not sure about a better place for this so I put it here: http://wiki.openstreetmap.org/wiki/Tirex/Logging -- Ing. Radek Bartoň Faculty of Information Technology Department of Computer Graphics and Multimedia Brno University of Technology E-mail: black...@post.cz Web: http://blackhex.no-ip.org Jabber: black...@jabber.cz ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] How to delete metatiles?
Dne neděle 16 Leden 2011 03:25:27 Frederik Ramm napsal(a): Ideally of course there would be a library that does all the metatile stuff (computing paths and so on) used by everyone, but that's maybe too hard because it would have to be usable from so many different places. +1 -- Ing. Radek Bartoň Faculty of Information Technology Department of Computer Graphics and Multimedia Brno University of Technology E-mail: black...@post.cz Web: http://blackhex.no-ip.org Jabber: black...@jabber.cz ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Tirex - Rendering jobs stucked in the queue
Any other thoughts what may cause it or how to debug where is the problem, please? -- Ing. Radek Bartoň Faculty of Information Technology Department of Computer Graphics and Multimedia Brno University of Technology E-mail: black...@post.cz Web: http://blackhex.no-ip.org Jabber: black...@jabber.cz ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Tirex - Rendering jobs stucked in the queue
You don't have renderd running in parallel to tirex, right? No, there is just mod_tile installed. Are you sure it isn't a tile which is hitting the timeout? There was a bug some time ago where the Agg code can get stuck in an infinite loop rendering some tiles but it only occurs in very rare circumstances. Have you tried starting up a fresh instance and just feeding in the tile co-ordinates of that one stuck request? I tired to stop apache2, tirex-master, tirex-backend-manager services, then delete all meta tiles and then start the services in order: tirex-backend- manager, tirex-master, apache2 (I suppose this is the correct one) and then I requested a single tile from a high level (14-17) sevral times with different tiles. From what I've seen while debugging it it doesn't matter on the tile requested. It stucks anytime and even there are some success=1 lines in the jobs.log, the metatiles are all empty. Isn't it possible that all this is caused by some problem with mod_deflate presence since it is the only difference between my working server and this new one, I'm aware of, except of hardware? -- Ing. Radek Bartoň Faculty of Information Technology Department of Computer Graphics and Multimedia Brno University of Technology E-mail: black...@post.cz Web: http://blackhex.no-ip.org Jabber: black...@jabber.cz ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Tirex - Rendering jobs stucked in the queue
heuristics: next planet render 345599; zoom level based 10800; last modified 0\n, referer: http://opentrackmap.no-ip.org/ [Thu Jan 13 16:08:48 2011] [debug] mod_tile.c(337): [client 147.229.13.140] Setting tiles maxAge to 352215\n, referer: http://opentrackmap.no-ip.org/ [Thu Jan 13 16:08:48 2011] [debug] mod_tile.c(693): [client 147.229.13.140] Update file info abs_path(/var/lib/mod_tile/tracks/7/0/0/0/50/136.meta), referer: http://opentrackmap.no-ip.org/ [Thu Jan 13 16:08:48 2011] [debug] mod_tile.c(693): [client 147.229.13.140] Update file info abs_path(/var/lib/mod_tile/tracks/7/0/0/0/50/136.meta), referer: http://opentrackmap.no-ip.org/ [Thu Jan 13 16:08:48 2011] [info] [client 147.229.13.140] tile_handler_serve: xml(tracks) z(7) x(63) y(44), referer: http://opentrackmap.no-ip.org/ [Thu Jan 13 16:08:48 2011] [debug] mod_tile.c(693): [client 147.229.13.140] Update file info abs_path(/var/lib/mod_tile/tracks/7/0/0/0/50/136.meta), referer: http://opentrackmap.no-ip.org/ [Thu Jan 13 16:08:48 2011] [info] [client 147.229.13.140] tile_handler_serve: xml(tracks) z(7) x(63) y(42), referer: http://opentrackmap.no-ip.org/ [Thu Jan 13 16:08:48 2011] [debug] mod_tile.c(288): [client 147.229.13.140] expires(tile_serve), uri(/tracks/7/63/44.png), filename(/var/lib/mod_tile/tracks/7/0/0/0/50/136.meta), path_info((null))\n, referer: http://opentrackmap.no-ip.org/ [Thu Jan 13 16:08:48 2011] [debug] mod_tile.c(326): [client 147.229.13.140] caching heuristics: next planet render 345599; zoom level based 10800; last modified 0\n, referer: http://opentrackmap.no-ip.org/ [Thu Jan 13 16:08:48 2011] [info] [client 147.229.13.140] tile_handler_serve: xml(tracks) z(7) x(63) y(43), referer: http://opentrackmap.no-ip.org/ [Thu Jan 13 16:08:48 2011] [debug] mod_tile.c(337): [client 147.229.13.140] Setting tiles maxAge to 350929\n, referer: http://opentrackmap.no-ip.org/ [Thu Jan 13 16:08:48 2011] [debug] mod_tile.c(288): [client 147.229.13.140] expires(tile_serve), uri(/tracks/7/63/42.png), filename(/var/lib/mod_tile/tracks/7/0/0/0/50/136.meta), path_info((null))\n, referer: http://opentrackmap.no-ip.org/ [Thu Jan 13 16:08:48 2011] [debug] mod_tile.c(288): [client 147.229.13.140] expires(tile_serve), uri(/tracks/7/63/43.png), filename(/var/lib/mod_tile/tracks/7/0/0/0/50/136.meta), path_info((null))\n, referer: http://opentrackmap.no-ip.org/ [Thu Jan 13 16:08:48 2011] [debug] mod_tile.c(326): [client 147.229.13.140] caching heuristics: next planet render 345599; zoom level based 10800; last modified 0\n, referer: http://opentrackmap.no-ip.org/ [Thu Jan 13 16:08:48 2011] [debug] mod_tile.c(326): [client 147.229.13.140] caching heuristics: next planet render 345599; zoom level based 10800; last modified 0\n, referer: http://opentrackmap.no-ip.org/ [Thu Jan 13 16:08:48 2011] [debug] mod_tile.c(337): [client 147.229.13.140] Setting tiles maxAge to 352484\n, referer: http://opentrackmap.no-ip.org/ [Thu Jan 13 16:08:48 2011] [debug] mod_tile.c(337): [client 147.229.13.140] Setting tiles maxAge to 348796\n, referer: http://opentrackmap.no-ip.org/ --- /var/log/tirex/jobs.log: 2011-01-13T16:08:48 id=1294931328_172267672 map=tracks x=64 y=40 z=7 prio=1 request_time=1294931328 expire= sources=MM render_time=86 success=1 2011-01-13T16:08:48 id=1294931328_173550768 map=tracks x=72 y=40 z=7 prio=1 request_time=1294931328 expire= sources=MM render_time=89 success=1 2011-01-13T16:08:48 id=1294931328_173565296 map=tracks x=56 y=40 z=7 prio=1 request_time=1294931328 expire= sources=MM render_time=87 success=1 2011-01-13T16:08:48 id=1294931328_173568768 map=tracks x=64 y=32 z=7 prio=1 request_time=1294931328 expire= sources=MM render_time=85 success=1 2011-01-13T16:08:48 id=1294931328_173568080 map=tracks x=72 y=32 z=7 prio=1 request_time=1294931328 expire= sources= render_time=90 success=1 2011-01-13T16:08:48 id=1294931328_173587752 map=tracks x=56 y=32 z=7 prio=1 request_time=1294931328 expire= sources=M render_time=90 success=1 --- PostgreSQL log even with all queries logging is empty becase it never gets to actual rendering. -- Ing. Radek Bartoň Faculty of Information Technology Department of Computer Graphics and Multimedia Brno University of Technology E-mail: ibar...@fit.vutbr.cz Web: http://blackhex.no-ip.org Jabber: black...@jabber.cz -- Ing. Radek Bartoň Faculty of Information Technology Department of Computer Graphics and Multimedia Brno University of Technology E-mail: black...@post.cz Web: http://blackhex.no-ip.org Jabber: black...@jabber.cz ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Documentation about Tirex update strategies configuration
Look for tirex-batch, tirex-tiledir-check, and tirex-tiledir-stat on http://wiki.openstreetmap.org/wiki/Tirex/Commands and read the man pages. Thank you. But if I understand it correctly, tirex-batch can only send request for immediate rendering. What I'm looking for is how to set expration time of set of tiles so they are re-rendered when accessed from mod_tile? Another taks not explained is how do I derive what tiles has changed since the last replication interval as described at http://wiki.openstreetmap.org/wiki/Minutely_Mapnik -- Ing. Radek Bartoň Faculty of Information Technology Department of Computer Graphics and Multimedia Brno University of Technology E-mail: black...@post.cz Web: http://blackhex.no-ip.org Jabber: black...@jabber.cz ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Documentation about Tirex update strategies configuration
Dne pondělí 10 Leden 2011 15:49:28 Philipp Borgers napsal(a): I'm not totally sure but I think this is impossible to configure in mod_tile. Check for expiration is a global configuration option and done the same way for every tile in code. IIRC, it is possible for mod_tile+renderd. Perhaps you write your own solution that checks sets of tiles and if they are expired you submit a render request to tirex for this set of tiles. Should not be that difficult. Writing own parser of osc.gz files that determines which tiles are affected by the change is quite complex task and I'm quite sure there must be something already (it must run on the official OSM tile server). I just don't know how it's called and how can I setup it. -- Ing. Radek Bartoň Faculty of Information Technology Department of Computer Graphics and Multimedia Brno University of Technology E-mail: black...@post.cz Web: http://blackhex.no-ip.org Jabber: black...@jabber.cz ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Documentation about Tirex update strategies configuration
Option 1: Have osm2pgsql write out a list of dirty tiles (options -e/-o). Process that with render_expired (in mod_tile directory). This will slow down your osm2pgsql runs by something like 25%, and IMHO it tends to re-render more than required because it makes an attempt to understand polygon relations. Option 2: (AFAIK this is used in the OSM production system) use a ruby script to parse the OSC diffs and generate rendering instructions: http://trac.openstreetmap.org/browser/applications/utils/export/tile_expiry Option 3: (used by OpenPisteMap) use a python script that processes OSC diffs and stores expiry information in a database: https://subversion.nexusuk.org/trac/browser/openpistemap/trunk/scripts/expi re_tiles.py Thank you, this is exactly kind of information I needed. One last sub-question: Is there a way how to delete expired tiles from the cache instead of re-rendering them? Othrerwise, I'd implement tirex-batch -- delete option if possible. Radek Bartoň. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Documentation about Tirex update strategies configuration
Hello everyone. I'm looking for documentation how to configure Tirex update strategy as described at http://wiki.openstreetmap.org/wiki/Tirex/Tile_Update_Strategies . Thank you. -- Ing. Radek Bartoň Faculty of Information Technology Department of Computer Graphics and Multimedia Brno University of Technology E-mail: black...@post.cz Web: http://blackhex.no-ip.org Jabber: black...@jabber.cz ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Multithread generate_tiles.py, generate_images.py and question about attribution.
Dne neděle 04 Říjen 2009 05:06:52 Dane Springmeyer napsal(a): We have a fix for that now in Mapnik SVN trunk. Would be great to get your help testing: This is what I'm getting with lastest SVN trunk: (gdb) run generate_poster.py Starting program: /usr/bin/python generate_poster.py [Thread debugging using libthread_db enabled] registered datasource : sqlite registered datasource : postgis registered datasource : raster registered datasource : osm registered datasource : ogr registered datasource : gdal registered datasource : shape Loading map of area (12.10 lon 48.395892 lat) - (18.86 lon 51.205865 lat)...grammar(unknown): [kct_yellow]='ski' rule(filter_statement): [kct_yellow]='ski' rule(or_expr): [kct_yellow]='ski' rule(and_expr): [kct_yellow]='ski' rule(not_expr): [kct_yellow]='ski' rule(cond_expr): [kct_yellow]='ski' rule(equation): [kct_yellow]='ski' rule(relation): [kct_yellow]='ski' rule(expression): [kct_yellow]='ski' rule(term): [kct_yellow]='ski' rule(factor): [kct_yellow]='ski' rule(function): [kct_yellow]='ski' rule(literal): [kct_yellow]='ski' rule(boolean): [kct_yellow]='ski' #rule(boolean): [kct_yellow]='ski' rule(number): [kct_yellow]='ski' #rule(number): [kct_yellow]='ski' rule(string_): [kct_yellow]='ski' #rule(string_): [kct_yellow]='ski' rule(property): [kct_yellow]='ski' /rule(property): ='ski' /rule(literal): ='ski' /rule(function): ='ski' /rule(factor): ='ski' /rule(term): ='ski' /rule(expression): ='ski' rule(regex): ='ski' #rule(regex): ='ski' /rule(relation): ='ski' rule(relation): 'ski' rule(expression): 'ski' rule(term): 'ski' rule(factor): 'ski' rule(function): 'ski' rule(literal): 'ski' rule(boolean): 'ski' #rule(boolean): 'ski' rule(number): 'ski' #rule(number): 'ski' rule(string_): 'ski' /rule(string_): /rule(literal): /rule(function): /rule(factor): /rule(term): /rule(expression): rule(regex): #rule(regex): /rule(relation): /rule(equation): /rule(cond_expr): /rule(not_expr): /rule(and_expr): /rule(or_expr): /rule(filter_statement): /grammar(unknown): bit_depth=8 color_type=6 *** glibc detected *** /usr/bin/python: malloc(): memory corruption: 0x086fe8b0 *** I can send you more info, just tell me what you need. -- Ing. Radek Bartoň Faculty of Information Technology Department of Computer Graphics and Multimedia Brno University of Technology E-mail: black...@post.cz Web: http://blackhex.no-ip.org Jabber: black...@jabber.cz ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Multithread generate_tiles.py, generate_images.py and question about attribution.
Dne neděle 04 Říjen 2009 05:09:51 Dane Springmeyer napsal(a): I meant to ask if you had yet compared your generate_tiles.py threading support to the recent additions in svn? I assume not since you wrote yours, as you say several months ago, but it would be interesting to test the speed of each version. Now I tried and the results are quite interesting. I tested on 3GHz Intel Core 2 Duo machine with 2GB RAM and using 2 threads. Result for OpenStreetMap generate_tiles.py was: real 42m10.608s user 21m39.037s sys 4m36.265s Result for OpenTrackMap (mine) generate_tiles.py was: real 56m57.562s user 32m7.568s sys 8m24.184s Then I noticed that OSM version doesn't use any overlapping. When I removed overlapping from mine version the result (even when full color version of tile is stored to the disk and then converted to 256 color version using ImageMagick) was: real 40m35.201s user 21m42.249s sys 6m42.197s Anyway, OSM version should use some overlapping because then there are some artifacts on tile borders. Maybe the best solution would be to render for example 16x16 (or more) tiles image with small border and then cut the image to separated tiles. This could bring also another performace gain because of better memory utilization or less access to DB. Mine version has small benefit compared to OSM version - it can be interrupted with CTRL+C keys, while mine version doesn't use job queue so it probably doesn't scale as well as OSM version. -- Ing. Radek Bartoň Faculty of Information Technology Department of Computer Graphics and Multimedia Brno University of Technology E-mail: black...@post.cz Web: http://blackhex.no-ip.org Jabber: black...@jabber.cz ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Multithread generate_tiles.py, generate_images.py and question about attribution.
Dne neděle 04 Říjen 2009 05:09:51 Dane Springmeyer napsal(a): I assume not since you wrote yours, as you say several months ago, but it would be interesting to test the speed of each version. I'll try it but I suppose that mine would be slower because it's writing to the disk both versions of tiles - 24-bit tiles and 256 colours ditherted tiles. It'll also depend on the overlapping area of tiles. In former generate_tiles.py there was rendered 512x512 tiles and then cropped to 256x256. I kept this setting but I think it can be much smaller like 256+2*32x256+2*32 to speed it up. -- Ing. Radek Bartoň Faculty of Information Technology Department of Computer Graphics and Multimedia Brno University of Technology E-mail: black...@post.cz Web: http://blackhex.no-ip.org Jabber: black...@jabber.cz ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Multithread generate_tiles.py, generate_images.py and question about attribution.
Dne sobota 03 Říjen 2009 18:52:12 Dane Springmeyer napsal(a): Jon recently added threading to generate_tiles.py in svn as well: Oh, I needed it two months ago so I wrote it. http://trac.openstreetmap.org/changeset/17484 I would if you have compared your implementation yet? Sorry, I don't understand the meaning of this sentence. Were you running into limitations within Mapnik or just memory when rendering large single images? When rendering large image for large geospatial area - whole Czech Republic. For example if you set x_parts and y_parts to 1 in the script and when you run it on 2GB RAM machine with 32-bit operating system. -- Ing. Radek Bartoň Faculty of Information Technology Department of Computer Graphics and Multimedia Brno University of Technology E-mail: black...@post.cz Web: http://blackhex.no-ip.org Jabber: black...@jabber.cz ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Multithread generate_tiles.py, generate_images.py and question about attribution.
Dne sobota 03 Říjen 2009 18:52:12 Dane Springmeyer napsal(a): Were you running into limitations within Mapnik or just memory when rendering large single images? Ah, now I remember, the memory error was caused by large memory needs when rendering hillshading layer in GeoTIFF file. -- Ing. Radek Bartoň Faculty of Information Technology Department of Computer Graphics and Multimedia Brno University of Technology E-mail: black...@post.cz Web: http://blackhex.no-ip.org Jabber: black...@jabber.cz ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Multithread generate_tiles.py, generate_images.py and question about attribution.
Hello everyone. First of all, I want to share with my two scripts for Mapnik rendering. First is a modified version of generate_tiles.py to use multithread rendering. Second is a modified generate_image.py to generate large bitmap posters like [1,2]. It uses tiled rendering so it's possible to render very large areas with high DPI. Only limitation is that whole poster must fit into computer's memory during merging and texts drawing because I don't know any image rendering library which can draw to memory mapped files or such. See scripts' code and comments or ask for detailed information. Seconly, I would like to ask how should I properly extend an OpenStreetMap attribution on the [1,2] to include my name and to mention an OpenTrackMap project [3]. Could you give me an advice about this? Thank you in advance. [1] - http://blackhex.no-ip.org/raw-attachment/wiki/Files/poster_preview.png - OpenTrackMap poster, scaled down to 25% (13.4 MB) [2] - http://blackhex.no-ip.org/raw- attachment/wiki/Files/poster_small_preview.png - OpenTrackMap poster, scaled down to 10% (2.4 MB) [3] - http://opentrackmap.no-ip.org/ - OpenTrackMap project homepage. -- Ing. Radek Bartoň Faculty of Information Technology Department of Computer Graphics and Multimedia Brno University of Technology E-mail: black...@post.cz Web: http://blackhex.no-ip.org Jabber: black...@jabber.cz #!/usr/bin/python # -*- coding: utf-8 -*- # # Generates a single large PNG image for a UK bounding box # Tweak the lat/lon bounding box (ll) and image dimensions # to get an image of arbitrary size. # # To use this script you must first have installed mapnik # and imported a planet file into a Postgres DB using # osm2pgsql. # # Note that mapnik renders data differently depending on # the size of image. More detail appears as the image size # increases but note that the text is rendered at a constant # pixel size so will appear smaller on a large image. from math import pi,cos,sin,log,exp,atan from mapnik import * import sys, os if __name__ == __main__: # Use Mapnik template from MAPNIK_MAP_FILE environment variable or osm.xml # file. try: map_file = os.environ['MAPNIK_MAP_FILE'] except KeyError: map_file = osm.xml # Configuration options poster_filename = poster.png # Name of output PNG file. lonlat_bottom_left = Coord(12.10, 48.55) # Bottom-left corner of area of interest in Lon/Lat coordinates. lonlat_top_right = Coord(18.86, 51.06) # Top-right corner of area of interest in Lon/Lat coordinates. x_size = 14040 # A0 width at 300 DPI y_size = 9930 # A0 height at 300 DPI #x_size = 28080 # A0 width at 600 DPI #y_size = 19860 # A0 height at 600 DPI x_parts = 8 # Number of tiles in x-direction. y_parts = 8 # Number of tile in y-direction overlap = 32 # Number of pixels of tile's overlapping. borders = (400, 600, 400, 800) # Left, bottom, right and top white border of the poster. frame_line_width = 10 # Line width of frame around map. title = OpenStreetMap - CTC Hiking Tracks Network - 30 September 2009 # Text of a title on the top. title_font_size = 300 # Font size of the title. title_offset = 700 # Offset of title bottom from the top of the poster. attribution = \302\251 OpenStreetMap contributors (http://www.openstreetmap.org/), CC-BY-SA # Text of an attribtuion on the bottom. attribution_font_size = 100 # Font size of the attribution, attribution_offset = 400 # Offset of attribution bottom from the bottom of the poster. # Compute image size for map. x_size = x_size - borders[0] - borders[2] y_size = y_size - borders[1] - borders[3] # Compute rendered area size in target projection. projection = Projection(+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgri...@null +no_defs +over) target_bottom_left = projection.forward(lonlat_bottom_left) target_top_right = projection.forward(lonlat_top_right) # Modify area to respect aspect ratio of image. image_aspect = x_size / float(y_size) target_center = Coord((target_bottom_left.x + target_top_right.x) * 0.5, (target_bottom_left.y + target_top_right.y) * 0.5) target_width = target_top_right.x - target_bottom_left.x target_height = target_top_right.y - target_bottom_left.y target_aspect = target_width / float(target_height) if image_aspect target_aspect: target_bottom_left.x = target_center.x - (target_height * image_aspect * 0.5) target_top_right.x = target_center.x + (target_height * image_aspect * 0.5) else: target_bottom_left.y = target_center.y - (target_width / image_aspect * 0.5) target_top_right.y = target_center.y + (target_width / image_aspect * 0.5) # Update target dimensions. target_width = target_top_right.x - target_bottom_left.x target_height = target_top_right.y - target_bottom_left.y target_aspect = target_width
[OSM-dev] renderd - terminate called after throwing an instance of 'mapnik::config_error'
Hello OSM developers. Since last svn up (maybe few more, I'm not sure), my instance of renderd is failing with message: terminate called after throwing an instance of 'mapnik::config_error' what(): Unable to find specified font face 'DejaVu Sans Book' Here is my renderd.conf: [mapnik] plugins_dir=/usr/lib/mapnik/input font_dir=/usr/share/fonts font_dir_recurse=1 And here is find /usr/share/fonts -name *DejaVu*: /usr/share/fonts/dejavu/DejaVuSerifCondensed-Italic.ttf /usr/share/fonts/dejavu/DejaVuSansMono.ttf /usr/share/fonts/dejavu/DejaVuSans.ttf /usr/share/fonts/dejavu/DejaVuSerif.ttf /usr/share/fonts/dejavu/DejaVuSerif-Italic.ttf /usr/share/fonts/dejavu/DejaVuSansCondensed-Bold.ttf /usr/share/fonts/dejavu/DejaVuSansMono-BoldOblique.ttf /usr/share/fonts/dejavu/DejaVuSerifCondensed.ttf /usr/share/fonts/dejavu/DejaVuSans-ExtraLight.ttf /usr/share/fonts/dejavu/DejaVuSansCondensed-BoldOblique.ttf /usr/share/fonts/dejavu/DejaVuSans-Bold.ttf /usr/share/fonts/dejavu/DejaVuSerif-Bold.ttf /usr/share/fonts/dejavu/DejaVuSansCondensed.ttf /usr/share/fonts/dejavu/DejaVuSerifCondensed-BoldItalic.ttf /usr/share/fonts/dejavu/DejaVuSerif-BoldItalic.ttf /usr/share/fonts/dejavu/DejaVuSansMono-Oblique.ttf /usr/share/fonts/dejavu/DejaVuSerifCondensed-Bold.ttf /usr/share/fonts/dejavu/DejaVuSans-Oblique.ttf /usr/share/fonts/dejavu/DejaVuSans-BoldOblique.ttf /usr/share/fonts/dejavu/DejaVuSansCondensed-Oblique.ttf /usr/share/fonts/dejavu/DejaVuSansMono-Bold.ttf I would like to ask if this is a problem of missing font (I don't see any DejaVuSansBook.ttf) and in what package/version I can find this font or this font face shoud be already included in for example DejaVuSans.ttf file. Nevertheless, shouldn't renderd/mapnik find alternative font instead of crashing with an excepiton? Thank you for your help. -- Ing. Radek Bartoň Faculty of Information Technology Department of Computer Graphics and Multimedia Brno University of Technology E-mail: black...@post.cz Web: http://blackhex.no-ip.org Jabber: black...@jabber.cz ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] renderd - terminate called after throwing an instance of 'mapnik::config_error'
Dne sobota 05 Září 2009 19:10:43 Richard Weait napsal(a): To check the fonts recognized by python, try python from mapnik import * for face in FontEngine.face_names(): print face ... [Enter] DejaVu Sans Bold DejaVu Sans Bold Oblique DejaVu Sans Book ... So missing font is not the problem: from mapnik import * for face in FontEngine.face_names(): print face ... DejaVu Sans Bold DejaVu Sans Bold Oblique DejaVu Sans Book DejaVu Sans Condensed DejaVu Sans Condensed Bold DejaVu Sans Condensed Bold Oblique DejaVu Sans Condensed Oblique DejaVu Sans ExtraLight DejaVu Sans Mono Bold DejaVu Sans Mono Bold Oblique DejaVu Sans Mono Book DejaVu Sans Mono Oblique DejaVu Sans Oblique DejaVu Serif Bold DejaVu Serif Bold Italic DejaVu Serif Book DejaVu Serif Condensed DejaVu Serif Condensed Bold DejaVu Serif Condensed Bold Italic DejaVu Serif Italic Any other reason for the exception? -- Ing. Radek Bartoň Faculty of Information Technology Department of Computer Graphics and Multimedia Brno University of Technology E-mail: black...@post.cz Web: http://blackhex.no-ip.org Jabber: black...@jabber.cz ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] renderd - terminate called after throwing an instance of 'mapnik::config_error'
renderd[16728]: DEBUG: Loading font: /usr/share/fonts/dejavu/DejaVuSansCondensed.ttf renderd[16728]: DEBUG: Loading font: /usr/share/fonts/dejavu/DejaVuSerifCondensed-BoldItalic.ttf renderd[16728]: DEBUG: Loading font: /usr/share/fonts/dejavu/DejaVuSerif- BoldItalic.ttf renderd[16728]: DEBUG: Loading font: /usr/share/fonts/dejavu/DejaVuSansMono- Oblique.ttf renderd[16728]: DEBUG: Loading font: /usr/share/fonts/dejavu/DejaVuSerifCondensed-Bold.ttf renderd[16728]: DEBUG: Loading font: /usr/share/fonts/dejavu/DejaVuSans- Oblique.ttf renderd[16728]: DEBUG: Loading font: /usr/share/fonts/dejavu/DejaVuSans- BoldOblique.ttf renderd[16728]: DEBUG: Loading font: /usr/share/fonts/dejavu/DejaVuSansCondensed-Oblique.ttf renderd[16728]: DEBUG: Loading font: /usr/share/fonts/dejavu/DejaVuSansMono- Bold.ttf Running in foreground mode... renderd[16728]: Starting stats thread -- Ing. Radek Bartoň Faculty of Information Technology Department of Computer Graphics and Multimedia Brno University of Technology E-mail: black...@post.cz Web: http://blackhex.no-ip.org Jabber: black...@jabber.cz ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] renderd - terminate called after throwing an instance of 'mapnik::config_error'
Dne sobota 05 Září 2009 23:32:18 Jon Burgess napsal(a): It certainly used to work but looks like it was broken in r17329. I have applied a fix in SVN. Jon Yeah, I knew it was something in some of the last commits :-). Thank you for the fix (I tested that it's working). -- Ing. Radek Bartoň Faculty of Information Technology Department of Computer Graphics and Multimedia Brno University of Technology E-mail: black...@post.cz Web: http://blackhex.no-ip.org Jabber: black...@jabber.cz ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
