Object query hits javascript error TypeError: t.bounds is undefined

[mmd-osm]

For full details and some background infos, please refer to this post: https://help.openstreetmap.org/questions/48088/what-makes-a-closed-way-show-up-as-an-enclosing-feature-with-query-features
That's where the issue was initially reported.

How to reproduce:

• See http://www.openstreetmap.org/query?lat=39.6181&lon=-74.5019#map=15/39.6176/-74.4857

Issues:

• Although there are several enclosing features, none of them are shown.
• Javascript console shows the following error message: TypeError: t.bounds is undefined

Further analysis:

Upon calling the query feature above, the following Overpass API is getting executed in background:

[timeout:5][out:json];is_in(39.6163,-74.5054)->.a;way(pivot.a);
out tags geom(39.59927344095099,-74.5391035079956,39.633324269501465,-74.4717264175415);relation(pivot.a);out tags bb;

Overpass result:

  "type": "way",
  "id": 33832747,
  "geometry": [
...

    null,
    null,
    null,
    null
  ],
  "tags": {
    "area": "yes",
    "boundary": "national_park",
    "name": "Pinelands National Reserve"
  }
},

To display a list of enclosing features on the UI, they're initially sorted by their respective size. This is implemented in the following piece of Javascript code. Due to the missing bounds element in the Overpass API result for way 3383274, we hit a Javascript error.

    function i(t, e) {
        var n = t.bounds.maxlon - t.bounds.minlon
          , o = t.bounds.maxlat - t.bounds.minlat
          , a = n * o
          , r = e.bounds.maxlat - e.bounds.minlat
          , i = e.bounds.maxlat - e.bounds.minlat
          , s = r * i;
        return a - s
    }

[tomhughes]

Surely when looking for enclosing objects it's entirely normal for none of the nodes to be in the visible area?

Certainly we wouldn't want to filter out those results, just not try and draw the bbox or something.

[mmd-osm]

enclosing objects it's entirely normal for none of the nodes to be in the visible area?

Yes, http://www.openstreetmap.org/way/33832747 is pretty huge, and if you're on zoomlevel 15, it just happens, that you're inside the area, but none of the nodes are in the bbox provided in the Overpass query. That's pretty much what geom(39.59927344095099,-74.5391035079956,39.633324269501465,-74.4717264175415) is good for.

[tomhughes]

Well exactly - every time I click somewhere in London the "England" polygon will doubtless enclose it but without any nodes being in the bbox so why do we not see this all the time?

[mmd-osm]

Well, the overpass query only restricts the ways' output via geom(...). Relations are returned as is. I guess in case of the "England" polygon, we're dealing with a relation, so that's really a different case.

Conditions for this issue to occur seem to be:

• the area needs to originate from a way in the first place
• the area covered by the way has to be pretty large, so that none of its nodes are included in the current screen's bbox

Edit: I did a cross check using the following queries:

[timeout:5][out:json];is_in(39.6163,-74.5054)->.a;way(pivot.a);
out tags geom(39,-76,41,-74);relation(pivot.a);out tags bb;

(bbox was set large enough for way 33832747 to fit in)

[timeout:5][out:json];is_in(39.6163,-74.5054)->.a;way(pivot.a);
out tags geom;relation(pivot.a);out tags bb;

