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/[email protected]/msg23769.html (in which I did not take part) and there : http://www.mail-archive.com/[email protected]/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 <[email protected]> wrote: > Hi, > > Richard Weait wrote: > > On Sat, Apr 17, 2010 at 7:59 AM, Jochen Topf <[email protected]> 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 [email protected] ## N49°00'09" E008°23'33" > > _______________________________________________ > dev mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/dev >
_______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
