Stops loading slowly

[gy-mate]

Problem

1. I open the app while having a wifi or 5G mobile network connection
2. The loading process of stops begins
3. They only load after 30+ seconds

Which app version do you use?

0.8.2+21

What operating system do you use?

iOS

What operating system version do you use?

17.6.1

Additional information

#288 (comment)

[Robbendebiene]

Just copying over some context from the previous issue:

The magnifier indicates that nearby stops (just their locations and names) are being queried. This can take longer in bigger cities due to the amount of data the overpass server has to process (not because a lot of data is transmitted). Admittedly this is not ideal and is mainly introduced by #262 We could think about caching loaded stops (not the actual elements). Maybe the underlying overpass query could also be improved (ideally overpass would have something like DBSCAN).

Some Ideas for possible solutions:

• Cache loaded stops (initial loading would still be slow)
• Switch to previous method were stops where clustered on the device (main drawback is higher bandwidth see Improve stop area generation #262)
• Improve Overpass query performance (main slowdown is caused by clustering, unclear if it can be improved)
• Rethink working principle 1: Since the stops and their size is something that rarely changes we could pre-create them e.g. per country and provide them to OpenStop
• Rethink working principle 2: Stop preloading any stops/stop areas - there could be a button to load the actual data of stops nearby (drawback, requires additional user interaction which we would like to avoid)
• Shrink the stop area pre-loading "window" (bbox) - this means loading smaller grid cells which individually should load faster but will lead to poorer stop clustering.

[gy-mate]

• Shrink the stop area pre-loading "window" (bbox) - this means loading smaller grid cells which individually should load faster but will lead to poorer stop clustering.

@Robbendebiene I would prefer this solution. Loading only ~one nearby stop (and then waiting for loading the next stop when the map is moved) is much better than waiting for one minute when starting the app.

[Robbendebiene]

@gy-mate It is definitely worth a shot. Unfortunately at the moment my time is limited. I post any updates here.

[Robbendebiene]

Quick update for future me:

There is a performance optimized overpass API fork https://github.com/mmd-osm/Overpass-API. A constructed "worst case" query runs 4 times faster (original: 32s fork: 8s). This would certainly solve our problem.

Try at:

• https://mmd-osm.github.io/overpass-turbo/
• add {{data:overpass,server=//dev.overpass-api.de/api_mmd/109eca93-0273-400b-94f7-c65737e86e8d/}} in overpass turbo at the end of the query script (source)

@mmd-osm I just discovered your performance optimized overpass fork and was stunned by the speed. Is there a chance we can get an API key to use your instance in OpenStop? Would you even recommend using it in a released app? Thanks.

---

Other sources:

• https://community.openstreetmap.org/t/efficient-overpass-query-for-clustering-nearby-elements/118612
• https://wiki.openstreetmap.org/wiki/User:Mmd/Overpass_API_-_experimental_corner

[mmd-osm]

I’m afraid, you can’t use our development server for any sort of productive purposes. There’s a reason why it’s marked as “experimental”.

As the code is not released for general usage, I also cannot recommend to set up an own instance. It’s just prototyping at this point of time, and I don’t have the bandwidth to help people run their own thing.