Apache Superset Feature request: Support icons and/or text points in deck.gl GeoJSON chart

Feature description

Support icons and text type points in deck.gl's geojson chart.

Bug report this feature request is stemming from:

The description of the deck.gl Geojson chart states this: The GeoJsonLayer takes in GeoJSON formatted data and renders it as interactive polygons, lines and points (circles, icons and/or texts).

I am specifically interested in the point as an icon or text option. However, it seems that it is not possible to set a point as an icon or text.

The text option would be highly useful because it can be used to annotate points on the map.

Here is a sample data set i am using:

SELECT '{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "geometry": {
        "type": "Point",
        "coordinates": [-92.0060, 42.7128]
      },
      "properties": {
        "name": "New York City"
      }
    },
    {
      "type": "Feature",
      "geometry": {
        "type": "LineString",
        "coordinates": [
          [-122.4194, 37.7749],
          [-118.2437, 34.0522],
          [-87.6298, 41.8781],
          [-74.0060, 40.7128]
        ]
      },
      "properties": {
        "name": "Cross-country route"
      }
    }
  ]
}' as JSON

The point indeed appears but as a circle and I don't see how to turn it into an icon or text.

Looking at deck.gl's documentation, it seems that the pointType option has to be set at the level of the GeoJsonLayer. So I'm not sure how this is supposed to modified since the geojson column we provide only provides the features but not the level above setting for the geojson layer tiself. Unless I'm confused and there's a way of including it in the json.

Screenshots/recordings

No response

Superset version

5.0.0

Python version

3.9

Node version

Browser

Chrome

Additional context

No response

Checklist

[x] I have searched Superset docs and Slack and didn't find a solution to my problem.
[x] I have searched the GitHub issue tracker and didn't find a similar bug report.
[x] I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.

Comment From: dosubot[bot]

Hi @fin-gal! I'm Dosu and I’m helping the superset team.

You're correct—Superset's deck.gl GeoJSON chart does not currently expose the pointType property, so points can only be rendered as circles. There is no option in the control panel or chart configuration to display points as icons or text, and the GeoJSON data itself can't specify this rendering style. This limitation is confirmed in the codebase, where the GeoJsonLayer is instantiated without setting pointType and the control panel does not offer this as a configurable option [source].

There are no built-in workarounds or alternative plugins in Superset to achieve icon or text rendering for GeoJSON points. To get this functionality, you would need to develop a custom deck.gl plugin, fork/modify the GeoJSON chart, or submit a feature request.

To reply, just mention @dosu.

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

Comment From: fin-gal

@dosu All clear, this confirms what I thought by looking at the code you mentioned. I would be willing to try and develop this as a new feature myself. Can I convert this issue to feature request and work on a PR on my side?

Comment From: dosubot[bot]

Yes, you can absolutely convert your issue to a feature request—just edit the title and description to clarify it's a feature proposal. Superset welcomes contributions like this. To work on a PR, fork the repo, create a branch, make your changes, and open a pull request against master [contribution guidelines].

