New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add allow-overlap and ignore-placement icon/text options #486
Conversation
@mourner want to make a PR for https://github.com/mapbox/mapbox-gl-style-spec as well? |
@yhahn already did mapbox/mapbox-gl-style-spec#64 |
o |
I'm wondering if we could make this one option instead of two. Is there any case where you'd want to allow overlap with the current/previous layers, but not allow overlap with later layers? |
Maybe, — that's a question to style designers. cc @nickidlugash |
Carto's support for this is just a pass-through to Mapnik XML, no real magic or complexity there. |
OK, maybe @artemp @springmeyer can weigh in here :) |
@ajashton do you have any thoughts on whether allow-overlap and ignore-placement could be combined, or if they are useful to have separate? |
There are use cases where you don't want things within a single layer overlapping, but you want to be able to draw things in subsequent layers on top. One example is big semitransparent labels like you see in Bing or some print maps: I can also see it being useful for icons-as-texture, like what Saman was experimenting with a while back (tho ignore-placement is not used in this particular style): |
awesome, thanks! |
Add allow-overlap and ignore-placement icon/text options
tl;dr - I agree with @ansis - seems wise to start with just The longer winded version is: Having them as separate options is important only in the rare case where you want icons to overlap themselves but you do not want text or icons from other layers (rendered after) to overlap. E.g. The sad part of this design (having two options) in TileMill has been that users often set Also, I just did a quick grep of tm-custom-styles and see a ton of cases where the intention is for them both to be true, so keeping as one option seems wise:
|
ha. @AJ's comment just appeared once I posted (had this open for a while stewing). |
Fix geojsonhint error filter
* Add measure light example * Add measure light parsing * Add measure light brightness evaluation * Fix calculateLightsBrightness * Propagate brightness changes * Fix stale brighness values in expression evaluation context * Fix flow and lint * Fix invalid leftover * Fix unit tests * Add render tests * Fix invalid ignore path * Update to correct baselines * Fix lint and increase render test allowed due to CI aliasing * Review comment * Fix small rebase issue * Review suggestion
Closes #477