Talk:Tiles@home

From OpenStreetMap Wiki
Jump to navigation Jump to search

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)

  • I noticed there is a bug in the t@h Browse map. It provides Links that lead to error 500 pages. They are created for both zoom level borders. z=0 and clicking "-" leads to a error 500 page as well es z=17 and klicking on "+". In My opinion both links should not exist and the pages should not present an error page, but an available zoom level (z<0 should lead to z=0 and z>17 should redirect to z=17). -- Quelbs 09:18, 30 January 2009 (UTC)
Examples:
this page and click on "+"
this page and click on "-"
  • Running Mac OS X the T@H client does not parse the authetification.conf, instead one has to change the UserData in the config.default to get the client working not really sweet such a workaround DooMMasteR 12:37, 17 July 2010 (UTC)
  • just seen the following:
[#3 0% tile-z16] Splitting stripe 0... gd-png: fatal libpng error: Read Error: truncated data
[#3 0% tile-z16] Putting job (12,2332,1183) back due to 'SplitTiles: Missing File /tmp/12_2332_1183_59ORO/tile-z16
...
[#4 0% ] Tileset (12,2332,1183) around 60.26,25.00 complexity 16664754 priority 2
[#4 0% tile-z12] Splitting stripe 0...

--> system did download same again, even if it was too complex the last time. (guess what it's this time. ( running vt@h)) --Zwiskle 19:24, 18 August 2011 (BST)

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), dagbj, DooMMasteR

Users Not Rendering Chinese or Rendering Chinese Incorrectly

PaulJ (one font, many characters missing), tapio, piega, Bagpuss_thecat, Gwenn, Andre68, aj_osm_aj_gps_net (Tileset also almost 2x larger than others), Patty21

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 Would be realy cool even for *nix Users with less sparetime --!i! 08:41, 14 March 2009 (UTC)

Any news on this? Is it possible and if so, is anyone working on it? Bitplane 02:04, 28 May 2009 (UTC)

  • Support: for me on Mac OS X it took around 5h to get things working (compiling and stuff) and there are still bugs DooMMasteR 12:34, 17 July 2010 (UTC)
  • strong support: running VirtualBox is great but the Boinc client is available on more platforms... -- AlNo 21:50, 2 December 2010 (UTC)
  • I'm running the BOINC software on several servers and it works like a charm (on Linux and Windows) and stable (which is not always the case with the OSM render software. They even keep the load on the server so well managed that endusers don't notice the additional load on the server. For me, BOINC is the way to go! Hieronymousch 11:47, 4 January 2011 (UTC)
At least few years back someone told "us" that every "computation unit" downloaded from boinc servers has to be a standalone unit. Downloading all the software required for rendering and turning to bitmaps is too much overhead (several megabytes) compared to the actual map data; and the full software package (t@h/orp/inkscape/what else) has to be packaged and downloaded again for every tile request. Would be nice way to distribute the clients but is likely unfeasible. Alv 14:57, 4 January 2011 (UTC)
This (standalone units requiring redownload of everything) is unfortunately incorrect information. BOINC distinguishes between "Applications" (a version of a software package - basically a set of executables and their dependencies) and "Workunits" (the computational unit used - it has some input files and some output files). The difference is that application files only change when a new application version is released whereas workunit files are (read: may be, not must be) unique for each workunit.
That said, it is however the case that a normal BOINC project client shouldn't access the web AFTER it has started a workunit. In other words, a workunit must have links to all relevant data set from the server-side so BOINC can fetch it and prepare it in advance. This is just a rule of thumb, though - the client can establish a network connection if it absolutely has to.
I am not aware of how difficult it would be to determine the required data in advance.
Have a look at the legacy wrapper application (http://boinc.berkeley.edu/trac/wiki/WrapperApp) if all you want to do is run the existing T@H client from BOINC. jbk 10:57, 20 July 2011 (UTC)

Inspired by the great success of http://www.renderfarm.fi for 3D users and the loss of the T@Home server within the next days let's start at least a discussion about this approach BOINC] --!i! This user is member of the wiki team of OSM 10:49, 5 February 2012 (UTC)

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?

Why not SVG instead of PNG tiles?

Can someone explain the reasons why even the Osmarender-slippy-map uses PNG tiles instead of SVG pictures although Osmarender output originally is SVG? I can only imagine that some browsers like IE6 don't support SVG natively. Are there other reasons? --Spuerhund 10:05, 25 October 2008 (UTC)

I think svg is more data-rich and therefore larger amount of data has to be downloaded. This means the slippy map will be slower. GercoKees 10:49, 25 October 2008 (UTC)
I had a quick look at different PNG tiles created from Osmarender SVGs and they have a filesize of ~10 KB or more. I bet the original SVG pictures are smaller, at least after gzip-ing them. Any other ideas? --Spuerhund 11:09, 25 October 2008 (UTC)
The processing power needed for svg display is much higher than for displaying plain images. Browser support is another issue, PNG has become standard enough, whilst according to Wikipedia "As of October 2008, Windows Internet Explorer provides no native SVG support.". HannesHH 11:46, 25 October 2008 (UTC)
It would be possible to use a Flash-based SVG viewer in Internet Explorer, though I don't know how desirable this would be. Bitplane 02:12, 28 May 2009 (UTC)
I guess PNG is the most suitable for mobile devices with limited processing power, so flash is definitely no option at all. --Scai 17:08, 17 July 2010 (UTC)

Zoom level 18 request

If some people wanted to implement an optional zoom level 18 (I myself am interested) which if it was implemented would have to be enabled explicitly so it won't affect all other users, does osmarender support this, and if yes are the only changes that need to be done in the Tiles@home software? logictheo 19:24, 11 September 2010 (BST)

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Talk:Tiles@home&oldid=732874"