Tracking missing (data driven) images

[jliebrand]

Hi there,

We use data driven properties for some of the symbols on our charts. In particular, we combine a number of data properties to produce the name of the image that should be shown for the image.

eg:

  "icon-image": "{TYPE}-{COLOR}-{PATTERN}",

However recently we realised we do not have images in our sprite collection for every possible single combination of these. In the end we might not need every combination, and indeed want to prioritise the missing ones based on which our end users come across the most. I appreciate this is a very specific use case, but my question is a little more generic:

When using dynamic data driven styles, there's always the risk that a certain combination leads to an image that doesn't exist in our sprite collection. I had actually half expected mapboxgl to throw an error, and we do have a listener for errors (eg map.on('error', ...)) but it doesn't fire if an specific requested symbol doesn't exist.

Is there a way to spot these cases? where a requested image is missing (and thus resulting in a bad map for our users)? We'd like to be able to track if/when this happens so that we can log a client side error and track down which combinations most of our users are coming across...

[ryanhamley]

#6831 includes a console warning if an image that doesn't exist in the sprite sheet is requested. I'm not sure that we'd necessarily want to fire an event or error in that situation though because it could break otherwise valid styles and prevent further map rendering. That makes it harder to track when an image not in the sprite sheet is requested though.

[jliebrand]

@ryanhamley that's a great addition - maybe it would be good to fire a new "warning" event? That way it doesn't break anything, but still allows an app to track the occurrences for their customers?

[ryanhamley]

There's a larger issue opened around this feature request in #7587 so I'm going to close this to focus discussion there, if you'd like to follow along @jliebrand

[ryanhamley]

This issue has been resolved with #7987