CartoDB / carto-vl

CARTO VL: a Javascript library to create vector-based visualizations
BSD 3-Clause "New" or "Revised" License
129 stars 26 forks source link

getRenderedCentroid doesn't always render element in the proper place #1327

Open ztephm opened 5 years ago

ztephm commented 5 years ago

This is from an Enterprise client via Support. We thought it was better handled here, but let us know if this should be for Response Team instead.

Context

Semcog is using our getRenderedCentroid function in a CARTO VL map. They are using it to place Pop-Ups instead of labels, but the issue below also happens with labels. They based their code on this Developer Center example.

The problem is that depending on the polygon shape, it's centroid is not always an appropriate place for a label.

For example, in this case the polygon Warren completely surrounds the polygon Centerline:

Screen Shot 2019-04-05 at 1 13 13 PM

When you zoom/pan to a place where only part of Warren poly is shown in the Map View, and Centerline poly happens to be in the center of the Map View, Warren Pop-Up opens over the Centerline polygon & Warren label is located there also:

centroid_popup

Steps to Reproduce

  1. Open this example from client and pan so the Centerline polygon is in the center of Map View: test_getCentroid.zip
  2. Click on the Warren polygon.

Current Result

Warren label and Pop-Up appear over the Centerline polygon, as shown in gif above.

Expected result

Warren label & Pop-Up won't appear over Centerline polygon.

Browser and version

Google Chrome Version 73.0.3683.86 (Official Build) (64-bit)

Additional info

If the client tries to get center coordinates by using something like ST_Centroid or ST_PointOnSurface for the entire selected polygon, that doesn't take into account that the resulting center coordinate can be outside of the Map View.

VictorVelarde commented 5 years ago

The getRenderedCentroid is calculated in the client side, for each fragment of the geometry (maybe shared between different tiles). Then, a common ‘centroid’ for the whole feature is calculated ponderating each piece by its size. And that gives us as a result an "approximate centroid of the current visible part of the polygon".

We can not guarantee that this centroid is on the surface of the polygon (in this issue, the centroid is in the hole of the polygon, but that is indeed its centroid) . What you are talking about would probably require another different function, but I have serious concerns about that being a valid approach in terms of performance (the current function is already very heavy).

So I'm removing the 'Bug' label and assigning it a 'Feature request' one.