It seems st_area is used for labels. We should likely remove this as I doubt it helps with speed and ideally if http://trac.mapnik.org/ticket/870 can land in the next day this would not be relevant to shared queries for drawing/labels.

With the master branch I'm seeing a request of http://12.189.158.78:8091/?SRS=EPSG:3857&LAYERS=__all__&STYLES=&FORMAT=image/png&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&BBOX=-11897702,4726388.2,-11853070,4785392&WIDTH=588&HEIGHT=778

mapnik:

mapserver:

comparing to mapserver output I noticed we're rendering a few less very small lakes.

mapserver: http://12.189.158.78:8081/cgi-bin/mapserv6?MAP=/benchmarking/wms/2011/mapserver/osm-google.map&layers=default&mode=map&map_imagetype=png&mapext=-12059880+4573133.2+-12007840+4612597.4&imgext=-12059880+4573133.2+-12007840+4612597.4&map_size=722+548&imgx=722&imgy=548&imgxy=722+548

mapnik: http://12.189.158.78:8091/?SRS=EPSG:3857&LAYERS=__all__&STYLES=&FORMAT=image/png&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&BBOX=-12059880,4573133.2,-12007840,4612597.4&WIDTH=722&HEIGHT=548

@ajashton - When you get back in can we sync up on getting you running with the latest patch from http://trac.mapnik.org/ticket/780 ?

I'd like you to test with it to see if you can find things that we can either be doing better in how the styles are authored, things perhaps carto could be doing in conversion, or things mapnik could do better based on what you see output.

Benchmarking is happening over the next couple of days. Technically the deadline is the 1st but I think teams will allow further testing, so if you could make any tweaks before the end of the week that would be ideal, or early next week.

We area using a WHERE clause like: where round(st_area(geometry)) > 1000 on the waterareas_gen* tables, which is unfair if it selects fewer features than mapserver. So, I think we should remove. Also, at least in my local db it appears these were having no affect, so it may be faster to not use the WHERE clause anyway to avoid the calculation...

osm=# select count(*) from osm_waterareas_gen0;
 count 
-------
   267
(1 row)

osm=# select count(*) from osm_waterareas_gen0 where round(st_area(geometry)) > 1000;
 count 
-------
   267
(1 row)

osm=# select count(*) from osm_waterareas_gen1 where round(st_area(geometry)) > 1000;
 count 
-------
  1840
(1 row)

osm=# select count(*) from osm_waterareas_gen1;
 count 
-------
  1840
(1 row)

Perhaps experiment with new placement options.

The mapserver mapfile I think uses some shapefiles in wgs84. Early on we discussed with the mapserver team about ensuring these would be in mercator for the main test, and then there will likely be a fully reprojected test (where map request will be in wgs84).

So, just flagging an issue that we may need to change the style first thing next week when I can get more info on this.

shapefiles should be from: http://mapserver-utils.googlecode.com/svn/branches/imposm-branch/data/

We need to match the mapserver mapfile exactly in terms of shapefile usage. I just noticed we're not actually using these shapefiles and we need to be.

They provide the background, and their usage will definitely slow down rendering, but we need to match the mapserver mapfile.

I try to understand the drawing order of the places labels

You style them like this:

place::city[type='city'] {...}

place::town[type='town'] {...}

place::village[type='village'] {...}

place::small[type='suburb'] {...}

In witch order should the labels be drawn ?

I can do what i want if there is a suburb label near a city label ... the city label is not drawn and the suburb label is drawn

I cannot change that behaviour with the order of the styles or with the order of the Names in the db (with z_order)

I only can control the order of drawing when i write the style different :

place[type='city'] {...}

place[type='town'] {...}

place[type='village'] {...}

place[type='suburb'] {...}

This works and the labels are drawn in the order they appear in the db ... so if i order them there (cities first) cities are drawn first.

Not so with your kind of style. Could you explain the order of the labels in the way you used it with the places labels ?

You should include 'order by z_order' in the query of the landusage layer

It appears you've used 'osm_new...' as a prefix for tables vs. osm. If this was just for testing would be great to switch back to the default as the benchmarking server tables just are like "osm_roads_gen0".

I'm starting to make progress on reflecting the syntax used in the mapserver version via a python conversion script at https://github.com/springmeyer/mapserver2mapnik/. I'll update this issue as I make progress so we can check in.

Currently I've only focused on one set of bounds but most things are working, except:

• river order is wrong
• labels are too dense (need to be more sparse - likely will fix upstream in mapnik via new parameters to prevent labeling short streets)
• some primary-link filters are broken.

If we can land http://trac.mapnik.org/ticket/870 (which is not working yet) then we should quickly create a branch (likely based off of unified) that attempts to reduce the # of layer queries down to the same # that mapserver uses.

Need to look into why this is happening. With latest carto master, when trying to load the style in tilemill, tilemill renders blank blue tiles and the console outputs:

Client Error: ReferenceError: Can't find variable: id
    at http://localhost:8889/assets/bones/all.js:5645
proj_init_error:failed to initialize projection with: 'undefined'

@ajashton - can you take a look at mapbox/carto#105 and comment on what this might look like to start leveraging.

@kkaefer - I assume this could help ensure the most possible efficiency in rendering in cases where you don't need to draw features in two passes (like casings)?

water_label[zoom>15][area>125000],

water_label[zoom>16][area>612500], <- should be 62500

landuse_label[zoom>15][area>125000],

landuse_label[zoom>16][area>612500], <- should be 62500

reviewing mapnik for download denver vs mapserver I see several small issues:

marked up at: https://skitch.com/springmeyer/fss8g/12.189.158.78-800x800-pixels

I've just started a diagnostics tool for mapnik that reports # of features queries vs rendered: http://trac.mapnik.org/ticket/780#comment:4

I'm going to use this ticket to log changes I make to the style to avoid what seem like uneeded queries - partly for @ajashton to review correctlness and partly because I may have bugs in my tool.

This is urgent.

It appears that mapnik has blue backgrounds for some requests while mapserver has white, which indicates to me that the mapnik style may be skipping rendering of some shapefiles when it should not. Ideally this could be fixed before #13.

The two requests (from http://svn.osgeo.org/osgeo/foss4g/benchmarking/wms/2011/jmeter/csv/3857.csv) that I noticed this are:

415;514;-11560133,4664945.2,-11559977,4665138.9
127;412;-11927140,4816562.7,-11927095,4816706.6

And the script I used to spot this was:

mapnik = 'http://12.189.158.78:8091/?SRS=EPSG:3857&LAYERS=__all__&STYLES=&FORMAT=image/png&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&BBOX='
mapnik_template = '%(bbox)s&WIDTH=%(width)s&HEIGHT=%(height)s'

mapserver = 'http://12.189.158.78:8081/cgi-bin/mapserv6?MAP=/benchmarking/wms/2011/mapserver/osm-google.map&layers=default&mode=map&map_imagetype=png&mapext=%(bbox)s&imgext=%(bbox)s&map_size=%(width)s+%(height)s&imgx=%(width)s&imgy=%(height)s&imgxy=%(width)s+%(height)s'

import os

# http://svn.osgeo.org/osgeo/foss4g/benchmarking/wms/2011/jmeter/csv
csv = '3857.csv'

csv_file = open(csv,'r')

csv_lines = csv_file.readlines()
#csv_lines = csv_file.readlines()[:4]

idx = 1

for line in csv_lines:
    width,height,bbox = line.split(';')
    bbox = bbox.strip()
    mapnik_url = mapnik + mapnik_template % locals()
    os.system('wget "%s" -O tiles/%s_mapnik.png' % (mapnik_url,idx))
    bbox = bbox.replace(',','+')
    mapserver_url = mapserver  % locals()
    print mapserver_url
    os.system('wget "%s" -O tiles/%s_mapserver.png' % (mapserver_url,idx))
    idx += 1
    #print width,height,bbox

mapserver appears to be drawing labels (in the one sample request at least) more sparsely than this style (which is now set up and viewable here)

I think we should be able to match this with a new text_symbolizer property like text-buffer-size:200 which could fast track throwing away nearby labels: http://trac.mapnik.org/ticket/840