https://github.com/mapnik/mapnik-reference/blob/master/2.3.0/reference.json#L449

mapbox/carto#355

The default value is stated as

radial-distance (geometry will not be simplified using the radial distance algorithm)

The not appears to be misplaced.

From @pnorman's comment in carto.

See mapbox/tilemill#994 for more details.

Seems critical for this file to be built from templates since many datasources share parameters and using a template will reduce duplication.

Currently the template can be built into a standalone doc like:

node util/make-datasource-ref.js latest/datasources.template

higher the value the fewer the placement tries: https://github.com/mapnik/mapnik/wiki/TextSymbolizer, but automatically calculated from spacing by default: http://mapnik.org/news/2012/10/06/gsoc2012-status9/

Need to figure out my grep pattern and add all expression types at the same time to the transforms branch.

Hello,

I've started to work on using reference.json as a file to autogenerate symbolizers reference for mapnik.
See a first result on https://github.com/ThomasG77/mapnik-symbolizers-autodoc/wiki/
As you will see, the columns order is wrong because we don't have a predefined order for them.

So, we need to defined the global order of the columns to get a table with important columns in first. We maybe need to hide some columns because they are not very important.
You will see below an unordered list. Help us to choose the best order and the hidden columns.

[parameters,
'api',
'availability',
'css',
'default',
'default-meaning',
'default-value',
'doc',
'range',
'required',
'serialization',
'type',
'validate']

Any comments is welcome.
Some columns may be removed or change e.g previous ticket

These parameters could use friendlier descriptions:
line-join
line-cap
*-gamma-method
*-simplify-algorithm
*-rasterizer
line-pattern-simplify-algorithm
text-placement
text-placement-type
text-placements
shield-placement
shield-placement-type
shield-placements

Not sure how this "map" parameter ended up within symbolizers. Moving it will break carto, but it does not make sense where it is.

Just noticed this new text-placement-type. What does it do?

There doesn't seem to be any indication of what license this is under, either in the package.json metadata or in the README.md, nor is there a separate license file...

I download mapnik-reference-5.0.0,use the file ../2.1.0/reference.json ,I found:
1) Style lost "name " property
2) the "font-set" and "face-name" lost

A negative integer is valid and can be useful for the text-line-spacing property to allow wrapped text lines to be less far apart than the default.

But currently the reference reports it as unsigned which is incorrect.

We should be able to indicate new features of Mapnik to give more helpful feedback when things aren't supported in a users version but are in HEAD.

This goes hand-in-hand with tagging this project in lockstep with Mapnik itself.

as reported by rhildebrand on IRC. See https://github.com/mapnik/mapnik-reference/blob/master/2.0.1/reference.json#L62

@springmeyer is raster-composite-operation missing from https://github.com/mapnik/mapnik-reference/blob/master/2.1.0/reference.json or should I use something else?

I started cleaning this up by consistifying formatting and fixing default values in this branch: https://github.com/mapnik/mapnik-reference/tree/cleanup

Next steps:

• Add 'extended-reference' URLS to transform and comp-op parameters
• Add 'example-value' to some parameters so docs in mapbox studio are more self-explanatory.

@springmeyer this look ok so far?

The SVG spec uses comp-op which is why Mapnik went with this naming, whereas we usually we tend to spell out words fully to avoid abbreviations.

So, the open question is: is there a good reason to call this composite-operation in CSS, or should we switch to comp-op before all this goes live in a TileMill release?

shield-transform is missing in the reference, and of course is different than shield-text-transform.

It is likely missing because I stopped short when I encountered #22

Reported downstream at http://support.mapbox.com/discussions/tilemill/6154-placements-placement-type-and-transform-attributes-of-a-shield-symbolizer#comment_26229210

Like for docs and doc, it seems duplicated.
Choose one depending on impacts on others tools.
For info, "default-value" is most of the time the prefered keyword (compare to "default" ) in reference.json.

A sample below :L 347-358

    "avoid-edges": {
        "css": "shield-avoid-edges",
        "doc": "Tell positioning algorithm to avoid labeling near intersection edges.",
        "type": "boolean",
        "default": false
    },
    "minimum-distance": {
        "css": "shield-min-distance",
        "type": "float",
        "default-value": 0,
        "doc": "Minimum distance to the next shield symbol, not necessarily the same shield."
    },

Would be great to have raster-filter-factor exposed to further refine the sampling for rasters in TileMill.

mapnik/mapnik#2416

GNU Make has a -j switch to specify how many threads to use for building. This is hard-coded in mapnik-reference's Makefile to match the number of cores on the machine.

It is annoying because using all cores makes the machine unresponsive so you can't do anything else, and there's no switch to disable that. Dunno what's the best way to deal with this

This got named back in Mapnik master, need to adjust soon.

The upright property of TextSymbolizer is missing in the reference for 3.0.0.

Unfortunately if X.Y versioning can't be supported (see #29) there's no way to make things work automatically without providing a reference file for each and every version...

Could you add one for 2.0.0 ?

Latest reference is currently 2.1.1 (beside "latest"). Since 2.2.0 is out a named reference for it is due.

The Mapnik expr-v2 branch has a new framework to make it very easy to move most symbolizer properties to expressions. This branch will soon be merged to Mapnik master and released as Mapnik 3.0.0.

Already most properties that express color fills stroke widths and opacity have become expressions in this Mapnik branch. This ticket stands to track which are newly expressions and which have been enabled here in the reference.json. For these new expressions to be available in TileMill they need to be added reference.json

I've done this for some in:

28cc754

TODO:

