Skip to content
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

Data Driven Styling Based on Feature Id #3804

Closed
jasonpepper opened this issue Dec 14, 2016 · 6 comments
Closed

Data Driven Styling Based on Feature Id #3804

jasonpepper opened this issue Dec 14, 2016 · 6 comments

Comments

@jasonpepper
Copy link
Contributor

jasonpepper commented Dec 14, 2016

Motivation

What use cases are we trying to accommodate? I have a dataset where each feature has a distinct color. I would like to use the feature id for the style function property so that styling can be done as a function of the feature's id. Currently I have to add the feature id as a property in order to make it work, instead of using the feature id.

Design Alternatives

How could we accommodate the use cases above? For example, I would like to do something like this:

            "fill-color": {
                "property": "$id",
                "type": "categorical",
                "stops": stops
            },

Or since that might be misleading since id is not technically a property, use the "key" terminology as is done with filters. For example:

            "fill-color": {
                "key": "$id",
                "type": "categorical",
                "stops": stops
            },

Design

Mock-Up

Concepts

How will we teach this design? Add documentation to the "property" section in the "Functions" section of the style spec.

What existing precedents support the new concepts? Filters currently support the $id key, although it is not documented.

Implementation

How you would implement the design? Add a special case when getting the property value. If the key/property is $id, use feature.id instead of feature.properties[property].

@mollymerp
Copy link
Contributor

Hi @x9xjdzz9 - thank you for contributing this idea to mapbox-gl-js. Could you clarify why you don't want to include the feature id in the properties section of your feature data? Or even put a color property in there and use the identity function type to style your features? That would be the simplest option because you could avoid adding individual stops for every feature in your dataset and I suspect be much more performant.

That syntax would look like

"fill-color": {
  "type": "identity",
  "property": "color"
} 

@jasonpepper
Copy link
Contributor Author

I prefer the use of the feature id because I think it is a more obvious way of representing a unique id in my data. But it's a minor preference and I can easily use a property instead. Mainly, I saw that there was some support for the id field in the filters, so I thought it would be nice to use the same thing in data-driven styling.

Unfortunately, I can't use a color property because the color changes over time and depending on the context in which the feature is used. I would have to have a separate version of the vector tiles for each context, and change them whenever a color needed to change.

@lucaswoj
Copy link
Contributor

This feature is already implemented mapbox/mapbox-gl-style-spec#391

We have an open issue to capture the poor documentation around this capability mapbox/mapbox-gl-style-spec#391. If you're having trouble using this feature, please provide a test case that demonstrates the problem.

@lucaswoj
Copy link
Contributor

Oopsie. The linked issues are only relevant in the context of feature filters. This is a valid request for property functions 👍

@lucaswoj lucaswoj reopened this Dec 15, 2016
@gmaclennan
Copy link
Contributor

+1 this would be useful for us too. There are definitely cases where it is useful to style each feature individually, and it makes more sense for this to be on $id rather than a feature property. Aligning with the feature filter spec would be great.

@anandthakker
Copy link
Contributor

This is now being covered in the work on allowing arbitrary expressions in style functions over at #4777

Duplicate of #4077

@anandthakker anandthakker marked this as a duplicate of #4077 Jul 21, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants