How to create an Interactive Choropleth Map

I am using Leaflet, so reopening and posting here, instead of creating a new issue. This issue was closed as a duplicate with this comment in a Geofield Map issue in 2019 (See "Related issues"):

Geofield stack mapping modules are not able to deal and drive thematic mapping based on polygons (numeric attributes).
I think that the best way would be to use some Charting js frameworks instead, at the moment, such as Charts module.

Since that is four years ago, I wonder if it would now be possible, as a workaround, to:

1. Insert a value in each polygon via a token (field_avg_height used in example below)
2. Calculate an average via javascript, placing the polygon within a color range
3. Update fillColor under "Path Geometries Options" with the result? (<CALCULATED_HEX>)

{"color":"#3388ff","opacity":"0.5","stroke":true,"weight":"2","fill":"depends","fillColor":"<CALCULATED_HEX>","fillOpacity":"0.2","radius":"1","field_avg_height":"{{ field_avg_height }}"}

So, for example if the color range is from #e5f5f9 to #2ca25f and there are three polygons with field_avg_height values 100, 200 and 300, these values would be set:

100: #e5f5f9
200: #99d8c9
300: #2ca25f

Alternatively, targeting fillOpacity instead could be simpler, since that just requires calculating a value between for example 0.3 and 0.7, thereby visualizing the difference via more or less opacity.

Or is Charts or something similar still the best solution?

@ressa ... you are close to the more appropriate solution I would use with Leaflet in Drupal.

In case of discrete (predefined) values (not numeric) you could always use a Taxonomy, with a name/value and corresponding HEX color field,
that you could then use in the "Path Geometries Options" value as token (adding a Taxonomy relation in the View setting to access that Taxonomy Term field).

In case of numeric values instead you could use the hook_leaflet_views_feature_alter (see the leaflet_views.api.php) define here:
https://git.drupalcode.org/project/leaflet/-/blob/10.0.x/modules/leaflet...

and add the specific color property (throughout a mapping array or a specific mapping function) depending on the feature numeric value, etc.

or even better, you could also add a Drupal 8/9/10 computed color field value generated during the rendering and calculated depending on the entity numeric value ( https://www.drupal.org/docs/drupal-apis/entity-api/dynamicvirtual-field-... → ) ... and use it as token directly in the same "Path Geometries Options" value, considering that computed field can be integrated (made available) in Views ( https://www.drupal.org/docs/drupal-apis/entity-api/dynamicvirtual-field-... → ).

Hope all this sufficiently clear ... and helps.

Let me know.

Fantastic and thorough answer @itamair, thank you so much. I will dive into the options you presented during the next few days, and see which one of them will work best, and share it here, or maybe return with a follow up question. Have a nice day.

I went for your first suggestion @itamair, creating a nine level Choropleth taxonomy, where each term (choro1-choro9) has a HEX field, with a sliding color range. All my data is imported via Migrate, so the term value is set during migration with a Migrate process plugin → placing each unit on a range from 1 to 9.

The HEX field is indexed in Solr as type Storage, so I don't even need to add a relationship in the View, which bypasses additional requests to the database, for better performance.

Dynamic/Virtual field values using computed field property classes does look pretty cool, and it would be better in some ways, but maybe also add a bit more complexity?

Anyway, thanks a lot for guiding me in the right direction, it was extremely helpful.

Cool.
Well, if you have a discrete scale of values (1-9) that is associated to the entity, with its direct match with HEX value, you are all set then ...

You would need a Dynamic/Virtual/Computed field if your entities had a continuous (not discrete) value (such as 1.2, 2.3, 5.741, etc.) which you had to associate an HEX value on the basis of related values intervals,
then you would a computed value at run/rendering time, on the basis of a specific function, and that can be integrated (made available) in Views.
Of course it would be some worth additional complexity/or smartness but only if needed (overhead if not).

Luckily, I can do the setting of values during migration with the process plugin, according to predefined intervals (switch -> case -> value less than 8000 = choro1, value less than 10000 = choro2, etc.).

But as we both agree, it would be a more flexible solution with a Dynamic/Virtual/Computed field. Maybe someone at some point could share a simple example custom module example, which uses predefined intervals (or logic) to create terms or just simply HEX-values, exposes the virtual field in Views, and finally how to use the token in a Views-driven Leaflet map under https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... → .

I created ✨ Add Dynamic/Virtual field example Active in the Examples for Developers → project.

Automatically closed - issue fixed for 2 weeks with no activity.