Skip to content
This repository

MarkersSymbolizer width & height values get doubled #1134

Closed
ajashton opened this Issue March 17, 2012 · 12 comments

4 participants

AJ Ashton Dane Springmeyer novldp strk
AJ Ashton

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

novldp

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.

novldp

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.

Dane Springmeyer springmeyer closed this in 3f26c43 March 23, 2012
strk
strk commented June 15, 2012

Did it really make sense to backport this ? Sounds like something that will change the aspect of any map using markers.

Dane Springmeyer
Owner

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

strk
strk commented June 15, 2012

Why do you mention dynamically sized markers ? Isn't this about statically sized ones ?

Dane Springmeyer
Owner

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

Dane Springmeyer
Owner

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

strk
strk commented June 18, 2012

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 ?

strk
strk commented June 18, 2012

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 ?

Dane Springmeyer
Owner

2.0.1 was released April 10th, 2012 (just added this): https://github.com/mapnik/mapnik/blob/master/CHANGELOG.md#mapnik-201

strk
strk commented June 18, 2012
Dane Springmeyer
Owner

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)

Dane Springmeyer springmeyer referenced this issue from a commit July 04, 2012
Dane Springmeyer 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
ff27185
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.