• - evaluate which other properties should become expressions in Mapnik
• - ensure they are listed as "expression" type in the latest reference.json

In reference.json file, some keys in the keys of symbolizers are "doc" and "docs" and seems to describe the same thing.
Choose a convention or don't change if the two keywords really don't have the same meaning.

Ilustrated examples extract from:

L 292-296

    "spacing": {
        "css": "marker-spacing",
        "docs": "Space between repeated labels",
        "type": "float"
    },

Line 385-392

    "halo-fill": {
        "css": "shield-halo-fill",
        "docs": "Color of the text halo",
        "type": "color",
        "default-value": "#FFFFFF",
        "default-meaning": "white",
        "doc": "Specifies the color of the halo around the text."
    },

I don't know impact on other applications depending of this file.

  ✖ 7 of 84 tests failed:

  1) mapnik.Datasource should validate with known shapefile:

  AssertionError: "unknown" deepEqual "polygon"
      at Context.options.type (/home/src/cartodb/node-mapnik/test/datasource.test.js:81:16)

  2) mapnik.Datasource should validate with known geojson:

  AssertionError: "unknown" deepEqual "polygon"
      at Context.<anonymous> (/home/src/cartodb/node-mapnik/test/datasource.test.js:143:16)

  3) mapnik.Parameters  should be accessible from map:

  AssertionError: "undefined" == 0.999
      at Context.<anonymous> (/home/src/cartodb/node-mapnik/test/parameters.test.js:12:16)

  4) mapnik.Parameters  should be settable on map: 

  AssertionError: "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<Map srs=\"+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs\"/>\n" == "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<Map srs=\"+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs\">\n    <Parameters>\n 
      at Context.<anonymous> (/home/src/cartodb/node-mapnik/test/parameters.test.js:21:16)

...

I omitted part of the test results.

Note that I built and checked with LD_LIBRARY_PATH=/extra/mapnik-2.1.0/lib/ PATH=/extra/mapnik-2.1.0/include/:$PATH

It is not clear to me whether shield symbolizer rendering supports these, and whether they affect shields, or text on the shields, or both.

@herm - can you advise?

The Makefile expects to find node_modules/mocha/bin/mocha but package.json doesn't list mocha in the devDependencies.

Try throwing reference.json through http://www.jsonlint.com and you'll get errors for the trailing commas on the following lines:

• https://github.com/mapnik/reference.json/blob/master/reference.json#L46
• https://github.com/mapnik/reference.json/blob/dashes/reference.json#L98

These prevent parsing on some platforms.

mapbox/carto@d3b16a4

mapbox/carto#359

The docs state

shield-text-dy

Default Value: 0 Displace text within shield by fixed amount, in pixels, +/- along the Y axis. A positive value will shift the text down

shield-dy

Default Value: 0 Displace shield by fixed amount, in pixels, +/- along the Y axis. A positive value will shift the text down

Do both shift the text down, or does one shift the shield down?

I'd do a PR to fix it, but I'm not positive what all the alignment stuff does here.

after read the latest mapnik code,I think shieldSymbolizer also has placement-type,placements which the TextSymbolizer has!

consideration should be given to renaming this in carto and mapnik to be more clear (this is @springmeyer writing this from @geografa's machine) :)

Need to have a think on this. We originally went with text-transform (for upper/lowercase) since that is what css uses. But this will conflict with the transform attribute when/if Mapnik supports that.

text-size, text-ratio, text-character-spacing, text-line-spacing, text-label-position-tolerance all have float as their type in reference.json but take unsigned in mapnik.

A DTD was added to mapnik/utils/xml after mapnik/mapnik#684, but it has not been updated. I just don't have the bandwidth to keep it up to date when focusing on mapnik-reference and the codebase instead.

Therefore it was removed before Mapnik 2.1 release.

We should consider auto-generating it using the reference, and providing scripts here.

/cc @manelclos.

Using marker-type:arrow with 2.0.0 is failing for me.
I do see it listed in the reference for 2.0.1 (reference for 2.0.0 is missing, see #35) but git log seems to say the support was added on July, 10 2012 (3e895ac6b7205d4490501ce66f83c2ae178fbca3).

So is arrow supposed to work with 2.0.1 and 2.0.2 or should the reference be fixed ?

The raster-colorizer type is currently tags - not sure if this really makes sense - sure, it's tags, but lots of other things, like text placements, will be tags as well, and should have type checking so that you can't specify color stops as text placements and so on.

Types are also usually named by carto input rather than serialization.

Thinking a better name might be stops?

/cc @springmeyer

• mapnik::geometry_type: point,linestring,polygon,collection
• anything else?

See mapbox/carto#167 (comment)

wrap-character is removed starting at Mapnik 3.x (mapnik/mapnik#2333) and is now auto-detected: mapnik/mapnik#1467

Currently it is just a string, leading to odd syntax errors in Carto if you try to use it as if it were a function.

I'm researching about the possibility to specify a target version to go along carto documents to ensure their interpretation won't change over time. In doing this I found that mapnik-reference looks like trying to serve a similar need.

What I don't understand, though, is why mapnik-reference provides versions up to the patch level.
Does mapnik itself changes the language between patch level releases ?

I would expect to be able to reference "2.0" or "2.1" without the need to go as deep as "2.0.1".

https://github.com/mapnik/mapnik/wiki/TextSymbolizer

From mapnik 2.1, the placement types were expanded to dummy, simple and list. Only dummy and simple values are currently in the reference.

Also, the corresponding element also needs an entry in the reference somewhere, but it's not clear to me where that would go.