Re: [Viking-devel] RIP msrmaps.com/terraserver; welcome CalTopo!
Master branch status: Map is now available via the global map.xml. 2012/4/29 Evan Battaglia : > Hi all, > I happened to notice on msrmaps.com, which I believe we are currently using > for Terraserver topos, that they are shutting down on May 1, 2012. Yeah, 2 > days from now. That's no good. For me, topo maps is what mostly using Viking > with these days. > > But not to fear! I found an awesome source of USGS topo maps called CalTopo > (http://caltopo.com/). They use the same scheme as > Google/OSM/BlueMarble/most everything these days (mercator), so by watching > the AJAX requests in my browser it was trivial to figure out the URL > structure and add support to Viking. Not only that, from what I can tell, > they are actually newer, better quality, and more accurate than old > MSR/Terraserver topos! > > I contacted them about using their tiles. I'm a bit unclear on the license > (if there is one?), because it isn't displayed on their home page, but what > I mentioned what I wanted to do with them (use them to make my own custom > topos for free redistribution) he said that was OK: > > "Because the underlying data is public domain I don't know if I could > actually prevent someone from reassembling the tiles into a map, but I > wouldn't want to even if I could. By all means feel free to do what you're > describing." > > When I asked about using the tiles in Viking, he basically said go ahead: > "You guys should go ahead and use the tiles, and if bandwidth becomes a > concern we can sort it out then." > > They also have support for forest service maps (don't look that much > different but show campgrounds differently and such. Only available for some > issues) and evidently aerial maps, but I haven't added either and haven't > looked into the latter yet, but it should be trivial to add. > > Anyway, my commit to add support for it is here: > https://github.com/evanbattaglia/viking/commit/799f073c1ff89f8cd904d39e364fb9d402bce844 > > Tell me if anyone has any comments. I just copied the autotools stuff from > BlueMarble, man that stuff is crazy :) I'm not sure how we're picking map > source IDs these days, I just picked a random number that wasn't being used > (29). Seems like these ids are kind of all over and hard to see what is > being used... > > I've also attached a patch made with 'git format-patch master'. Or I guess I > still have permissions to write directly to the SF git repo... haven't done > it in a few years ... > > Evan > > -- > 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/ -- 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!
Humh... I revised my position. My patch now use XDG_DATA_HOME and XDG_DATA_DIRS. 2012/5/4 Guilhem Bonnefille : > 2012/5/3 Robert Norris : >>> I already have a patch that add the following beahviour to viking: >>> - loop over a given list of directory to look for the differents >>> extension files (maps.xml, external_tools.xml, goto_tools.xml). >>> - if $VIKING_CONFIG_PATH is set, it is parsed instead of a built-in list >>> For the moment, I do not load maps*.xml files (next patch?). >> >> Again I would advocate trying to use appropriate $XDG_* env vars instead of >> using a newly made up one > > Sorry, i did not replied to your previous mail. $XDG_* env vars seems > nice. Nevertheless, I think it's not really clean to use such var env, > while viking.conf is still located in .viking and not an XDG compliant > directory. > >>> Now, it is time for fixing the patch: >>> - which directories to definitively look for? >>> - what exact data should we put in the soonly deployed maps.xml, >>> external_tools.xml, goto_tools.xml? >>> - where to deploy these files? >> >> >>> For the directories to look for, I think $(pkgdatadir) as provided by >>> autoconf/automake is the good one. Can someone confirm this option? >>> For "/etc" related I will use @sysconfigdir@. >>> >>> For the data, I plan to ship all example given (we already have an >>> example file) + all maps declared in wiki. >>> Good idea? Too many data? >> >> I can't decide either way. >> >>> >>> And finally, at the "install" stage, I plan to deploy these data in >>> @pkgdatadir@. I imagine it is the better for packagers. Note that this >>> is the directory used by other Gtk application to ship their .ui >>> files. >>> >>> Please, feel free to comment these choice. Note that before pushing, I >>> will share my patch on this list before, for review. >>> -- >>> 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/ >> >> -- >> 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/ > > > > -- > Guilhem BONNEFILLE > -=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com > -=- mailto:guilhem.bonnefi...@gmail.com > -=- http://nathguil.free.fr/ -- 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/3 Robert Norris : >> I already have a patch that add the following beahviour to viking: >> - loop over a given list of directory to look for the differents >> extension files (maps.xml, external_tools.xml, goto_tools.xml). >> - if $VIKING_CONFIG_PATH is set, it is parsed instead of a built-in list >> For the moment, I do not load maps*.xml files (next patch?). > > Again I would advocate trying to use appropriate $XDG_* env vars instead of > using a newly made up one Sorry, i did not replied to your previous mail. $XDG_* env vars seems nice. Nevertheless, I think it's not really clean to use such var env, while viking.conf is still located in .viking and not an XDG compliant directory. >> Now, it is time for fixing the patch: >> - which directories to definitively look for? >> - what exact data should we put in the soonly deployed maps.xml, >> external_tools.xml, goto_tools.xml? >> - where to deploy these files? > > >> For the directories to look for, I think $(pkgdatadir) as provided by >> autoconf/automake is the good one. Can someone confirm this option? >> For "/etc" related I will use @sysconfigdir@. >> >> For the data, I plan to ship all example given (we already have an >> example file) + all maps declared in wiki. >> Good idea? Too many data? > > I can't decide either way. > >> >> And finally, at the "install" stage, I plan to deploy these data in >> @pkgdatadir@. I imagine it is the better for packagers. Note that this >> is the directory used by other Gtk application to ship their .ui >> files. >> >> Please, feel free to comment these choice. Note that before pushing, I >> will share my patch on this list before, for review. >> -- >> 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/ > > -- > 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/ -- 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!
For the directories to look for, I think $(pkgdatadir) as provided by autoconf/automake is the good one. Can someone confirm this option? for files provided by viking tarball, only For "/etc" related I will use @sysconfigdir@. for machine-wide viking config, sounds good. This should default to /etc/viking somehow (or $prefix/etc/viking), rather than bare etc, if there is more than 'viking.conf' (which there is, it seems). I suggest "~/.viking/etc" for per-user config files parallel to the above. pgp9Tfautnp4b.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/
Re: [Viking-devel] RIP msrmaps.com/terraserver; welcome CalTopo!
> > Hi, > > I already have a patch that add the following beahviour to viking: > - loop over a given list of directory to look for the differents > extension files (maps.xml, external_tools.xml, goto_tools.xml). > - if $VIKING_CONFIG_PATH is set, it is parsed instead of a built-in list > For the moment, I do not load maps*.xml files (next patch?). Again I would advocate trying to use appropriate $XDG_* env vars instead of using a newly made up one > Now, it is time for fixing the patch: > - which directories to definitively look for? > - what exact data should we put in the soonly deployed maps.xml, > external_tools.xml, goto_tools.xml? > - where to deploy these files? > For the directories to look for, I think $(pkgdatadir) as provided by > autoconf/automake is the good one. Can someone confirm this option? > For "/etc" related I will use @sysconfigdir@. > > For the data, I plan to ship all example given (we already have an > example file) + all maps declared in wiki. > Good idea? Too many data? I can't decide either way. > > And finally, at the "install" stage, I plan to deploy these data in > @pkgdatadir@. I imagine it is the better for packagers. Note that this > is the directory used by other Gtk application to ship their .ui > files. > > Please, feel free to comment these choice. Note that before pushing, I > will share my patch on this list before, for review. > -- > 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/ -- 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!
Oops... I forgive other: what about Windows and Mac users? Is there something similar? 2012/5/3 Guilhem Bonnefille : > Hi, > > I already have a patch that add the following beahviour to viking: > - loop over a given list of directory to look for the differents > extension files (maps.xml, external_tools.xml, goto_tools.xml). > - if $VIKING_CONFIG_PATH is set, it is parsed instead of a built-in list > For the moment, I do not load maps*.xml files (next patch?). > > Now, it is time for fixing the patch: > - which directories to definitively look for? > - what exact data should we put in the soonly deployed maps.xml, > external_tools.xml, goto_tools.xml? > - where to deploy these files? > > For the directories to look for, I think $(pkgdatadir) as provided by > autoconf/automake is the good one. Can someone confirm this option? > For "/etc" related I will use @sysconfigdir@. > > For the data, I plan to ship all example given (we already have an > example file) + all maps declared in wiki. > Good idea? Too many data? > > And finally, at the "install" stage, I plan to deploy these data in > @pkgdatadir@. I imagine it is the better for packagers. Note that this > is the directory used by other Gtk application to ship their .ui > files. > > Please, feel free to comment these choice. Note that before pushing, I > will share my patch on this list before, for review. > -- > Guilhem BONNEFILLE > -=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com > -=- mailto:guilhem.bonnefi...@gmail.com > -=- http://nathguil.free.fr/ -- 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!
Hi, I already have a patch that add the following beahviour to viking: - loop over a given list of directory to look for the differents extension files (maps.xml, external_tools.xml, goto_tools.xml). - if $VIKING_CONFIG_PATH is set, it is parsed instead of a built-in list For the moment, I do not load maps*.xml files (next patch?). Now, it is time for fixing the patch: - which directories to definitively look for? - what exact data should we put in the soonly deployed maps.xml, external_tools.xml, goto_tools.xml? - where to deploy these files? For the directories to look for, I think $(pkgdatadir) as provided by autoconf/automake is the good one. Can someone confirm this option? For "/etc" related I will use @sysconfigdir@. For the data, I plan to ship all example given (we already have an example file) + all maps declared in wiki. Good idea? Too many data? And finally, at the "install" stage, I plan to deploy these data in @pkgdatadir@. I imagine it is the better for packagers. Note that this is the directory used by other Gtk application to ship their .ui files. Please, feel free to comment these choice. Note that before pushing, I will share my patch on this list before, for review. -- 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!
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/
Re: [Viking-devel] RIP msrmaps.com/terraserver; welcome CalTopo!
> > 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. My 2p or 2cents (American or Euro) Since Viking is a desktop program, to me that means it is effectively is for the sole user of the that machine. However, it could best to move all current code definitions of maps into a central maps.xml - and then load in your own maps.xml afterwards. 1. This simplifies the code as Evan notes 2. It's 'easier' to add new ones for developers. 3. The end user can remove any one they don't want to use by editing the system file. 4. The end user can override the system ones if they choose to with their own config. Checking each of XDG_DATA_DIRS for /viking/maps.xml files See: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html Albeit there still needs some way of choosing the default - e.g. Mapquest entry - but if not there - then use the first in the list of available maps. > 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. > This seems a lot of complexity, just load a couple of files in a predefined order - system ones then user ones. It would be really good (for the end user) if one could edit/reload the map configuration from within Viking itself, without having to fiddle with text file configurations directly. Not that I'm volunteering to write such code :) But this should make it *much more* obvious the default maps can be changed. However I suspect most people who use Viking would be capable of fiddling with their maps.xml (and probably know of this possibility or find out via the Wiki) Viking is *not* that simple to use - especially for new users ( I won't go into it's shortfalls ATM - perhaps I should write a blog post... ) Maybe we should just stick CalTopo in - as in USA is important (large population + probably many Viking users). Whether that's via code - as it is the more expedient way or via a future deployed maps.xml (or maps-us.xml etc..) Only if anyone else expresses an interest, would I think it's worth trying to do 'VIKING_CONFIG_PATH' or command line options (not that I expect many desktop users to invoke Viking via the command line). -- 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 : > 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 > wrote: >> >> 2012/5/1 Evan Battaglia : >> >> 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
Re: [Viking-devel] RIP msrmaps.com/terraserver; welcome CalTopo!
2012/5/1 Evan Battaglia : >> 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!
> 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? Evan On Mon, Apr 30, 2012 at 1:21 AM, Guilhem Bonnefille < guilhem.bonnefi...@gmail.com> wrote: > Hi Evan, > > 2012/4/29 Evan Battaglia : > > [snip] > > Anyway, my commit to add support for it is here: > > > https://github.com/evanbattaglia/viking/commit/799f073c1ff89f8cd904d39e364fb9d402bce844 > > > > Tell me if anyone has any comments. I just copied the autotools stuff > from > > BlueMarble, man that stuff is crazy :) I'm not sure how we're picking map > > source IDs these days, I just picked a random number that wasn't being > used > > (29). Seems like these ids are kind of all over and hard to see what is > > being used... > > > > I've also attached a patch made with 'git format-patch master'. Or I > guess I > > still have permissions to write directly to the SF git repo... haven't > done > > it in a few years ... > > I did not test your patch, simply read it. > > You do not have to credit me on the two new files, they are yours. :-) > > You can find a (quite) complete list of maps here: > http://sourceforge.net/apps/mediawiki/viking/index.php?title=Maps > Can be a good source to check if an internal id is free or not. You > can also describe your new source as a simple configuration. This can > allow people to use it even with an older version of viking. > > About the integration of such map inside the viking code, I do not > have clear position. 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? > > Any opinion? How to decide wether a map as to be a built-in and when a > simple configuration is enough? > > Best regards, > -- > 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!
Hi Evan, 2012/4/29 Evan Battaglia : > [snip] > Anyway, my commit to add support for it is here: > https://github.com/evanbattaglia/viking/commit/799f073c1ff89f8cd904d39e364fb9d402bce844 > > Tell me if anyone has any comments. I just copied the autotools stuff from > BlueMarble, man that stuff is crazy :) I'm not sure how we're picking map > source IDs these days, I just picked a random number that wasn't being used > (29). Seems like these ids are kind of all over and hard to see what is > being used... > > I've also attached a patch made with 'git format-patch master'. Or I guess I > still have permissions to write directly to the SF git repo... haven't done > it in a few years ... I did not test your patch, simply read it. You do not have to credit me on the two new files, they are yours. :-) You can find a (quite) complete list of maps here: http://sourceforge.net/apps/mediawiki/viking/index.php?title=Maps Can be a good source to check if an internal id is free or not. You can also describe your new source as a simple configuration. This can allow people to use it even with an older version of viking. About the integration of such map inside the viking code, I do not have clear position. 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? Any opinion? How to decide wether a map as to be a built-in and when a simple configuration is enough? Best regards, -- 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/
