CartoDB / turbo-carto

CartoCSS preprocessor
BSD 3-Clause "New" or "Revised" License
28 stars 7 forks source link

Not defining each class explicitly leads to null values getting default polygon-fill #56

Open makella opened 8 years ago

makella commented 8 years ago

Hello, I noticed that there is one less class break condition in Turbo Carto's output CartoCSS. For example, if you ramp a variable using quantiles(5) the output CartoCSS only shows 4 class breaks or if you ramp quantiles(6) the output only shows 5 class breaks, etc.

Every feature that does not meet the criteria gets the default properties.

The major problem I see with this approach is that null values get the default properties. In Editor, by explicitly defining each class break, we avoided nulls getting colored as part of the classification. I'm not sure if there are other unintended consequences of this... this is the first time I noticed.

Example Map

Here is the same data mapped using Quantiles, 5 classes in Editor (left) and Builder (right).

You'll notice places like Greenwood Cemetary and Prospect Park have no fill because their data value is null:

screen shot 2016-11-02 at 12 33 50 pm

Data and CartoCSS

This is a dataset that has some null values in the poverty_per_pop field: https://team.carto.com/u/mamataakella/dataset/brooklyn_poverty

If I symbolize this in Editor, Quantiles, 5 class breaks, this is the CartoCSS:

#brooklyn_poverty{
  polygon-fill: #FFFFCC;
  polygon-opacity: 1;
  line-color: #FFF;
  line-width: 0.5;
  line-opacity: 1;

  [ poverty_per_pop <= 8.4375] {
     polygon-fill: #6c2167;
  }

  [ poverty_per_pop <= 0.3426566252834025] {
     polygon-fill: #a24186;
  }

  [ poverty_per_pop <= 0.226669708123785] {
     polygon-fill: #ca699d;
  }

  [ poverty_per_pop <= 0.1540617568153065] {
     polygon-fill: #e498b4;
  }

  [ poverty_per_pop <= 0.08955616473399425] {
     polygon-fill: #f3cbd3;
  }
}

The output Turbo Carto for polygon-fill: ramp([poverty_per_pop],cartocolor(Magenta),quantiles):

#brooklyn_poverty {

    polygon-fill: #f3cbd3;

    [ poverty_per_pop > 0.08955616473399425 ] {

        polygon-fill: #e498b4;

    }

    [ poverty_per_pop > 0.1540617568153065 ] {

        polygon-fill: #ca699d;

    }

    [ poverty_per_pop > 0.226669708123785 ] {

        polygon-fill: #a24186;

    }

    [ poverty_per_pop > 0.3426566252834025 ] {

        polygon-fill: #6c2167;

    }
    line-color: white;
    line-width: 0.25;   
}

cc @rochoa @javisantana

rochoa commented 8 years ago

Hey @makella

With:

#brooklyn_poverty{
  polygon-fill: #FFFFCC;
  polygon-opacity: 1;
  line-color: #FFF;
  line-width: 0.5;
  line-opacity: 1;

  [ poverty_per_pop <= 8.4375] {
     polygon-fill: #6c2167;
  }

  [ poverty_per_pop <= 0.3426566252834025] {
     polygon-fill: #a24186;
  }

  [ poverty_per_pop <= 0.226669708123785] {
     polygon-fill: #ca699d;
  }

  [ poverty_per_pop <= 0.1540617568153065] {
     polygon-fill: #e498b4;
  }

  [ poverty_per_pop <= 0.08955616473399425] {
     polygon-fill: #f3cbd3;
  }
}

I get a different result from yours:

screen shot 2016-11-22 at 15 39 28

vs. the one using turbo-carto:

screen shot 2016-11-22 at 15 39 42

So this is more about what color the null values get:

What I don't understand is how you were able to get the "transparent"/no fill behavior.

BTW, if you want to treat null values in a special way you can always do:

#brooklyn_poverty {
   [poverty_per_pop=null] {
    polygon-opacity: 0;
  }

  polygon-fill: ramp([poverty_per_pop],cartocolor(Magenta),quantiles)
}
makella commented 8 years ago

@rochoa ok so for your first question, that is CartoCSS straight from EDITOR. I'm not sure why we are seeing different results from the exact same CartoCSS in the Turbo Viewer but in both cases the culprit is the default polygon-fill color.

Here is the link to the Editor map: https://mamatablog.carto.com/viz/2665643e-a11b-11e6-a6bb-0ecd1babdde5/embed_map

Here is the .carto from the EDITOR (if that helps): Untitled Map 4 (on 2016-11-22 at 16.43.17).carto.zip

I think what should happen is that all values should be encapsulated within the class breaks. We should not have a need for a default polygon-fill. Then if there were null values, they would not get colored because they would not be considered in the classification method.

I agree with the special treatment for null values, I just don't think a user will know that they need to do that... So I am trying to see if there is a way that we could do what we were doing before in Editor.