Are you trying to understand the system here, rather than the code? Just ask any specific questions you want to know
the system breaks down into 3 parts: * server (relatively clean code still, though lots of queueing mechanisms everywhere) * protocol (very simple, changes require assistance from both server and client developers) * client (conceptually simple [download requests, then upload tile images] but very hackish code that's difficult to understand) as to your question about the choice of zoom12 as base: there are actually two things which treat z12 as special: 1: the requesting of updates, and the distribution of work to the clients. This is pretty simple stuff, and there's no great reason for picking any particular zoom level 2: the drawing of maps. now this is probably where some people are seeking to do research at the moment, into which zoom level is best to start at some notes from my point of view (there may be others) on rendering: (as background info, zoom-12 is about 10km across each tile, i.e. one small village, or 1/4 of a town, or < 1/15 of a city) * the smaller the region, the less OSM data to download, but more chance of missing a route which goes across your tile without having a node inside it. So a way with widely-spaced nodes could cut-across the corner of your tile, but the larger the tile, the more likely you are to catch it. * osmarender projection isn't quite right (when you render an image, it treats dLat/dy as constant when it should be more compllicated than that), and the smaller the area you render in one go, the less error you get. with 10km tiles the error isn't particularly noticable (someone post stats here - I'm sure we've run some on error % versus tile level). note: this was the case when [EMAIL PROTECTED] was first designed - osmarender may have improved since, and the perl version could certainly solve this * the larger the complexity of the region, the more work that the rendering engine has to do. We've got some complex drawings, with roads going over and under some feature and then over again. Even without that, there is huge density of data in any well-mapped area. Now that we have some well-mapped areas [which is good obviously, and a lot better situation than when [EMAIL PROTECTED] was designed], this becomes an inkscape memory problem, so one good fix would be a way to convert OSM data (or SVG) into PNG images more efficiently * however, don't forget that most tiles aren't that complex. Just because Berlin city centre can't be rendered without 8GB of memory, doesn't mean that you need to apply the same optimisations to a field in englandshire something people have suggested here is keeping track of complexity for each tile (is alredy done I think? reply with details) and then only give those complex tiles to renderers who claim to have large amounts of RAM. As others have mentioned, that would solve the delays caused by some feeble old PC trying to render London on its own while better more capable machines wait politely until it's given-up. * because of the projection issue we can't (or don't) render z<12 tiles directly - we join together lots of the z12 tiles. This means that the lowest level of rendering (z12 at the moment) needs to be suitable for connecting all 16 mibbion of them together to make a map of the world. You can suggest alternate strategies here for creating the lowzoom tiles, but one limitation is that each render starts with only a small area of map data available. one interesting thing to try here, is maybe each render can simplify the tile it downloaded, to produce an outline version of the tile data (nodes every 1km along a way, all small roads removed etc) which could be used later by a special lowzoom renderer that joins a load of simplified tiles together to do the intercontinental railway and autoroute map * when a client downloads the map data for their area (currently z12), they don't receive any ways which are completely outside their area. this can be a problem when they describe (e.g.) a large forest which completely covers the tile being rendered and many other tiles around it. The smaller the area downloaded, the more of a problem this is (e.g. z12 downloads mean that forests more than about 20km across have holes. z14 would give more of the same problem extending to holes in even smaller forests) one area of research I can suggest here is: when one renderer discovers a large area feature (forest, lake, etc.) they somehow notify other renderers (e.g. through a database) that someone rendering tile y (inside the forest) should also download way x which surrounds y. Or they might mark tile y as being 'forest' in the database even though they're not currently rendering y because they happen to have downloaded information about the forest's extents as part of their tile data * place names on the map cover an area of map. e.g. a 40-point font at zoom-12 of the map will cover a certain number of kilometers (more so for places around Llanfairpwllgwyngyll, although we seem to have the abbreviated version of that name...). If you're rendering an area that 'should' contain the right-hand end of a place name label that started 20km away, it can be very difficult to tell just by looking at the tile of data you downloaded. The smaller the zoom level that you render, the more place names will get truncated like this. another area of research here - when you download map data at z12, would it be possible to also download a much larger area (extending to the west of your tile for english language renders, depending on what direction text flows) of just place-names (e.g. using osmxapi) and merge those into the data. So place names that cross your area would be downloaded even if they didn't start in the tile you're rendering. we currently download a 'border' of extra data around the tile of interest (maybe 10-20% not sure) which helps with the forests and placenames but hinders the memory/download/CPU. In all of this, the key thing to remember is that we want the maps fast. someone has just gone out cycling in the rain to gather this information and they're waiting on your renderer to reassure them that they've contributed something useful to the map. Old data isn't particularly helpful in this context. And of course, that affects map rendering too -- if the choice is between rendering an 'elegantly understated' map on one hand, or convincing the tired hiker that their efforts to locate some obscure feature was not only appreciated but is there on the map already to show their friends, then we typically tend to follow the latter option on [EMAIL PROTECTED] again, ask on this list if you have any more specific questions On Mon, Jun 2, 2008 at 2:08 PM, Gert Gremmen <[EMAIL PROTECTED]> wrote: > Sebastian, > > You voluntarily misunderstand me . > > I would be very happy to > contribute (and I offered help several times), but I am not > able to step-in, due to the complexity level of [EMAIL PROTECTED] and > the absence of any documentation but comments. > What remains is requesting (not demanding, that's what you read) > > Believe me, I have tried a few times, to understand what happens > in the code. > > Anytime I ask a question I get sour replies (AARRGG) about > me just requesting and not offering. > > Well, to start, I HAVE to ASK first. Then, unfortunately, > for those who did most of the work, they need to make time free > to educate me/us. Others must feel the same.... > I understand perl, but perl is difficult to read without extensive > comments > > >>You are very free to implement the necessary code to allow the >>requesting of z13 tilesets, remove all the hardcoded assumptions of z12 > >>within the client, modify it to cope with large areas where a z13 lies >>inside (forests bigger than a z13 tile would break, for example. As >>would names that overlap more than a z13 tile). If you want to upload >>z13 tilesets you would additionally need to modify the server to cope >>with z13 uploads and donate the diskspace for quadrupled database disk >>space for the z13 tileset data. > > Now I feel happy. That's an offer I cannot refuse !!! > Nor carry out. > Il leave [EMAIL PROTECTED] to the know-it-alls. > > Thanks Sebastian, > > You lost a [EMAIL PROTECTED] contributor and renderer. > > Gert > > > -----Oorspronkelijk bericht----- > Van: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Namens Sebastian Spaeth > Verzonden: Monday, June 02, 2008 2:25 PM > CC: [email protected] > Onderwerp: Re: [Tilesathome] Proposal: New [EMAIL PROTECTED] Server structure > > Gert Gremmen wrote: >> I have requested several times for modification of the [EMAIL PROTECTED] >> starting >> point to level 13. The render jobs will be smaller, allowing >> more clients to participate successfully. > > You are very free to implement the necessary code to allow the > requesting of z13 tilesets, remove all the hardcoded assumptions of z12 > within the client, modify it to cope with large areas where a z13 lies > inside (forests bigger than a z13 tile would break, for example. As > would names that overlap more than a z13 tile). If you want to upload > z13 tilesets you would additionally need to modify the server to cope > with z13 uploads and donate the diskspace for quadrupled database disk > space for the z13 tileset data. > > > *I have requested*. ARRGGGG > You can request things in a shop when you pay for it. In OpenStreetMap > you can request stuff all day long and things won't change. > > If something bothers you STOP REQUESTING and START DOING something about > it! > >> In my opinion it is very frustrating that in the morning the >> [EMAIL PROTECTED] process was stopped due to too many heap sections or a >> inkscape memory problem. Spill of energy, effort and >> computer time. > > Yes, we all find that very frustrating when Inkscape crashes. Yes it's a > > spill of energy, effort and computer time. It's not going to be solved > by you requesting things. > >> Is this a too big change of strategy ? > see above. >> Will the level 12 results be too bad of quality ? > see above >> Does the [EMAIL PROTECTED] community think this is not relevant (yet) ? >> Is there any major reason that I overlooked ? > man power. >> Will inkscape be replaced soon, making this unnecessary (like ORP)? > or/p is no replacement for inkscape. Have you evaluated alternatives? > Some people have more success with batik than with inkscape and you are > free to improve things, or write you own darn svg->png converter. > > Complaints without efforts to improve things are a spill of energy, > effort, and my brain time. It's immensely frustrating too. > > End of rant > spaetz > > _______________________________________________ > Tilesathome mailing list > [email protected] > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/tilesathome > > _______________________________________________ > Tilesathome mailing list > [email protected] > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/tilesathome > _______________________________________________ Tilesathome mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/tilesathome
