[OSM-dev] mod_tile svn's project variables 1)hardcoded 2)in many files

Jonathan-David SCHRODER jonathan.schroder at gmail.com
Wed Feb 3 01:16:28 GMT 2010

Hi !!

On Wed, Feb 3, 2010 at 1:45 AM, Frederik Ramm <frederik at remote.org> wrote:

> Hi,
> Jonathan-David SCHRODER wrote:
>> for the render_expired.c program (;-) )..
> Uh-oh, that's my nasty little secret I believe.
> 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.
> 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):
> Yes I had understood the purpose of tile_requested by reading the c code
and its comments.

>  #define TILE_REQUESTED(z,x,y) \
>> (tile_requested[z][((x)*twopow[z]+(y))/(8*sizeof(int))]>>(((x)*twopow[z]+(y))%(8*sizeof(int))))&0x01
>  #define SET_TILE_REQUESTED(z,x,y) \
>>   tile_requested[z][((x)*twopow[z]+(y))/(8*sizeof(int))] |= (0x01 <<
>> (((x)*twopow[z]+(y))%(8*sizeof(int))));
> You should be able to simply pre-compute the twopow array to something
> higher and it should work.
> 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...

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.

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).
Do you know if mapnik loses rendering precision up to some zoom level ?

> 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.
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...

> 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.
There's an issue in using mod_tile as is for what I'm trying to achieve.
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...)
... and I'll want to do tiles compositing with mapnik xml stylesheets
changed online before being handed to mapnik...

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

Now I've got to understand mod_tile and render_expired better thanks !

> Bye
> Frederik
> --
> Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20100203/9d783560/attachment.html>

More information about the dev mailing list