Mapbox-gl-js: possible rendering issue with upcoming core style updates

[natslaughter]

While staging the updated v9 and new v10 core map styles in api-styles, there appeared to be a rendering issue for road data with a geometry type filter point.

With the level_crossing and turning_circle classes, some points were receiving a name label, and some were not. Those that received a label were rendered with the desired icon, and those without a label had no icon.

It seemed that a potential reason why some points received a label and others did not was proximity to other, similar points. Clusters of these points received no labels whereas the lone point did.

@ajashton and @ian29 will be able to speak more accurately and effectively to the details, but the cartography team was hoping this issue could be resolved for the next gl-js release. In two of our new styles - outdoors-v10 and streets-v10 - there is a new level_crossing, and it would be great to see all of them if possible.

cc @xrwang

[ajashton]

The problem comes up when there are multiple points of the same type and class in one tile (including the buffer area). To keep tile sizes compact, the queries for most layers in Mapbox Streets include a ST_Collect that groups together any geometries that have identical data properties (name, type, class, etc).

[mollymerp]

I'm not sure if I fully understand the issue here. Was rendering unexpected only in the studio x-ray view? Did you try turning on the debug mode to see if your labels were getting removed due to collisions?

@natslaughter

[ajashton]

In the screenshot above there is no difference between the points that have labels and the ones that do not, so they should all look the same in the x-ray view. But (more importantly) this is an issue in the main styling view as well - symbol styles (either icons or text) never appear for "multipoint"* objects. Styling them as a circle works, however.

* I have been told our vector tiles do not encode "multipoints", but they do allow "multiple points as a single row / object" and I'm not sure what else to call that.

[jfirebaugh]

@natslaughter @ajashton Is this still a relevant issue?

[xrwang]

[jfirebaugh]

Turns out this was fixed in #3763.