[OSM-dev] Tirex vs Renderd

Jonathan-David SCHRODER jonathan.schroder at gmail.com
Mon Apr 19 16:26:18 BST 2010


Hello,
I am part of the Geopard project adverstised here some time ago.
This project is about indoor mapping + indoor wifi geopositioning on any
devices, while relying on the OSM stack.

During the dev of a first prototype, I had 2 major issues related to
mod_tile/renderd current design&implementation :

1) mod_tile & renderd's max zoom level is hardcoded at 17, while we want ~22
or maybe more. I would like to have this number 1) not harcoded, or codable
only in a single config.h-like file or a single .conf file loaded at
startup. Or even more flexible, have the max zoom level settable with
unix/internet socket packets. In discussions here about this max zoom level,
I had raised and a developer agreed that mod_tile's current tile-expiring
management was implemented with a hacky C bit array instead where 1 bit = 1
tile, r/w with a clever calculation. That array would be 2GB wide for
max_zoom=22, so we concluded that a graph-based implementation would be
better for Geopard.
I am spotting two conversations on the max zoom level here :
http://www.mail-archive.com/talk@openstreetmap.org/msg23769.html (in which I
did not take part) and there :
http://www.mail-archive.com/dev@openstreetmap.org/msg10266.html (which I had
started).

2) in indoor tiles rendering, we have a bunch of vectors tagged with
building=yes, name="uniqueBuildingName" and level=INTEGER. When I want to
render only floor N of building uniqueBuildingName, I would successfuly HTTP
the TMS scheme http://domain/tiles/uniqueBuildingName_levelN/z/x/y.png(which
is ugly). In the background, mod_tile would see... ok you want layer
uniqueBuildingName_levelN and use the appropriate single-file stylesheet for
handing renderd its jobs. Let me stress, that as for the wikipedia project
multi-lingual issue with non-dynamic/on-the-fly stylesheet customization,
this would force in an indoor mapping use case to have  ~
NumberOfExistingBuildings*AverageNumberOfLevelsPerBuilding hand-generated
stylesheets. In our case, we need a per-building-per-level stylesheet to
have some of its PostgreSQL vector selection query changed dynamically out
of a single template (select walls from lines where building=yes and
name=[dynamically set by renderd] and level=[dynamically set by renderd]).

In the case of our project (indoor mapping & indoor wifi geopositionning),
we have not got far yet but this is obvious that :
a) we'd need patching and keeping up with upstream changes (=forking...)
both both:
- mod_tile (max zoom level dynamic non-hardcoding, tile-expiry graph
implementation, nicer/customizable URL scheme)
and
- renderd (max zoom level dynamic coding, dynamic stylesheet generation)

b) why not, creating a mapnik plug-in for the dynamic stylesheet generation
issue

c) using implementations of mod_tile & renderd -like applications written in
dynamic languages (thus Tirex, and renderd's python implementation) to
prototype things more quickly and easily.

So.. If I can sum up my yet unmet requirements regarding mod_tile/renderd,
those are :
- easy on the fly max zoom level change without any application restart
- easy URL scheme customization
- easy way to implement middleware code that allows pre-rendering stylesheet
transformations thanks to input parameters received such as URL scheme
parameters and other disk files/database stored info

As far as indoor mapping is concerned, speed is not a big concern for me, so
not staying with C-coded applications is not an issue for me.

Thanks very much for our thoughts and decision to love ourselves and each
other better,

Jonathan-David Schröder
Geopard Team http://geoparden.wordpress.com

On Sat, Apr 17, 2010 at 8:35 PM, Frederik Ramm <frederik at remote.org> wrote:

> Hi,
>
> Richard Weait wrote:
> > On Sat, Apr 17, 2010 at 7:59 AM, Jochen Topf <jochen at remote.org> wrote:
> >
> >> There are many ways we could approach this: One would be to implement
> >> something in Mapnik so that it can allow variables in style files. Then
> >> you would only have one style file for all languages and somehow feed
> >> the language in separately.
> >
> > That sounds like a great idea.
> > Please see the "New Expressions Engine" portion of the Mapnik2
> > announcement. You might like it.   ;-)
> > http://mapnik.org/news/2009/dec/
>
> That could be a good basis for what Jochen suggested; the missing link
> would be the ability to "inject" variables from the outside when
> rendering, i.e. before you call the renderer's apply() method in Mapnik
> you would have to do something like "render.setVariable(key, value)" and
> then you could have a rule in the style file that, dending on the value,
> would create a different rendering outcome.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"
>
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20100419/48bb4448/attachment.html>


More information about the dev mailing list