Dane Springmeyer wrote: > I've been reviewing and corresponding with Albert Valverde about his > excellent patches to the Gdal driver (getting overviews working) and > RasterSymbolizer (adding support for colorizing, working with > individual bands, and nodata values, among other advancements). > > I'd like to propose Alberto commit access to start a branch for his > work. It looks feasible to begin pulling some of his changes into > trunk soon (particularly the support for GDAL overviews which is > working nicely, built upon Lucio's nice start), while review of best > practices and approaches for colorization would be great from all of you. Hi all,
Thanks for the commit bit! I was having a hard time keeping my sanity with all these patches lying around ;) Well, I've just created a "gdalcolors" branch and applied the patch. It still lacks some cleanup, docs and tests which I hope to finish soon. I must admit I'm not too happy with the patch as it is right now as some parts are really "hacky, partly due to my C++ inexperience and partly because it seems (from my c++ newbie POV) that mapnik was never designed to display raw raster data. Anyway, this patch shows it's possible and I'm pretty sure that a little bit of refactoring could make this functionality fit-in more cleanly. I hope I can get some help guiding me on how to best introduce some changes in mapnik to better support raster data. Some of these, from the top of my head: * To make best use of any overviews the featureset needs to know the geographic extent and the image size as it was requested to the Map. Currently it derives this information by peeking into the query object (the patch makes it available to the featureset) to look at the resolution but this is sub-optimal because the resolution is calculated out of the intersection of the requested extent and the layer's extent. Would it be possible to make the original extent and image size available to the featureset somehow? Perhaps the query object could carry this information too? * The raw data from the GdalBand is passed from the featureset down to the symbolizer casted as a float into the ImageData32's int buffer and then casted back. This is ugly but it works, at least with 32 bit data. I yet have no use-case of it but perhaps some folks will need to display Float64 data but it's not possible ATM (without incurring in yet more horrible hacks). Any ideas on how to extend the ImageData (?) to be able to carry other datatypes? Finally a little bit of background about the itch I'm trying to scratch with these patches: I'm in the process of migrating the rendering engine of a GIS webapp we're working on which currently uses mapscript to mapnik due to the beautiful maps it makes, a (much) nicer python API and its ability to load the styles from an XML file which will allow the people in charge of administering the app to style the maps themselves and stop bothering me all the time ;) This app is used mostly to display meteorological and other data we derive from the meteo. one to aid in the wild forest fire-fighting in Spain (we're unfortunately having a terrible summer so far with 14 active fires in this very moment :( ) Since 99% of this data is raster based this functionality is essential for us to be able to use mapnik as the main rendering engine. Cheers, Alberto P.S I've created another "arrowsymbolizer" branch with an ArrowSymbolizer we use to render arrows to visualize wind speed/direction and fireline intensity/direction. Perhaps this can be useful to others working in a similar domain as us, or just to have fun ;). Though I have briefly mentioned this to Dane I didn't get any explicit permission to upload it so if there's any problem (perhaps it's too specialized for mapnik's audience?) don't hesitate to tell me an I'll remove it immediately _______________________________________________ Mapnik-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/mapnik-devel
