Re: [Viking-devel] RIP msrmaps.com/terraserver; welcome CalTopo!
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/
Re: [Viking-devel] RIP msrmaps.com/terraserver; welcome CalTopo!
2012/5/2 Evan Battaglia gtoe...@gmx.net: I'm not sure if you meant to email just me or forgot to hit 'reply all' to email the whole mailing list. Oups... thanks for the advice. It doesn't matter too much to me. I think you're right the second options is slightly better. I'm guessing many people who use viking will be the sole users of their computers (like I am), so they can edit the /usr/share and /etc/ files directly themselves. One thing that would be nice would be the ability to use the global maps.xml file without doing a make install (i.e. it looks in the directory relative to where it is), but even that isn't really necessary, since I or a user can just copy it into his ~/.viking/maps.xml directory. It would be good to try and give as much visibility about this file as possible, though. Humh, I do not really like the idea to load a local file silently. But perhaps I'm wrong. What do you think about adding a command line option to: - specify a single .xml file - specify a config directory I think the second option is better and probably cover your expected use case. A related question is What is the precedence of the file specified in command line? I think common usage expect that command line option are prior than $HOME config files, prior than /etc prior than /usr/share. Other idea is to add a VIKING_CONFIG_PATH variable environment. If unset, built-in configuration path is $HOME/.viking:/etc/viking:/usr/shar/viking. If set, the built-in is not used and only the specified path are used. But perhaps should we ALWAYS process the $HOME/.viking even when VIKING_CONFIG_PATH is set. On Tue, May 1, 2012 at 11:50 AM, Guilhem Bonnefille guilhem.bonnefi...@gmail.com wrote: 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 I have a preference 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
Re: [Viking-devel] RIP msrmaps.com/terraserver; welcome CalTopo!
While I agree that typically a single user will use viking on a
computer, I think it should remain clean with respect to ${prefix}/share
not being modified, $etcdir being system-wide config, and ~/.viking for
per-user config.
In pkgsrc, the distribution default maps.xml would be put in
/usr/pkg/share/examples/viking/maps.xml ($egdir), and then treated as
the default value of /usr/pkg/etc/viking/maps.xml (copied to it on first
install, and that file removed if it matched on deinstall). In other
words, share really is for things that don't need changing by users or
machine admins.
Merging the maps.xml makes sense, but perhaps one needs a whiteout
command to drop an entry. OTOH that may be foolish complexity.
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.
I vote for loading/merging maps*.xml from ${etcdir} and ~/.viking.
It makes a lot of sense to have one xml file per map type, for easy
handling.
So I guess the real question is whether having a map known to viking
ever needs overriding. One could say the list can always be made
bigger, and the only question is whether a particular menu list should
show each map. That view says /usr/share/viking/maps.xml is not a
config file, but distribution-defined maps. Then a user would disable
some of them if they were annoying.
My own use case is that I have a gpx.viking file that I prepend to
tracks/waypoints, so I rarely use the 'add map' menu.
pgpsF1LiJAkqx.pgp
Description: PGP signature
--
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/