For best results, include tests and documentation, and keep your code simple and well-designed. If you have questions or want feedback, maintainers are active in issue and PR discussions. Recent PRs (like #34322) show that new deck.gl chart features are contributed by updating frontend React components and layer implementations in superset-frontend/plugins/legacy-preset-chart-deckgl.

Let the maintainers know in your PR that it’s linked to your feature request—they’ll help guide the review process.

To reply, just mention @dosu.

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

Comment From: rusackas

We would definitely welcome such a feature! Happy to review a PR.

In terms of this issue, we can close it out (not a bug) or move it to an "Ideas" discussion here on the repo if you want to keep the conversation going.

Hit me up here or on Superset Slack if you need help with the PR process once you've got the code going, and/or ping me on the PR!

There's also the new CartoDiagram viz plugin, which you're welcome to try if adding pie charts (or whatever) on map points solves part of your use case.

Comment From: SupersetOdT

Hello fin-gal,

I've never been able to display text from points via the "deck.gl Geojson" chart. I spent a lot of time on it, believing it was possible, even though this feature was announced as possible in Superset ("Select a visualization type > Map > deck.gl Geojson") and in the deck.gl documentation (https://deck.gl/docs/api-reference/layers/geojson-layer). It would be great if you could update the code and if this fork could be integrated into the next version of Superset.

Mapbox basemaps sometimes lack certain crucial information for my maps. This feature could solve this problem.

Comment From: fin-gal

Perfect. thanks for the feedback to both of you! I'll definitely reach out if I need help. I'll give this a try next week then, excited to work on a first PR.

Comment From: JoshuaJADaniel

Hey @fin-gal, are you currently working on this issue? I might be interested in taking a look at this.

Comment From: fin-gal

@JoshuaJADaniel I haven't had a chance to try this out yet and if I do it would only be in 2 weeks at earliest and 6 weeks at latest, so if you want to go ahead earlier than me, feel free to do it!

Comment From: JoshuaJADaniel

@fin-gal Great, thank you for the quick reply! I'll go ahead and pick this up. I'll post any progress or questions here.

Comment From: JoshuaJADaniel

@rusackas @fin-gal @SupersetOdT, just wanted to get your thoughts on how this feature should be implemented.

To support text points, we could add a checkbox that enables labels. Once enabled, the user can enter the property key/name from the GeoJSON properties object to source the text from. Graphically, it would look like this:

While this would be sufficient to support text points, there are several other interesting settings available in deck.gl's documentation: https://deck.gl/docs/api-reference/layers/geojson-layer#pointtype-options-2. Which of these additional text settings (if any) should we expose to the user? Furthermore, should these additional text settings be customizable globally or per point?

As for supporting icons, we can pass icons to deck.gl as an icon map or an image URL + height + width (source). I am leaning towards the image URL route as that would probably be simpler for users to configure and understand. Anyway, should the icon itself be customizable globally or per point?

Comment From: fin-gal

@JoshuaJADaniel To me the label option and property name seems great.

For the properties, here I'm not an expert nor do i have extensive knowledge of the superset code base and conventions but I see a few approaches:

We expose them to the user through checkboxes, buttons, etc... As is done for the line settings: filled, stroked, width, etc... I assume this method by default would apply these settings to all points globally, I can't think of an easy way to assign them to specific points through the UI?
Or they get taken in programmatically, here is where it gets more blurry for me:
One way could be to take in some kind of JSON from the user, I think this is not very standard in superset?
Or we get the properties from the user's data. For example, there's this Extra data for JS field in the Advanced part that allows to add columns. The sharedDeckGL component seems to pick these columns up and store them as jsColumns. The spatial utils component seems to take these and add them to extraprops. These extraProps then seem to be made available to the features of the geojson and used for tooltips? Maybe I'm misunderstanding the code though, I didn't have a very detailed look at all of this. A similar mechanism could be used to customise the features styling directly from the user's data, and this would also allow per-point customisation. but maybe this is overkill?

In any case, there are definitely some properties for the text that I think are very interesting in a general way:

getTextColor
getTextSize
gettextAnchor
getTextBackgroundColor
textFontFamily

For the icons, here I'm not sure at all, so I don't have much feedback.

Comment From: JoshuaJADaniel

@fin-gal

We expose them to the user through checkboxes, buttons, etc... As is done for the line settings: filled, stroked, width, etc... I assume this method by default would apply these settings to all points globally

Correct, that's how we would implement it if we wanted the text settings to be applied globally.

I can't think of an easy way to assign them to specific points through the UI?

Agreed, doing per-point customizations through the UI would be clunky and/or inflexible.

One way could be to take in some kind of JSON from the user

I was thinking of something similar too. Specifically, what do you think about allowing customization to happen through the GeoJSON properties object itself? For example, the properties object could look something like this:

{
  "type": "Feature",
  "geometry": {
    "type": "Point",
    "coordinates": [-92.0060, 42.7128]
  },
  "properties": {
    "name": "New York City",
    "labelSize": 24,
    "labelColor": "#ff0000" // We could also let this be [r, g, b, a] for flexibility
  }
}

My thinking is that the user would anyway be providing the label text through the properties object, so if they want to (optionally) customize the labels, they can just add the extra properties to do so. This would be simple and flexible.

Or we get the properties from the user's data [...] A similar mechanism could be used to customise the features styling directly from the user's data, and this would also allow per-point customisation. but maybe this is overkill?

I did not think of this, but it could be a possibility as you said.

For the icons, here I'm not sure at all, so I don't have much feedback.

I guess if there's no strong inclination to let icons be customized globally versus per point, we could just make it per point to cover all the use cases. It could mirror the (proposed) label customization flow (i.e., "Enable Icons" checkbox on the UI and the actual icon image URLs + customizations are provided via the properties object).

Comment From: fin-gal

@JoshuaJADaniel

Having the customisation done through the geoJSON properties object itself seems very nice to me. It allows the user the customise any property, do per-point customisation and also construct the geoJSON using data stored elsewhere, so sounds ideal to me. Sounds good for the icons also, seems like a reasonable approach.

Comment From: SupersetOdT

Hello,

Sorry to intervene so late. Happy to read you and see that the work has already started.

I agree with you on the idea that the label to be displayed at the position of the point should be chosen from the "properties" fields integrated into the geojson (geojson converts to text format to be able to be read by Superset).

Regarding the customization of the text display, you distinguish 2 possibilities if I understand correctly:

1) Either display all the labels in the same way on the map. In this case, the easiest for the user is to directly choose the color, size, transparency, background-color, padding, boder, border-radius... via several boxes appearing in the Superset graphical interface or a single JS code box (as is currently the case with Tooltips) or in another way... Simple, fast and efficient.

