This page is for people using the Tiles@home servers, people running the client, using the API, or viewing the results.
List whatever are the highest-priority things to fix with the tiles@home system (website, APIs, procedures, databases, etc.)
One heading per user. Only edit in your own heading. Reply to people on their talk page.
- Very often my client doesn't have to do anything (wasted Ressources)
- Send a message to the server if the client doesn't do anything
- API Method, to find out, how much capacity is available
- Depending on the available capacity, automatically render the Map.
- Ultimate Goal: Always have about 98% of the available capacity rendering.
Please give me some Feedback
-- 14:48, 08 August 2009
- Trap SIGINT events and close gracefully upon receipt. Specifically, if caught during "./tilesGen.pl loop" during upload, do not grab another job and start running it.
- Expand tiles@home be expanded to render tiles from VMAP0 (for political boundaries, land/water boundaries etc) where no data exists in the OSM database.
- Would in that case the server notice that there is no data and send on-the-fly converted data to the tiles@home client
seperate tile sets for land, sea, land+sea merged, etc.partially solved with the multi-layer tiles@home client
- Integration with lowzoom.pl - an uploaded z12 tile should trigger an appropiate lowzoom event to recreate the zoomed images
Nice-to-have: Links from the image cells on the "Credits by User" page to the corresponding tile browser page
Better requests queue, that marks stuff as finished, re-requests stuff that didn't get rendered, and allows low-priority updates
Find whoever wrote the land/sea rendering software, and see if it can be integrated.
- Coastlines and blue sea
- Polish up zoom level 17
- Tunnel rendering at z12 and z16 (tunnel style is hardcoded in Osmarender)
- Some t@h clients generate different sized text for some captions (eg city name). Text generated by, for example, deelkar and enxrah is slightly larger than text generated by clients like RalfZ and dodi.
- replace all occurence of font-family: "DejaVu Sans",sans-serif; with font-family: DejaVu Sans,sans-serif; in map-features-*.xml files (because of quotation marks a more general sans-serif font was used by inkscape which may differ on different systems) --Dido 11:42, 17 May 2007 (BST)
A better (resource friendly) preprocessor, if a preprocessor is really needed at all. (80n is currently investigating this issue - 23:48, 28 March 2007 (BST))
Better requests queue (if not monitoring itself at least remotely monitor-able)
- Requests log that not only shows who completed a job but also who is currently working on which tile(s)
Better communication between osmarender and client devs
- Add some tests to tilesGen.pl to ensure a more homogeneous environment across the rendering herd.
- There is something screwey about the anti-aliasing. It looks like it has been anti-aliased at twice the resolution, then had half the rows and columns thrown away.
- Ability to generate more than one layer - e.g. MapLint or a transparent pubs overlay.
- Highest overall priority probably the already mentioned blue sea, better request queue, multi-layer capability
- Better integration with OSM API, so that whenever an upload takes place, a sort of "tile dirty" message is created that causes t@h to issue a request for rendering, and a similar structure for re-rendering lowzoom tiles when level-12 tiles change
- Remove centralisation wherever possible. It would be great to combine multi-layer capability with multi-server capability, where different layers need not reside on the same upload server, and clients can, if desired, be restricted to certain layers. So somebody could set up a parallel t@h layer which (for example) has only railway lines, and if he manages to talk some renderes into activating that layer, they will automatically upload stuff to his server whenever they render an area. Well. Yeah. Phase 2, I guess ;-)
- Better integration of metadata - would love to have some indication of when the tile was last created on the tile browser or, if at all possible, even the slippy map (either a tooltip, or a color coding like green - less than 24h, yellow - 24 to 36h, red - over 36h). If possible on the slippy map (maybe taking the form of an overlay layer, where transparent PNG files with only text on them or a coloured border etc. are created on the fly?) this would also be a desirable message to the outside world that this data is "live" and changing.
- Implement priorities, give high priority to real (human) manual requests. Offer clients the chance to request a minimum priority ("I'm willing to donate processing power but only if there is something of priority 3 or higher"). Then combine this with a sort of "idle loop", i.e. when a client requests a job and is willing to accept lowest priority ("I am sitting idle anyway so might as well do something useful") and there's nothing, of any priority, then just assign it something that we guess might be useful - e.g. "anything that hasn't been rendered for 4 weeks" plus "anything in the top-1000 most viewed tiles that hasn't been rendered in the last 24 hours" or something.
I got this error message today running on svn revision 2718 of the tilesAtHome client.
[#35 0% jobinit] Doing tileset 2176,1448 (area around 46.528559,11.293945) [#35 0% default] Frolloizing (part II) ...... ERROR The following command produced an error message: nice "xmlstarlet" tr frollo2.xsl temp-31234.osm > "data-31234-frollo.osm" Debug output follows: | runtime error: file frollo2.xsl line 108 element param | xsltApplyXSLTTemplate: A potential infinite template recursion was detected. | You can adjust xsltMaxDepth (--maxdepth) in order to raise the maximum number of nested template calls and variables/params (currently set to 3000). | Templates: | #0 name linkedSeg | #1 name processSeg | #2 name nextSeg | #3 name linkedSeg | #4 name processSeg | #5 name nextSeg | #6 name linkedSeg | #7 name processSeg | #8 name nextSeg | #9 name linkedSeg | #10 name processSeg | #11 name nextSeg | #12 name linkedSeg | #13 name processSeg | #14 name nextSeg | Variables: | #0 | var linkedFromToSeg | #1 | var linkedFromFromSeg | #2 | var linkedToToSeg | #3 | var linkedToFromSeg | #4 | var unprocessedSegs | #5 | var currentSegFromNodeId | #6 | var currentSegToNodeId | #7 | processedSegs | reverse | currentSeg | #8 | reverse | currentSeg | #9 | currentSeg | #10 | var nextSegFromNodeId | #11 | var nextSegToNodeId | #12 | var currentSegFromNodeId | #13 | var currentSegToNodeId | #14 | var alreadyProcessed | no result for temp-31234.osm
I'm running a recent debian sid. LosHawlos 10:49, 2 May 2007 (BST)
- it would be nice if client cleans up after himself. Now it leaves:
2.0K /tmp/tile_12_2389_0.dir 1.3M /tmp/tile_12_2389_1154.dir 1.3M /tmp/tile_12_2389_1154.tmpdir 1.6M /tmp/tile_12_2397_1204.dir 359K /tmp/maplint_12_2389_0.dir 359K /tmp/maplint_12_2389_1154.dir 359K /tmp/maplint_12_2389_1154.tmpdir 497K /tmp/maplint_12_2397_1204.dir
If I run it in the loop it will eat my HD pretty quickly.
With a standard tilesGen.pl I am not able to render the tile 2199 1343. After applying a patch from the mailing list [Tilesathome] (Changing line 955 of tilesGen.pl (SVN Rev. 5202))
- my $Cmd = sprintf("%s \"%s\" tr %s %s > \"%s\"", + my $Cmd = sprintf("%s \"%s\" tr --maxdepth 20000 %s %s > \"%s\"",}}
the tile renders successfully.
- It would be very nice to have this (maybe with --maxdepth 30000) in the "official" tilesGen.pl version.
- It would be necessary to clean up after himself (/tmp). It just ate my hard disk, I lost a few emails. (ok, that's a complaint I have to pose to my mail client)
- Have a look at the option "DeleteZipFilesAfterUpload" in your tilesAtHome.conf. -- LosHawlos 11:42, 2 July 2007 (BST)
- Some way to change api url in config file.
Currently the api url (http://www.openstreetmap.org/api/0.4/) is hardcoded in tilesGen.pl. I want to generate tiles for a local map from my own api server. Easy enough to edit tilesGen.pl but it would be nice if it was possible to set the api url in a config file. Perhaps also prevent uploads if the osm api server is not used. --Thewinch 22:55, 24 July 2007 (BST)
Please always use the signature button at the end of your posting in order to print the timestamp. Else the reader can only estimate how old/relevant the posting is. Thanks. --Krza 20:41, 28 July 2008 (UTC)
Each time I press "r" on a specific tile at zoom 12 (see here), the answer is "Request failed (None,2173,1399): Request currently rendering". That is since yesterday. But I cannot find a rendering request on tah.openstreetmap.org/Request/show/ for this tile. What's wrong?
If it's possible to do a 'rough estimate' about how much RAM is needed by the client, it would be nice, to include a option in the config, which lets the user decide, how much RAM could be used and deliver only datasets which can be rendered with the available RAM. If there is no value in the config, a method in tilesGen could read out the available RAM of the system it's running on. E.g. a user with 1GB RAM can't render a high density area of Den Haag but a low density rural area can be rendered by such a system. The other extrem situation would be a powersystem with 16GB RAM. The system could be feed with the high density areas where other clients get problems. Morpheus1703 19:12, 7 August 2008 (UTC)
Hi all, I am able to do the rendering and even upload it but nothing happening in stats. For some reason I'm not getting through and my renderings are being wasted :( See http://tah.openstreetmap.org/User/show/byid/2097/ one can see the requests but none of the uploads. I rechecked my authentication.conf file and this is what it shows.
My openstreetmap username is 'shirish' while the wiki login is with 'Shirish' but that I guess has to do with the shortcomings/feature of mediawiki. I rechecked the password in the browser and it works. I also saved it in UTF-8 just so no issues are there but still not getting through. This is what I got when uploading some render to the server.
~/t@home$ perl tilesGen.pl upload - Using working directory /home/shirish/t@home - Using process log file tah-process.log - Keeping ZIP files after upload - OptiPNG version 0.6.4 - pngnq version 1.0 - Java version 1.6 is available - ImageMagick version 6.6.9 (lowzoom enabled) This is version 23290 (Vizag) of tilesgen running on linux, ID: 30994 06.11.2011 - 11:41:41[#1 100% upload] uploaded 2 files
Looking forward for answers,comments or where am I going wrong ? Shirish 06:28, 6 November 2011 (UTC)