Simon Poole

No problem, I didn't want to indicate that you had to hurry. We've just started with the migration, and while it "in principle" works with the "jetifier" it would be...

@cyb3rko unluckily the fork requires switching themes, which is something that is not planned short term for our project,

> > > fyi I'm now using this in my build.gradle: `implementation 'com.github.sevar83:indeterminate-checkbox:965fdc7c20'` > > This just takes the library built from the currently latest commit on master ([965fdc7](https://github.com/sevar83/indeterminate-checkbox/commit/965fdc7c20ab29f56e53b646de5dca0268879530)) The...

Note that an alternative approach would be to save the icons on the OSM wiki (or something else operated by the OSMF, we also have some AWS storage iirc).

@rbuffat I fully support the size argument (though for me it is mainly a question of how long it takes to read and parse the file once), but from a...

> Please excuse me to slightly extend the scope of this issue, but I guess this could be relevant: Isn't loading the index from github (e.g. https://osmlab.github.io/editor-layer-index/imagery.geojson) also problematic in...

Would someone be so kind and explain what the point of supporting this for aerial imagery is (contrary to maps with labels, where the reasoning is clear)?

> Editors that do not wish to use higher resolutions could simply drop the {r} token. We could integrate this token in the URLs but drop it automatically in the...

> > > Other option could be extending `properties` with additional URLs for every supported scaling (even fractional). This would make it backward compatibile with old (current) software: If we...

Given that've suggested similar things I suppose I should comment. > > > I've been thinking about where to take this project next for a while. The current index, which...