Skip to content
This repository has been archived by the owner on Apr 10, 2018. It is now read-only.

Stop functions based on arbitrary properties (not zoom) #226

Closed
mourner opened this issue Dec 16, 2014 · 8 comments
Closed

Stop functions based on arbitrary properties (not zoom) #226

mourner opened this issue Dec 16, 2014 · 8 comments

Comments

@mourner
Copy link
Member

mourner commented Dec 16, 2014

Just capturing what has been discussed tonight — we need more fancy stops to be able to satisfy a use case such as choropleth maps (as a first step). Currently stops functions are always [zoom, value] pairs, while it would be nice to make stops based on arbitrary properties. Maybe like this:

{
  "property": "height",
  "stops": [[0, "blue"], [100, "green"], [200, "red"]]
}

The next step would be calculating the breaks (0, 100, 200 above) automatically. For naive scales, we could do this either on the app side (generate manually) or as a style spec feature. But for something like Jenks natural breaks, we need to know the whole range of values, which can only be calculated on the VT serving side if we don't want to readjust the classes as the tiles come.

cc @tmcw @jfirebaugh @edenh

@tmcw
Copy link
Contributor

tmcw commented Dec 16, 2014

My impression was that the vast majority of the work / technical challenge here is getting the gl-js and gl-native renderer to be able to keep attribute values & vary styles based on them. Figuring out stops is a separate issue and personally I'm happy to punt on something like Jenks at first - but it doesn't seem like we have the data at the rendering stage to pull this off, since right now we've made all the styling decisions earlier in the rendering cycle.

@mourner
Copy link
Member Author

mourner commented Dec 16, 2014

I think it's manageable. Draw calls in source tiles get buckets with geometry & layer style — we can keep track of values that need resolving and do it finally there, including property values in buckets when necessary.

@jfirebaugh
Copy link
Contributor

In terms of syntax, I suggest we follow D3 scales and specify domain and range separately:

{
  "property": "height",
  "domain": [0, 100, 200],
  "range": ["blue", "green", "red"]
}

Pros:

  • "domain" can be optional, and inferred implicitly from usage (each unique value that is encountered gets assigned a new value from the range)
  • recycling range values is permitted if there are fewer elements in the range than in the domain
  • possibility to reuse common domains and ranges as constants

In general D3 scales are a good model for this.

@tmcw
Copy link
Contributor

tmcw commented Dec 16, 2014

vega could be a useful example here because it has already thought through JSON representations: https://github.com/trifacta/vega/wiki/Scales http://trifacta.github.io/vega/editor/index.html?spec=population

@mourner
Copy link
Member Author

mourner commented Dec 16, 2014

I like @jfirebaugh's suggestion. Clean, easy to understand, and extendable.

@nickidlugash
Copy link
Contributor

Related? mapbox/mapbox-gl-js#146

@wboykinm
Copy link

wboykinm commented Jan 3, 2015

👍 for matching D3 scale syntax.

@jfirebaugh
Copy link
Contributor

#249

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants