Dense data not displaying even at highest zoom level

[SColchester]

URL

https://www.openstreetmap.org/#map=19/3.133989/43.677309

How to reproduce the issue?

• Dense buildings only show at higher zoom levels, however this example shows where a collection of very densely mapped buildings never shows, the loading wheel in the bottom right just continues to spin

Screenshot(s) or anything else?

Which deployed environments do you see the issue in?

Released version at openstreetmap.org/edit

What version numbers does this issue effect?

No response

Which browsers are you seeing this problem on?

Chrome

[tordans]

The error message in the console is:

https://api.openstreetmap.org/api/0.6/map.json?bbox=43.676147460937514,3.1295462178004865,43.681640625000014,3.1350311752713904

You requested too many nodes (limit is 50000). Either request a smaller area, or use planet.osm

Each of the circular buildings has 20 notes, so this sounds like #8389 would prevent this from happening in the future.

[RAytoun]

I think the problem is
A building multipolygon Baydhabo with 53 membersbuilding has 45,929 nodes
A farmland multipolygon with 49,027 nodes
A place multipolygon Dhur Iyo Qalin with 49,028 nodes
A building multipolygon and buildings with 45,929 nodes

[shiller27]

Interesting to hear that too many nodes can cause problems - in future I won't copy and paste round buildings, but create my own...

However, the same issue with display occurs in tasks with a low density of data - for example task 398 where most buildings are as yet unmapped : a few rectanguar buildings that have been mapped at the bottom of the task only appear in JOSM, not in the iD editor

[RAytoun]

That task square 398 is also affected by two of the multipolygons mentioned above so the loading wheel at the bottom right just keeps spinning.

[bhousel]

This is #1520.
The solution is probably just to detect the error and fetch the 4 child tiles.

[Shyam-123pandey]

I was able to reproduce this issue at the provided location in the iD editor.

The console shows:
“You requested too many nodes (limit is 50000). Either request a smaller area, or use planet.osm.”

From what I understand, this occurs because certain multipolygons in that area contain ~45k–49k nodes, and when combined within a single bbox request, the 50k node API limit is exceeded.

It seems that iD currently does not recover gracefully from this API error, resulting in the loading spinner continuing indefinitely.

Since this was linked to #1520, I’d like to better understand:

• Where in the iD data-loading pipeline the bbox request is handled
• How API errors of this type are currently processed
• Whether tile subdivision (fetching 4 child tiles) is already partially implemented or would need to be introduced

I would be interested in investigating how iD could detect this specific error and retry with smaller bounding boxes means i tried but won't be able to produce this issue , has it fixed in mean time ?

[FaisalMisbah23]

FWIW, the issue doesn’t appear to be fixed in the current codebase.

I checked modules/services/osm.js: map data is loaded via loadFromAPI with /api/0.6/map.json?bbox=..., and there’s no handling for the “You requested too many nodes (limit is 50000)” API response. There’s also no tile subdivision (fetching 4 child tiles) as suggested in #1520.

So when the API returns that error, iD never recovers and the loading spinner can run indefinitely. The fix would be to detect this specific error (e.g. 400 with that message) and retry by subdividing the tile (e.g. as described in this comment on #1520).

[Shyam-123pandey]

Yes Sir I got the issue it haven't fixed yet Please see in network tab rejected api calls.

-Error: You requested too many nodes (limit is 50000). Either request a smaller area, or use planet.osm

so now I am going to fix this. After fixing will inform to you thanks

[Shyam-123pandey]

https://drive.google.com/file/d/1-3UsnZWG6jUg05__sEQULTYYidnYVkZg/view?usp=sharing
Here is a short video showing the fix and spinner behavior after subdivision handling of PR #11888.

[Shyam-123pandey]

Review raised PR things if any improvement tell till that i will fix some basic changes then will do PR again
Additionally, at line 1259-1262, when max depth is reached, the code checks _isLoading and dispatches "loaded" only if it's true. However, there's no check at line 1292 for whether _isLoading is true before dispatching "loaded", which could cause redundant "loaded" events.

[Shyam-123pandey]

https://drive.google.com/file/d/1-3UsnZWG6jUg05__sEQULTYYidnYVkZg/view?usp=sharing Here is a short video showing the fix and spinner behavior after subdivision handling of PR #11888.

@FaisalMisbah23 Sir AS @tyrasd sir said unrelated code changes but they didn't which thing is unrelated here.