База данных для оффлайновых плиток с скользкой картой

25

В настоящее время у меня есть автономное приложение карты 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 ]

Вопрос: Что коллективная мудрость (и опыт) говорит о следующих вариантах выбора дружественной к JavaScript БД:

  1. SqlLite
    • Похоже, вам нужно создать встроенную оболочку приложения, чтобы она могла общаться с JavaScript
    • Например, добавьте вашу DLL в собственную программу для Windows и PhoneGap для Android / IOS
  2. WebSQL
    • depricated
    • но это был SQL Lite, который я мог легко генерировать и распространять с хост-сервера
  3. 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


Dr.YSG
источник
Любая конкретная причина для дублирования? stackoverflow.com/questions/14058489/…
radek
Подземье не Подземье? ;]
radek
Спасибо за вашу правку Анита. Я новичок, и я не знал надлежащего этикета для закрытия этой заметки, но оставлял читателям подсказки, что я выбрал для решения.
Dr.YSG

Ответы:

7

PhoneGap и MBTiles .

WebSQL & IndexDB будет недостаточно. «Ноутбуки Windows» не будут такими же кодами, как мобильные устройства.

tmcw
источник
Дополнительная информация: клиент попросил только поддержку ноутбука. Я лично хочу посмотреть, смогу ли я распространить это на планшеты (IOS, Android). Я чувствую, что PhoneGap слишком сильно увеличит время разработки и приведет к фрагментации базы кода (затраты на обслуживание программного обеспечения). Но спасибо за статью, это было оригинально.
Dr.YSG
Я только что вспомнил, что здесь есть дополнительное ограничение: если мы реализуем его с PhoneGap, спонсор назовет это нативным приложением, а затем ему придется пройти год или около того сертификации. Мы действительно хотим избежать этого.
Dr.YSG
1
То, что вы хотите сделать, невозможно без встроенного компонента. Вероятно, пришло время пересмотреть.
tmcw
Для моего любопытства, что проблема с IndexDB или FileAPI?
Dr.YSG
1
Почти нулевая и пятнистая поддержка браузера плюс низкие ограничения по размеру. Попробуйте сами.
tmcw
3

Результаты Автономный кэш больших двоичных объектов для карт PNG Slippy

тестирование

  • 171 файл PNG (всего 3,2 МБ)
  • Проверенные платформы: Chrome v24, FireFox 18, IE 10
  • Должно также работать с Chrome и FF для Android

Получить с веб-сервера

  • использование XHR2 (поддерживается почти во всех браузерах) для загрузки BLOB-объектов с веб-сервера
  • Я пошел с XHR2-Lib от Phil Parsons, который очень похож на JQUERY .ajax ()

Место хранения

  • IndexedDB для IE и FireFox
  • Chrome: Polyfill (блоб хранится с использованием API-интерфейса FileSystem, ссылка хранится в IndexedDB) polyfill
  • Обязательно прочитайте статью "Как браузеры хранят данные IndexedDB"
  • Примечание: FireFox использует SQLlite для NOSQL IndexedDB. Это может быть причиной низкой производительности. (капли хранятся отдельно)
  • Примечание. Microsoft IE использует механизм расширяемого хранилища:
  • Примечание. Chrome использует LevelDB http://code.google.com/p/leveldb/.

дисплей

  • Я использую Leaflet http://leafletjs.com/, чтобы показать плитки карты
  • Я использовал функциональный плагин слоя листов от Ishmael Smyrnow для извлечения слоя листов из БД
  • Я сравнил слой плиток на основе БД с чисто локальным (localhost: //) хранилищем
  • Там нет заметной разницы в производительности! между использованием IndexedDB и локальными файлами!

Полученные результаты

  • Chrome: Fetch (6,551 с), магазин (8,247 с)
  • FireFox: выборка (0,422 с), магазин (34,519 с)
  • IE 10: выборка (0,668 с), магазин: (0,896 с)
Dr.YSG
источник
2

так что вы почти наверняка не хотите использовать leaf.pouch, я сделал это с учетом векторных данных, а не плиток, вам, вероятно, было бы лучше использовать прямую PouchDB для хранения ваших плиток, так как вы также можете копировать из CouchDB для Быстрая первоначальная загрузка. Ответ по @tmcw выше также будет работать, если у вас есть больше приложений для телефона, чем для мобильной веб-страницы.

Кальвин
источник
0

использовать стандартный формат MBTILES контейнера SQLite3 с таблицей плиток с полем BLOB-элемента tile_data с PNG или JPG или WebP или GZipped PBF, интегрированным с MBTILES.JS https://github.com/tilemapjp/mbtiles.js/tree/master https: // www.npmjs.com/package/Leaflet.TileLayer.MBTiles

Вы можете конвертировать TMS или XYZ Tiles в mbtiles с помощью MBUTIL от MapBox. если вам нужно сгенерировать папку плиток, сначала используйте GDAL2TILES_Parallel.py или gdal2tilesp.py параллельные многопроцессорные реализации Python для orginal. Они оба требуют GDAL.

GeospatialInformationTech
источник
Я реализовал прямое чтение mbtiles (растр, вектор и рельеф местности) в листовке для полностью автономного просмотра.
GeospatialInformationTech
Моя реализация добавила поддержку OGC GeoPackage. Растровые, векторные, вертикальные и векторные плитки. с использованием GeoPackage-JS
GeospatialInformationTech
0

MBTILES в Leafletjs введите описание изображения здесь

он будет читать локальные и удаленные записи. Пакет как мобильное приложение с IONIC или React Native. или рабочий стол с электронным атомом. MBTILES - это путь

GeospatialInformationTech
источник