Query tool: hovering over relations sometimes unresponsive

[mmd-osm]

Testcase: http://www.openstreetmap.org/query?lat=43.5370&lon=-6.4806#map=13/43.5298/-6.4386

Issue: I'm hovering over the different elements on the left. While ways are updated immediately on the map, hovering over the different relations a couple of times takes 5-30s each here. During that time, the UI appears somewhat sluggish, not to say frozen.

I realize that those relations are quite long, yet the Overpass API result returns an empty / null geometry for most part of the relation. What I find a bit puzzling is that overpass turbo renders the query results more or less instantaneously: http://overpass-turbo.eu/s/qPT

Tested on Firefox 54.0 and Chrome 51, Ubuntu 16.04. + Win10

[mmd-osm]

Further checking in Chrome, it looks like we have to process several thousand (!) layers for the relations in question. Most of these layers seem pretty empty, i.e. I think it is fairly obvious that this is not the best thing to do.

Could it be, that the large number of JSON fragments returned by Overpass API as shown below trick the application into creating all those useless layers?

    {
      "type": "way",
      "ref": 7660203,
      "role": "",
      "geometry": [
      ]
    },

That's how most of the layers look like:

[mmd-osm]

Suggested fix:

diff --git a/app/assets/javascripts/index/query.js b/app/assets/javascripts/index/query.js
index 018aedf..7ac613d 100644
--- a/app/assets/javascripts/index/query.js
+++ b/app/assets/javascripts/index/query.js
@@ -146,7 +146,7 @@ OSM.Query = function(map) {
 
     if (feature.type === "node" && feature.lat && feature.lon) {
       geometry = L.circleMarker([feature.lat, feature.lon], featureStyle);
-    } else if (feature.type === "way" && feature.geometry) {
+    } else if (feature.type === "way" && feature.geometry && feature.geometry.length > 0) {
       geometry = L.polyline(feature.geometry.filter(function (point) {
         return point !== null;
       }).map(function (point) {

[mmd-osm]

Thanks for the quick merge. I just figured out that normal ways now don't show up anymore for the following test case: http://www.openstreetmap.org/query?lat=43.4602&lon=-6.4156#map=15/43.4602/-6.4156

Investigating further...

The overpass response doesn't include any geometry, so that's really a different issue now, which has nothing to do with the patch. After all, this looks like an Overpass API regression. It doesn't return geometry for ways anymore, if the ways are not fully contained in a bbox. I'll open a separate issue for that.

{
  "type": "way",
  "id": 193407337,
  "bounds": {
    "minlat": 43.4554455,
    "minlon": -6.4191086,
    "maxlat": 43.4624413,
    "maxlon": -6.4139779
  },
  "tags": {
    "highway": "tertiary",
    "name": "Pontigón-Tineo",
    "ref": "AS-359"
  }
}

[tomhughes]

If you mean http://www.openstreetmap.org/way/193407337 then that seems to be being returned from overpass without a geometry.

[mmd-osm]

Yes, right. That somehow changed in the most recent version. On the French instance, you still get a partial geometry as before, overpass-api.de and Rambler (both on the most recent version) behave differently and don't return any geometry at all.

Test case:
[timeout:10][out:json];way(193407337);
out geom(43.44416399866694,-6.424341201782227,43.458401741026194,-6.399600505828857);

[mmd-osm]

fyi: I added a fix to my Overpass dev instance, which seems to work. See the following instructions on how to use a different Overpass instance in Chrome for testing: https://github.com/mmd-osm/Overpass-API/wiki/Switching-to-a-test-Overpass-API-instance

Now, we just have to wait till Roland merges the patch and rolls it out to the official instance.

Edit: May 2018: fix was deployed as part of 0.7.55 release now.