В настоящее время у меня есть автономное приложение карты HTML5 (построенное на Leaflet & KendoUI с пользовательскими дополнениями), которое имеет манифест приложения и прекрасно работает на нескольких платформах. Тем не менее, я не решаюсь использовать манифест для хранения фактических листов карты таким образом (файлы PNG хранятся в виде Tile Cache в стиле TMS).
Вопросы:
- В 1000 файлов PNG может быть много фрагментов (10–50 МБ).
- Начальная загрузка может быть очень медленной (и трудно показать прогресс пользователю)
- Манифесты приложений работают или не работают, если не все кэширование в автономном режиме завершится неудачей (согласно [whatwg.org] [1])
- Офлайн-пользователь будет иногда переподключаться, и ему нужно будет обновить Tiles. Это небольшие ошибки, но механизм манифеста приложения перезагрузит все файлы js, css и PNG сразу после обновления манифеста.
Альтернативная идея: хранить веб-приложение отдельно от хранилища фрагментов скользкой карты. Храните плитки в дружественной базе данных веб-приложения
Обновить:
[PouchDB недавно добавила поддержку двоичных двоичных объектов. Я получаю хорошие начальные результаты. См .: /programming/16721312/using-pouchdb-as-an-offline-raster-map-cache ]
- Это предложил Бен Нолан http://bennolan.com/2011/06/03/offline-mapping.html
- Аналогичная работа над Картами на Флешке: http://developmentseed.org/blog/2010/oct/02/maps-stick-version-2-released/ ([устарело] [2])
- MBtiles http://mapbox.com/developers/mbtiles/
- TileStream https://github.com/mapbox/tilestream
- Lous Remi: http://louisremi.com/2011/10/07/offline-web-applications-were-not-there-yet/
Вопрос: Что коллективная мудрость (и опыт) говорит о следующих вариантах выбора дружественной к JavaScript БД:
- SqlLite
- Похоже, вам нужно создать встроенную оболочку приложения, чтобы она могла общаться с JavaScript
- Например, добавьте вашу DLL в собственную программу для Windows и PhoneGap для Android / IOS
- WebSQL
- depricated
- но это был SQL Lite, который я мог легко генерировать и распространять с хост-сервера
IndexDB
- Хранение блобов, кажется, работает, см .: https://hacks.mozilla.org/2012/02/storing-images-and-files-in-indexeddb/
- Меня беспокоит, если это единственный способ изначально заполнить БД
- Это в основном файл SQLLite? Могу ли я отправить его для массовой загрузки БД?
- Я склоняюсь к этому как к решению. Это их ошибки, о которых я не знаю?
Требования:
- Быстрое начальное заполнение (через загрузку) клиентской веб-БД
- Совместим с текущим API-интерфейсом Leaflet TileLayer (т.е. я бы не писал пользовательский слой, но при необходимости ...) (например, MbTiles)
- Платформа: ноутбуки с Windows, но желательны планшеты Android и IOS (я могу подождать, пока будет выпущен IndexDB, не нуждаюсь в немедленной поддержке)
- Я бы предпочел не писать нативное приложение (EXE, IOS, Android), но если это лучший способ ...
- Генерация веб-карт на стороне сервера (это будет автоматизированный процесс). Пользователь выбирает местоположение, выбирает карты, и они динамически преобразуются и превращаются в скользкий тайник тайлов (эта работа в основном уже выполнена).
- Быстрая массовая начальная загрузка
- Дельта изменения карты обновляется (я напишу эту логику, основываясь на постоянных номерах запасов и логике даты обновления)
- Минимальное влияние на текущее веб-приложение Leaflet & KendoUI
Обновить:
Основная фоновая идея: хотя веб-приложение довольно стабильно, фрагменты скользкой карты генерируются на лету для вашего местоположения и типа проблемы, которую вы делаете (на заднем плане). Поэтому я подумал о двух других способах передачи начального «большого взрыва», а затем обновлений:
Zip-файл (вероятно, не очень хорошая идея - поскольку он добавляет нагрузку на сервер), также расширение на клиентском компьютере потребует взаимодействия с пользователем, но оно позволяет скользким плиткам использовать локальные URL-адреса.
HTML5 File API: я не рассматривал это очень подробно. Но, похоже, большинство операций по созданию локального файлового дерева в формате TMS: http://www.html5rocks.com/en/tutorials/file/filesystem/, что будет интересно проверить, это производительность (например, могу ли я использовать веб-работы максимизировать пропускную способность на диск и через сеть). IndexDB широко не используется для работы с веб-персоналом (интерфейс синхронизации: /programming/10698728/indexeddb-in-web-worker-on-firefox
Я нашел дополнительную информацию об использовании IndexDB с Leaflet:
https://github.com/calvinmetcalf/leaflet.pouch (синхронизирует couchdb с indexdb для автономного режима). Также вот несколько тестов для скорости чтения / записи для indexdb, websql и локального хранилища: http://jsperf.com/indexeddb -vs-LocalStorage / 15
А вот как использовать API для чтения / записи файлов из javascript: (а также попросить увеличить лимиты хранения) http://www.html5rocks.com/en/tutorials/file/filesystem/
Спасибо, Tom MacWright (ak tmcw), за хорошие отзывы. Ваш пример действительно поможет, когда я доберусь до создания пользовательских слоев для приема двоичных двоичных объектов.
Вчера я провел некоторое тестирование с IndexedDB, и, используя некоторые полифилы и библиотеки, я думаю, что это решит мои проблемы. Теперь пришло время внести некоторую долю пота в это, и я доложу.
Кстати: если вы хотите увидеть мои результаты моего исследования на клиентских базах данных, смотрите:
/programming/14113278/storing-image-data-for-offline-web-application-client-side-storage-database
