Actualmente tengo una aplicación de mapa HTML5 fuera de línea (construida en Leaflet y KendoUI con adiciones personalizadas) que tiene un manifiesto de aplicación y funciona bien en múltiples plataformas. Sin embargo, dudo en usar el manifiesto para almacenar los mosaicos de mapas reales de esta manera (archivos PNG almacenados como una memoria caché de mosaicos de estilo TMS).
Cuestiones:
- Podría haber muchos mosaicos (10MB - 50MB) en aproximadamente 1,000 archivos PNG
- La descarga inicial podría ser realmente lenta (y difícil de mostrar el progreso al usuario)
- Los manifiestos de aplicaciones funcionan o no lo hacen si no lo hacen, todo el almacenamiento en caché sin conexión fallará (de acuerdo con [whatwg.org] [1])
- El usuario fuera de línea ocasionalmente se volverá a conectar y necesitará actualizaciones de los mosaicos. Estos son pequeños deltas, pero el mecanismo de manifiesto de la aplicación volvería a cargar todos los archivos js, css y PNG tan pronto como las actualizaciones del manifiesto
Idea alternativa: mantener la aplicación web separada del almacenamiento de los mosaicos de mapas resbaladizos. Almacene los mosaicos en una base de datos amigable para aplicaciones web
Actualizar:
[PouchDB agregó recientemente soporte para blobs binarios. Estoy obteniendo buenos resultados iniciales. Ver: /programming/16721312/using-pouchdb-as-an-offline-raster-map-cache ]
- Esto es sugerido por Ben Nolan http://bennolan.com/2011/06/03/offline-mapping.html
- Trabajo similar en Maps on a Stick: http://developmentseed.org/blog/2010/oct/02/maps-stick-version-2-released/ ([en desuso] [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/
Pregunta: ¿Qué dice la sabiduría colectiva (y la experiencia) sobre las siguientes opciones para un DB amigable con JavaScript:
- SqlLite
- Parece que necesita crear un contenedor de aplicaciones nativo para esto para permitirle hablar con JavaScript
- Por ejemplo, agregue su DLL a un programa nativo para Windows y PhoneGap para Android / IOS
- WebSQL
- despojado
- pero era un SQL Lite que podía generar y distribuir fácilmente desde el servidor web host
IndexDB
- El almacenamiento de blobs parece funcionar, consulte: https://hacks.mozilla.org/2012/02/storing-images-and-files-in-indexeddb/
- Me preocupa si esta es la única forma de poblar inicialmente la base de datos
- ¿Es esto básicamente un archivo SQLLite? ¿Puedo enviarlo para una carga masiva de DB?
- Me estoy inclinando hacia esto como una solución. ¿Son sus problemas los que no conozco?
Requisitos:
- Población inicial rápida (mediante descarga) a la base de datos web del cliente
- Compatible con la API actual de Leaflet TileLayer (es decir, prefiero no escribir una capa personalizada, pero si es necesario ...) (por ejemplo, MbTiles)
- Plataforma: computadoras portátiles Windows, pero se desean tabletas Android e IOS (puedo esperar hasta que se publique IndexDB, no necesito soporte inmediato)
- Prefiero no escribir una aplicación nativa (EXE, IOS, Android) pero si esa es la mejor manera ...
- Generación de mapas web del lado del servidor (este será un proceso automatizado). El usuario elige una ubicación, elige mapas y se transforman dinámicamente y se convierten en un caché de mosaico resbaladizo (este trabajo ya está hecho en gran medida).
- Descarga inicial masiva rápida
- Actualizaciones del delta de cambio de mapa (escribiré esta lógica, basada en números de stock constantes y lógica de fecha de actualización)
- Impacto mínimo en la aplicación web actual de Leaflet y KendoUI
Actualizar:
Idea de fondo clave: aunque la aplicación web es bastante estable, los mosaicos de mapas resbaladizos se generan sobre la marcha para su ubicación y qué tipo de problema está haciendo (en el back-end). Así que pensé en otras dos formas de transferir el 'big bang' inicial y luego las actualizaciones:
Archivo Zip (probablemente no sea una buena idea, ya que agrega carga del servidor) también la expansión en la máquina del cliente requerirá la interacción del usuario, pero permite que los mosaicos resbaladizos usen las URL locales
API de archivos HTML5: no he visto esto con gran detalle. Pero parece que tiene la mayoría de las operaciones para crear un árbol de archivos local en formato TMS: http://www.html5rocks.com/en/tutorials/file/filesystem/ lo que será interesante probar es el rendimiento (por ejemplo, ¿puedo usar trabajos web? para maximizar el ancho de banda al disco y a través de la red). IndexDB no está ampliamente implementado para ser apto para trabajadores web (interfaz de sincronización: /programming/10698728/indexeddb-in-web-worker-on-firefox
He encontrado información adicional sobre el uso de IndexDB con Leaflet:
https://github.com/calvinmetcalf/leaflet.pouch (sincroniza couchdb con indexdb para fuera de línea) También aquí hay algunas pruebas para las velocidades de lectura / escritura para indexdb, websql y tienda local: http://jsperf.com/indexeddb -vs-localstorage / 15
Y aquí se explica cómo usar la API de lectura / escritura de archivos desde JavaScript: (y también para pedir que aumenten los límites de almacenamiento) http://www.html5rocks.com/en/tutorials/file/filesystem/
Gracias, Tom MacWright (también conocido como tmcw), por algunos buenos comentarios. Su ejemplo realmente ayudará cuando llegue a crear capas personalizadas para ingerir los blobs binarios.
Ayer hice algunas pruebas con IndexedDB y al usar algunos polyfills y bibliotecas, creo que resolverá mis problemas. Ahora es el momento de poner algo de sudor en esto, e informaré de nuevo.
Por cierto: si desea ver mis resultados de mi estudio en bases de datos del lado del cliente, consulte:
/programming/14113278/storing-image-data-for-offline-web-application-client-side-storage-database
