Hi Tom, > From: Tom Hughes [mailto:[EMAIL PROTECTED] > I can't pretend to understand most of this because I don't know > anything about GDAL but I don't see why the fact that a plugin is used should > have any effect on anything.
The problem is that the current plugin architecture doesn't allow the passing of arbitrary fields to the plugin itself. So, in the case of GDAL you can't set what bands you want to extract for viewing from it. Imagine having a 2GB 128 band hyperspectral image. Right now you'd have to create 128 single band files in order to allow Mapnik to render any possible band. And that's just for grayscale images. What if you want to set your RGB bands to 3 other arbitrary bands? So maybe the solution is just to allow arbitrary arguments to plugins, then the plugins themselves can handle plugin specific options. In fact, that probably is the much better solution than my previously stated draconian approach of ditching plugins. > As far as repeated reopening of the file goes, the solution is probably > just some sort of pool/cache in the plugin much as the postgis plugin > does for database connections. Maybe, I'm not familiar with how the postgis plugin works. If it maintains a connection and retrieves data as needed then that's exactly what is needed. It looks more like the GDAL plugin was quickly put together just to get something able to read all of the GDAL supported formats. It can probably use a bit of work. I'll look at the postgis plugin. I'm pretty new to Mapnik and don't have a full understanding of it so it's very likely I'm missing some really basic things, but that's why I'm posting here. > That would be a rather radical design change... > > > I'd like to do this but it'd likely be a large job and difficult due > to the > > general lack of documentation and comments. > > I would suggest that you would want to get Artem's agreement before > starting on such a project - there doesn't seem to be much point if > he has good reasons for the current architecture. I'd really like to hear Artem's views on it, or pointers on how to potentially work around the problem, but it's now been over 2 months since his last appearance on these lists. I've also emailed him independently. He appears to have gone missing. > For what it's worth it sounds to me like the real solution to your > problem is an extension to the RasterSymbolizer to allow a colour > to be specified to override that which comes from the source raster > data. That's if I've understood the problem correctly. If only that would work, but I don't think it will because the styles are applied at too late of a stage - after all the data has been read in and thus after the color bands have been specified (and specified by the file itself rather than the user wanting to read it). > To be honest I think mapnik's real target is rendering of vector > data, which may be why the support for raster data is quite limited. I think you're right - the target also seems to be mostly python users. Unfortunately it's also the only C++ library to support vector on raster rendering that I've found. Mapserver and Geoserver do it, but they don't have a stand alone developer library to use that functionality. _______________________________________________ Mapnik-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/mapnik-users
