Low data mode

[quincylvania]

iD can download a lot of data, which is an issue for mappers with slow or limited connections. This could become even more of a pain point as we continue to expand iD's mobile capabilities. We should consider adding the option to reduce the amount of downloaded data, at the cost of somewhat reduced functionality. Here are a few ideas:

• Don't download map data or tiles outside the visible area
• Prefer low-res tiles, even on high-res screens
• Don't request external images
• Don't preload anything before the mapper actually needs it

Of course, the underlying goal should be to keep regular data usage as lean as reasonably possible so most mappers won't need this setting.

[jidanni]

(Indeed... going a tiny bit further, zero data mode, would allow iD to be usable offline, like JOSM (whose opposite panning mouse binding means I cannot use it.) Anyway, imagery, if desired, could be cached beforehand, and edits would be saved up until an internet connection was available.)

[Nakaner]

Couldn't we save data by just building a light version of iD not containing secondary features like name-suggestion-index, Mapillary and StreetSide? It would make it possible to load smaller JavaScript assets. Migrating the imagery index to a API returning only what one needs and not returning all entries for the whole world could save space as well.

[quincylvania]

Indeed... going a tiny bit further, zero data mode, would allow iD to be usable offline, like JOSM

@jidanni Offline mode would be a totally separate and much more difficult feature to build, particularly for a web app.

Couldn't we save data by just building a light version of iD not containing secondary features like name-suggestion-index, Mapillary and StreetSide?

@Nakaner I don't see these as secondary since they add significant functionality that mappers constantly use. If someone doesn't want something then they can always fork iD. Though I do agree that, as much as possible, we should avoid loading assets until the mapper initiates whatever feature.

[sun-geo]

It seems the new version v2.18.2 loads many more data to get access to the iD editor after pressing the "Edit" button on top of the osm.org page. I assume there is a rough estimation of app. 1MB for v2.17.x to app. 5MB now for v2.18.2. Do you have more exact figures by chance. Is it possible to reduce the data load while the iD starting procedure? Do you know the reason for the strong increase of the download data?

[quincylvania]

@sun-geo I haven't been paying much attention to initial download size, so I don't have great answers for you. Since we unbundled a lot of data in release (#4994), iD's JavaScript payload should be smaller but the data file minification may not be as optimized, but that's just a guess. Before even starting low data mode I'd definitely like to take a look into this.

[cicku]

Another issue is that even if I focus on a different nearby area and then switch back, iD will attempt to reload the imagery.

This significantly increases the bandwidth consumption of both the editor and the imagery server.

@tyrasd