Results of Tests with scalestyle.rb

scalestyle.rb is a ruby script that performs the scaling operations outside mapnik. It modifies the line widths and font sizes directly in the stylesheet before it is passed to mapnik for rendering.

The following images were created with nik2img.py, all with a scale factor of 1.0.

Text

Labels are scaled correctly.

600x400 Scale factor of ruby script: 1.0

1200x800 Scale factor of ruby script: 2.0


1800x1200 Scale factor of ruby script: 3.0

Dashes

Dashes don't seem to be scaled.

600x400 Scale factor of ruby script: 1.0


1200x800 Scale factor of ruby script: 2.0

1800x1200 Scale factor of ruby script: 3.0

Lines

Lines either.

600x400 Scale factor of ruby script: 1.0

1200x800 Scale factor of ruby script: 2.0

1800x1200 Scale factor of ruby script: 3.0

Test Results

I wanted to post these results in redmine, but the wiki doesn't support resizing of images.

Here are the results of some tests with scale factors. The tests are organized according to the element they test. For each element tested (lines, dashes or fonts), I created a style based on osm.xml, removing the symbolizers I didn't need with the purpose of emphasizing the element. The images were created using nik2img.py.

Text

The three images appear scaled and very similar. The second image has twice the size of the first one, with a scale factor of 2 to fix the size of the labels. The third image has three times the size of the first and a scale factor of 2.

600x400 Scale-factor: 1.0

1200x800 Scale-factor: 2.0

1800x1200 Scale-factor: 3.0

Although the size of the labels seems to be correct, some of them move from one image to the other.

Dashes

The following images were created with a style that contained only line symbolizers with dashes.

600x400 Scale-factor: 1.0

1200x800 Scale-factor: 2.0

1800x1200 Scale-factor: 3.0

Lines

Lines also seem to be scaled correctly.

600x400 Scale-factor: 1.0

1200x800 Scale-factor: 2.0

1800x1200 Scale-factor: 3.0

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

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.

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: http://svn.openstreetmap.org/applications/rendering/mapnik. 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, generate_image.py and nik2img.py:

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

[1] http://code.google.com/p/townguide/wiki/InstallationInstructions

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://svn@svn.mapnik.org/trunk

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@svn.mapnik.org/trunk svn+ssh://svn@svn.mapnik.org/branches/mapnik_resolution

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

May 29

Mapnik Installation (r1796)

I checked out the project's branch from SVN. I want to manage the project locally with Git, so I'll be committing to the server using git-svn.

The installation caused me some trouble:

• After installing version 1_43 of boost in /usr/local and building boost.regex, libboost_regex was still linked to libicu version 42. I had libicu 44 in both /usr/local/lib and /usr/lib, but libicu 42 stil in /usr/lib. Even when I included -sICU_PATH=/usr/local when building with bjam it was still linked to the older version. I solved it removing libicu 42 from /usr/lib and leaving only version 44, but I'm sure this is not the correct way to solve this problem.
  

• The revision I checked out (1796) includes new code that implements some SVG features that are still in development. This revision had two bugs, which where solved by Herm (http://trac.mapnik.org/ticket/557), in files include/mapnik/svg/agg_svg_path_renderer.h (declaration of function 'arc_to' had parameter 'rx' twice | the second 'rx' should be 'ry') and agg/include/agg_rasterizer_scanline_aa.h (function 'abs' should be preceded with 'std::').

• When configuring the build with scons (python scons/scons.py configure) the following problem was solved by removing 'config.py' which (I think) acts as a cache where scons saves the options chosen (i.e. BOOST_LIBS, DEMO) of previous ran configurations:

Note: will build without these OPTIONAL dependencies:
- ociei (Oracle database library | configure with OCCI_LIBS & OCCI_INCLUDES | more info: http://trac.mapnik.org/wiki/OCCI)
- rasterlite

Problem encountered parsing mapnik version, falling back to [0, 8, 0]

• Finally, when I finished the installation, importing mapnik2 in python produced the following error, which I solved removing the input file plugins from /usr/local/lib/mapnik2/input [UPDATE: Running the build again installed correctly the input files and python doesn't show errors anymore when importing mapnik2 (it may have something to do with what's referred to here http://trac.mapnik.org/wiki/InstallationTroubleshooting under 'Input/Plugin 'file not found' output')]:

Problem loading plugin library: /usr/local/lib/mapnik2/input/ogr.input (libtool error: file not found)
Problem loading plugin library: /usr/local/lib/mapnik2/input/gdal.input (libtool error: file not found)