2012/5/1 Evan Battaglia <gtoe...@gmx.net>: >> You do not have to credit me on the two new files, they are yours. :-) > Yeah, I just copy and paste files and don't give much thought to copyright > notices :) > > I wasn't aware of the maps.xml file, but it is truly awesome, especially > given how so many services use that same mercator > OSM/slippymap/whatever-it's-called scheme. And great that users of today's > versions of viking can use CalTopo just by editing that. > > >> In one hand, it seems to be a usefull freely >> available map. In the other hand, this is USA only related. Perhaps >> the hability to configure it is enough? > I strongly advocate built-in support for topos, even if they are USA-only. > Sure, I live in the USA, but hear me out: my main use of Viking is with > topos, and I suspect there are many others who are the same way (for > instance, a long long time ago, Reid Priedhorsky made some topo maps for an > Escalante hiking trip with Viking). There is a big market for making your > own custom topos: National Geographic TOPO > (http://www.natgeomaps.com/topo_state.html ) sells for a ridiculous amount > of money (like $50 for each state!), and there is also TopoFusion. And we > can compete here. If Viking (as installed by 'apt-get install viking' in > Ubuntu) comes shipped with support to make your own topo maps, I think it > would increase the visibility and really show people what Viking can do. > (I'm assuming the debian package is compiled with the default options). I > don't think the one extra item in the menu that users from other countries > may never use hurts much. If there were a really good Topo map source for > only France or New Zealand or something, I wouldn't object to having it > built-in, in fact I might be curious to see what the maps look like... and > there are already tons of map sources compiled in that I don't use... > > Anyway, it does seem strange to me that I would have to add new code to get > CalTopo in; I guess there's no global "maps.xml" file?
You're definitively right: this was a old open item on my todo list since I added maps.xml feature. I imagine to put some files in standard locations: - /usr/share/viking/maps.xml (or something like that, depending on distribution) - /etc/viking/maps.xml Classicaly, the main difference is that /etc/viking/maps.xml is editable by admin while /usr/share/viking/maps.xml is supposed to stay untouched, only deployed by package. But a question remains: what logic should we implement to offer maximum power to user. First logic: we only load a single file, the first one found: - $HOME/.viking/maps.xml - /etc/viking/maps.xml - /usr/share/viking/maps.xml This logic allows the user to overwrite all settings, keeping only the most interesting for him. Second logic: we load all files. The current internal management allow to overwrite existing ids with new definitions. The matter with this logic is that the list of supported maps provider can be very long. In the other hand, this will allow the user to discover new maps when upgrading the package, even if he already defined a personnal maps.xml. I'm not sure about the right option. And perhaps there is other options. I think the second one is better. And I imagine we can go further: load more than one file per directory. For example, load maps.xml + maps_*.xml (or *_maps.xml). Why? In order to allow packaging all map source in different files and different package (one per country, for example viking-data-us.deb). This way, the packagers and users will have lot of power with few effort. Any comment appreciated. I'm available to do such changes, but I need a direction. -- Guilhem BONNEFILLE -=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com -=- mailto:guilhem.bonnefi...@gmail.com -=- http://nathguil.free.fr/ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Viking-devel mailing list Viking-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viking-devel Viking home page: http://viking.sf.net/
