You can clone with
HTTPS or Subversion.
This XML snippet will render an ellipse that is 20 pixels wide and 40 pixels tall:
<MarkersSymbolizer width="10" height="20" stroke-width="0" />
Are the width and height units meant to be pixels? The values for stroke-width match up with pixels as expected, but the width and height parameters do not.
(AGG renderer, Mapnik master 385ca5b ).
Ah, I noticed this some time ago, but seem to have forgotten to open an issue on this.
You almost think it's "radius" in x/y direction instead of width/height, but then the parameter name is just plainly confusing.
agg::ellipse c(x, y, w, h);
Yup, width/height are actually radii for ellipses. I suggest for clarity's sake to internally divide by two the given width/height params for MarkersSymbolizer. I see no real sense to introduce radius parameters just for the ellipse case.
fix marker width/height to mean pixels - which it should have all alo…
…ng - closes #1134
Did it really make sense to backport this ? Sounds like something that will change the aspect of any map using markers.
@strk - I think it did, but I can understand your concern. In the case of dynamically sized markers they are new in Mapnik 2.0.0 as a feature, so I deemed this fix worthy of fixing in all maintained series.
Why do you mention dynamically sized markers ? Isn't this about statically sized ones ?
Previously markers could only be loaded from a file, and not drawn at arbitrary (e.g. dynamic) widths/heights - that's what I mean. And soon width/height will be expressions - so more dynamic: #1102
I am totally open to removing the backport I made to 2.0.x, just let me know what others think. I however think the fix should stay in mainline master (aka 2.1.x-pre).
Looking at the CHANGELOG this one seems to be the only interface breaking change. Unfortunately a release with this change exists already, so any reversion would go in 2.0.2 which would represent even more troubles for those who based their maps on the "correct" semantic in 2.0.1. When was 2.0.1 released ?
Looking at the CHANGELOG this one seems to be the only interface breaking change. Unfortunately a release with this change exists already, so any reversion would represent troubles for those who based their maps on the "correct" semantic in 2.0.1. When was 2.0.1 released ?
2.0.1 was released April 10th, 2012 (just added this): https://github.com/mapnik/mapnik/blob/master/CHANGELOG.md#mapnik-201
another +1 vote in favor of seeing 2.0.1 as "young" is that @dpaleino who manages debian packaging is waiting for 2.0.2 (since he saw it would come very soon): #1221 (comment)
partially rollback b93c760 - meaning that radii will continue (as in …
…Mapnik 2.0.0) to be assumed for marker width/height in the Mapnik 2.0.x series (>= 2.0.2) - closes #1163, refs #1134