search

fablabbcn / smartcitizen-web

The Smart Citizen Kit platform
https://smartcitizen.me
GNU Affero General Public License v3.0
13 stars 7 forks source link

Proposals to improve map load #451

Open oscgonfer opened 7 months ago

oscgonfer commented 7 months ago

Let's discuss in this issue how can we improve the map load. There is an ongoing branch by @pral2a working on a range-slider approach, that would limit the range of dates in the devices as a WIP here.

In conversations with @timcowlishaw, we also thought it would help to show only the online devices on page load, which would dramatically reduce the load time. This also would help with the everlasting question of online/offline devices when people visit the map.

What do you think? Comments welcome.

pral2a commented 7 months ago

Maps view

My primary concern is that the actual map no longer aligns with the platform's purpose for the last 5-6 years. The goal of a real-time worldwide sensor network changed in favour of supporting situated sensing experiments by local communities.

With it, one option is to think creatively about a better visualization that is not a map and doesn't require heavy development.

Online vs Offline

The idea of online vs. offline should be treated with care. The purpose of showing so many devices, even offline, is to show the legacy of the community and the impact the project has created. It's not for scientists or tech gurus to look for real-time online data available to use.

Loading time improvements

In my experience, the long loading time was not only connected with the API response time. The client processing time also plays a role on it. It takes a while for Angular to build all the device marker instances and then call Leaflet to load them on the map. It's relevant to note that we make Angular objects before the Leaflet instead of directly creating them on Leaflet as other apps do. That is why my slider approach did request all the devices at once but will only show them all on the map if you choose the slider.

Regarding the response time, I suggest improving RoR or NGINX level caching, a classic.

oscgonfer commented 7 months ago

Maps view

My primary concern is that the actual map no longer aligns with the platform's purpose for the last 5-6 years. The goal of a real-time worldwide sensor network changed in favour of supporting situated sensing experiments by local communities.

With it, one option is to think creatively about a better visualization that is not a map and doesn't require heavy development.

As we have quite a large list of changes, I would say we can leave this for after March.

Online vs Offline

The idea of online vs. offline should be treated with care. The purpose of showing so many devices, even offline, is to show the legacy of the community and the impact the project has created. It's not for scientists or tech gurus to look for real-time online data available to use.

Sure, totally agree on that. However, as the number of points is growing, a way of filtering as the first load would be beneficial, and doesn't necessarily remove the legacy, it simply doesn't make the points in the map. Similar reasoning would apply to older devices, versus those that are newer (which would be the filtering done by the range slider).

Loading time improvements

In my experience, the long loading time was not only connected with the API response time. The client processing time also plays a role on it. It takes a while for Angular to build all the device marker instances and then call Leaflet to load them on the map. It's relevant to note that we make Angular objects before the Leaflet instead of directly creating them on Leaflet as other apps do. That is why my slider approach did request all the devices at once but will only show them all on the map if you choose the slider.

I want to think it's a mix, maybe I am mistaken. Part of the problem could come from the request itselfhttps://github.com/fablabbcn/smartcitizen-web/issues/431#issue-907298001 And then part of it after.

Maybe a small assessment of the page load bottlenecks will help us.

Regarding the response time, I suggest improving RoR or NGINX level caching, a classic.

@timcowlishaw ?