Talk:Tiles@home

From OpenStreetMap

Jump to: navigation, search

Contents

How does tiles@home fit in?

This might sound stupid but can you clarify this...

So the output from Tiles@home rendering is appearing here? : http://www.zimmerheimer.de/mapnik/almien.html (looks great!)

Does this relate to the map here in any way? : http://www.openstreetmap.org/index.html (also looking good, but patchy tile coverage as if this needs some more tile rendering CPU time)

I wasn't following the conversations about all these new developments. Just going by the info on these wiki pages.

-- Harry Wood 23:40, 30 November 2006 (UTC)

Harry, the projects are related and are just 2 layers with a different layout. If you go to the map you mentioned and press the + sign in the top right corner of the map you can select different layers. Select the Osmarender layer to see the other maps from the tiles@home project. Note that the tiles@home project is currently only rendering maps till zoom level 12 so the general overview doesn't look as nice as the main map. Hope this clarifies some things. Cimm 12:24, 1 December 2006 (UTC) Cimm

Render bugs

See also Tiles@home/Dev/Client development area

I'm rendering tiles in the center of Belgium and it works fine but there seems to be a rendering mistake wheb I look at the rendered map. The white line shouldn't be there, how can this be corrected? Cimm 12:14, 1 December 2006 (UTC)

Rendering Hertfordshire (map) I too have the horizontal white line problem, as seen on the B656 south of Hitchin. In addition there is a vertical disjoint as can be seen on the railway line just north of Hitchin station. These disjoints appear to be at the zoom=12 tile boundary points. -- Batchoy 18:43, 14 December 2006 (UTC)
There is an issue with map projection that causes some gaps to appear between tiles. Some efforts have been made to fix it but obviously without success. -- Higgy 23:09, 14 December 2006 (UTC)
These will appear at the top/bottom of every tileset (a zoom-12 tile boundary). Look in the SVG -> PNG code for mathematical errors, or disparities between the area downloaded and rendered (e.g. rounding errors, off-by-one errors) Ojw 08:45, 15 December 2006 (UTC)
The bug has been fixed in revision 2058 of the client. --Deelkar (talk) 19:07, 10 February 2007 (UTC)

Other Bugs

The 'Upload log - recent uploads to the dev server' stats are showing some uploads as being 0 B, investigating the associated zip files on my client they are not 0 B but over 2.2MB, is this a reporting bug, an upload bug or a client bug? Meantime I have reduced the setting in the conf file to 1.2MB and am monitoring the result. -- Batchoy 09:24, 21 December 2006 (UTC)

I have tracked down the problem. This is a windows issue upload.pl was configured with "$Dir\\*" in the command line for the zip function, as a result it was including the 'Thumbs.db' system file, that windows had created in the gather folder, in the ZIP file thus inflating it to over 2MB. Changing the line to "$Dir\\*.png" so that only PNG files are included in the zip appears to resolve the issue. --Batchoy 23:13, 21 December 2006 (UTC)
  • T@H on Windows bugs in Bangkok:
    • tilesGen.pl - 2007-03-03
      • cmd generated for lines2curves.pl uses hardcoded ./lines2curves.pl which fails like this 
 [#1   0%] Beziercurvehinting zoom level 17... ERROR
 The following command produced an error message:
  ./lines2curves.pl c:\temp\output-35292-z17.svg-temp.svg > c:\temp\output-35292-z17.svg
 Debug output follows:
 | '.' is not recognized as an internal or external command,
 | operable program or batch file.
 [#1   0%] Rendering... The system cannot find the path specified.

using $Bin instead of . fixes it...

    • tahconfig.pm/tilesathome.conf.windows - 2007-03-02 - tahconfig.pm now checks for location of zip, will use Zip config param, but, not documented or specified in the .conf file, needed if using e.g. 7z

-- Dtucny 06:47, 4 March 2007 (UTC)

    • tilesGen.pl - 2007-02-28 - outputting to /dev/null causes inkscape command to fail

-- Dtucny 01:37, 6 March 2007 (UTC)

Requested map features

See also theTiles@home/Dev/Appearance discussion page, and options to change things yourself

I have noticed that at zoom=12 tertiary ways are not being rendered thus giving a cleaner map, however lesser unclassified ways and cycleways are still being rendered giving the map an odd and incomplete appearance (see map) -- Batchoy 18:51, 14 December 2006 (UTC)

I'd like to see tertiary roads, as well as unclassified roads, rendered at z12. Cycleways, bridleways and footpaths make the map too cluttered at zooms < 12. OTOH, I like to see detail so I can be sure of seeing everything even when looking at a wider area. Things that appear too cluttered, such as unclassified roads, I'd rather have hidden at z<=11 but this will mean rendering a larger area of data which the API may not be able to cope with at the moment. -- Higgy 23:09, 14 December 2006 (UTC)
I will go with Higgy here, and agree with having tertiary and unclassified roads rendered at Z12, and not have cycleways, bridleways and footpaths etc rendered until Z13 or Z14. I have also noted that at Z14 and particularly using my laptop it is difficult to differentiate the green primary route and the green cycleway, because of the similarity of both the greens and the rendered widths -- Batchoy 10:51, 15 December 2006 (UTC)

Zoom levels?

Currently the program is renderling tiles for level 12 and below so the details are great. This is perfect but when I zoom out it shows white tiles for the regions which are rendered at lower levels. Are these high level tiles generated by someone, another program or another setting? I can generate a whole are and it would still pass by unnoticed when the high level tiles are not done yet. Cimm 11:49, 8 December 2006 (UTC)

It's run manually (using zoom-12 tiles to create the others), but not often due to the server-load it generates. Ojw 13:13, 8 December 2006 (UTC)
Would it not be possible to do this with a modified client thus reducing the load on the server for Z=0 - Z=9 even further, ie download 16 * z=12 datasets, render and create the z=10 and z=11 tiles from the randered images before uploading? This would also give the option of reducing the rendered detail at Z=10 further still i.e. motorways, trunk and primary roads, railways, rivers and placenames only, similar to what you get on the summary map in a UK road atlas. -- Batchoy 12:29, 17 December 2006 (UTC)

Seeding

When you specify an xy parameter, does it then just generate that one level-12 tile and its children, or does it then proceed to adjacent tiles? ie, if I see some errors in a region, do I need to rebuild each level-12 tile in the area manually once I've fixed them?

--Parsingphase 14:03, 10 December 2006 (UTC)

It just generates one tileset. But once it's generated (if it's non-empty), the server will add the nearby squares to it's list of things to do. Ojw 16:10, 10 December 2006 (UTC)
Does the server "time out" old tiles that have been rendered like weeks ago so that they can be re-rendered? or does it primarily try to get the world covered? or, more to the current question: will that work even if the surrounding tiles had been rendered some time before? --Deelkar (talk) 16:05, 14 December 2006 (UTC)

Restart?

I'm not getting emails at the moment - any ideas when we might want to restart the rendering queue? Ojw 11:32, 9 May 2007 (BST)

I already rendered some tiles manually (to get some swiss lakes displayed) the last hours. Was currently working fine. Which reminds me on some comments about the lowzoom.pl rendering which I was trying out while OSM downloads didnt work. Lowzoom.pl probably should a) call pngcrush, b) check downloaded tiles for being 67/69 and create such a dummy-file if all 4 subtiles are either 67 or 69 bytes in size. c) downlad should set headers to force proxy caches to revalidate (it rendered old images for me from a proxy) c) if a donwload failed it put in empty tiles indtead of reporting an error or retrying the download. I dont speak perl so I failed to patch this myself. -- LosHawlos 13:03, 9 May 2007 (BST)
Perhaps we should first start to use the second drive. Starting it now, just to stop it because there is no space availible does not make sence to me. --Damian 19:27, 9 May 2007 (BST)

Chinese Rendering

Reasons for failure to render Chinese

The main reason for Chinese not being rendered seems to be the lack of fonts that have Chinese glyphs... The DejaVu fonts don't have Chinese glyphs, so Inkscape will fall back to a sans Chinese font, if none are present it will render nothing or garbage...

Users Rendering Chinese Correctly

Ludovic, avantman42, cybic (multiple fonts)

Users Not Rendering Chinese or Rendering Chinese Incorrectly

PaulJ (one font, many characters missing), tapio, piega, Bagpuss_thecat, Gwenn


BOINC

Just throwing in for discussion: What do you think about the idea to make tiles@home a BOINC(http://boinc.berkeley.edu/) client? Boinc has lots of users and could be used to improve the turn-around-time for renderin larger areas, or to automate the update process (If you support this idea, I would try to take a closer look into the boinc API.) [ coldtobi ]

  • Support: This'll allow tiles@home to be very accessible for the less tech-savy ( windows users ;) ).

This is a great idea, I had the same today :) I can use my X2 for rendering. --Kelvan Mo 11. Aug 17:16:31 UTC 2008

Informationfreeway

Hi, is there someone from informationfreeway.org reading this page? I noticed that the default map (tiles@home - direct) does not work anymore, but multihost does (2nd choice). Could you please change the default map to multihost? Thank you, Longbow4u 21:28, 1 February 2008 (UTC)

Works for me! 80n 00:38, 2 February 2008 (UTC)
OK, works for me again, too. Thank you, Longbow4u 11:06, 2 February 2008 (UTC)

PHP error

The link to "Tile Info" leads to an PHP error on the "Tile Info Page". Can some fix this?

Retrieved from "http://wiki.openstreetmap.org/index.php/Talk:Tiles%40home"
Personal tools
recent changes