Hi !!<br><br><div class="gmail_quote">On Wed, Feb 3, 2010 at 1:45 AM, Frederik Ramm <span dir="ltr"><<a href="mailto:frederik@remote.org">frederik@remote.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<div class="im"><br>
<br>
Jonathan-David SCHRODER wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
for the render_expired.c program (;-) )..<br>
</blockquote>
<br></div>
Uh-oh, that's my nasty little secret I believe.<br>
<br>
render_expired is more or less a version of render_list, but it processes an expiry list coming from osm2pgsql. Because osm2pgsql has no knowledge about meta tiles, the expire list might contain up to 64 tiles that fall onto the same meta tile. render_list tries to keep track of meta tiles already requested for rendering, to avoid requesting the same tile multiple times.<br>

<br>
It does so in a bit array which is manipulated with these beastly things (which anyone is welcome to replace by something that is more en vogue):<div class="im"><br></div></blockquote><div>Yes I had understood the purpose of tile_requested by reading the c code and its comments. <br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
#define TILE_REQUESTED(z,x,y) \<br>
(tile_requested[z][((x)*twopow[z]+(y))/(8*sizeof(int))]>>(((x)*twopow[z]+(y))%(8*sizeof(int))))&0x01<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
#define SET_TILE_REQUESTED(z,x,y) \<br>
   tile_requested[z][((x)*twopow[z]+(y))/(8*sizeof(int))] |= (0x01 << (((x)*twopow[z]+(y))%(8*sizeof(int))));<br>
</blockquote>
<br></div>
You should be able to simply pre-compute the twopow array to something higher and it should work.<br>
<br>
HOWEVER #1:<br>
<br>
These macros are used only at the meta tile level, i.e. the "z" in these macros is always the real zoom level minus 3. If they break with z=19 then that means that the script cannot handle tiles on zoom level 22. Are you *sure* you want to handle tiles on zoom level 22? On that zoom level, one pixel corresponds to 4 centimetres on the surface of the earth (at the equator). One tile corresponds to less than 100 square metres. You'll be rapidly approaching a situation where OSM's accuracy becomes a problem...<br>
</blockquote><div><br>I want to do rendering for indoor stuff and the extent will be that of <5 buildings in height &width. So yes zoom = 22 is a zoom level I want. Even I could want more than 22, so as to see small things indoor (that depends on the project, but that could be at most a pile of books on a shelf for an amazon-like assets facility)... I'm just planning large. If I can pushing limits without doing hardcode C hacking (I'm a scripting guy), then I'm ok to try doing it.<br>
<br>As to precision issue, someone earlier on this list told (using the ruby code as a prof) that the rails port would allow to store vector data with integer precision up to 7cm without modifying anything to the rails port (and for JOSM I don't know). <br>
Do you know if mapnik loses rendering precision up to some zoom level ?<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
HOWEVER #2:<br>
<br>
You will need roughly 2^(2*maxzoom-39) GB of RAM to run this program. So if you want to go down to zoom level 22, then that's 32 GB RAM.<br></blockquote><div>yes.... for zoommax = 17, your code states that we'd need 2GB RAM. 2GB => 32GB is a big leap... and for example an Amazon EC2 32 bits instance has 1.7 GB memory... <br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
For your application, you might want to use a different approach, one that keeps rendered tiles in a tree or list like osm2pgsql does and not one that makes an array like render_expired.<br></blockquote><div>There's an issue in using mod_tile as is for what I'm trying to achieve.<br>
the tiles expiry itself that osm2pgsql provides doesn't consider as to which indoor level has changed (osm2pgsql would need to read level= attributes of changed tags to guess it...)<br>... and I'll want to do tiles compositing with mapnik xml stylesheets changed online before being handed to mapnik...<br>
<br>As Dane Springmeyer had warned/advised me earlier on IRC, for my indoor rendering thing, I don't want to use mod_tile (even though I could use a tree as you say instead of this 2-dimensions array... while I could just use bash's sort --unique option on osm2pgsql's expiry list file before calling render_expired)...<br>
<br>Now I've got to understand mod_tile and render_expired better thanks !<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<br>
Bye<br>
Frederik<br><font color="#888888">
<br>
-- <br>
Frederik Ramm  ##  eMail <a href="mailto:frederik@remote.org" target="_blank">frederik@remote.org</a>  ##  N49°00'09" E008°23'33"<br>
</font></blockquote></div><br>