Can't reasonanbly map unmapped areas such as amazon with iD - zoom in to edit

[stillhart]

Description

I would like to map the amazon forest but more or less can't using iD. iD has the "zoom to edit" feature in order to avoid loading too much data. This is great for dense urban areas. The zoom level threshold could be even higher in dense areas where too much data makes iD unusable.

But the reverse happens in unmapped areas. I would like to map the amazon forest and I just can't. The biggest forest my 4k screen let's me do is this, which is minuscule compared to the problem I would like to solve.

https://www.openstreetmap.org/way/1395509631

Screenshots

[tordans]

Image that would work, we would end up with gigantic areas. Have you ever tried to change something in such an area? It’s super hard. My understand is that map renderer use external data for those zoomed out views which I think is a good solution.

[danieldegroot2]

Hey stillhart,

In general, changesets should be local. Large polygons and large changesets are hard for other mappers to verify, validate and maintain. (consider even larger areas are still problematic, not what the exact (editor-specific) limit is or if one is needed for specific use case. (iD is a general-purpose editor, not a power tool))

Users should usually be zoomed in properly to edit, user should

• manually check changes/sources (sidenote: in other areas, the difference between a forest, wood, tree nursery, orchard, etc. might be small and better left to local mappers, only map so much which you understand to actually be forest.)
• make change with sufficient accuracy (prevent low quality data); just as important as Completeness. (little inaccuracy is okay, you can only see so much of where forest cover is and what is below it.)
• make good use of existing data, not duplicate it, map on top of it, or delete it (the last only if actually needed)
• Some imagery providers will provide different (or compressed) imagery at other zoom levels. (using multiple aerial layers can be useful, noteably it can mean different years/seasons(/visibility), etc.)

Also, there is a limit in the OpenStreetMap API for the amount of nodes you can add (2000 nodes). (splitting up area into smaller areas helps with some renderer applications / API calls or used to do so.) As of https://github.com/openstreetmap/iD/pull/8808, when you make an area too big, there should be an explicit warning before saving your changes. This warning will also suggest a fix 'split up the area'. (before there was only an error post-save) You can currently not easily split areas manually. There has been some work on this, but multipolygons still require some attention.

Furthermore, iD (currently) runs on your local browser cache so after a few hundred/thousand changes you risk losing them if the editor/browser/pc crashes.

Eventually polygons become more complex and usually you will have to map a multipolygon relation for i.e. forest with 'holes'(farmland, water, residential landuse(ignore buildings)) which should be excluded from the forest.

Large areas and relations such are multipolygons are best mapped using the JOSM editor (more hotkeys, operations etc.) and plugins (FastDraw, utilsplugin2, Scanaerial (remember to check changes manually)). This way you can more easily map and maintain such objects and prevent making accidental changes (moving nodes, changing order or removing member of relation which might 'break' it for applications such as routers and renderers.) which iD is prone to (at least for beginners).

If you have any questions how to map etc., please contact the (local) community at https://openstreetmap.community/ or start a thread on the community forums https://community.openstreetmap.org/

You can also choose to organize a mapathon (mapping event) with the local community using a tasking manager.

---

In iD,

• creating line/area and dragging the hovering endpoint to near the edge of the active view, it will move the active view. (for continuing finished areas, see #2272.)
• you can always Enter finish drawing, then extend with A Extend. (see last button Help menu on right sidebar for more hotkeys)
• you can always hide data using the filters at the bottom of the Data layers menu in the right sidebar. (just remember you have hidden it)

---

My understand is that map renderer use external data for those zoomed out views which I think is a good solution.

Yes, while not directly relevant for this issue, OSM Carto uses some Natural Earth data (see also implementation) though it has been discussed to remove (some of) it.

[bhousel]

I would like to map the amazon forest but more or less can't using iD. iD has the "zoom to edit" feature in order to avoid loading too much data. This is great for dense urban areas. The zoom level threshold could be even higher in dense areas where too much data makes iD unusable.

Rapid lets you edit at lower zooms, you should switch to it. https://rapideditor.org/

We've heard feedback that this is important for remote locations or places at higher latitude where the Mercator projection stretches things.

The Rapid implementation is not perfect, and you can still put the map into situations where the amount of data being shown in the viewport is just too much. But at least there isn't a "Zoom To Edit" block anymore.

The current iD dev team will likely not be able to help with this issue, but previously we did some work at #2427 and #2442 and related tickets. It's been an issue that the former iD team had wanted to improve for over 10 years, this is why we made it a priority for Rapid.

[jjiglesiasg]

I would like to map the amazon forest but more or less can't using iD. iD has the "zoom to edit" feature in order to avoid loading too much data. This is great for dense urban areas. The zoom level threshold could be even higher in dense areas where too much data makes iD unusable.

Rapid lets you edit at lower zooms, you should switch to it. https://rapideditor.org/

We've heard feedback that this is important for remote locations or places at higher latitude where the Mercator projection stretches things.

The Rapid implementation is not perfect, and you can still put the map into situations where the amount of data being shown in the viewport is just too much. But at least there isn't a "Zoom To Edit" block anymore.

The current iD dev team will likely not be able to help with this issue, but previously we did some work at #2427 and #2442 and related tickets. It's been an issue that the former iD team had wanted to improve for over 10 years, this is why we made it a priority for Rapid.

I was coming to suggest the mapper #stillhart to use Rapideitor.org instead of ID. ID is capped on purpose, and there are a lot of mappers who do not want to use JOSM and Rapid fit perfectly as an ID on steroids.

Thanks Brian