Support loading of existing atlases from file system
Brought to you by:
r_x
Menu
▾
▴
#23 Support loading of existing atlases from file system
I have a big atlas with many maps. I would like to load this atlas into TAC.
Use case 1: See which region is already covered by atlas content.
1) Selecting one map shall fill the bounding box coordinates and display the selection, so I could download an updated version / the same rectangle from different provider with ease
2) Selecting further maps (using CTRL or SHIFT as usual for multi selection) shall not change selection, but add the bounding boxes of all selected maps, so I could see which regions are not covered yet.
Use case 2: Manage the atlas structure, like renaming maps or layers or moving maps between layers. There are no real alternatives available at the moment:
TBMapper is not working properly for atlases as big as mine which are not even 2GB and moreover can't zoom out to get an overview.
In the file system, I can do all folder renaming and moving, but can't see (visualized) which map covers which region, and I can easily produce an atlas that does not work (special characters / umlauts / spaces in path, one directory nesting too much / too little etc) where TrekBuddy is not providing much debug info in exception text => time consuming
Use case 3: Possibility to add/update content on foreign computer without having my TAC settings + cache with me. Profiles may be seen as a meta data representation of an atlas on file system (FS) - currently, only profile=>FS works, and I would like to have FS=>profile added, so both representations can be transformed into the other.
Use case 1.1: "Reading info from existing atlas/maps":
Good idea
Use case 1.2: "Multiselection of regions":
Multi-Selection is not planned. But have you tried the "Display map area" function from the atlas context menu? I think this will help you visualizing the different areas.
Use case 2: Not planned.
Use case 3: Sorry, but I don't understand the proposed feature. If you need to run TAC on different computers you can copy it together with the atlas on your SD-card and carry it with you. TAC should be more or less portable.
@1.2: For hiking, I sometimes have many areas (>15) along one path to reduce total amount of tiles, and usually have 3 providers (map, terrain, sat image). It helps nothing to see all the path is covered by atlas; I need to see that it is covered for each provider. One atlas per provider would result in too many atlases. Either I need multi selection or I need possibility to move maps between layers which would be even more useful for atlas management (if use case 1.1 is implemented).
@2: 50% is already implemented (renaming of atlas, layers, maps), now all required is moving maps between layers.
@3: TAC already is portable. Sorry for unclear formulation,; it is closely related to use case 1.1. Currently I can define an atlas and save it as profile for re-use, and can create an atlas on file system out of a profile. If 1.1 is implemented, I could read an atlas from file system and create a profile out of it. This would make my profiles portable to other TAC installations (this is more than having my TAC installation including profiles being portable).
Merging multiple layers is already possible since TAC 1.5. Just use drag & drop in the atlas content area. But for 1.7 I implemented also map moving via drag & drop.
Regarding the recovery of an atlas in file system => profile I have to say that this is IMHO not possible. The region can be extracted and the zoom level can be computed by the size of the map and the region. But how to retrieve the map source? The map name is fully customizable and therefore does not allow a solid indication.
If you want to load an atlas again later please copy the profile xml into the atlas folder.
Can I suggest you simply implement MOBAC saves the atlas XML file in the atlas folder, maybe as mobac.xml, or tr.xml. Right next to the atlas main tar file? That would be quite useful.