How do I use mapbox.selectPoint()?

Feature Requests
1

The docs say the sole parameter for .selectPoint() is a point object. What is a point object?

I tried duplicating the points array which is the default data input for a mapbox:

{latitude: {{self.selectedRow.data.lat}},  longitude: {{self.selectedRow.data.lng}}
}

I tried making it an array:

[{latitude: {{self.selectedRow.data.lat}},  longitude: {{self.selectedRow.data.lng}}
}]

I tried geoJson which appears to be the Point definition per the MapBox docs:

{
   "type": "Point",
   "coordinates": [{{self.selectedRow.data.lng}}  {{self.selectedRow.data.lat}}]
 }

I calling this from the Control Component Action of a Row Select trigger on a table.

Am I missing something or did I do something dumb?

2

Hi @bradleymathews

You first example is working on my side:

3506×1030 359 KB

Maybe try wrapping the whole input in {{}} instead of each selectedRow input?

3

@Tess,

Ok I think I found a bug.

You confirmed that first method of making the object is the right one and both of our techniques of making it ({{ }} around each value or {{ }} around the whole thing) work.

In my dataset they are "lat" and "lng" and I have the MapBox's Latitude field name and Longitude field name properties set to those and the map points display fine.

But the object passed to .selectPoint() ONLY works with "latitude" and "longitude". I tested this by aliasing my columns to latitude/longitude and it started working.

4

@bradlymathews

Thank you for pointing this out! I believe this is expected behavior. MapBox is expecting 'latitude' and 'longitude' specifically and in the UI we map those correctly no matter what you call them in your dataset -- but if you are manually filling out the parameters for that function then you need to adhere to their API.

5

Got it.

Might I suggest a warning on the Latitude and Longitude field name properties that one should only use the standard field names wherever possible to avoid possible conflicts with the MapBox library? I would have suggested removing the properties and enforcing standard field names, but that would be a breaking change at this point so best not go that far.

6

@bradlymathews

Great suggestion! I will move this over to feature requests :slightly_smiling_face: