Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

MarkersSymbolizer width & height values get doubled #1134

Closed
ajashton opened this Issue · 12 comments

4 participants

AJ Ashton novldp Sandro Santilli Dane Springmeyer
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.

Sandro Santilli

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.

Sandro Santilli

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

Sandro Santilli

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 ?

Sandro Santilli

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

Sandro Santilli
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
Dane Springmeyer 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.