2) Either display each label in a personalized way : the size, the color... of the text can vary depending on the parameters of each point that appears in the GEOJSON in the database. Attention in this case that the display settings in Superset are often made by trial and error. If we simply want to darken the color a bit, will we have to make a query in the database each time? It will increase the display adjustment work. Moreover, if we simply want to display all the labels in the same way (which is often the case), it complicates the preparation and adjustment of the display. If one wishes to have several types of text, is it not preferable to create several Deck.gl Geojson and then assemble them via Deck.gl Multiple Layers?

Regarding the icons, the url is indeed the simplest way.

Comment From: JoshuaJADaniel

@SupersetOdT

Yes, you are understanding correctly — it's a question of global vs per-point customizations.

via several boxes appearing in the Superset graphical interface or a single JS code box

I did not want to add too much clutter to the UI, but using a single JS code box is a great idea to avoid that.

Attention in this case that the display settings in Superset are often made by trial and error. If we simply want to darken the color a bit, will we have to make a query in the database each time?

This is a great point too, as I can imagine it would be tedious to update/requery the dataset for small, global customizations. For per-point customizations though, I feel it would be unavoidable since it makes sense to source the per-point customizations from the properties object (which would necessitate updating/requerying the dataset).

If one wishes to have several types of text, is it not preferable to create several Deck.gl Geojson and then assemble them via Deck.gl Multiple Layers?

Had some time to play around with it, and yes, this could work if the user has a few types of text as you said.

Okay, so your suggestion about JS code box interested me, because I believe it can solve both global and per-point customization requirements cleanly. Specifically, if we add a JS code box, the user could provide both global and per-point customizations as such:

For global customizations, it would solve the issue you mentioned by allowing you to make changes without updating/requerying the dataset. Moreover, the user can do per-point customizations by grabbing properties from the properties object as needed. The only potential downsides I see are:

The user might not have the JS control feature enabled.
The user might not be comfortable with JS code.
The user might not want to read the deck.gl documentation.

To address this, we could add a few basic controls to the UI that covers the basic use cases, and we let the JS code box act as a sort of "escape hatch" for more complicated use cases. What do you think of this idea?

Comment From: SupersetOdT

@JoshuaJADaniel

It’s true that the JS code area can perfectly meet the customization requirements by point: we could also have a 'label_type' property in the geojson in which we would find values 'river', 'municipality', 'motorway'... and for each of these values, we would assign CSS/html tags in JavaScript. For example, with "municipality":

<div style=" background-color: white; color: #666; padding: 10px; border-radius: 8px; border: 1px solid #ddd; margin: -10px; "> <b><span style="color: #333;">${municipality}</span></b><br> </div>

"To address this, we could add a few basic controls to the UI that covers the basic use cases, and we let the JS code box act as a sort of "escape hatch" for more complicated use cases. What do you think of this idea?"

Your idea is really excellent and satisfies both low-code users and those who wish to customize a more advanced display.

(Note that for the tooltips, Superset offers a 2nd field titled "Extra data for JS" which allows the tooltips to display values from any field in the table (not just the properties integrated into the geojson).)