style based on scale

[ansis]

This might make things harder to design, but its worth thinking about.

The relationship between zoom level and actual scale changes based on latitude. Helsinki is 2x more zoomed in than a location at the equator. This means features that show up at z at the equator show up at effectively z+1 in Helsinki. While for the most part this has been ok so far, but there is a noticeable difference in the visual density of Caracas and Helsinki.

Even if its really blue sky, we should start thinking about how this could help us make projection-independent styles. Independent in the sense that you don't need a different value system, not that you don't need to adjust your style.

Maybe stick to zN values but automatically adjust them based on latitude. The log scale is way more intuitive than dealing with large numbers.

[mourner]

This is not simply a matter of absolute scale. Mercator y scale rises as we go towards the pole, but x scale does not. It's impossible to fix the density problem by adjusting the z value, it's just the way mercator rolls. So I think lets punt on this.

[ansis]

Mercator y scale rises as we go towards the pole, but x scale does not.

If your units are in degrees of lon and lat. If you are dealing with surface distances, then both x and y scales increase linearly as you approach the poles. Mercator is conformal. It is possible to mostly fix the density problem by adjusting the z value.

This type of adjustment doesn't make sense at really low zoom levels where there is a lot of distortion, but at higher zoom levels with low distortion it would work.

It might make things worse by adding confusion though.

[mourner]

Oh, I see now.

[mourner]

OK, it's pretty easy to hack up together:

_updateStyle: function() {
    if (this.style) {
        var correction = this.transform.scaleZoom(1 / Math.cos(this.transform.center.lat * Math.PI / 180));
        this.style.recalculate(this.transform.zoom + correction);
    }
},

The question is how confusing is this for the style designer, and whether we adjust zoom like this (so that the current style would only remain the same on the equator), or shift the adjustment so that it's 0 for some average/reasonable latitude (e.g. ~0 correction for DC, negative for equator, positive for Helsinki but not as high as +1).

@nickidlugash @edenh thoughts?

[nickidlugash]

@mourner @ansis This is really interesting. I hadn't noticed the density discrepancy, but now that I see it, I think it would be great to adjust the styling to resolve it. Some thoughts/questions:

• Using this method, would zoom levels have to be calculated as float values?

This type of adjustment doesn't make sense at really low zoom levels where there is a lot of distortion, but at higher zoom levels with low distortion it would work.

• At roughly what zoom level do you see this type of adjustment starting?
• I could see this working well visually for styles that are declared as either single values or single linear/exponential functions, but it might be confusing for styles that have multiple discrete values or functions at different zoom levels. See Control properties by zoom level? #311. For example, if a designer wanted to style neighborhood labels so that at z16, they shifted from a dark color to a light color, does this mean that at z15 through z17, there would be some labels that are dark and some that are light?

[ajashton]

First of all, I think this feature would be awesome.

The question is how confusing is this for the style designer, and whether we adjust zoom like this (so that the current style would only remain the same on the equator), or shift the adjustment so that it's 0 for some average/reasonable latitude (e.g. ~0 correction for DC, negative for equator, positive for Helsinki but not as high as +1).

I think if we can communicate the compensated zoom level well then there's no reason to shift it, otherwise it's going to be confusing anyway. I'm not strongly opposed to shifting, though.

At roughly what zoom level do you see this type of adjustment starting?

For vector hillshades we start the full compensation at z9, with 66% compensation at z8 and 33% at z7. These were chosen arbitrarily but its at about those zoom levels that you won't really notice things changing as you pan around normally.

[mourner]

I commited the change into the adjust-zoom branch, play with it and let me know how it feels.

For vector hillshades we start the full compensation at z9, with 66% compensation at z8 and 33% at z7.

Implemented the same heuristic here. Adjustment multiplier varies from 0 to 1 from zoom levels 6 to 9.

Using this method, would zoom levels have to be calculated as float values?

They are already, even without adjustment.

For example, if a designer wanted to style neighborhood labels so that at z16, they shifted from a dark color to a light color, does this mean that at z15 through z17, there would be some labels that are dark and some that are light?

In my sample implementation, the zoom adjustment doesn't change until you zoom, so you won't see any artifacts while panning. Also, at higher zoom levels where the adjustment is really noticeable, you will have to pan really far to notice the change, so it shouldn't be a big problem in theory. But lets try that out.

[ansis]

The implementation in #341 seems good to me. We should expose the adjusted value somewhere

I think if we can communicate the compensated zoom level well then there's no reason to shift it, otherwise it's going to be confusing anyway.

I agree with not shifting.

[mourner]

@nickidlugash if you're good with the new behavior, we can merge.

[nickidlugash]

@mourner 👍

[mourner]

OK, style now gets adjusted. You can disable this by passing adjustZoom: false in map options, and control the adjustment "break-in" with minAdjustZoom and maxAdjustZoom options (6 and 9 by default)