It would be easier if map content packs did not bundle both code and data [OSM]

[tim-moody]

Bundling code and data causes a number of problems:

• tiles must be downloaded in order to get code changes
• file names have to change even when the underlying 'map' does not
• makes the catalog unclear
• leads to on the fly patching of code for redirection
• causes confusion about whether to redownload an already downloaded map

[holta]

I recall @georgejhunt wanted the ease-of-use that comes with self-contained RACHEL-like (OER2Go) content packs.

While I was not part of this Map Pack design/decision, I presume the thinking was similar to Emmanuel Engelhart's decision to bundle everything possible into ZIM files in 2016 — so that nothing is lost during offline (peer-to-peer) exchanges among non-technical users handing off "media files" to each other — in very informal/civic settings...

[tim-moody]

That would be like bundling kiwix-serve with each zim so that you have to download all zims again to get the new release of kiwix-serve.

[holta]

That would be like bundling kiwix-serve with each zim so that you have to download all zims again to get the new release of kiwix-serve.

Yes. FWIW Stephane Coillet-Matillon advocated for this strategy in 2016/2017 so that ZIM file content was fully self-sufficient, each in its own Android app, hence far friendlier to newbie/normal Android users.

[holta]

@mir123, @m-anish & all:

There was an excellent discussion on these topics yesterday during IIAB's weekly community/team call.

Sorry I unfortunately didn't capture all the many / very thoughful details / design discussions that were considered. Around balancing tradeoffs...towards reducing UX/maintenance confusion among newbie implementers...while supporting diverse and unpredictable Map Pack "ecologies"...while at the same time keeping an eye on evolving real-world deployment/maintenance patterns among more advanced implementers & Sneakernet-of-Alexandria field content exchanges, etc!

e.g. this should have been written up at http://minutes.iiab.io (see under June 13, 2019) but I couldn't quite keep up, my apologies — so please do ask @georgejhunt & @tim-moody for more details if you are interested and/or can help!

[holta]

@georgejhunt has posted a draft of possible OSM improvements/restructurings to follow IIAB 7.1:
https://github.com/georgejhunt/maps/blob/1map_reorg/docs/7.1%20Features.md

See also conversation notes from IIAB's 2020-01-02 call here: http://minutes.iiab.io (Item 1.e.)

Ref: #877 Package up vector-based OSM maps

[holta]

As we redesign maps for IIAB 7.2+ note also...

• IIAB's current "per continent" Map Packs are proving very successful — currently about 10 are offered and their are shown here: http://iiab.me/maps/maplist/
• @georgejhunt would like to add a "12th" layer of OSM zoom outside of each continent's detailed-area-of-interest, as this will only add about 0.5GB to each Map Pack, and confers many usability benefits!
  • Context: there are currently only 11 such layers (levels 0-to-10) outside the core/continental bounding box of interest, according to https://github.com/iiab/iiab/wiki/IIAB-Maps
• IIAB Maps Doc: https://github.com/iiab/iiab/wiki/IIAB-Maps

Ref: #877 Package up vector-based OSM maps

[holta]

@georgejhunt is this complete?

Can this ticket be closed?

[georgejhunt]

yes

…

On Thu, Sep 3, 2020 at 4:37 PM A Holt ***@***.***> wrote: @georgejhunt <https://github.com/georgejhunt> is this complete? Can this ticket be closed? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1726 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOTQHF5P2Q3VYW5QX4AGF3SEASETANCNFSM4HVXMH6Q> .