Sometimes must zoom OUT to edit

[jidanni]

We are used to seeing the words "zoom in to edit".

But sometimes one must in fact "zoom out to edit"!
(Else yes one can edit, but at one's own risk...)

Here the railroad data doesn't arrive on to the map:
https://www.openstreetmap.org/edit#map=19/42.20668/-87.83946
Only now it does:
https://www.openstreetmap.org/edit#map=18/42.20668/-87.83946

[tyrasd]

I see the point. However, this is not something that can be fixed in iD. The cause for this is a limitation of OSM API v0.6's map call: OSM editors only receive ways which have at least one node in the requested bounding box. In the case for long linear features with few node vertices, it is possible that the mapping bounding box does not include any of these nodes. This results in the respective way(s) from missing in the editor's map.

iD already tries to mitigate this issue by requesting a little bit more than just the area one is mapping in.¹ But ways in OSM could technically have very long distances between their nodes (in some extreme examples they are dozens of kilometers apart). It's just not feasible for iD to increase the request by a large enough buffer to never miss any features.

I think it is reasonable to assume that mappers interested in mapping potentially long or large features will automatically zoom out far (or pan around) enough to see the respective features properly (e.g. in this example, to check how the intersection between the railway line and the road is mapped) before starting to draw in the apparently missing features. This works as long as the nodes are reasonably spaced out on the mapped data (which is the case in this example). Otherwise, I'd recommend to map a few intermediate vertices on the affected ways.

To sum this up: Yes, this is a nuisance and can be confusing for mappers. However, it would need to be fixed outside of iD on the OSM API side.²

Footnotes

1. And it seems to work at least a bit: When one opens the example areas you posted above in JOSM, both the zoom level 19 and 18 do not include the culprit railway line. ↩

2. Interestingly, this issue does not appear on the list of possible enhancements for OSM's API "v0.7", I'll probably have to add it. 🙈 //edit: done ↩

[jidanni]

Indeed, mappers might get used to zooming out a little further to make sure they're seeing all the stuff. And then one day there's something with even wider spaced nodes, so they might think that must not be mapped yet..

Another interesting thing is the carto renderer. That always gets all the stuff no matter if the nodes are in the screen or not. Maybe some software theorems could be borrowed from it into the API...

[1ec5]

openstreetmap-carto ingests the entire planet file rather than extracting a small bbox to render. There is prior art out there, for example in the Overpass API and tools like Osmium for generating extracts, but @tyrasd is right that the OSM API won’t be able to solve this problem until the next major version.