Optimizing for speed / It's loading forever

[amenk]

Actually the page is loading forver, I think it's because there are lots of overpass queries and also I run into API limits on overpass-api.de

Anyways, it's an interesting project and it would be sad to see it unusable.

In thought I had:
In our usecase we want to display a PTmap only for one city. As the data does not change so often, once all is in, we might case Overpass POST requests.

For other use cases maybe queries can be merged together to one bigger query? Unfortunately I have not much experience with Overpass QL ...

What do you think?

[plepe]

Hi!

Since publishing ptmap, the overpass-frontend module (which is responsible for communication with Overpass API) improved significantly, it can even load .osm (or .osm.bz2 or osm json) files directly and use them as source. I will test, if everything works and provide instructions.

[amenk]

Do you have in mind to load the full .osm file into the browser? (I guess then we need to prefilter it somehow, so it stays small enough) Or running overpass-frontend on a nodeJS server and then query that from the browser?

[plepe]

The idea is to load a .osm file into the browser which only contains the data you need. I'll provide some examples how to download the data from Overpass API. I already tried it yesterday, it works pretty fine - if the data is not too large.

An option could be to split the .osm file into tiles (similar to vector tiles) and load these on request (we would also need a way to load objects by ID, maybe an additional index file). I could implement this into the overpass-frontend library, but I would endorse sponsorship :-)

The alternative would be to run a dedicated Overpass API server on your infrastructure - the vector tiles option might be even faster though.

[plepe]

I just provided information how to use an offline .osm file to the README. Hope this is useful. I tested variants: .osm, .osm.bz2 and .osm.json files. The fastest is .osm.json, so I would recommend these. .osm.bz2 takes a long time to load (the decompression is not very efficient).

One more thing - if you zoom out, dragging the map becomes slow. The problem is the leaflet-textpath library, because it uses text on svg paths. And these are really slowing everything down, when there are many lines with text attached. You can see the difference by commenting out all .setText statements in src/SharedRouteWay.js.

Hope to hear from your progress!

[amenk]

Works pretty well. Thank you. No tiling needed I guess. The current file for Addis Ababa is 42KB (while it's not yet completely mapped) You are right with the setText statements. How can we optimize that? maybe displaying less instances of the text? Currently the routes are also pretty crowded with those labels.

[amenk]

Somehow I does not seem to have the stops for bus lines:

https://lp.addismap.com/ptmap/#lat=9.01462&lon=38.77328&q=r10410197&zoom=15

Actually only the platforms are in the relations.

Seems I have to optimize the Query (and learn Overpass GL at first g)

For the record, this is what I am currently using

[out:json][bbox:{{bbox}}];
relation[route~"^(tram|bus|trolleybus|subway|ferry|train|light_rail)$"]->.routes;
.routes out;
way(r.routes)({{bbox}})->.ways;
.ways out skel;
node(r.routes)->.stops;
.stops out;
node(w.ways)->.geometry;
(.geometry; - .stops;);
out skel;

[amenk]

The Overpass query does not seem to be the reason.

{
  "type": "relation",
  "id": 10410197,
  "members": [
    {
      "type": "node",
      "ref": 7057187393,
      "role": "platform"
    },
    {
      "type": "node",
      "ref": 7037142426,
      "role": "platform"
    },
    {
      "type": "node",
      "ref": 7037142423,
      "role": "platform"
    },

...

{
  "type": "node",
  "id": 7057187393,
  "lat": 8.9903142,
  "lon": 38.7932003,
  "tags": {
    "bus": "yes",
    "highway": "bus_stop",
    "name": "Brass Clinic (Bole)",
    "network": "Addis Ababa Public Transport",
    "operator": "Anbessa City Bus;Sheger City Bus",
    "public_transport": "platform",
    "ref:AB": "AB009"
  }

[amenk]

This would work ...

diff --git a/src/Route.js b/src/Route.js
index 1f36756..0067f75 100644
--- a/src/Route.js
+++ b/src/Route.js
@@ -576,7 +576,7 @@ Route.prototype._initStops = function () {
   for (i = 0; i < this.object.members.length; i++) {
     var member = this.object.members[i]
 
-    if (member.type === 'node' && member.role === 'stop') {
+    if (member.type === 'node' && member.role === 'stop' || member.role === 'platform') {
       if (member.id in this._stopsIndex) {
	 this._stopsIndex[member.id].push(this._stops.length)
       } else {

[plepe]

Good to hear that the solution with the .osm.json file works for you.

About the platforms - yes, we could do that, but then I have to check, that not stop and platform appear in the route listing, but that they are merged (by name).

About setText() - I could think about solutions:

• do not show text on ways, that are short in pixels in the current zoom level
• merge ways with the same label into one
• use an alternative leaflet plugin, e.g. https://github.com/triedeti/Leaflet.streetlabels

Btw, one of the ideas I had, were multi-colored labels (e.g. for route colors). I made a pull request for leaflet-textpath, but I realized that there are browser support issues and so I didn't continue developing (also I suppose, that performance is even worse).

Keep me updated about the state of your ptmap!

PS: if you want to integrate additional overlays (e.g. ticket vending machines, taxi stands), you could use my overpass-layer module which also uses overpass-frontend.

[amenk]

Thanks. I think this can be closed, as the loading problem is solved.