Jonathan-David SCHRODER wrote:

> for our project (Geopard) which does indoor & outdoor mapping, we need
> zoom levels up to 24 or so.
> mod_tile's svn's render_config.h defines a constand #define MAX_ZOOM 18
> (and also MIN_ZOOM)
> but this constant is used in only 2 or so files and the rest of max zoom
> values are hardcoded (just grep for 18 in the svn and you will find them)...

The only 2 hardcoded z18 references I could find for renderd/mod_tile
proper were in gen_tile.cpp. The other references are in the python
support scripts, none of which play a crucial role in normal renderd
operation.

Unless you use renderd.py instead of renderd, that is. There is another
hardcoded 18 in there.

I increased my renderd to z19 for haiti related tiles, and that was as
easy as changing those 2 hardcoded '18' occurences and the MAX_ZOOM
define to 19.

--
Lennard

_______________________________________________
dev mailing list
dev <at> openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

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):

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

HOWEVER #1:

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

HOWEVER #2:

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.

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.

Bye
Frederik

--
Frederik Ramm  ##  eMail frederik <at> remote.org  ##  N49°00'09" E008°23'33"

Frederik Ramm <frederik <at> remote.org> writes:

> Hi,
>
> Jukka Rahkonen wrote:
> > Has anybody made yet a tool which separates ways and tags to different
> > tables?
>
> Yes, Brett Henderson has, it's called Osmosis  Osmosis can generate a
> database schema that has all the data plus geometry columns.

Hi,

Apologies, I had thought that Osmosis is just for OSM specialists. Does it
really create spatial tables which I can use as simply as the ones created by
osm2pgsql with QGis, uDig or OpenJUMP, and which I can use for rendering with
Mapnik, Mapserver, Geoserver etc.?