Kepler.gl scripting

[pdehaye]

Kepler.gl is a library we could use to view geographic data. It has a nice scripting setup whereby you can define data sources and then visual layers on top. This would allow more easy building of standard visualizations of the data. I have met two drivers who have sufficient skills that they could look at their data, build the visual layers and then export the configuration to benefit users. As a consequence I think a possible way of rapidly creating hestialabs experience could be to have pre-configured Kepler.gl layers, with data TBD upon upload.

[valentinoli]

@fquellec in Signal

I [...] checked for the addition of kepler in our application, and apparently they don't plan to integrate it with Vuejs, there are still ways to do it but I'm not sure of the best way to implement it... https://github.com/keplergl/kepler.gl/issues/1380

[valentinoli]

We can maybe try this here https://github.com/akxcv/vuera

[andreaskundig]

Vuera would have been the way to go, but the project is not very active and looking for a maintainer...

[andreaskundig]

I'm going to try including it in a iframe in order to completely avoid any compatibility layer between vue and react

[andreaskundig]

Copied from signal

@andreaskundig I'm looking at how to integrate kepler.gl in experiences. It's built on mapbox, a commercial product which a big free tier and not too expensive afterwards. To use it we need a token from them, and they will be collecting some data on where the requests come from.

Here's their privacy policy: https://www.mapbox.com/legal/privacy/

We'll be using an API, not a mobile SDK. Here's what they have to say about what they collect and for what purpose:

APIs and SDKs: We automatically collect certain technical information through our APIs and SDKs, including (a) IP address, (b) device and browser information, (c) operating system, (d) the content of the request, (e) the date and time of the request, (f) limited usage data, and (g) for our mobile SDKs, limited location data. We delete IP addresses after 30 days. In addition, when a mobile application uses our SDKs, it may send us certain limited location and usage data along with an ephemeral ID. This ephemeral ID changes hourly and we do not associate it or the unprocessed mobile location data with any personally identifying information, including names, permanent IDs, email addresses, IP addresses, or phone numbers. We also collect randomly-generated IDs for the limited purpose of analyzing the use of our APIs and SDKs, including the number of active users. We will delete the randomly generated IDs and the content of requests made to our APIs after 5 years.‍

APIs and SDKs: We use the data collected through our APIs and SDKs (1) for internal diagnostic and analytic purposes (2) to improve our mapping products and services (3) to provide our Services to end users of our customers and (4) to generate aggregated and anonymized usage statistics. We have a legitimate interest in improving our Services and certain data collection is necessary in order to provide the Services. You can find more information specifically about how we secure and use location data on our telemetry page.‍

Is that OK?

@pdehaye I see little chance we would not use kepler/mapbox but it would be good if you could tell me how much an equivalent access would cost via swisstopo or similar

@andreaskundig I don't find any pricing information on swisstopo, could it be that it's all free?

We can't use swisstopo in kepler.gl, or any other provider. Kepler.gl is build on a js graphics library made by mapbox. At first glance it seems the big advantage is that it allows much more customization of the maps than just using tiles from a provider like swisstopo.

The alternative to kepler/mapbox would be to use leaflet with providers like swisstopo or open street maps, or draw maps with d3. This would all be free, but most of what kepler brings we would have to code ourselves. This is approximately what François said this morning, ask him if you want more details.

[streitl]

Kepler.gl integration has been added in #214, but we still need to make sure that the data is being passed correctly, and we need to make the map appear nicely on the app.