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 ...

Thursday, 24 June 2010

June 24

Yesterday, I took advantage of the installation I did of townguide-py, Waldemar's project, to test changes in the branch more quickly and to have a variety of different maps to render (using osm's viewer).

Before that, I merged the branch with trunk to have it up to date and take a look at the changes in agg_renderer with respect to scaling. I based the last commit on these changes but also added the scale factor to image_32. It makes sense to me to have it there, because I also need to change the size of the image, not only of the map elements.

Tuesday, 22 June 2010

XML Upgrade Problem

I faced a problem when rendering OSM data, that made some elements of the map not to be displayed; the cities appeared in gray and the streets were just thin black lines. The following map of Hartlepool, England, shows how the maps were displayed:

The problem seemed weird to me, because I was following the instructions in Townguide's manual [1] and they produced good results to Waldemar. Besides, Waldemar tried it yesterday in his computer and the maps were rendered correctly, both with mapnik and mapnik2. I thought that the problem was something I changed in the code of AGG renderer, but I went back to the previous revision and the problem was still there.

The problem turned out to be in osm.xml, which I got from: Dane Springmeyer had already told me that mapnik2 introduced some changes in the stylesheet, so my stylesheet was outdated. I was also getting deprecation warnings when running mapnik's demos, and

Deprecation Warning: symbolizer value now an expression, please wrap properly in brackets like "[name]".

My first attempt to eliminate these warnings was to use the upgrade_map_xml utility, as Dane Springmeyer told me. However, it didn't seem to work, because the stylesheet was still the same. So what I did was to replace manually what the warnings were telling me, but I guess I made some mistakes (replacing, for example, in sql queries too).

Searching the web, I found that the output of upgrade_map_xml needed to be printed to a file, as it is displayed in the terminal by default. So the correct usage is:

$ python osm.xml > osm.xml

But what I really did was to print the output in a second file, because python generated the following error:

lxml.etree.XMLSyntaxError: Document is empty, line 1, column 1

And indeed it was empty after issuing the command.


June 22

It's been a while since I last updated the blog and I feel that my communication with the community and my mentor has been poor and scarce. I really need to improve in this aspect, because many people are interested in the project and expect a lot from it.

Talking about the progress of the project, my mentor gave me some directions last week, which I haven't had the chance to put in practice, because of some technical difficulties I've found. The problem is starting to frustrate me, because I'm falling behind my schedule and I still have to deal with units and the second part of the project.

I felt that I needed to test the code with images with more elements or detail, so I began to investigate how to work with OSM data in mapnik. Townguide's installation manual was very helpful in this respect. After solving some issues with the postgis database (the nodes table wasn't created when I imported the data using osm2pgsql) I finally manged to create an map. However, this map looks like the following:

When it should look like this:

The second image was produced with townguide-py, Waldemar's project, with mapnik 1 behind and the first one with the new branch, mapnik_resolution. The problem may be caused by some code I introduced lately because Waldemar rendered the map using my branch (latest committed changes) and it looked fine. I'll go back to the previous revision and make the changes one by one to detect the problem.

My next move was to merge trunk with my branch. To incorporate the changes in trunk, I issued the following command:

svn merge -r 1796:HEAD svn+ssh://

Revision 1796 is the snapshot of the repository from which the branch was created. While the merging was being executed, conflicts arose; I accepted the changes completely because I wanted mine to be overwritten. However, the changes from trunk were applied, but my changes were still there, which caused a failure when I built the code.

Then I decided to copy it, like this:

svn copy svn+ssh:// svn+ssh://

But this only created a directory for trunk inside the branch. I need to get help to do it.