Hi!
With the improved uSD arriving in the latest storage the possibility
to store big data sets on-device is opening for non-expert Jolla users.
One of such potential data sets is mapping and navigation related
data.
With multiple navigation systems for Sailfish already in development
(such as Maep and modRana) it might not be a good idea to discuss the
possibility of having a well known path for map data on external storage
which would make it possible to share data sets between navigation apps.
Background - Maemo 5 & N900
There are various mapping and navigation apps for Maemo 5, such as Maemo
Mapper/Mappero,
Maep, modRana, Cloud GPS, Yosmapa, AGTL and others. By a convention that
wasprobably set ba Maemo Mapper
as one of the first navigation apps on Maemo 5 store their map data (in
this case map tiles) in a common location.
This common location is the .maps directory in the MyDocs folder, giving
the /home/user/.maps path.
Individual map layers each have their own directory, such as for example:
/home/user/.maps/OpenCycleMap
This common tile storage directory makes it possible to share map tiles,
meaning that tiles for the same place
downloaded by modRana can be viewed in CloudGPS and don't need to be
downloaded twice.
Proposal - common map data path on Sailfish external storage
Based on the experience from Maemo 5 I would like to propose this set of
well known map storage paths
for external storage (uSD card partitions) on Sailfish OS:
- base directory:
<card partition root>/.maps
- tiled data
<base directory>/tiles
With subfolders per layer, for example:
<base directory>/tiles/OpenCycleMap
- offline routing data
<base directory>/routing_data
With subfolders per routing data type, for example:
<base directory>/routing/monav
<base directory>/routing/routino
<base directory>/routing/navit
- vector map data
<base directory>/vector
With subfolders per vector data type, for example:
<base directory>/vector/osm_pbf
<base directory>/vector/kothic_sqlite
- POI
<base directory>/poi
With subfolders per poi database type, for example:
<base directory>/poi/osm_extracts
This directory is meant mostly for big POI extracts,
(all cities in on the world, all restaurants in Europe, etc.)
private POIs should be stored in an application specific folder.
On the other hand the <base directory>/poi folder might
be a god place for sharing Points Of Interest between applications.
Benefits
- applications that agree on a common format (web mercator tiles,
OSM PBF/XML, routing routing database) can use the same data set
(also opens the possibility to have separate data loaders and viewers)
- automatic discovery - applications can automatically detect know if any
given uSD partition has map data they can use and also know that if a
partition
has a .maps folder, the folder can be used for data storage
- centralized map data management - if the map data is stored in a single
location it is possible to easily check both total amount of space used
and space usage per data type independent on data management
capabilities in individual applications
- it makes it also possible to easily delete selected map data types
without hunting for app specific data folders
- could be made Tracker-safe - most people probably don't want Tracker to
crawl a couple thousand map tiles to their image gallery :)
Possible topics for further discussion
- .maps as base directory ?
The directory is marked as hidden and thus would not bother most
users during normal uSD usage, On the other hand users might
wonder about missing space. A visible map data base folder
(say just "maps") could on the other hand be more easily deleted
by accident.
- who creates the base directory ?
An application needs to first create the base directory on the proper
partition, most probably based user input.
- sub folder standardization ?
How to map map data type, such as an individual tiled map layer,
to a subfolder name, so that multiple applications can use it.
Looking forward to your feedback! :)
Withe best wishes
Martin Kolman
_______________________________________________
SailfishOS.org Devel mailing list
