Friday, 25 June 2010

June 25

The last change I made has some things I don't like:
  1. First, to achieve the change in size in the image and the map elements, I applied the scale factor directly in the constructors of image_32 and agg_renderer. For example, I multiplied the scale factor by the width and height of the image before setting these values. I also changed the values of the bboxes that are passed to CoordTransform and label_collision_detector in agg_renderer's constructor. There are maybe other better places than these to apply the scale factor. However, it is convenient to apply it before all these dimension values (image's width and height, label collision area, etc.) are used further.
  2. Agg_renderer holds a reference to a template type (T & pixmap) instead of a explicit reference to image_32. I assume there might be other image objects that could be used as well, but I haven't seen them in code yet. mapnik_python uses only the image_32 object in the render methods. If there are such other objects, I would have to make the changes I made in image_32 in all these classes.
Image_32 seems a good place to have the scale factor, because resolution is a property of an image. However, it also makes sense to manage resolution from the renderer because one can render an image at different resolutions. Having it as a property of Map makes the interface easier to the user, and more if this user uses only stylesheets. If the user uses instead the scripting bindings, having the scale factor passed to image_32 (or the render method) is as convenient as having it passed to Map, but more flexible because he/she can have only one map object, which can be used to produce images of different sizes/resolutions.

I tried to reflect the changes in the python bindings. I added a third parameter to mapnik.Image's constructor and the code compiled correctly. However, townguide's code doesn't produce the images. I tried to disable the code that determines the resolution, but these values are used in other parts of the code that may be ...

No comments:

Post a Comment