Re: [OSM-talk] Is tile rendering having a crisis?
On Tue, 2016-08-09 at 14:41 -0700, Ben Discoe wrote: > The tile renderer, "renderd", has been heavily overloaded for quite a > while, like 90% of the time it is dropping, and the dirty queue is > entirely ignored. However, in the past day, something has happened > so > that it is even more overloaded, even the standard request queue is > not getting handled, and the dropped is out of control: > > http://munin.openstreetmap.org/openstreetmap/orm.openstreetmap/render > d_processed.html > > Does anyone know what's going on? This is a large frustration for > me, > and I'd happily donate money to beefing up our render server(s). There was an update to the rendering style a couple of days ago and this triggered all of the existing tiles on Orm to be marked as needing a fresh render the next time someone requests them. This means there are far more requests hitting the render daemon than normal. It typically takes about a week for the request queues to return to normal when this happens. If you look at the "by-year" chart you can see spikes in the dropped counts where this has happened about a dozen times in the past year. The OSM operations team are aware of the increased load on the tile servers. There was a recent jump in usage when one of the other tile providers stopped unlimited free access to their service. There was also a site using OSM tiles for a popular Pokemon Go map causing lots of additional traffic, once this was identified the site was blocked. Jon (member of the OSM operations team) ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-GB] The Chilterns AONB boundary
On Wed, 2015-12-16 at 15:36 +, Bob Hawkins wrote: > Neither of these sites seem to offer the opportunity to download a > digital file. I wonder if an OSM user here can help? There is a download option for the AONB data in this list of files: http://www.geostore.com/environment-agency/WebStore?xml=environment-agency/xml/ogcDataDownload.xml I haven't checked the licensing so cannot make any comment about its suitability for use in OSM. Jon ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [OSM-talk] My first coastline question
On Mon, 2012-10-29 at 18:48 +, John Sturdy wrote: In the view around http://www.openstreetmap.org/?lat=52.21134lon=-10.35719zoom=16layers=M, the road R549 seems to cross the coastline a few times. I brought up Potlatch 2 to try to fix this. It turned out that the photo data isn't available for part of that area, but I did notice that the coastline way isn't the coastline that's visible on the slippy map (which doesn't seem to have a way corresponding to it). Is it just a matter of waiting for a very occasional automatic update, or is there something that needs to be fixed manually here? If you zoom out to around level 13 then you will see that the coastline follows the purple path. That seems to accurately reflect the current coastline data. There is no automated refresh of the high zoom tiles except when some other data changes in the surrounding area. The coastline rendering involves an additional shapefile processing step which adds a little more update latency too. If you wait a few months then the oldest tiles will probably be purged from disk and rendered with fresh data. You can make this happen sooner by grabbing the URL for the tile and appending /dirty to the end. This tells the rendering system that you want it to refresh the contents. I have just done this for a few of the tiles shown on your link above so you should see the effect soon (you may need to hit refresh in your browser). Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-GB] This one is driving me potty
On Tue, 2012-09-25 at 17:43 +0100, Ed Loach wrote: It’s almost as though the rendering database is missing a changeset (or a replication diff containing that changeset), possibly http://www.openstreetmap.org/browse/changeset/9728130 We just had a similar data error reported via trac where another change was dropped within the same hour as this changeset: https://trac.openstreetmap.org/ticket/4591 I looked back through various logs and it seems the machine holding the rendering database was rebooted at this time. There was an error applying the first 30 minutely replication diffs when it came back up. It is not clear why this happened. There is an intention to reload the Mapnik rendering database with the ODBL planet file and this will fix these inconsistencies. I don't have an estimate of when this will be done. Jon ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [OSM-talk] News report license switch done
On Sat, 2012-09-08 at 18:22 +0200, Stephan Knauss wrote: Hi, german IT newsticker heise online did report that we finally switched the license to ODbL. They said it was announced during SOTM. Is this right? http://www.heise.de/newsticker/meldung/OpenStreetMap-schliesst-Lizenzwechsel-ab-1703197.html If so, I'm quite disappointed that the community was not informed first... If this is a false announcement, the OSMF might want to have that corrected. Stephan Were looking for an announcement like these: http://blog.osmfoundation.org/2012/09/06/your-first-odbl-planet/ http://www.mail-archive.com/talk@openstreetmap.org/msg43823.html Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapnik coastline layer
On Fri, 2012-08-24 at 12:21 +0100, David Groom wrote: Just wondering if it might be time for the mapnik coastline files to be updated. It seems over two months since this was last done. I have just updated the coastline shapefiles with a new version derived from the planet-120801 file. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Coastline updates still running?
On Wed, 2012-04-11 at 20:41 +0100, OJ W wrote: Is there some problem with the coastline at Doha airport? The new coastline (changed since February) doesn't yet appear in rendered maps, but looks reasonable in the Edit view: http://www.openstreetmap.org/?lat=25.24915lon=51.61024zoom=15layers=M I have just deployed an updated set of coastline shapefiles which look like they will fix the problem once the area is rendered again. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Issues with OSM import to postgis
On Mon, 2011-06-13 at 12:04 +0200, Zolt Egete wrote: As far as other map files are concerned I have downloaded a few ones but this is the only one which I could unpack (have used pbzunzip2, bzip2, bunzip2) but all the time I have got corrupt archive messages. Also the MD5 sum of the downloaded file where not consistent with the md5 hash sum from the servers (I do not yet know the reason why) I think this is where your problem is. With the recurring checksum issues you are seeing I would suspect that something in your system is causing random data to be corruption. This could be one of a thousand different things: a faulty RAM module, hard drive cable, bad PSU, an over clocked or over heating CPU, bad PCI card etc. Or it could be a software issue, such as a bad driver in the kernel or X11. It can be really hard to identify the real cause but you could try running memtest86+ or swapping around pieces of hardware. I do not believe the files on the server are at fault. If they were then I would expect to see many more complaints. Until you can resolve the underlying data corruption issue then I don't believe it is worth you trying different combinations of options with osm2pgsql. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Coastline updates
On Fri, 2011-02-25 at 20:01 +0100, Jochen Topf wrote: Hi! Falmouth: http://www.openstreetmap.org/?lat=50.15364lon=-5.0639zoom=17layers=M Looks ok now in this zoom level. Still some errors if you zoom in. I had a look at it again and marked some tile manually as dirty and I get the correct rendering then. So the problem seems not to be the coastline stuff but that there are tiles that haven't been re-rendered for half a year!? I updated the coastline shapefiles used by the mapnik layer last night. The previous update was about 4 weeks ago. If no one edits any data in an area after the coastline shapefiles are changed then it may be a long time before the tiles are rendered again to pick up the changes (as you are seeing here). Normally I force the zoom 0 - 12 tiles to re-render across the world each time I update the coastline shapefiles but it takes too long to do all zoom levels on each update. Back in January I ran a process to re-rendered all tiles last rendered prior to 1st Oct 2010 across the full 0-18 zoom range. This took a few weeks to complete and should have picked you older changes. I will consider running it again with a more recent cut-off point. Perhaps some of the other discrepancies are due to newer edits to the coastlines? Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] South Pole?
On Mon, 2010-11-22 at 17:59 +0100, Rob wrote: even more polution http://www.openstreetmap.org/?lat=0.445lon=-1.674zoom=10layers=M That has a different cause. Someone did upload data putting buildings here which have since been removed: http://www.openstreetmap.org/browse/way/75383193 What you are seeing is a few tiles which have escaped the re-rendering process after the data was removed. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] coastline in mapnik
On Sun, 2010-11-07 at 23:29 -0800, Michal Migurski wrote: I think we went back to some older shapefiles after reports of a significant problem with one of more recent updates. I just updated the files with coastlines generated from the planet file this week. Thank you Jon! Can I ask if it would be possible to include in those shapefiles a processed coastline that's just the outlines, rather than the tiled land area polygon? osm2pgsql doesn't import natural=coastline (a hardcoded exception) and sometimes it's useful to put lines on coastlines, for which the processed_p data isn't very well suited. There are three intermediate shapefiles produced by the coastcheck utility: # coastline_p - points with errors http://yevaud.openstreetmap.org/coastline_p.tar.bz2 # coastline_i - incomplete sections of coastline http://yevaud.openstreetmap.org/coastline_i.tar.bz2 # coastline_c - complete sections http://yevaud.openstreetmap.org/coastline_c.tar.bz2 They are the input to last step of the processing which creates the closed polygons for each tile in the final 'processed_p' output. At no point is there a file which has fully closed polygons without the tiling. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] coastline in mapnik
On Sun, 2010-11-07 at 01:05 +0100, Vladimir Vyskocil wrote: I checked the shoreline last modification date with : wget --server-response --spider http://tile.openstreetmap.org/shoreline_300.tar.bz2 and the answer show : Last-Modified: Fri, 24 Sep 2010 23:44:09 GMT It's about 1 month and half ago !! Is this process broken ? Vlad. I think we went back to some older shapefiles after reports of a significant problem with one of more recent updates. I just updated the files with coastlines generated from the planet file this week. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Query using ST_transform fails
On Mon, 2010-11-01 at 09:21 +0100, Torsten Mohr wrote: Hello, i once got a hint on this mailing list to use a query like this to get the lat/lon of the world capitals: A) select st_X(wayLL), st_Y(wayLL), name from (select ST_AsText(ST_Transform(way,4326)) as wayLL, name from planet_osm_point where capital='yes') as foo limit 5; B) Based on that hint i used this query: select st_X(st_transform(way,4326)), st_Y(st_transform(way,4326)), name from planet_osm_point where place='city' and capital='yes'; That query worked fine and i did not change my system since then (that somehow can't be true). I now get errors for both queries: FEHLER: transform: couldn't project point (653103 6.63036e+06 0): failed to load NAD27-83 correction file (-38) TIP: PostGIS was unable to transform the point because either no grid shift files were found, or the point does not lie within the range for which the grid shift is defined. Refer to the ST_Transform() section of the PostGIS manual for details on how to configure PostGIS to alter this behaviour. Could it be that due to an RPM update of PostgreSQL some scripts need to be reinstalled? I can still generate maps using mapnik. What do i need to do to make those queries work again? Try: # yum install proj-nad Then I think you need to restart the postgres server. I think the error started appearing after a proj or postgis update, I don't remember exactly when. It took me some time to realise that these grid shift files were in this package. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapnik render queue stuck
On Thu, 2010-08-19 at 08:51 +1000, John Smith wrote: 2010/8/19 Jonas Häggqvist ras...@rasher.dk: I've had the same suspicion. I've asked around on IRC without response and had come to the conclusion that I must be going mad, because surely such a thing would be noticed instantly. Maybe not? Which is why I didn't file a bug after no one else said anything, I thought it must have been only me having/noticing the issue. Forcing tiles to regenerate via /dirty works, but using render_expired to tell renderd to expire tiles doesn't seem to have an effect any more. The automated expiry mechanism is working. There would be many more complaints if it was completely broken. If you believe this is not the case then we need links to some specific nodes or ways which you believe should have been rendered. Then we someone can investigate further if there is a reason why this data is not appearing. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-GB] OS LandForm Panorama (contour data) parsing tools?
On Thu, 2010-08-12 at 16:15 +0100, Nick Whitelegg wrote: To save effort, are there any open source scripts available for parsing the LandForm Panorama data out there? e.g. converting the DXF format into shapefiles, or populating a database? DXF is supported by the gdal (ogr) tools since version 1.7.0. The contour information can be extracted into a shapefile by converting the G8040201 layer: $ ogr2ogr sy08.shp sy08.dxf -where Layer=G8040201 The resulting shapefile will be in OSGB projection like the rest of the OS data. Information on the other available layers can be found in the Landform Panorama user guide, linked from [1]. Jon 1: http://wiki.openstreetmap.org/wiki/Ordnance_Survey_Opendata#Land-Form_PANORAMA ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [OSM-talk] wiki down ?
On Tue, 2010-06-29 at 10:04 -0400, Phil! Gold wrote: * Grant Slater openstreet...@firefishy.com [2010-06-29 06:44 +0100]: All fixed now. Squid fell over during a backup when disk space became tight. It acts as cache for wiki and some of the mapnik tiles. It seems that tiles still aren't rendering; munin shows the renderd queue is empty. Is something still broken there? The process which invalidates the tiles suffered a segmentation fault and stopped the import process. New tiles would still render OK but would not include any recent edits. The import process is restarted now but will take some time to catch up. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] coastline error checker
On Fri, 2010-06-04 at 14:42 -0300, Ulf Mehlig wrote: I've the impression that the coastline error checker is not working at the moment (last updated: 14th of April); coastline changes I've made some weeks ago in northern Brazil have not yet been applied to the openstreetmap.org mapnik layer. Is there anything one can do? I don't know about the coastcheck web site but the coastline shapefiles on the main mapnik layer have been updated several times since Apr 14th. The latest update was done from the planet file this Weds. Can you provide a map link to the exact area you modified? Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] coastline error checker
On Sat, 2010-06-05 at 20:30 +0100, Chris Hill wrote: Carsten Gerlach wrote: Am Samstag 05. Juni 2010 11:15:16 schrieb Jon Burgess: Can you provide a map link to the exact area you modified? Some weeks ago I fixed this coastline http://www.openstreetmap.org/?way=12193534 but is only in zoom level 14 right rendered, all other levels show the old version... It just needed to be forced to rerender. Zoom 16 17 look better around Plymouth now. Cheers, Chris Unfortunately the code which does the automatic tile invalidation does not work correctly for the coastline because it has no way to know when the shapefiles are going to be updated and which tiles they effect. The tiles either need to be marked manually or you have to wait until another edit in the area triggers them to render again. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapnik renderer issue?
On 29 May 2010 18:04, Mike N. nice...@att.net wrote: Is there an issue with the renderer now? The Mapnik tiles are not rendering, and the Wiki status page confirms this. I don't know any more details. A node at -90 degrees caused an exception in the tile expiry code and stopped the diff import process. I added a limit to clamp the latitude at +-85 degrees and the process has been restarted. It will probably take about 6 hours to catch up with the pending diffs. -- Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] project
On Sun, 2010-04-11 at 22:36 +0200, Torsten Mohr wrote: Hello, i created a GIS database and imported the planet data with osm2pgsql -m. So the data is stored in mercaator format. When executing this raw SQL query: select st_X(way), st_Y(way), name from planet_osm_point where capital='yes'; Then i get some data like: st_x| st_y|name ---+---+ -18915583.203791 | -2162182.86527014 | Alofi -11035458.4801666 | 2205926.10968281 | Ciudad de México -10075876.3988655 | 1648035.49949994 | Guatemala City How can i reproject the st_x and st_y to latitude / longitude? I'd like to do this in an own program. I already reprojected some Tiff data from latitude / longitude to mercaator, that worked fine. But i don't know what st_x and st_y actually are, how they are scaled, what is their offset. The documentation for st_X and st_Y didn't help me for this issue. Can anybody please explain to me what st_x and st_y are, how they are scaled, what is their offset so i can reproject these data to latitude / longitude? The are coordinates are plain 900913 data with no scaling or offset. Postgis can project this back to latlong (4326) for you, e.g. select st_X(wayLL), st_Y(wayLL), name from (select ST_AsText(ST_Transform(way,4326)) as wayLL, name from planet_osm_point where capital='yes') as foo limit 5; st_x| st_y| name +---+--- 15.0489992 |12.1130018 | N’Djamena نجامينا 15.3125301 |-4.3102408 | 9.4540009 | 0.39000220005 | Libreville 10.1862628 |36.8002392 | تونس 14.4212127 |50.0876559 | Praha (5 rows) Alternatively there are formulas on the wiki to convert between latlong and 900913. http://wiki.openstreetmap.org/wiki/Mercator Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Project of the Week 2010Mar28 - Swimming in data
On Tue, 2010-03-30 at 16:45 +0100, Grant Slater wrote: 2010/3/30 John Smith deltafoxtrot...@gmail.com: anything tagged natural=coastline only updates intermitently, I'm not sure if there is a regular schedule or not, however shape files are produced from the coastline segments and so on and so forth. Coastlines updating is currently a manual process for tile.osm.org Coastline Checker is much more frequently updated: http://coastline.openstreetmap.nl/ (see update line on site) Details on wiki: http://wiki.openstreetmap.org/wiki/Coastline_error_checker The shapefiles were last updated just a couple of days ago, from the planet-100324.osm.bz2 file. I can't see any obvious reason why the islands would be missing. The coastline generating utility really only cares about things tagged with natural=coastline so any other tags like place=island should have no effect on it. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] get latitude / longitude of points?
On Tue, 2010-03-16 at 08:19 +0100, Torsten Mohr wrote: Hello, thanks a lot for your hint. http://postgis.refractions.net/documentation/manual-svn/ST_X.html http://postgis.refractions.net/documentation/manual-svn/ST_Y.html select st_X(st_transform(way,4326)), st_Y(st_transform(way,4326)) from planet_osm_point where ... I tried it like this: select st_X(st_transform(way,4326)), st_Y(st_transform(way,4326)) from planet_osm_point where name='Berlin' and place='city'; But this lead to this error: FEHLER: transform: couldn't project point (1.48918e+06 6.894e+06 0): failed to load NAD27-83 correction file (-38) TIP: PostGIS was unable to transform the point because either no grid shift files were found, or the point does not lie within the range for which the grid shift is defined. Refer to the ST_Transform() section of the PostGIS manual for details on how to configure PostGIS to alter this behaviour. So i looked it up in the documentation for st_Transform(). I got: select PostGIS_Full_Version(); postgis_full_version POSTGIS=1.4.1 GEOS=3.2.0-CAPI-1.6.0 PROJ=Rel. 4.7.1, 23 September 2009 USE_STATS (1 Zeile) So to my understanding, my version of Proj is fine, right? I then tried to google for that error and got some discussion threads. But none of them seemed to have a really usable solution. Is there any hint you could give me to solve this problem? Sometimes the nad files are not included in the base proj installation. - On Fedora you need to install the proj-nad package. - On Ubuntu you may need to install proj-data. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM2PQSQL / PostGis: Coordinate Conversion
On 22 February 2010 10:51, d8930 d8...@uggsrock.com wrote: Sorry for spamming. I found out that it has to deal with the 4326 entry. I have added the projection 4324 from the Postgis installation package, and I get quite precise results: POINT(8.30107722233746 50.1359315159791) Nevertheless, this result differs a few meters from the one you obtained with the 4326 projection. So I guess, with your entry I should get it right. It looks like your problems are around your postgis or proj install and not an osm2pgsql issue. Make sure that you have the datum files for the proj library installed, on Fedora/CentOS these are in a separate proj-nad package. -- Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM2PQSQL / PostGis: Coordinate Conversion
On Fri, 2010-02-19 at 08:19 -0800, d8930 wrote: Hi, I am working on this as well. However, for testing I am using a point that lies in the German city of Wiesbaden-Naurod. This city has the geocoordinates 8.301388 / 50.13472. When I transform it by SELECT astext(ST_Transform(ST_SetSRID(ST_MakePoint(8.301388,50.13472), 4326), 900913)) I get the value POINT(924106.285037392 6469639.74359406), which pretty much is the same as the value in my PostGIS-DB (that was fed from OSM): 646985238;92409686 (considering multiplication by 100). However, the other way round, with SELECT astext(ST_Transform(ST_SetSRID(ST_MakePoint(92409686/100,646985238/100), 900913), 4326))) I get the strange result POINT(1.30152356525693e-06 7.86059348425535e-06) instead of somethin with 8.3* and 50.1*. Any idea, why this could be? It works for me, though there was an extra ) in what you quoted. gis= select astext(ST_Transform(ST_SetSRID(ST_MakePoint(92409686/100,646985238/100),900913), 4326)); astext - POINT(8.30129560793713 50.135942170124) (1 row) You will get slightly better accuracy if you divide by 100.0 to force the result to be calculated as a float: gis= select astext(ST_Transform(ST_SetSRID(ST_MakePoint(92409686/100.0,646985238/100.0),900913), 4326)); astext - POINT(8.3013044857 50.135944358132) (1 row) Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Planet, osm2pgsql interruptus, and reclaiming disk space
On Sun, 2010-02-21 at 10:12 -0800, Michal Migurski wrote: Hi, I have a problem with osm2pgsql and postgres, I hope someone can point me in the right direction for a fix. I started up a whole-planet osm2pgsql import session from a recent planet dump. While that was going on, the computer had to be rebooted and the process was interrupted. Now I have no data tables (okay) and a few dozen GB less disk space (not okay). I tried to vacuum full the planet_osm database, but didn't reclaim any space. Where does storage go when osm2pgsql is rudely interrupted like that? Temp files? A core dump somewhere? Any advice much appreciated. osm2pgsql only stores data in PostgreSQL. I imagine that the extra disk space is in use in the postgres DB directory. I should get cleared and re-used if you begin the import again. Otherwise you should be able to reclaim it immediately by dropping the database. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Question about create a tiles in my PC
On Wed, 2010-02-03 at 09:35 +0100, francescobocca...@libero.it wrote: Hi, i'm a new user of OpenStreetMap. I try to create a little OSM in my PC and i make step by step installation. I have installed postgres\postgis, mapnik and i have download all code file for generarate tiles. Now i have a problem.During a rendering of world boundaries i have a prblem of created tiles. For zoom=0 the file generale_tiles.py with a own xml file create a right tile (256x256px) for all planet. but for zoom 1 and up all tile cointain some are (like south america o other part)repeted so when i view with my browser (sing openlayer) i see some part overlayed. This is a xml file: ?xml version=1.0 encoding=utf-8? !DOCTYPE Map [ !ENTITY % entities SYSTEM inc/entities.xml.inc %entities; ] Map bgcolor=#b5d0d0 srs=+proj=longlat +datum=WGS84 +no_defs minimum_version=0.6.1 Have you adjusted the projection parameter in generate_tiles.py? By default it expects the map to be in 900913 projection, not longlat. fontset-settings; - Style name=Poli - Rule - PolygonSymbolizer CssParameter name=fill#f2eff9/CssParameter /PolygonSymbolizer - LineSymbolizer CssParameter name=strokergb(50%,50%,50%)/CssParameter CssParameter name=stroke-width0.5/CssParameter /LineSymbolizer /Rule /Style - Layer name=Poli srs=+proj=longlat +datum=WGS84 +no_defs StyleNamePoli/StyleName - Datasource Parameter name=typeshape/Parameter Parameter name=fileC:\mapnik\world_boundaries\processed_p. shp/Parameter /Datasource /Layer /Map Someone help me? Thank you Francesco ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Haiti coastline, [ was] coastline error checker stalled
On Wed, 2010-01-20 at 00:10 +, David Groom wrote: Great, will these shapefiles be used for the coast outline on the mapnik layer of www.openstreetmap.org? The coastline shapefiles on the main Mapnik layer have been updated to the 2010-01-20 data. The main Mapnik site use worldwide shapefiles which take about 8 hours to generate so it is not really practical to update them every day. They are typically updated about once per month from the data released in the weekly planet dumps. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Haiti coastline, [ was] coastline error checker stalled
The main Mapnik site use worldwide shapefiles which take about 8 hours to generate so it is not really practical to update them every day. They are typically updated about once per month from the data released in the weekly planet dumps. That's a pity, as there were one or two errors in the 2010-01-20 data which have caused certian areas to render very wrong . I'm open to updating it once-per-week if there are significant errors. I noticed that some of the sea areas around Miami are showing up as blocky bits of land at the moment. Alternatively, if you make some fixes and these are in the updated processed_p shapefiles from Hypercube coastline checker then let me know and I'll pull these files in. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM2PQSQL / PostGis: Coordinate Conversion
On Wed, 2010-01-13 at 20:39 +, Jon Burgess wrote: On Wed, 2010-01-13 at 22:45 +0300, Alexander Menk wrote: Hi! how can I translate the coordinate from the database to normal GPS coordinates as they are used by OpenLayers etc. SELECT ST_Transform(lat,4326) FROM planet_osm_nodes ERROR: function st_transform(double precision, integer) does not exist Something like this should work: select astext(ST_Transform(ST_SetSRID(ST_MakePoint(lon/100,lat/100),900913),4326)) from planet_osm_nodes; astext POINT(-0.233660788552329 51.6420473016351) POINT(-0.323177906614839 51.6455034823677) POINT(-0.490731673408812 51.6320228876355) POINT(-0.415551667280849 51.6282701316099) To improve the accuracy you should change the factor of 100 to 100.0, this will force postgres to perform the calculation using floating point. select id,astext(ST_Transform(ST_SetSRID(ST_MakePoint(lon/100.0,lat/100.0),900913),4326)) from planet_osm_nodes limit 10; id | astext -+ -1 | POINT(-0.233669322547528 51.6420490297913) -2 | POINT(-0.323178535435538 51.6455051546494) -3 | POINT(-0.490739848077898 51.6320247834516) In case you are wondering, the factor of 100 allows osm2pgsql to store the nodes positions using 4 byte ints instead of needing to use a double which needs 8 bytes. This makes a real difference when storing 600 million nodes. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] osm2pgsql error in Oxford/Cotswolds .osm data 19/12/09
On Tue, 2009-12-22 at 17:21 +, Nick Whitelegg wrote: Hello everyone, I'm having problems loading in a slab of OSM data for the Oxford/Cotswolds area for the UK extract for 19/12/09 downloaded from geofabrik.de. osm2pgsql stops with the error Error allocating ways (no other info is produced) The relevant file is http://nick.dev.openstreetmap.org/downloads/planet/oxford-cotswolds-191209.osm.bz2. Has anyone else seen problems loading data from the Oxford/Cotswolds area from recent planets? The error means it ran out of memory. Try running in the --slim mode instead. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] When will the next mapnik coastline update be?
On Fri, 2009-12-11 at 09:10 +1000, John Smith wrote: It's slightly annoying now that things render so quickly that the coastlines don't. I ran the coastcheck utility last night to update the coastline shapefiles on the main Mapnik layer. The updates will not automatically appear on the map unless the tiles is re-rendered due to updates of other data. We have no mechanism to recognise which tiles need to be rendered when the coastline is updated. This is part of the reason why the updates are normally coincident with the bulk reload where we mark all the old tiles as invalid. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] When will the next mapnik coastline update be?
On Sun, 2009-12-13 at 22:14 +1000, John Smith wrote: 2009/12/13 Jon Burgess jburgess...@googlemail.com: On Fri, 2009-12-11 at 09:10 +1000, John Smith wrote: It's slightly annoying now that things render so quickly that the coastlines don't. I ran the coastcheck utility last night to update the coastline shapefiles on the main Mapnik layer. The updates will not automatically appear on the map unless the tiles is re-rendered due to updates of other data. We have no mechanism to recognise which tiles need to be rendered when the coastline is updated. This is part of the reason why the updates are normally coincident with the bulk reload where we mark all the old tiles as invalid. Are the tiles still automatically refreshed on the first request after 7 days? If so updating at least weekly would still be useful. I think the 7 day figure was only used to set the http expiry headers on the returned tiles. It did not actually force anything to re-render. It was based on the assumption there would be a fresh full import every 7 days which no longer happens now we have the minutely updates. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] When will the next mapnik coastline update be?
On Sun, 2009-12-13 at 23:33 +1100, Steve Bennett wrote: On Sun, Dec 13, 2009 at 11:08 PM, Jon Burgess jburgess...@googlemail.com wrote: I ran the coastcheck utility last night to update the coastline shapefiles on the main Mapnik layer. Sweet, thanks. The updates will not automatically appear on the map unless the tiles is re-rendered due to updates of other data. We have no mechanism to recognise which tiles need to be rendered when the coastline is updated. This is part of the reason why the updates are normally coincident with the bulk reload where we mark all the old tiles as invalid. What's the best way to force an individual tile to re-render? Edit something in the area and save? If you grab the URL of a tile (right click, copy image location) and apped /dirty on to the end then it will add the tile into the rendering queue. e.g. http://c.tile.openstreetmap.org/16/59149/40219.png/dirty if you append /status to the URL then you will see when it was last rendered. The tiles get rendered in a 8x8 grid, if any one get marked dirty then they will all rendered. The /dirty only applies to that one zoom level. If you want to effect other zooms then they need to be done separately. The other way you can check the current data is to use the export tab. The images are not cached and always render with the current shapefiles. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Osm2SpatiaLite ?
On Wed, 2009-11-25 at 15:16 +, Jukka Rahkonen wrote: Hi, Has anybody written a tool like osm2pgsql for importing OSM data directly into SpatiaLite database? If you want to have a go yourself you could look at: http://trac.openstreetmap.org/ticket/1371 This copied the postgres code and changed it to use sqlite, but did not use SpatiaLite. The patch did not get applied as-is because I was unhappy at the code duplication, but it might get you started. Alternatively, are there plans to make an OSM driver for ogr2ogr? Not that I know of. I'm sure you could fallback to some path like: osm - postgres - shapefile - spatialite Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] how to make renderd.py render more than 18 levels
On Wed, 2009-11-18 at 06:58 +0530, Kenneth Gonsalves wrote: hi, I edited renderd.py and changed MAX_ZOOM=20 and levels=20. But it is still not rendering more than 18 levels - where else do I change it? I am using mod_tile. I tried the plain C renderd and it looked like it was working at zoom 20 with the changes from the patch you supplied. If have updated to the very latest mod_tile code then I suspect the problem is nothing to do with the zoom range. It is that the renderd.py has not been updated to understand the two new types of request: priority bulk. At the moment all these requests are being dropped by the python code. You might want to downgrade your code back to before r17688 which added these two new render commands rebuild. We should probably rev the protocol version because of the new enum values. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] does one need to download the planet to use osmosis
On Sun, 2009-11-15 at 22:04 +0100, Peter Körner wrote: good idea - but can you confirm that it is impossible to extract it from the remote file? you could do it with good ol' shell pipes: wget http://planet.openstreetmap.org/planet-latest.osm.bz2 -O - | bzcat osmosis --read-xml /dev/stdin --bounding-box top=49.5138 left=10.9351 bottom=49.3866 right=11.201 --write-xml extract.xml Isn't this bbox only a few times larger then what the API will download in a single call? IMO you'd be crazy to download nearly 8GB of data just to get hold of what probably amounts to a few 10's of MB. At the very least you should start with an extract for something smaller, like a single country. Using JOSM to selectively download all the pieces to cover your area seems a much better idea to me. I normally would endorse this if you were attempting to download something of many degrees in size, but for a few tenths of a degree you are probably OK. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Tilesathome] Ghost water rendering in mapnik Leaky titles in osmarender
On Sat, 2009-11-14 at 04:54 -0500, Andrew Sawyer wrote: Andre, Thank you for looking into that. Would it be okay to go back and update the river data with the new data so that it can render appropriately when the old coastline errors get purged from the renders. Osmarender looks good right now. I will see what happens with Mapnik. Is the coastline checker an automated process, or do I have to track down the people who oversee Mapnik to purge the ghost data. The mapnik coastline data is updated when we reload the rendering database. This tends to happen about once per month but there is no fixed schedule. The next update will probably be in a couple of weeks. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Getting roles of relation's members in PostGIS using osm2pgsql
On Sat, 2009-11-14 at 21:58 +0200, Ciprian Talaba wrote: I am trying to do some work with the public transport network, and for that I need to get the roles (forward/backward mainly) of the route members as attributes of ways(lines) in PostGIS. I am using osm2pgsql and I hoped to get this done by modifying the default style. I have added a new line in the style file way roletextlinear but this is not working (maybe it's obvious why not for some of you). Also I was looking at the osm2pgsql source code and I saw that getting information about the cycling network is treated separated in the code (in output-pgsql.c), and I was thinking of doing the same for public transport. Do you know if there is a way for doing this with the style, or I have to dig more in the code? Any pointers will be appreciated. I'm afraid the relation roles are not accessible in the style file. Pretty much all the relation processing is handled in the C code and each type of relation needs special handling. When a route relation is converted into a postgis geometry all of the constituent ways are joined into a single linestring. There is no obvious place where the role of each individual way could be recorded on this linestring. One possibility might be to keep the members as separate linestrings for and then add an artificial tag, say route_role=... in the output. Another approach might be for you to query the planet_osm_rels table (provided you imported the data in --slim mode). This contains the raw data listing all the relations and their members. Armed with this information you could then query the planet_osm_line table to obtain the geometry for each of these ways (all the members will probably appear as distinct roads in this table). Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Garmin eTrex Vista Hcx
On Sat, 2009-10-31 at 21:45 +, Randy wrote: These are more likely the reason for the issue Shalabh described. The position has been frozen at an inaccurate point, and when the GPS power is cycled, it comes back up with a good lock and resets the position based on the new measurement. I would doubt an error buildup just because GPS fixes are based on discrete fixes, rather than any kind of incremental measurements. I have a trace which fits the profile of an accumulated error. The attached screenshot shows several NaviGPS traces in JOSM for the section of motorway around the M25, M3 junction. One trace is clearly offset by up to 300m for a significant period of time. http://www.openstreetmap.org/?lat=51.40094lon=-0.53633zoom=15layers=B000FTF Jon attachment: gps-offset.png___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] multipolygon (lake) not rendering
On Sat, 2009-10-24 at 13:41 +0200, Peter Herison wrote: Ævar Arnfjörð Bjarmason schrieb: Peter Herison pheri...@web.de wrote: Could somebody take a look at http://www.openstreetmap.org/browse/relation/300524 and why it's not rendering in mapnik? There are also some issues with osmarender: http://www.openstreetmap.org/?lat=29.5216lon=-101.0699zoom=12layers=0B00FTF I've fixed it: http://www.openstreetmap.org/browse/changeset/2936060 * You need to add natural=lake on the relation when outer is made up of multiple ways *Dough* Thanks :) * Don't add tags on the inner ways. That's redundant But if the inner member is also an island? Eventually the island is also covered with wood? How to tag the inner way in this case? In that case tag the inner way with natural=wood. The confusing and redundant thing is to tag the inner ways with natural=water or natural=land. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapnik tile rendering working?
On Fri, 2009-10-23 at 18:58 +, Ed Avis wrote: Is the main slippy map updating? I edited this area: http://www.openstreetmap.org/?lat=51.537285lon=-0.153966zoom=18layers=B000FTF and expected this tile to update: http://a.tile.openstreetmap.org/18/130959/87134.png When I download the data, however, I see that my edit is there. The Mapnik rendering database is in the process of being reloaded with this weeks planet dump. It should start rendering current data again in a few hours but may be a little slow as all the tiles will get marked for re-rendering. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-GB] Funny with Mapnik?
On Fri, 2009-10-23 at 15:21 +0100, Ian Caldwell wrote: I put a few roads in last night and when I checked them this morning they were missing from the level 14,15,16 in Maplink. I then added a turning circle I had missed. About 1/2 hour ago they were missing from levels 14-18. They are all there in Osmarender. location is http://www.openstreetmap.org/?lat=52.11225lon=-2.29763zoom=17layers=0B00FTF Streets Moatway Moat Cresent and Five Oaks Close. As I check for this mail parts of them have appeared in level 18. but when I do a status on the showing bit I get http://tile.openstreetmap.org/18/129396/86455.png/status Tile is clean. Last rendered at Thu Oct 22 22:38:30 2009 but were it is missing status shows http://tile.openstreetmap.org/18/129396/86456.png/status Tile is clean. Last rendered at Fri Oct 23 14:16:29 2009 So the later tile has the streets missing Have I done anything wrong or is it Mapnik? That was my fault. I started importing this weeks planet dump on Thursday evening. The DB is in the process of applying the updates from Wednesday to now in order to catch up with the recent changes. When I started this diff process I initially forgot to turn off the tile invalidation so it ended up rendering tiles with data which could have been older than that available previously. That is why the tiles from Thursday show the recent data but the tiles rendered today do not. The diffs have currently got as far as Thursday midday and probably will not catch up until some time in the early hours tomorrow morning. Jon ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [OSM-talk] zoomlevel 8 rendering
On Sun, 2009-09-27 at 08:25 +0300, Roman Neumüller wrote: When does zoomlevel 8 get rendered? Every few weeks after a full import or when started manually. It was last done yesterday River Lena for example did not update on zoomlevel 8 since 24. July! (1) No problem for zoomlevel 9 though (2)... The part which renders on zoom level 8 has natural=water waterway=riverbank [1] The part which does not render has just waterway=riverbank [2] The osm.xml style rules only render riverbank up to a scale of 2 million: Rule Filter[waterway] = 'dock' or [landuse] = 'reservoir' or [landuse] = 'water' or [waterway] = 'mill_pond' or [waterway] = 'riverbank' or [waterway]='canal'/Filter MaxScaleDenominator200/MaxScaleDenominator PolygonSymbolizer CssParameter name=fill#b5d0d0/CssParameter /PolygonSymbolizer /Rule This means that they only appear at zoom = 9. The natural=water renders to a scale of 10M which is zoom = 6. 1: http://www.openstreetmap.org/browse/way/27729622 2: http://www.openstreetmap.org/browse/way/29074703 Jon Roman (1) http://www.openstreetmap.org/?lat=61.215lon=128.018zoom=8layers=B000FTF (2) http://www.openstreetmap.org/?lat=61.215lon=128.018zoom=9layers=B000FTF ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] County-Boundary in Mapnik same as primary highway
On Sun, 2009-09-20 at 20:10 +0200, Peter Herison wrote: Hi Is this correct that boundary=administrative;border_type=county is rendert the same way as highway=primary? http://www.openstreetmap.org/?lat=47.628756lon=-108.687472zoom=18layers=B000FTT That would be because way for Phillips County is tagged with highway=primary. http://www.openstreetmap.org/browse/way/24307804 Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] mapnik rendering
On Fri, 2009-09-11 at 07:48 +0300, Roman Neumüller wrote: I don't know whether I have missed something, or else am just lucky, but mapnik is rendering the things I am editing super-fast. Two new and different renders of an area in about 30 minutes. Now the renderer is sucking up to the cartographers? It's really old news, that tile.openstreetmap.org is using the minutely diffs. Shaun We moved the tile rendering to a new server[1] last weekend and this is rendering tiles several times faster than the old server. Currently it is managing to render all the tiles faster than the request rate so the changes are showing up very quickly. But seemingly only on zoomlevel 12 and higher numbers, right? Roman The tile expiry script only marks tiles between zoom 13 and 18 for automatic re-rendering. Limiting the minimum zoom is a performance optimisation, otherwise the low zoom tiles get re-rendered far too often. I'll try changing the minimum to 12 or 11 this weekend. As a fallback I may setup a forced weekly render of the low zoom tiles so they don't get left completely behind. Jon 1: yevaud http://wiki.openstreetmap.org/wiki/Servers/yevaud ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] A tile that just won't update
2009/8/31 Tom Chance t...@acrewoods.net: There's a curious Mapnik problem in Peckham, London: http://www.openstreetmap.org/?mlat=51.47008mlon=-0.06592zoom=16layers=B000FTF That industrial park has been split into two halves at that particular zoom level - each with a different shade of purple - for months. Zoom in and it's the newer, darker purple. There's no problem that I can see with the data, and I've even made updates to the area which have forced the left hand, lighter tile to be redrawn. But it's still split. Any ideas? That looks like an artefact of the colour reduction algorithm used to make the 256 colour PNG files. It is quite rare and I don't know how to fix it. -- Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] http://gazetteer.openstreetmap.org/namefinder/ broken?
It looks like something has changed again on gazetteer which has broken the munin stats which are hosted on the same machine: http://munin.openstreetmap.org/ is now redirecting to the namefinder as well. 2009/8/31 David Earl da...@frankieandshadow.com: Something weird has gone wrong - I've not made any changes to it. I'm looking at the problem. David -- Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] my flag is not showing on the green
On Thu, 2009-08-27 at 16:29 +0530, Kenneth Gonsalves wrote: Parameter name=tableselect node from planet_osm_point where golf='green' as golfmarkers/Parameter Try: select way,golf from planet_osm_point where golf='green' as golfmarkers * way is required for Mapnik to know where the point is located. * golf is required for your filter. If you want to optimize things, the filter in the style is redundant since the SQL select is only going to return points with golf='green' anyway. Alternatively you could replace you select with just planet_osm_point and leave the filter in place. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Weather overlay
On Fri, 2009-08-21 at 10:50 +, John Smith wrote: --- On Fri, 21/8/09, Peter Körner osm-li...@mazdermind.de wrote: If you have some kind of database anyway (e.g. postgis for mapnik-rendering on cassini, it shouldn't be the problem. I have a suitable query, I just don't know how to turn the query into kml data, such as lines. select way from planet_osm_polygon where boundary='administrative' and admin_level='10' One possibility is: ogr2ogr -f KML admin.kml PG:dbname=gis -sql select name,transform(ST_ExteriorRing(way),4326) from planet_osm_polygon where boundary='administrative' and admin_level='10' This admin.kml loads up fine in GoogleEarth and the boundaries appear as lines. postgis also has an AsKML() function but this does not appear to create a complete KML document. It outputs the geometry data with no styling. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mysterious PostGIS Problem with Polygons
On Fri, 2009-08-21 at 18:51 +0200, Peter Körner wrote:
The second should fetch the border of Germany and the first
one all boundaries in that. At least that's what I want it
to do :)
I just ran that query on my database and used name='Australia' and it works
as you thought it should.
Yes, you're right. It works with
Nederland, Australia, Italia
but not with
Deutschland, Danmark, Polska
SELECT osm_id, admin_level, name
FROM planet_osm_polygon
WHERE ST_Within(way, (
SELECT way
FROM planet_osm_polygon
WHERE boundary='administrative' AND
name='Polska'
LIMIT 1
))
AND boundary='administrative'
LIMIT 25
Any Idea Why?
In part it could be caused by invalid geometries. Postgis reports that
only Polska is actually a valid polygon geometry. Any errors could upset
algorithms like ST_Within().
gis= select name,isvalid(way) from planet_osm_polygon where
boundary='administrative' AND admin_level='2' AND name in
('Deutschland','Danmark','Polska','Nederland','Australia','Italia');
NOTICE: Holes are nested
NOTICE: Hole lies outside shell
NOTICE: Hole lies outside shell
NOTICE: Hole lies outside shell
NOTICE: Hole lies outside shell
name | isvalid
-+-
Nederland | f
Polska | t
Italia | f
Deutschland | f
Danmark | f
Australia | f
(6 rows)
Jon
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapnik: problem with water
On Sat, 2009-08-15 at 18:48 +0300, Aleksejs Mjaliks wrote: There is some problems in Mapnik layer. For example, in Riga one island is missing: http://www.openstreetmap.org/?lat=56.93228lon=24.12574zoom=15layers=B000FTF . Another example, in Jelgava is missing river itself: http://www.openstreetmap.org/?lat=56.6582lon=23.7364zoom=13layers=B000FTF The problem might be related to the multipolygon relation in Mapnik. I am running a re-import of the OSM data into the Mapnik rendering database at the moment. This should complete late today or early tomorrow and the data will start to be re-rendered. If this is the cause then it should be fixed when it renders again. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapnik render
On Sat, 2009-08-15 at 19:47 +0300, Peteris Krisjanis wrote: HI there! I am new to this list, so if this question is already answered, please don't be harsh :) I browsed archive, and I didn't saw anything for answer, but maybe I didn't look hard enough. As far as I understand mapnik render rules have been subject of change recently. I did a string of changes of my home town Ogre, Latvia yesterday. Today, there is still no indication of anything new in mapnik slip map render (osmarender has bugs, but have rendered all of it). Tried to apply /dirty to permalink - still nothing. So question is what are rules of mapnik rendering now? Every few weeks the Mapnik rendering database gets reloaded with the complete OSM planet dump. This takes around 24 hours to complete and is running at the moment. This full import fixes up some data consistency issues which occur with the minutely diff imports. The rendering should start again late tonight or early tomorrow. Your edits should show up within the next few days. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multiple nodes for one country
On Mon, 2009-08-03 at 20:49 +0200, Peter Körner wrote: Peter Körner schrieb: andrzej zaborowski schrieb: Hi Peter, I don't think anybody has a reason to object to merging them. At least me and User:Mala have been merging some of these nodes last week and we got no blackmail so far :) I believe we went through all the country nodes which didn't have a name:pl= or name:it= assigned yet so out of your list at most 15 or so countries should still remain duplicated. Cheers The main problem is that I'm unable to produce an up-to-date list from database since I don't have the resources to import an up-to-date dump. I'll try to process an up-to-date planet.osm tomorrow to generate an up-to-date list from it. It's a pity that cassini is not updated via the diffs right now. At the next step I'll generate a list for each wikimedia-language containing all countries and their names in this language, so people can correct the locale names more easy. It seems you've already done this for pl and it -- I'm about to do it for de. Peter I threw an nearly up-to-date planet.osm against a simple sax-parser-script in php and after it ran about 10 hours (such a planet.osm is a really big thing) it produced this table: http://toolserver.org/~mazder/duplicate-countries/from-planet.osm/ Looks much better! Still 26 countries are duplicated, but this could be fixed manually, so I'll do that now. On some time in the near future, when cassini holds an regularly updated gis-database we'll be able to track such duplications at http://toolserver.org/~mazder/duplicate-countries/ I obtained a list of the duplicate country nodes IDs from the Mapnik rendering DB[1] and have downloaded fixed all the duplicates[2]. Jon 1: SQL: gis= select name,osm_id from planet_osm_point where place='country' and name in (select name from planet_osm_point where place='country' group by name having count(*) 1) order by name,osm_id; 2: Two changesets. The first removes those automatically fixed by the JOSM validator. The second picks up the few remaining ones which needed merging. http://www.openstreetmap.org/browse/changeset/2028815 http://www.openstreetmap.org/browse/changeset/2029180 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Something Might be Broken
On Fri, 2009-07-31 at 15:58 -0700, Andrew Ayre wrote: As Shaun mentioned in another email, this seems to be another instance of nodes missing from the minutely diffs. This is a known issue but I'm not sure if we have a trac ticket for it. I have put more details into the trac ticket. Jon Is there a history of when full imports where made listed somewhere, or is it on a predictable schedule? There is no log of the full imports. They generally happen every few weeks on a Thursday or Friday. I'm wondering if some other things I've seen are the same problem or something else. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Something Might be Broken
2009/7/31 Marc Schütz schue...@gmx.net: Wrong, osm2pgsql does process relations properly. If they aren't then Jon Burgess is happy to take a look to see if he can fix the problem with osm2pgsql. Second there has been no planet reload for a few weeks now. There's definitely something wrong here: http://www.openstreetmap.org/?lat=49.93906lon=10.9213zoom=17layers=B000FTF The building called Angewandte Informatik is a multipolygon, which has been moved one and a half weeks ago. Both the old and the new shape are rendered now, and the hole is filled too. I know that there have been problems with multipolygons and diffs. Are they supposed to be fixed? Please file a trac ticket with the details and assign it to me. Lots of issues have been fixed but there are still several possible reasons why things some times don't work correctly. It takes time to analyse, diagnose fix each example. -- Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Something Might be Broken
On Fri, 2009-07-31 at 09:36 -0700, Andrew Ayre wrote: Done. See: http://trac.openstreetmap.org/ticket/2118 I add add tickets for the other two issues I referred to later today. Thanks! As Shaun mentioned in another email, this seems to be another instance of nodes missing from the minutely diffs. This is a known issue but I'm not sure if we have a trac ticket for it. I have put more details into the trac ticket. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Coastline
On Mon, 2009-07-27 at 10:37 +0100, David Groom wrote: - Original Message - From: Chris Hill chillly...@yahoo.co.uk To: OSM Talk talk@openstreetmap.org Sent: Saturday, July 25, 2009 3:22 PM Subject: [OSM-talk] Coastline I have altered the coastline in the Humber estuary, UK to reflect the official position of where the coast ends and the river starts. The coastal area hasn't rendered in Mapnik yet [1]. I seem to remember that a coastline update process needs to run to change the coastline. Am I right? Yes. For mapnik, at high zoom levels the coast polygons used are generated from shapefiles created by the coastline error checker. The coastline error checker has been offline since sometime before mid June, so no updated shapefiles have been created. All the coastline on the Mapnik layer come from two sets of shapefiles (shoreline_300 processed_p) which are generated every few weeks from the planet dumps on the Mapnik tile server. The last update was done on July 10th. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-GB] Roundabout, ways and relationship policies
2009/7/23 Donald Allwright donald_allwri...@yahoo.com: I'm just trying to think what makes a roundabout a roundabout instead of just a one-way system. So far I've come up with: 1. It is one way in the appropriate direction (clockwise in the UK) 2. All the roads leave/join the outside of the loop (*) 3. It generally isn't very built-up in the middle (**) 4. It has a reasonably circular shape (***) 5. It is signposted as such Of course, there are sadly lots of exceptions... * Increasingly there are roundabouts with roads running through the middle: http://www.openstreetmap.org/?lat=52.936219lon=-1.24996zoom=18layers=B000FTF The road through the middle is generally one-way though, and usually just one road. ** http://www.openstreetmap.org/?lat=50.910579lon=-1.400756zoom=18layers=B000FTF (The Charlot Place roundabout in Southampton now has the reasonably tall Jury's Inn hotel in the middle of it - I'm sure people can think of many others) *** Can't think of any oddly shaped roundabouts off the top of my head, but I'm pretty certain that there are plenty. :) How about this one: http://osm.org/go/0EFYMXaIH-- which fulfills all of the above 5 criteria, but just has a 'short-cut' across one side. In this case, each 'junction' on the roundabout is controlled by traffic lights and has between 2 and 5 lanes. I have to navigate it frequently and I can't say it's one of my favourite ones! The roundabout I really dislike is at Winnersh Triangle, UK: http://osm.org/go/eusmtxB_j- If you look on some satellite imagery you will see it really does have a dual carriage way going right through the middle of the roundabout. -- Jon ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [OSM-talk] How big should a planet.osm-osm2pgsql database be?
On Mon, 2009-07-20 at 16:00 +, Ævar Arnfjörð Bjarmason wrote:
Should the PostGIS database imported from the Planet.osm using
osm2pgsql be only 13 GB? Someone else who imported it on #osm-dev
reported a size of 48 GB.
Here's how I imported it:
$ md5sum planet-090715.osm.bz2
c89227585338c72dfcf4ff5d2aaacf53 planet-090715.osm.bz2
Imported with:
$ osm2pgsql -d gis -U avar -W -S ./wikimedia.style planet-090715.osm
$ osm2pgsql -d gis-osm-like -U avar -W -S ./default.style planet-090715.osm
gis=# select pg_size_pretty(pg_database_size('gis-osm-like'));
pg_size_pretty
13 GB
(1 row)
gis=# select pg_size_pretty(pg_database_size('gis'));
pg_size_pretty
15 GB
(1 row)
That looks about correct for an import which was not done using the
--slim mode. There are far fewer tables and indexes.
The data at [1] gives a breakdown of all the table index sizes for a
full slim-mode import. The ones related to the tables which are present
in the non-slim mode total to about 13GB
(planet_osm_{point,line,roads,polygon}). The tables used for the slim
mode and diff imports add another 50GB+ (planet_osm_{nodes,ways,rels}).
Jon
1: http://lists.openstreetmap.org/pipermail/dev/2009-July/016059.html
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Error loading data with osm2pgsql
On Sun, 2009-07-12 at 05:59 -0700, trossachs wrote:
Thanks for your help Jon.
Yes, I'm using Windows and as you can tell, I'm a newbie at this map stuff.
I've managed to get Postgres installed with PostGIS extensions and I've got
GeoServer set up as well.
I tried downloading the osm2pgsql from the link you gave me and it appears
to download a 1.7Mb file but when I try to unzip it, the unzip software
tells me the file is empty.
The file should be 1.8MB (1850788 bytes exactly)
The file works for me, the example below was just done using Linux
tools:
$ wget http://tileserv.openstreetmap.org/osm2pgsql.zip
--2009-07-12 14:19:13-- http://tileserv.openstreetmap.org/osm2pgsql.zip
Resolving localhost... 127.0.0.1
Connecting to localhost|127.0.0.1|:3128... connected.
Proxy request sent, awaiting response... 200 OK
Length: 1850788 (1.8M) [application/zip]
Saving to: `osm2pgsql.zip'
100%[=]
1,850,788 --.-K/s in 0.07s
2009-07-12 14:19:13 (25.7 MB/s) - `osm2pgsql.zip' saved [1850788/1850788]
[jburg...@shark tmp]$ unzip osm2pgsql.zip
Archive: osm2pgsql.zip
creating: osm2pgsql/
inflating: osm2pgsql/zlib1.dll
inflating: osm2pgsql/bz2-1.dll
inflating: osm2pgsql/900913.sql
inflating: osm2pgsql/libiconv-2.dll
inflating: osm2pgsql/default.style
inflating: osm2pgsql/README.txt
inflating: osm2pgsql/libxml2-2.dll
inflating: osm2pgsql/libpq.dll
inflating: osm2pgsql/osm2pgsql.exe
[jburg...@shark tmp]$ osm2pgsql/osm2pgsql.exe
osm2pgsql SVN version 0.55-20081113 $Rev: 10464 $
Usage:
osm2pgsql.exe [options] planet.osm
osm2pgsql.exe [options] planet.osm.{gz,bz2}
osm2pgsql.exe [options] file1.osm file2.osm file3.osm
This will import the data from the OSM file(s) into a PostgreSQL database
suitable for use by the Mapnik renderer
Options:
-a|--append Add the OSM file into the database without removing
existing data.
-b|--bboxApply a bounding box filter on the imported data
Must be specified as: minlon,minlat,maxlon,maxlat
e.g. --bbox -0.5,51.25,0.5,51.75
-c|--create Remove existing data from the database. This is the
default if --append is not specified.
-d|--databaseThe name of the PostgreSQL database to connect
to (default: gis).
-l|--latlong Store data in degrees of latitude longitude.
-m|--mercStore data in proper spherical mercator (default)
-M|--oldmerc Store data in the legacy OSM mercator format
-E|--proj numUse projection EPSG:num
-u|--utf8-sanitize Repair bad UTF8 input data (present in planet
dumps prior to August 2007). Adds about 10% overhead.
-p|--prefix Prefix for table names (default planet_osm)
-s|--slimStore temporary data in the database. This greatly
reduces the RAM usage but is much slower.
-S|--style Location of the style file. Defaults to ./default.style
-C|--cache Only for slim mode: Use upto this many MB for caching
nodes
Default is 800
-U|--usernamePostgresql user name.
-W|--passwordForce password prompt.
-H|--hostDatabase server hostname or socket location.
-P|--portDatabase server port.
-h|--helpHelp information.
-v|--verbose Verbose output.
Add -v to display supported projections.
Use -E to access any espg projections (usually in /usr/share/proj/epsg)
Jon
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Error loading data with osm2pgsql
On Fri, 2009-07-10 at 13:32 -0700, trossachs wrote: Ah. Thanks. The error message was a bit general. I was trying to import the UK osm and I'm running an Intel Core 2 Quad with 4Gb of RAM. I tried a small osm file (1.7Mb zipped) and it loaded ok. I re-tried with the uk osm file using the --slim option but it now says that --slim is not an option I'm using osm2pgsql_latest.exe OK, so your using Windows The --slim option should be supported by the latest code @ http://tileserv.openstreetmap.org/osm2pgsql.zip I retried it with osm2pgsql and the -s option but it fell over with an AddGeometryColumns() - invalid SRID error. Try adding the 900913.sql into your DB, it should be in the osm2pgsql.zip Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Error loading data with osm2pgsql
On Thu, 2009-07-09 at 14:49 -0700, trossachs wrote: Hi, I've had the same type of error on the two occassions I've tried to load an osm file. The error is: Error allocating nodes. Error occurred, cleaning up. There is no data at all, loaded into the database. Does anyone know the cause of these errors and how to fix them? It ran out of memory. How much RAM do you have and how much data are you importing? Normally you can work around memory issues by using the --slim option but if you try and import too much data on an under powered machine then the import may take a very long time. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] osm2pgsql
On Fri, 2009-06-26 at 18:28 -0400, James McManus wrote: Hi - I'm trying to use osm2pgsql to extract a subset area of OSM, but the --bbox option does not appear to be working. I downloaded planet-090617.osm.bz2 and then issued the following command: osm2pgsql --bbox -0.5,51.25,0.5,51.75 -m -d gis planet-090617.osm.bz2 At first it appears to be working producing the following output: planet-090617.osm.bz2 osm2pgsql SVN version 0.66-16084 Using projection SRS 900913 (Spherical Mercator) Applying Bounding box: -0.50,51.25 to 0.50,51.75 Setting up table: planet_osm_point Setting up table: planet_osm_line Setting up table: planet_osm_polygon Setting up table: planet_osm_roads Mid: Ram, scale=100 Reading in file: planet-090617.osm.bz2 Processing: Node(1400k) Way(0k) Relation(0k) But it runs for hours and uses up all of my RAM. I eventually have to kill it. How long should it take to subset a small area such as this? How much RAM and swap do you have? It take at least 2 hours to process the full planet, this is time taken just to do the bzip2 decompression and XML parsing without even writing anything out to the database. There is a lot of data in the full planet file. The algorithms in the code are optimised for the full planet import and are not as efficient as they could be for very small areas. Using the --slim option should fix the memory issue. Alternatively you could start with a UK or England only extract and save yourself a lot of bandwidth and import time. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] osm2pgsql
On Fri, 2009-06-26 at 23:44 +0100, Jon Burgess wrote: On Fri, 2009-06-26 at 18:28 -0400, James McManus wrote: But it runs for hours and uses up all of my RAM. I eventually have to kill it. How long should it take to subset a small area such as this? How much RAM and swap do you have? It take at least 2 hours to process the full planet, this is time taken just to do the bzip2 decompression and XML parsing without even writing anything out to the database. There is a lot of data in the full planet file. The algorithms in the code are optimised for the full planet import and are not as efficient as they could be for very small areas. Using the --slim option should fix the memory issue. Alternatively you could start with a UK or England only extract and save yourself a lot of bandwidth and import time. To give you some firm numbers, the full planet import on the main tile server with 12GB of RAM takes around 12 hours. On my home machine I normally import a UK only planet file and it takes about 15 minutes and about 2GB of RAM. The --slim option reduces the RAM usage but the import time will increase if you have less RAM to cache the DB in memory during the import. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proper use of layer tag with the Mapnik renderer?
On Sat, 2009-06-20 at 20:02 -0700, Michal Migurski wrote: Hello, I've just made some edits to this interchange: http://www.openstreetmap.org/?lat=37.819252lon=-122.25409zoom=18layers=B000FTFT I've used the layer tag in what I think is the right way, but the Macarthur Blvd overpass (layer=3, bridge=yes) is now being shown underneath the I580 overpass (layer=2, bridge=yes). Seems like layer should be fairly unambiguous, why wouldn't it be able to draw the overpasses in the correct order? Did I mistag? The tagging seems reasonable. The current rendering is down to the rules in the oxm.xml: Layer name=bridges status=on srs=... StyleNameroad-bridges-casing/StyleName StyleNameroad-bridges-fill/StyleName StyleNamenoncased-ways-bridges/StyleName StyleNamemwaybridge_layer0_casing/StyleName StyleNamemwaybridge_layer0_fill/StyleName StyleNamemwaybridge_layer1_casing/StyleName StyleNamemwaybridge_layer1_fill/StyleName StyleNamemwaybridge_layer2_casing/StyleName StyleNamemwaybridge_layer2_fill/StyleName StyleNamemwaybridge_layer3_casing/StyleName StyleNamemwaybridge_layer3_fill/StyleName StyleNamemwaybridge_layer4_casing/StyleName StyleNamemwaybridge_layer4_fill/StyleName StyleNamemwaybridge_layer5_casing/StyleName StyleNamemwaybridge_layer5_fill/StyleName StyleNameprimarybridge_layer0_casing/StyleName StyleNameprimarybridge_layer0_fill/StyleName StyleNameprimarybridge_layer1_casing/StyleName StyleNameprimarybridge_layer1_fill/StyleName StyleNameprimarybridge_layer2_casing/StyleName StyleNameprimarybridge_layer2_fill/StyleName These rules will draw the motorway bridges above any secondary bridges regardless of the layering. I don't understand the logic behind the current rules, I believe they were done like this to fix some layering issues in some other complex junctions. Jon Here's the same spot from the air for comparison: http://maps.google.com/?ie=UTF8ll=37.81923,-122.254277spn=0.002301,0.004238t=kz=18iwloc=A -mike. michal migurski- m...@stamen.com 415.558.1610 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] more OSM coming soon
On Thu, 2009-06-18 at 20:26 +0200, Ivo van den Maagdenberg wrote: 2009/6/18 Ivo van den Maagdenberg ivo.vdmaagdenb...@gmail.com var noname = new OpenLayers.Layer.OSM(NoName, [ http://a.tile.cloudmade.com/; + nonamekey + /3/256/, http://b.tile.cloudmade.com/; + nonamekey + /3/256/, http://c.tile.cloudmade.com/; + nonamekey + /3/256/ Closer inspection and attention :/ reveals that the main tiles come from http://a.tile.openstreetmap.org/ and http://b.tile.openstreetmap.org/ Ah... if you consistently see 1 in every 3 tiles as missing then chances are that you may have fallen into a common trap. Try opening each of the following links: http://a.tile.openstreetmap.org/0/0/0.png http://b.tile.openstreetmap.org/0/0/0.png http://c.tile.openstreetmap.org/0/0/0.png If you get an error or a blank image on one of those then chances are that at some point you have asked your browser to 'block images from this server'. It is quite easy to select this option by mistake. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] coastline
On Sat, 2009-06-13 at 22:17 +0200, Lennard wrote: Ulf Mehlig wrote: Thanks again, Lennard. I thought that dev.openstreetmap.nl is a different machine that took over the services from hypercube. So, no coastline for a longer period? Are there any informations about when these services might be back? Shouldn't we update the wiki accordingly? We wrote kleptog to please take a look at it, but having no access to the original machine should make things harder. I don't know when he'll have time to work on it. Who else has past knowledge about the coastline checker processes, and can work on this as well? There have been several recent issues in the coastcheck code which would have prevented it working, I have fixed all these in SVN so the server might just need an update rebuild of osm2coast to get things working again r15382 | jonb | 2009-05-31 14:50:29 +0100 (Sun, 31 May 2009) | 1 line Update coastcheck limits to cope with up to 600M nodes, we just through 400M nodes r15133 | jonb | 2009-05-20 21:01:32 +0100 (Wed, 20 May 2009) | 1 line update osm2coast to ignore changeset elements r14860 | jonb | 2009-05-01 09:06:37 +0100 (Fri, 01 May 2009) | 1 line fix bzip2 issue with latest planet file as per latest osm2pgsql code PS: We have a new tile server for NL, and the 'tile' name was moved to that. 'dev' is just the new alias for the old server, where the coastline slippy still resides. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] more OSM coming soon
On Wed, 2009-05-13 at 22:12 +0100, Thomas Wood wrote: 2009/5/13 Ivo van den Maagdenberg ivo.vdmaagdenb...@gmail.com: Hi Folks, This is some sort of quality of service question. Half of all the tiles on http://www.openstreetmap.org render as 'more OSM coming soon'. I want to know if I am doing something wrong (Ubuntu 8.10 + firefox 3.0 + reasonable hardware) The tiles display this in the case of network troubles where the server isn't reachable, they're also displayed if the tile hasn't yet been rendered (and is present on the server's disk) and when it's not possible to render on the fly. Otherwise, the tile is added to the render queue and should be available at some point shortly in the future. Showing OSM to a friend that has not seen 'the Map' does not give a good impression this way. A solution is to implement some sort of double buffering where the old tiles are kept for display until the new one has properly rendered? Well, that's maybe impossible, but it would improve the responsiveness of the http://www.openstreetmap.org at the moment. I believe this is already the case. There is a cache of tiles which is used when the rendering can not keep up. The weekly planet import is running at the moment and I have temporarily turned of the re-rendering of tiles so you will only seeing tiles from the cache right now. I'm in the middle of making some updates to the server to migrate the cached tiles and rendering database to an external disk array which will speed things up quite a bit. All the old tiles should still be available, but the live rendering probably won't restart until some time tomorrow. If you really must see an image which has not been rendered, the export tab should still produce an image for you. Jon I am not 100% sure if this list is the most appropriate place to post and apolgise for hogging the wrong list with my concerns. Kind regards, Ivom ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] SQL
On Sun, 2009-05-10 at 06:49 +0200, Torsten Mohr wrote: I also tried to access Thüringen by its osm_id, but also no success. In PSQL gis: gis= select osm_id, name from planet_osm_polygon where name like 'Thüringen' limit 1000; osm_id | name +--- -76689 | Thüringen (1 Zeile) Can anybody tell me how to draw the three missing states? Is there an explanation why they are missing? Since the entry is in the polygon table, the only obvious problem I can think of is the direction of the polygon, clockwise vs counter-clockwise. Mapnik Postgis really want all polygons to be clockwise but the osm2pgsql code does not guarantee this. Try doing: $ psql gis gis= update planet_osm_polygon set way=ST_Reverse(way) where osm_id=-76689; On older versions of postgis, ST_Reverse(way) might need to reverse(way). Is it possible to access parts from PostGIS by their osm_id from osm.xml? Filtering on osm_id should work, but it would be better to put this into a WHERE osm_id=... clause in the datasource query. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] SQL
On Sun, 2009-05-10 at 13:19 +0100, Jon Burgess wrote: I also tried to access Thüringen by its osm_id, but also no success. In PSQL gis: gis= select osm_id, name from planet_osm_polygon where name like 'Thüringen' limit 1000; osm_id | name +--- -76689 | Thüringen (1 Zeile) Can anybody tell me how to draw the three missing states? Is there an explanation why they are missing? Since the entry is in the polygon table, the only obvious problem I can think of is the direction of the polygon, clockwise vs counter-clockwise. Mapnik Postgis really want all polygons to be clockwise but the osm2pgsql code does not guarantee this. Try doing: $ psql gis gis= update planet_osm_polygon set way=ST_Reverse(way) where osm_id=-76689; On older versions of postgis, ST_Reverse(way) might need to reverse(way). This afternoon I committed a fix which should make osm2pgsql generate all polygons with the rings in the correct direction. Try updating to the latest SVN[1] code and importing the OSM data again. Jon 1: The server hosting SVN and the talk mailing list is unavailable at the moment. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] osm2pgsql and proper/legacy mercator
On Fri, 2009-05-01 at 17:52 +0200, Francois Van Der Biest wrote: Hi list, osm2pgsql --help says: -m|--merc: Store data in proper spherical mercator (default) -M|--oldmerc: Store data in the legacy OSM mercator format I'm wondering what's the difference between those two srs. Which one is epsg:900913 (aka epsg:3785 http://www.spatialreference.org/ref/epsg/3785/) ? My experience (importing an osm dump into postgis, then exporting to shapefiles) would let me think that the legacy OSM mercator format is epsg:3785. So, what's the other one ? The other one should be epsg:3395 $ ./osm2pgsql -vh ... Supported projections: Latlong (-l) SRS: 4326 (none) WGS84 Mercator ( ) SRS: 3395 +proj=merc +datum=WGS84 +k=1.0 +units=m +over +no_defs Spherical Mercator (-m) SRS:900913 +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 The seconds line of the help should show (-M) for the legacy projection. I've just fixed it in SVN. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] mapnik weekly rendering after API 0.6
On Wed, 2009-04-22 at 14:16 +, Joe Richards wrote: Is the weekly Mapnik rendering process still running after the upgrade to API 0.6? If so, which day is it scheduled for? It will still occurs on Wednesdays. I have started off the import this evening so it should begin rendering the latest changes tomorrow. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapnik rendering export has only coastline
On Wed, 2009-04-08 at 21:54 +0100, Simon Ward wrote: On Wed, Apr 08, 2009 at 08:54:30PM +0100, Tom Hughes wrote: Maybe we should remove the Export tab when it is out of commision? Yes, because the users of all the other export modes that aren't dependent on the mapnik database would love that. There’s nothing like a bit of dry sarcasm to cheer the place up. The whole Export tab is never out of commission, so how about just disabling the Mapnik exports when we know they are not going to work? The current plan is to enhance the Mapnik update process so that the weekly import will go into a temporary DB. The export to can carry on rendering the existing data during the import. Then old data will be dropped and the new data put in its place which should only take a few seconds. The above plan is fine in principle but I need to work out an automated script which does all the steps in the right sequence an make sure that the partition containing the database does not run out of disk space. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] more OSM coming soon
On Thu, 2009-03-26 at 14:43 +, Andy Allan wrote: On Thu, Mar 26, 2009 at 12:00 PM, Shaun McDonald sh...@shaunmcdonald.me.uk wrote: This is the weekly re-import of the data, when the render daemon is stopped for the duration. I'm not entirely sure that it is, especially since I'd have expected it to restart yesterday morning (or maybe this morning - again, not sure when Jon does things). But looking at the munin graphs [1] I can see that the eth0 load is high, the CPU has been flat out earlier today, and the load average is spiking pretty high too. There was a spike in the number of Apache threads and render daemon crashed when it used up all 1024 available file descriptors. I have known about this for a while, the render daemon has hit this a couple of times over the past year. I have restarted the process with the ulimit on the descriptors raised to 4096. Longer term I think I either need rethink how we handle 1k Apache connections or make the process increase the descriptors itself. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The Jon Burgess edit of osm2pgsql.exe disappeared
On Thu, 2009-03-26 at 17:44 +, Jukka Rahkonen wrote: Hi, Jon Burgess compiled sometimes in November 2008 Windows executable of osm2pgsql. It used to be at http://tile.openstreetmap.org/direct/osm2pgsql.zip but now it has been disappeared. Does anybody know where to find it now? -Jukka Rahkonen- It moved to: http://tile.openstreetmap.org/osm2pgsql.zip Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Square gridlines appeared on slippy map
On Thu, 2009-03-26 at 15:42 +, Ed Avis wrote: On the OSM front page the map now has what look like square gridlines, making Greenland look made out of graph paper. Is this a permanent change? The pattern of the grid is square throughout the map, which doesn't match the Mercator projection, so what are they intended to show? No. It is what happens if you generate the coastline shapefiles with the default parameters. I have fixed it to use the larger overlap but it might take a couple of days for them to re-render. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] serving tiles with mapnik and generate_tiles.py
On Sat, 2009-03-21 at 11:16 +0530, Kenneth Gonsalves wrote: hi The wiki page for this says: Download the planet file from planet.openstreetmap.org Import into a PostGIS database using osm2pgsql Set up mapnik and test using osm.xml and the generate_image.py When everything works, use generate_tiles.py to create 1000s of tiles in a special hierarchy of folders Copy/move tiles into your webserver's document root. Change the OpenLayers instance to use your own tileserver instead of the main one can anyone give me an example of how to change the OpenLayers instance to point to the tiles generated by generate_tiles.py? First get a web page running with the OpenStreetMap.js [1][2] Then change the implementation OpenLayers.Layer.OSM.Mapnik to point the URLs are your own server. Or copy/paste the code to create your own layer. Jon [1] http://wiki.openstreetmap.org/wiki/OpenLayers_Simple_Example [2] http://trac.openstreetmap.org/browser/sites/rails_port/public/openlayers/OpenStreetMap.js ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] restart the Mapnik daemon?
On Wed, 2009-03-18 at 15:13 -0400, Wes Townsend wrote: Hi, Apologies, as I am new to this list. Can someone restart the Mapnik daemon? I am getting blank output when I export an Area (using the GUI). Thank you. The output will be blank until the weekly import completes in a few hours time. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapnik and towns
On Fri, 2009-03-13 at 16:01 +0100, Frederik Ramm wrote: Hi, Ed Loach wrote: Does Mapnik use some shape files somewhere to mark the extent of towns on the map at zoom level 10? Yes, Mapnik uses a set of shape files (world_boundaries) which contain OSM-derived coastlines and VMAP0-derived (I believe) grey spots for built-up areas. Right, the boundaries of the populated areas is the last remaining use of the vmap0 shapefiles in the mapnik style. I intend to talk to Steve Chilton about removing them at some point. We might replace them by making the landuse= areas visible at these zooms. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] mapnik does not display symbols
On Thu, 2009-03-12 at 18:15 +0530, Kenneth Gonsalves wrote: looks like the problem is missing columns in the lenny install. I checked and find the fedora10 install has 52 columns whereas the lenny one has only 41. I cannot find the file which contains the create table statement - if I can get my hands on that, I could check and manually add the missing columns. btw, the fedora10 install does not have a 'construction' column, but still works. Any idea where this create table statement is and where does it get a list of columns? The create table command is generated by osm2pgsql. The list of columns is defined in the default.style I mentioned earlier in this email chain. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] mapnik does not display symbols
On Tue, 2009-03-10 at 16:25 +0530, Kenneth Gonsalves wrote: On Tuesday 10 March 2009 14:20:41 you wrote: On Tue, 2009-03-10 at 06:26 +0530, Kenneth Gonsalves wrote: On Tuesday 10 March 2009 00:19:03 you wrote: The most likely problem is that you have not used an up to date copy of default.style when running the osm2pgsql import. If so, you may be missing some of the columns in the DB tables and Mapnik will silently fail to render any layer which references the missing data. I did not see any mention anywhere of default.style when running the import - could you elaborate please. osm2pgsql has the following option: -S|--style Location of the style file. Defaults to ./default.style The default.style file has a list of the keys which it will import into the postgresql database like: node,way admin_level text linear node,way aerialwaytext linear node,way aeroway text polygon node,way amenity text nocache,polygon There is a better description of this file in the comments [1]. As new fields are added into the osm.xml, each new column must be added into the default.style too. To use the latest osm.xml you also need to use the latest default.style when importing the data. I do not have access to the server to try this out, but the problem appears more complex. I have the same set up on fedora10 (local machine) and lenny (remote server). The rendering on the local machine is perfect. On the remote machine it is defective - not only missing symbols, but even the roads are the wrong colour. The osm.xml files are the same and the india.osm file imported into the db is the same - and the same syntax was used with osm2pgsql to import it. I am attaching two screenshots to show the difference. I *must* be missing something in the lenny install I think I know the cause. I just saw the very similar looking tiles when doing some local rendering after picking up the latest osm.xml file. You are probably missing the column named construction in your database. See whether executing the following commands in your DB fixes it: $ psql gis ... gis= alter table planet_osm_point add column construction text; ALTER TABLE Time: 284.689 ms gis= alter table planet_osm_line add column construction text; ALTER TABLE Time: 76.898 ms gis= alter table planet_osm_roads add column construction text; ALTER TABLE Time: 9.854 ms gis= alter table planet_osm_polygon add column construction text; ALTER TABLE Time: 34.955 ms If you update the osm2pgsql SVN to the latest version you should see the default.style now has a construction column (since r13945). Whenever you pick up a new osm.xml style it is important to note if there are any changes in the osm2pgsql default.style file. If there are, then you probably need to re-import your rendering DB. Alternatively a tweak like the commands above will add the new column, which should fix the rendering, but the data in the new column will just be empty until you run the import again. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] mapnik does not display symbols
On Tue, 2009-03-10 at 06:26 +0530, Kenneth Gonsalves wrote: On Tuesday 10 March 2009 00:19:03 you wrote: The most likely problem is that you have not used an up to date copy of default.style when running the osm2pgsql import. If so, you may be missing some of the columns in the DB tables and Mapnik will silently fail to render any layer which references the missing data. I did not see any mention anywhere of default.style when running the import - could you elaborate please. osm2pgsql has the following option: -S|--style Location of the style file. Defaults to ./default.style The default.style file has a list of the keys which it will import into the postgresql database like: node,way admin_level text linear node,way aerialwaytext linear node,way aeroway text polygon node,way amenity text nocache,polygon There is a better description of this file in the comments [1]. As new fields are added into the osm.xml, each new column must be added into the default.style too. To use the latest osm.xml you also need to use the latest default.style when importing the data. Jon 1: http://trac.openstreetmap.org/browser/applications/utils/export/osm2pgsql/default.style ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] mapnik does not display symbols
On Tue, 2009-03-10 at 16:25 +0530, Kenneth Gonsalves wrote: I do not have access to the server to try this out, but the problem appears more complex. I have the same set up on fedora10 (local machine) and lenny (remote server). The rendering on the local machine is perfect. On the remote machine it is defective - not only missing symbols, but even the roads are the wrong colour. The osm.xml files are the same and the india.osm file imported into the db is the same - and the same syntax was used with osm2pgsql to import it. I am attaching two screenshots to show the difference. I *must* be missing something in the lenny install These tiles definitely look odd. Is this with a standard Lenny install plus SVN mapnik, mod_tile, osm2pgsql? Are there any other non-lenny packages for postgresql, boost, gcc etc? Are you running on a 32 or 64 bit host? I think I'll need to create a kvm instance with a lenny install to try to reproduce it. You may want to raise a bug on http://trac.mapnik.org since it lokos to be a mapnik related problem, not something directly due to OSM data itself. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapping the sea
On Mon, 2009-03-09 at 09:14 +, Andy Deakin wrote: Is there any PD(ish) elevation data for undersea to be able to mark contours? There are several data sources, search for 'bathymetric' data and you should find things like the srtm30plus dataset: http://topex.ucsd.edu/WWW_html/srtm30_plus.html Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Problem with osm2pgsql
On Mon, 2009-03-09 at 11:38 +, Peter Childs wrote: 2009/3/9 Martijn van Oosterhout klep...@gmail.com: On Mon, Mar 9, 2009 at 10:00 AM, Peter Childs pchi...@bcs.org wrote: I've been trying to import the Planet file into postgres using osm2pgsql, Using the current SVN version, it seams to be segmenting when processing the first Way (Under Ubuntu Hardy). Does any one have any ideas, or shall I try and import a subset (The UK would fit my purpose) and try and get more details By segmenting you mean segmentation faulting? Tip for the future: if you're getting an error message you want help with, cut and paste the message in your email, that way we don't have to read your mind. At a guess you're not using --slim mode and are running out of memory (you probably don't have 2GB+ in that machine, right?). Hmm 2Gb plus swap on that machine (and quite a bit else running), So that could be the problem, Surely its easy enough to have an error or Out of Memory I'll have another go, Thanks We do report out of memory errors but there are many places where things can go wrong, some of them are inside other libraries and are outside of our control. We would need to see your backtrace to identify and fix your specific case. 2GB of ram is insufficient to process a modern planet dump without using the --slim mode. I think the the maximum bz2 file you can import without using the slim mode would be around 100MB (approx UK planet dump size). Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] mapnik does not display symbols
On Mon, 2009-03-09 at 16:47 +0530, Kenneth Gonsalves wrote: I have set up mapnik and mod_tile to display my own slippy map. I used the cloudmade osm file for my country. The map displays, but no symbols (like hospital or ATM) are being displayed. The symbols are loading, but not displaying - any idea where to look to debug this? What zoom are you looking at? Some features like ATMs only appear on zooms 17 18. The most likely problem is that you have not used an up to date copy of default.style when running the osm2pgsql import. If so, you may be missing some of the columns in the DB tables and Mapnik will silently fail to render any layer which references the missing data. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multipolygons in Mapnik
On Mon, 2009-03-09 at 13:47 +0100, Frank Sautter wrote: hello list, Ciprian Talaba schrieb: What are we doing wrong? How should we tag the building to get rendered with Mapnik? i'm also expiriencing a strange behaviour on multipolygons. multipolygons that rendered perfectly are not working anymore from one moment to another, but then after some time they render correct magically without any changes to the data. i have the suspicion that this appeared to happen since mapnik is rendering data after a few hours instead of the old weekly renderer run. in all cases, parts of the multipolygons have been touched, but not all. maybe someone can second this thesis. if so, we should file a bug. You are correct, the hourly diff imports can not handle the multipolygon relation properly. These will fix themselves after the weekly import each Wednesday. Any edit to the nodes or ways in the relation will probably break it again. Overall the benefits of the hourly import far outweigh the slight problems with the multipolygon handling. Feel free to raise a bug if you want. I'm sure someone will get around to fixing it eventually but I have other things to look at right now. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] problem compilint mod_tile under debian etch
On Tue, 2009-03-03 at 15:43 +0530, Kenneth Gonsalves wrote: well, tried that - all dependencies were satisfied, but then I got this: src/graphics.cpp: In constructor ‘mapnik::Image32::Image32(Cairo::RefPtrCairo::ImageSurface)’: src/graphics.cpp:51: error: ‘class Cairo::ImageSurface’ has no member named ‘get_format’ src/graphics.cpp:57: error: ‘class Cairo::ImageSurface’ has no member named ‘get_stride’ src/graphics.cpp:60: error: ‘class Cairo::ImageSurface’ has no member named ‘get_data’ scons: *** [src/graphics.os] Error 1 scons: building terminated because of errors. It looks like you need a newer version of Cairo. Or perhaps disable the cairo support in Mapnik. It is not required for generating normal map tiles. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapnik coastline shapefile update - Philippine coast still somewhat square when exported
On Tue, 2009-03-03 at 13:41 +0800, D Tucny wrote: There's a large chunk of bad coastline around The Philippines that's been there since some shapefile update in the recent past... I only updated the low zoom shapefiles last time. I just pushed an updated set of low zoom ones too but that won't start rendering until the weekly mapnik import finishes in a few hours. It can be seen here... http://www.openstreetmap.org/?lat=15.481lon=120.274zoom=9layers=B000FTFT The coastline is all OK now (there were a couple of problems at one point) and the view at the coastline checker (http://tile.openstreetmap.nl/coastlines.html?lat=15.481lon=120.274zoom=9) and a local mapnik render I've done using the coastline checker output both show the coastline correctly... OK, we'll see how things turn out tomorrow. A trac ticket was raised about this problem a couple of days ago now, but, I'd have expected an update of the shapefiles to have corrected this... It looks like it's only corrected the problem above zoom level 10 though suggesting that only the processed_p shapefiles have been updated... Yes So... some questions... Is there a problem with the world boundaries shapefiles being used? No Were they generated from the processed_p shapefiles at some point? They were derived from vmap0 data and we are slowly replacing them with data derived solely from the planet.osm file. I have just committed the changes into the mapnik osm.xml files so you can see how they are used, I was holding back because there were some occasional rendering issues, but I think these are resolved now. Are the world boundaries files used on tile different to the ones packaged here http://tile.openstreetmap.org/world_boundaries-spherical.tgz? The ones on the live map are different. What would be involved in regenerating them? Once regenerated, could new ones be made available somewhere? http://tile.openstreetmap.org/shoreline_300.tar.bz2 They are generated using the same coastcheck utility as is used for processed_p but with some slightly different parameters and some data simplification. The details are in: http://lists.openstreetmap.org/pipermail/dev/2009-January/013485.html Since I wrote that email I found that the RESOLUTION setting caused some issues, the current values I use are: #define RESOLUTION 0 #define TILE_OVERLAP 2 #define MAX_SEGS 200 Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] problem compilint mod_tile under debian etch
On Tue, 2009-03-03 at 13:38 +0530, Kenneth Gonsalves wrote: that solved that problem - now one more: /usr/share/apr-1.0/build/libtool --silent --mode=link i486-linux-gnu-gcc -I. -DLINUX=2 -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -D_REENTRANT - I/usr/include/apr-1.0 -I/usr/include/openssl -I/usr/include/postgresql - I/usr/include/xmltok -pthread -o mod_tile.la -rpath /usr/lib/apache2/modules -module -avoid-version mod_tile.lo dir_utils.lo store.lo g++ -o renderd store.c daemon.c gen_tile.cpp dir_utils.c protocol.h render_config.h dir_utils.h store.h -g -lmapnik -L/usr/lib/mapnik/0.5/ -g -O2 - Wall -I/usr/include/mapnik -I/usr/include/freetype2 gen_tile.cpp: In function ‘protoCmd render(mapnik::Map, char*, mapnik::projection, int, int, int, unsigned int, metaTile)’: gen_tile.cpp:245: error: ‘class mapnik::Map’ has no member named ‘set_buffer_size’ gen_tile.cpp:257: error: ‘save_to_string’ was not declared in this scope make: *** [renderd] Error 1 as far as I know, all the dependencies are done (I installed mapnik through apt-get install python-mapnik) The current mod_tile code requires you to use a newer version of Mapnik than is available in the debian packages. I'm afraid you will have to compile an SVN version of Mapnik too. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] odd rendering + county boundaries
On Mon, 2009-03-02 at 13:00 +, Kevin Peat wrote: It's two thingsthe county boundary shouldn't go up rivers in the first place but also the part of the boundary that follows the coast would be better not being rendered. It seems to me that it must be included in a relation so that the county is an area but would be better not being visible. Kevin I discussed this with Steve8 a few days ago on IRC and the plan is to: - Hide any boundary rendering on ways with natural=coastline - When there is more than one boundary on a given way, only render the one with the lowest admin_level. This corresponds to the most important boundary. It is complicated by the fact that the information has to be cross-referenced across multiple objects. This will need some extra processing in osm2pgsql to implement and it may be a few weeks before I get around to it. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] cyclemap layer z18 trouble?
On Sat, 2009-02-28 at 11:20 +, Dave Stubbs wrote:
The renderd process had crashed for some reason.. I've restarted it. I
deleted all the z18 tiles the other day because we're running out of
tile cache space (about 400GB)... a combination of that and the
process crash means that it's been churning out 404s for a while.
Anyway should all be working now.
I'd be interested if you could obtain a backtrace for any crashes and
I'll investigate them. Capturing the core file by running the renderd
from a shell with ulimit -c unlimited seems to be the best way to do
this.
Over the past couple of days I've seen several crashes on the main OSM
site and I've just tracked one of them back to an infinite recursion
problem in the agg code. Applying the attached patch seems to fix it,
provided you build with INTERNAL_LIBAGG=True.
I have not been able to figure out which OSM feature was triggering
this, but it occurs when rendering the metatile containing:
http://tile.openstreetmap.org/17/78728/52568.png
Jon
Index: agg/include/agg_rasterizer_cells_aa.h
===
--- agg/include/agg_rasterizer_cells_aa.h (revision 930)
+++ agg/include/agg_rasterizer_cells_aa.h (working copy)
@@ -323,6 +323,12 @@
{
int cx = (x1 + x2) 1;
int cy = (y1 + y2) 1;
+
+// Bail if values are so large they are likely to wrap
+if ((abs(x1) = INT_MAX/2) || (abs(y1) = INT_MAX/2) ||
+(abs(x2) = INT_MAX/2) || (abs(y2) = INT_MAX/2))
+return;
+
line(x1, y1, cx, cy);
line(cx, cy, x2, y2);
}
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] cyclemap layer z18 trouble?
On Sat, 2009-02-28 at 13:38 +, Jon Burgess wrote: On Sat, 2009-02-28 at 11:20 +, Dave Stubbs wrote: The renderd process had crashed for some reason.. I've restarted it. I deleted all the z18 tiles the other day because we're running out of tile cache space (about 400GB)... a combination of that and the process crash means that it's been churning out 404s for a while. Anyway should all be working now. I'd be interested if you could obtain a backtrace for any crashes and I'll investigate them. Capturing the core file by running the renderd from a shell with ulimit -c unlimited seems to be the best way to do this. Over the past couple of days I've seen several crashes on the main OSM site and I've just tracked one of them back to an infinite recursion problem in the agg code. Applying the attached patch seems to fix it, provided you build with INTERNAL_LIBAGG=True. I have not been able to figure out which OSM feature was triggering this, but it occurs when rendering the metatile containing: http://tile.openstreetmap.org/17/78728/52568.png I found the way causing the problem, approx 1km long: http://www.openstreetmap.org/browse/way/31278148 It seems unusual for a new way to be using such low node IDs, it looks like something got confused when creating new nodes. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] server cannot find mod_tile
On Wed, 2009-02-25 at 15:29 +0530, Kenneth Gonsalves wrote: Hi, I have set up apache to access renderd as in mod_tile readme.txt. But when I try to acess http://localhost//osm_tiles2/, the server insists on looking for /var/www/html//osm_tiles2/. Looks like some 'Location' directive is needed. Can someone tell me how? There are two things which need to be setup. The main /etc/renderd.conf file and the Apache config directives. In /etc/renderd.conf you need to define the names of your styles and the mapping to the URI and xml files: [Default] URI=/osm_tiles2/ XML=/home/jburgess/mapnik/osm-local.xml In an Apache config file you need to tell it to load the module and tell it where the previous configuration file is located: LoadModule tile_module modules/mod_tile.so LoadTileConfigFile /etc/renderd.conf The Apache LoadTileConfigFile option can be inside a virtual server definition or at the top level. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Flooding in Turkey
On Sun, 2009-02-22 at 19:30 +, Jon Burgess wrote: On Sun, 2009-02-22 at 18:19 +, Kærast wrote: Hi, There's been some flooding in Turkey for a while which nobody neither I or katpatuka have been able to fix. It's at http://www.openstreetmap.org/?lat=37.913lon=35.572zoom=9layers=B000FTFT and only appears on the Mapnik render at zoom level 9 and lower. There are rivers passing through that area, though surely they haven't just sprung a leak and flooded :-) and there is natural:water above and below the affected area, but surely they would have flooded the area they are in if there was a problem with them? Can somebody tell us what's going wrong and help fix it please? It appears to be a problem with the coastcheck utility used to generate the lower zoom shapefiles on the mapnik layer. I'm currently trying to run the tool with RESOLUTION set to 0 instead of 100 to see if that fixes the issue. This square in Turkey has now gone, as have several other bad squares around the globe. You might need to refresh the tiles in your browser to see the difference. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Flooding in Turkey
On Sun, 2009-02-22 at 18:19 +, Kærast wrote: Hi, There's been some flooding in Turkey for a while which nobody neither I or katpatuka have been able to fix. It's at http://www.openstreetmap.org/?lat=37.913lon=35.572zoom=9layers=B000FTFT and only appears on the Mapnik render at zoom level 9 and lower. There are rivers passing through that area, though surely they haven't just sprung a leak and flooded :-) and there is natural:water above and below the affected area, but surely they would have flooded the area they are in if there was a problem with them? Can somebody tell us what's going wrong and help fix it please? It appears to be a problem with the coastcheck utility used to generate the lower zoom shapefiles on the mapnik layer. I'm currently trying to run the tool with RESOLUTION set to 0 instead of 100 to see if that fixes the issue. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapnik updating more frequently?
On Tue, 2009-02-10 at 10:04 +, Harry Wood wrote: Grant Slater wrote: David Lynch wrote: Is the mapnik render now updating more frequently than once a week? I'm seeing buildings that I added a couple hours ago appearing on there before even ti...@home/osmarender gets to them Ssh don't tell anyone :-) Congrads to Jon Burgess and team. Consider it beta for now. Most style changes are still only imported once a week. Regards Grant Took a while for anyone to comment hey? This is a big improvement which I think will help massively with getting new mappers hooked on the project. We should sing it from the rooftops ...but I understand Jon Burgess and others are monitoring it to see if the tile server keeps up with it OK. Hope the change sticks! I should have announced it, but you all know now :) The tile server is currently importing the hourly diffs and it seems to be operating well. I want to start using the new tile expiry code in osm2pgsql and then I'll move over to importing the minutely updates. There may be some cases which don't work correctly when applied as a diff so I'll still run a weekly import each Wednesday. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Fwd: Problem exporting maps
On Thu, 2009-02-05 at 17:58 +, Tom Hughes wrote: Vittorio Nicolardi wrote: Since yesterday I am not able to export maps. I tried different locations (mostly London) and different formats (pdf is what I need). I searched the forum and thought it was a Wednesday problem, but... today it is not working as well. Export doesn't work while the new planet dump is happening, so that may be what is going on. The planet dump was delayed for about 24 hours due to a timeout talking with the database server. I have made some updates to the planet dump tool to make it more robust in future. The import into the postgresql database is also running slower this week because I have enabled the extra indexes required for applying diffs. The next step will applying the diffs each day (if all goes well). I hope the import will finish in the next few hours, if not I'll disable the indexes and restart it. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Osm2pgsql fails with Finland.osm.bz2
On Wed, 2009-02-04 at 15:27 +, Jukka Rahkonen wrote: Hi, I have been importing Finland.osm.bz2 dataset from Geofabrik into Postgis every day with osm2pgsql.exe (on Windows) but now it fails. The error looks like this: Reading in file: finland.osm.bz2 Processing: Node(2835k) Way(37k) Relation(0k)Error allocating ways Error occurred, cleaning up I tried next to use Scandinavian dataset from hypercube.telascience.org. Result is about the same: Reading in file: planet-scand-090203.osm.gz Processing: Node(6670k) Way(0k) Relation(0k)Error allocating nodes Error occurred, cleaning up These first two look like an out of memory condition causing malloc() to fail. I made a third trial by using another version of osm2pgsql.exe with Finnish data but again with no luck. A bit different error message though: Reading in file: finland.osm.bz2 Processing: Node(2835k) Way(194k) Relation(0k)terminate called after throwing an instance of 'geos::util::TopologyException' what(): TopologyException: found non-noded intersection between 2.78294e+006 9.41427e+006, 2.78315e+006 9.41433e+006 and 2.78326e+006 9.41433e+006, 2.78269e+ 006 9.41433e+006 2.78315e+006 9.41433e+006 Normally the code catches exceptions from geos and ignores them. In some builds of osm2pgsql.exe this mechanism is broken and a geometry exception will instead cause the program to abort. It looks like this is one of these broken versions. Does anybody has an idea about what is going on, and if it is just a data error, how to find and correct it? This version of osm2pgsql.exe it should not have the exception problem: http://tile.openstreetmap.org/direct/osm2pgsql.zip Run the utility with the --slim parameter. This should fix any out of memory problems but it will be a bit slower and require more disk space. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] problem compiling mapnik
On Wed, 2009-02-04 at 17:40 +0530, Kenneth Gonsalves wrote: hi, I was trying to compile mapnik from source using the command: python scons/scons.py I get this error: /usr/include/boost/python/object_core.hpp:309: error: ‘object_base_initializer’ was not declared in this scope I am on mandriva2008 any clues? What versions of Mapnik, boost and gcc do you have? You might get more responses on the mapnik-users or mapnik-devel list. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