Result:

  "type": "way",
  "id": 33832747,
  "bounds": {
    "minlat": 39.1919712,
    "minlon": -75.0191372,
    "maxlat": 40.1129889,
    "maxlon": -74.2086371
  },
  "geometry": [
    { "lat": 40.0391822, "lon": -74.5949842 },
    { "lat": 40.0431057, "lon": -74.5863072 },
    { "lat": 40.0477885, "lon": -74.5896906 },
    { "lat": 40.0471321, "lon": -74.5920778 },

I would assume, as long as there's some geometry available there will be also a bounds element. Only in case all of way's nodes are completely outside of our specified bbox, we will get null geometry elements all over the place. In addition, there's no bounds element returned back from Overpass API. That missing bounds element is exactly the reason why the UI fails with a Javascript error.

[ljb279]

Would it be OK if I try to 'fix' the specific case mentioned above on the map? (I am the one who started the question on help.openstreetmap.org referenced above.)

What I want to do is create a new multipolygon relation with one role=outer member - way 33832747, move the name and boundary tags from that way to the new relation, and remove area=yes from the way. If I understand the above, that should allow 'enclosing features' to work within the Pinelands National Reserve.

I understand this could make it harder to fix the underlying cause, so I don't want to do it without approval. But right now this affects a large part of Southern New Jersey where I do mapping.

[ljb279]

Followup: I tried the above change to Way 33832747 on the map but it didn't help with 'enclosing features'. I still get an empty list in the browser, and TypeError. So I undid my change, putting everything back the way it was.

[mmd-osm]

@ljb279 : under normal circumstances, transforming the area from a way to a relation would indeed work around the Javascript error.

However, as the area creation on overpass-api.de lags behind a few weeks (see status page: no area updates since 2016-02-11), your changes were not reflected on Overpass API at any time - the query was still using the old areas, hence returning way 33832747 without bounds element as before.

[tomhughes]

So the root problem is that, for enclosing features defined by a way, we ask overpass for a geometry clipped to the current view:

out tags geom(....)

Now normally that returns a bounding box as well as the clipped geometry, and I assumed that was the full bounding box, but it turns out it is the bounding box of the clipped geometry.

That causes two problem - firstly this exception if the geometry is completely clipped away so that there is nothing left and hence no bounding box and secondly it means we are sorting features incorrectly because we use the bounding boxes to sort them by size.

[mmd-osm]

At least in the documentation I could not find an explicit hint how bounds should behave in the context of out geom(...):

The attribute "geom" can be followed by a bounding box in the format "(south,west,north,east)". In this case only coordinates that are inside the bounding box are produced. For way segments also the first coordinate outside the bounding box is produced to allow for properly formed segments.

I assume that only those nodes which are produced by out geom(...) would also count towards the bounds element.

@drolbr : Roland, can you please comment on this one? Am I missing something here or is this all works as designed?

Maybe adding another out bb ids; would be an option to produce a full bounding box without repeating all data again:

[timeout:5][out:json];is_in(39.6163,-74.5054)->.a;way(pivot.a);
out tags geom(39.59927344095099,-74.5391035079956,39.633324269501465,-74.4717264175415);
out bb ids;relation(pivot.a);out tags bb;

This returns an additional way with id and unclipped bounds details and should be usable for sorting purposes.

{
  "type": "way",
  "id": 33832747,
  "bounds": {
    "minlat": 39.1919712,
    "minlon": -75.0191372,
    "maxlat": 40.1129889,
    "maxlon": -74.2086371
  }

Of course there's also the option to have ways behave like relations via out bb tags;

[tomhughes]

Yes doing separate outputs for bounds and geom works, but then it needs to be merged client side. I'm trying to make that work at the moment...

[mmd-osm]

Thanks for the quick fix! I didn't look at the code in detail, but I assume it also handles multiple, possibly contradicting bounds elements, like in the following example:

  [timeout:5][out:json];is_in(39.6163,-74.5054)->.a;way(pivot.a);
out tags bb;out ids geom(39.2,-74.5,41,-74);relation(pivot.a);out tags bb;

{
  "type": "way",
  "id": 33832747,
  "bounds": {
    "minlat": 39.1919712,
    "minlon": -75.0191372,
    "maxlat": 40.1129889,
    "maxlon": -74.2086371
  },
  "tags": {
    "area": "yes",
    "boundary": "national_park",
    "name": "Pinelands National Reserve",
    "website": "http://www.nps.gov/pine/",
    "wikipedia": "en:New Jersey Pinelands National Reserve"
  }
},
{
  "type": "way",
  "id": 33832747,
  "bounds": {
    "minlat": 39.5259208,
    "minlon": -74.5065613,
    "maxlat": 40.1129889,
    "maxlon": -74.2086371
  },
  "geometry": [
    null,

[tomhughes]

Hmm that's a good point...

[tomhughes]

Fixed in 6e154d4.

[mmd-osm]

Thanks, that looks better now!

There's one thing I noticed with the current version on osm.org. Wasn't there some red bbox shown on the map when hovering over each entry in the enclosing feature list? That feature was quite handy to get a rough idea about the actual size of an enclosing feature. For ways, there are still some nodes shown (as long as thery're inside the bbox), for relations, I don't see the red bbox on the map anymore.

Was the feature possibly removed in a different commit or is it some kind of side effect of this issue? Apologies if my memory is playing tricks on me here and that feature never existed in the first place.

[tomhughes]

I think that's only for features where we have a geometry isn't it?

[tomhughes]

Yes - eg http://www.openstreetmap.org/query?lat=51.76596&lon=-0.00648 where the first entry highlights the outline but the others are outside the viewport so don't.

[mmd-osm]

I might be confusing this with overpass turbo. I thought for relations, we also look at the bounds element and show some red bbox on the osm.org map.

Edit: I had this in mind.That was coming from overpass turbo, though:

[tomhughes]

Well relations won't have a geometry, because we only ask for a bounding box there.

[mmd-osm]

yes, sorry. you're right...

I think we can close this topic, I really had overpass turbo in mind. Thanks again for the patience!

[ljb279]

I just want to add that this ("enclosing features" query) is working really well for me now. Thanks for the effort fixing it.