Re: [Viking-devel] Viking 1.9 Released

[Greg Troxel]

Robert Norris  writes:

> # Viking 1.9 - released 2020-03-20

In NEWS it says 1.8 I think.

I have updated pkgsrc, and it builds and runs on NetBSD 9 amd64.  With
gtk2 I got a build error, but after flipping to gtk3 the build was ok
and it worked, so I decided that was good enough, as people will be
talking about deleting gtk2 as soon as they are done purging python2.

There was a new dependency of json-glib, but that was not a problem,
just unexpected.


As always, thanks for engaging in the glorious struggle to keep viking
working and getting better as the world changes around it.


signature.asc
Description: PGP signature
___
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] Calculating UTM coordinate from screen position

[Greg Troxel]

Robert Norris  writes:

> The projection is done based on the zone at the center position.
>
> The zone is for the east<->west, whereas the designation letter is the 
> latitude band, being 8 degrees wide, which Viking currently shows as part of 
> the UTM readout.
>
> This use of the from screen position is most likely for the UTM
> position readout of the mouse pointer location, so when viewing on a
> sufficiently zoomed out manner (e.g. around country / US state levels)
> the coverage will cross these bands.

What I meant is that looking at projected coordinates (screen position)
in a scheme like this, one will get values in the same zone as the
center.  These are valid, but are not necessarily the values that would
be obtained by converting to geodetic and back, choosing a zone anew.

Either approach seems legitimate in terms of display.


___
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] Calculating UTM coordinate from screen position

[Greg Troxel]

Robert Norris  writes:

> I don't think Viking is used much in UTM as a general purpose viewer -
> since there aren't many if any tile sources in UTM projections. More
> typical is probably using a GeoRef layer to view an existing map image
> (this is the way I use it in order to test it's working); although I
> suppose one could get a image that goes across letter boundaries.
>
> I don't know what the solution is, in working in purely UTM coordinates.
> Also the current screen conversion doesn't take into account the UTM 
> 'anomalies' around Svalbard.
>
> A possible way around it would be convert the center into Lat/Lon,
> workout the input screen position in Lat/Lon and then convert back
> into UTM.

If the screen projection really is UTM, then it is in some zone as
determined somehow, arguably best by the proper zone for the central
point.  This lets you convert lat/lon to UTM even if you end up in the
wrong zone.  Most conversion code lets you force the zone, as opposed to
finding out the natural zone.


___
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] another portability nit

[Greg Troxel]

On 2020-03-21 09:07, Robert Norris wrote:


NB We spoke about the $RANDOM issue back in November 2016.


I had a note in the patchfile that I might have sent mail, but not 100% 
clear.  I had just updated pkgsrc to 1.8 and found the problem still 
there.  This one turns out to be quite different, but every previous 
instance of non-POSIX constructs in configure has turned out to be 
non-portable constructs in configure.ac, so unfortunately I blindly 
assumed that was the case.



So I suppose you are using the one of the compressed releases of VIking and 
running the './configure' file provided directly? Since the 'configure' file 
itself is generated on my Debian Linux machine I guess it therefore thinks 
$RANDOM is available.


I am using the release tarball, which seems like the standard approach 
for users and packaging.  (My understanding is that autoconf intends to 
produce configure scripts that rely only on POSIX sh, so it would be a 
bug if when run on Debian it used $RANDOM.)



Perhaps you should try running the autotools stuff directly to generate the 
configure file for your system(s).
c.f. When acquiring Viking directly from source code repository there is no 
configure file; so here one needs to run the ./autogen.sh script to generate 
one. However ATM autogen.sh is not in the compressed releases.


I updated my git clone and ran autogen, and the RANDOM appeared, just 
like in the release tarball.



I don't why Viking would be any different to any other typical program 
autotools build systems though.


I now don't think Viking is different here.

It turns out the problem is that ${prefix}/share/aclocal/intltool.m4, 
installed by intltool-0.51.0, contains $RANDOM.  So any configure script 
that uses the intltool macro will pull that in and inherit the bug.


intltool's code only actually uses $RANDOM for obsolete versions of 
intltool, so this won't actually cause problems, except in a -Werror 
sort of way which is the present case.


I put a longer note in our patchfile, including a todo to file a bug 
with intltool.  I think it's quite likely that text will stop me from 
writing again in 2024!


Thanks for taking the time to think about this,
Greg


___
Viking-devel mailing list
Viking-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viking-devel
Viking home page: http://viking.sf.net/

[Viking-devel] another portability nit

[Greg Troxel]

In configure, we patch

  $(INTLTOOL_V_MERGE)_it_tmp_dir=tmp.intltool.$$RANDOM

to

  $(INTLTOOL_V_MERGE)_it_tmp_dir=tmp.intltool.not-random

$RANDOM is a bashism not specified by POSIX, and not available in a
number of shells.  (It is available in NetBSD's /bin/sh, but pkgsrc has
a bunch of portability checks because pkgsrc does not require that a
platforms /bin/sh have anything beyond what POSIX requires.)


I'd suggest changing to


  $(INTLTOOL_V_MERGE)_it_tmp_dir=tmp.intltool.viking.

I have not tested; I am guessing this passes $$ to the shell after make
quoting.

That should be enough not to collide, even if there are multiple viking
builds happening at once.



___
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] pkgsrc updated to 1.8, stray visibility defines fix

[Greg Troxel]

Robert Norris  writes:

>> #define _XOPEN_SOURCE
>
> Simply removing it is the best option, as it compiles and runs on Linux OK 
> without this line.
> I've no idea why it was put in, but the line originates from the initial code 
> creation back in 2005.
> Some background on this define:
>
> https://stackoverflow.com/questions/5378778/what-does-d-xopen-source-do-mean
>
> So as Viking doesn't use strdup() directly (it uses g_() versions when 
> available), any usage (or attempt thereof) of _XOPEN_SOURCE is unnecessary.
> Even in the very first version of gpx.c, strdup() was not used.
>  
> Admittedly I always wondered a little about this define really meant/what it 
> was used for, but never bothered to investigate further as it appeared to 
> 'work'.
>
> PS. Thanks as always for your pkgsrc efforts

2005 was a really long time ago.  So definitely just take it out, and if
something turns out to be needed on solaris, somebody can figure out the
minimal change.


The real point of these defines is to have a program declare the
specification it is written so, so that operating systems will hide all
symbols and functions etc. that are not mandated by that standard.  This
checks that the program really is portable.

Instead, they often get used when some operating system does not make
available extensions by default.  However, more or less the norm today
is that if POSIX specifies it, and the OS doesn't provide it, the OS
should be fixed (and usually is).


___
Viking-devel mailing list
Viking-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viking-devel
Viking home page: http://viking.sf.net/

[Viking-devel] pkgsrc updated to 1.8, stray visibility defines fix

[Greg Troxel]

I have updated pkgsrc to 1.8.  I haven't really shaken it out, but it
starts up fine on NetBSD 8 amd64.

I have a stray patch from before.  I am not sure what's going on with
the original visibility define, and why it needs to be different on
sunos.

In general, I lean to not having any visibility defines unless
they are really necessary and then only guarded with ifdefs for where
needed, as once you add one other symbols are hidden.

Also, I typically find that they are added and then not removed, so I
wonder if just removing _XOPEN_SOURCE line results in an ok build on
modern linux.  If not, I would be nice to a) ifdef guard it for linux
and version, and 2) explain what the failure is.

I built on NetBSD 8 w/o any of this (both _XOPEN_SOURCE lines and all
the ifs just plain removed) and it built fine.

It may be that on sunos, not defining _XOPEN_SOURCE is ok, but defining
it without a value is bad.

Thanks,
Greg




$NetBSD: patch-src_gpx.c,v 1.3 2020/03/18 00:02:46 gdt Exp $

This is a build fix for SunOS.
\todo Explain why, and if the new __sun way is correct in general.
\todo File upstream.

--- src/gpx.c.orig  2020-01-30 08:34:43.0 +
+++ src/gpx.c
@@ -26,7 +26,12 @@
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  *
  */
+
+#if defined(__sun)
+#define _XOPEN_SOURCE 600
+#else
 #define _XOPEN_SOURCE /* glibc2 needs this */
+#endif
 
 #include "gpx.h"
 #include "viking.h"


___
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] Released Version 1.7

[Greg Troxel]

Robert Norris  writes:

>> I am trying to make a minimal update first.
>> I had to disable geoclue and oauth, both listed in the announcement.
>
>> There was a new requirement for nettle, not explained.  I added
>> --disable-nettle as suggested.
>
> libnettle is used instead of having a copy of MD5 hash code
>
> This is used in the thumbnail cache (the cache filename) for images 
> associated with waypoints.
>
> Some kind of fallback is used when nettle is disabled, but unlikely to 
> integrate well with other programs that use the thumbnail cache.

Thanks.  Maybe it's just me, but it would be nice to have a more
descriptive list of optional dependencies that explains briefly (like
you just did) the consequences of having or not having them.

In the case of nettle it's gmp and "only" 20 MB, and seems to be needed
for a few other things, so it doesn't seem bad to just add it to the
package dep list always.


___
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] Released Version 1.7

[Greg Troxel]

I'm updating the pkgsrc package.

I am trying to make a minimal update first.
I had to disable geoclue and oauth, both listed in the announcement.

There was a new requirement for nettle, not explained.  I added
--disable-nettle as suggested.

I see a "test ==" patch was applied at some point - thanks.

And it works on NetBSD/8 amd64, over remote X.

I'll have some nits, but this is great!





___
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] 1.6.2 changes from 1.6

[Greg Troxel]

I tried adding gtk-doc as a dependency and doing --enable-gtk-doc, but
then it failed to build; I have mapnik disabled (because I haven't
gotten to checking it in packaging and trying it as an option, not
because I don't want to), and apparently the gtk-scan looks for the
symbol even though the build didn't make it.   Not a big deal, but I'm
not really sure how I should be packaging things.



signature.asc
Description: PGP signature
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Viking-devel mailing list
Viking-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viking-devel
Viking home page: http://viking.sf.net/

[Viking-devel] 1.6.2 buglets

[Greg Troxel]

I know I should make separate commits and push a branch, but I have the
following in pkgsrc.  The issues are the use of $RANDOM and ==, both of
which are outside of POSIX's sh specification and hence unportable.  ==
is easy; it should just be = and there is no downside.  RANDOM may be
harder, but I don't see a lot of configure collisions and it seems $$
(pid) or mkstemp is the sticking-to-posix way.

$NetBSD$

--- configure.orig  2015-11-24 22:18:34.0 +
+++ configure
@@ -8585,7 +8585,7 @@ INTLTOOL_SOUNDLIST_RULE='%.soundlist: %.
 if test "$INTLTOOL_APPLIED_VERSION_AS_INT" -ge 5000; then
   INTLTOOL_XML_NOMERGE_RULE='%.xml:   %.xml.in   $(INTLTOOL_MERGE) 
; $(INTLTOOL_V_MERGE)LC_ALL=C $(INTLTOOL_MERGE) $(INTLTOOL_V_MERGE_OPTIONS) -x 
-u --no-translations $< $@'
 else
-  INTLTOOL_XML_NOMERGE_RULE='%.xml:   %.xml.in   $(INTLTOOL_MERGE) 
; $(INTLTOOL_V_MERGE)_it_tmp_dir=tmp.intltool.$$RANDOM && mkdir $$_it_tmp_dir 
&& LC_ALL=C $(INTLTOOL_MERGE) $(INTLTOOL_V_MERGE_OPTIONS) -x -u $$_it_tmp_dir 
$< $@ && rmdir $$_it_tmp_dir'
+  INTLTOOL_XML_NOMERGE_RULE='%.xml:   %.xml.in   $(INTLTOOL_MERGE) 
; $(INTLTOOL_V_MERGE)_it_tmp_dir=tmp.intltool.not-random && mkdir $$_it_tmp_dir 
&& LC_ALL=C $(INTLTOOL_MERGE) $(INTLTOOL_V_MERGE_OPTIONS) -x -u $$_it_tmp_dir 
$< $@ && rmdir $$_it_tmp_dir'
 fi
   INTLTOOL_XAM_RULE='%.xam:   %.xml.in   $(INTLTOOL_MERGE) 
$(wildcard $(top_srcdir)/po/*.po) ; $(INTLTOOL_V_MERGE)LC_ALL=C 
$(INTLTOOL_MERGE) $(INTLTOOL_V_MERGE_OPTIONS) -x -u -c 
$(top_builddir)/po/.intltool-merge-cache $(top_srcdir)/po $< $@'
   INTLTOOL_KBD_RULE='%.kbd:   %.kbd.in   $(INTLTOOL_MERGE) 
$(wildcard $(top_srcdir)/po/*.po) ; $(INTLTOOL_V_MERGE)LC_ALL=C 
$(INTLTOOL_MERGE) $(INTLTOOL_V_MERGE_OPTIONS) -x -u -m -c 
$(top_builddir)/po/.intltool-merge-cache $(top_srcdir)/po $< $@'
@@ -12428,7 +12428,7 @@ $as_echo "no" >&6; }
 fi
 
 
- if test "x$XP" != "x" && test -r "$DB2MAN_XSL" && test "${HAVE_SCROLLKEEPER}" 
== "yes" ; then
+ if test "x$XP" != "x" && test -r "$DB2MAN_XSL" && test "${HAVE_SCROLLKEEPER}" 
= "yes" ; then
   GEN_MANPAGES_TRUE=
   GEN_MANPAGES_FALSE='#'
 else



signature.asc
Description: PGP signature
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Viking-devel mailing list
Viking-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viking-devel
Viking home page: http://viking.sf.net/

[Viking-devel] 1.6.2 changes from 1.6

[Greg Troxel]

I am (belatedly) updating the viking package in pkgsrc from 1.6 to
1.6.2.  I am seeing the following diff in the list of installed
packages.  I realize there are two new translations, but there are no
more help files and there is viking-C.omf instead of datasources.xml.

Is this expected?  Or a clue that some help-making program is required
but my version is undeclared as a dependency or out of date?

--- PLIST   2015-09-01 10:05:05.0 -0400
+++ PLIST.new   2016-11-02 19:53:16.0 -0400
@@ -1,47 +1,9 @@
 bin/viking
 share/applications/viking.desktop
-share/gnome/help/viking/C/attribution.xml
-share/gnome/help/viking/C/commandline.xml
-share/gnome/help/viking/C/figures/DEM_file_info_dialog.png
-share/gnome/help/viking/C/figures/LayersTracksList.png
-share/gnome/help/viking/C/figures/LayersTracksStatistics.png
-share/gnome/help/viking/C/figures/Maps_download_region_dialog.png
-share/gnome/help/viking/C/figures/Track_elevation_graph.png
-share/gnome/help/viking/C/figures/Track_properties.png
-share/gnome/help/viking/C/figures/Track_statistics.png
-share/gnome/help/viking/C/figures/Trackpoint_edit_dialog.png
-share/gnome/help/viking/C/figures/Viking-OSM-CycleMap-ManyTracks.jpg
-share/gnome/help/viking/C/figures/WaypointsList.png
-share/gnome/help/viking/C/figures/addtr_18.png
-share/gnome/help/viking/C/figures/addwp_18.png
-share/gnome/help/viking/C/figures/customize_toolbar_dialog.png
-share/gnome/help/viking/C/figures/demdl_18.png
-share/gnome/help/viking/C/figures/edtr_18.png
-share/gnome/help/viking/C/figures/edwp_18.png
-share/gnome/help/viking/C/figures/geomove_18.png
-share/gnome/help/viking/C/figures/geozoom_18.png
-share/gnome/help/viking/C/figures/map_tile_info_dialog.png
-share/gnome/help/viking/C/figures/mapdl_18.png
-share/gnome/help/viking/C/figures/mover_22.png
-share/gnome/help/viking/C/figures/properties_degree.png
-share/gnome/help/viking/C/figures/properties_units.png
-share/gnome/help/viking/C/figures/route_finder_18.png
-share/gnome/help/viking/C/figures/ruler_18.png
-share/gnome/help/viking/C/figures/select_18.png
-share/gnome/help/viking/C/figures/showpic_18.png
-share/gnome/help/viking/C/figures/trw_statusbar.png
-share/gnome/help/viking/C/figures/vik_new_route_18.png
-share/gnome/help/viking/C/figures/zoom_18.png
-share/gnome/help/viking/C/figures/zoom_status_popup.png
-share/gnome/help/viking/C/georef_layer.xml
-share/gnome/help/viking/C/legal.xml
-share/gnome/help/viking/C/mapnik_rendering_layer.xml
-share/gnome/help/viking/C/recommends.xml
-share/gnome/help/viking/C/viking.xml
 share/icons/hicolor/48x48/apps/viking.png
 share/locale/ast/LC_MESSAGES/viking.mo
+share/locale/ca/LC_MESSAGES/viking.mo
 share/locale/cs/LC_MESSAGES/viking.mo
 share/locale/da/LC_MESSAGES/viking.mo
 share/locale/de/LC_MESSAGES/viking.mo
@@ -68,10 +30,11 @@
 share/locale/sk/LC_MESSAGES/viking.mo
 share/locale/sl/LC_MESSAGES/viking.mo
 share/locale/sv/LC_MESSAGES/viking.mo
+share/locale/tr/LC_MESSAGES/viking.mo
 share/locale/uk/LC_MESSAGES/viking.mo
 share/locale/zh_CN/LC_MESSAGES/viking.mo
 share/locale/zh_TW/LC_MESSAGES/viking.mo
-share/omf/viking/viking-C.omf
+share/viking/datasources.xml
 share/viking/external_tools.xml
 share/viking/goto_tools.xml
 share/viking/latlontz.txt



signature.asc
Description: PGP signature
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
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] Four more questions about Viking source code

[Greg Troxel]

Robert Norris  writes:

> To be honest I don't know what/why/how the use of this 'One Zone' for
> UTM helps anything.

I agree UTM is used less and less as there are fewer maps in UTM (vs
maps that used to be in UTM reprojected into Web Mercator).

When using UTM, you can get awkwardness when the displayed portion
crosses a zone boundary.   It makes sense to decide the zone based on
the center, and then convert all the rest of the screen to/from geodetic
coordinates based on that single zone.This will result in some UTM
coordinates with the wrong zone, basically extended from the next one,
instead of the UTM coordinates you'd get from the geodetic coordinates,
but it should still render ok.  And if a UTM-style TMS-ish source has
tiles in that beyond-the-edge region, it should work ok.

I could well be misunderstanding.




signature.asc
Description: PGP signature
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
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] RFC: what about SourceForge?

[Greg Troxel]

My $0.02, and sorry if this is redundant:

- I am no longer comfortable with sourceforge.

- Free Software should be hosted by a charitable non-profit (501c3) that
  has advancing Free Software as a substantial part of its mission.
  That does not include github :-)

- I agree that self-hosting is too painful.

- Mailinglists are necessary, as are areas to put release tarballs.  I
  think it's unhelpful of github to run projects and provide neither of
  these.

- I tend to recommend savannah.nongnu.org, which has repos, bugtrackers,
  and lists, and is run by FSF.  I've been involved with quagga that has
  migrated to savannah, and it's been reasonable.


signature.asc
Description: PGP signature
--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551=/4140___
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] RFC: what about SourceForge?

[Greg Troxel]

Robert Norris  writes:

>> - Mailinglists are necessary, as are areas to put release tarballs. I
>> think it's unhelpful of github to run projects and provide neither of
>> these.
>
> Github do offer release tarballs - automatically generated against
> tagged versions of the repository.

As in they run "make distcheck", which has configure from configure.ac?
I had the impression they only offered tarballs of exactly what was in
the repo.  And it seemed their names and unpacking did not match the
usual open-source norm that the file viking-1.6.0.tar.gz unpacks to
viking-1.6.0/.

I see that the release tarball
  - is missing configure
  - is called and unpacks to viking-viking-1.6.0

compared to what "make dist" would do.

> See https://github.com/viking-gps/viking/releases
>
> It should be possible to guess the URL for scripted a download that follows a 
> known pattern for new version releases.
>
>> - I tend to recommend savannah.nongnu.org, which has repos, bugtrackers,
>> and lists, and is run by FSF. I've been involved with quagga that has
>> migrated to savannah, and it's been reasonable.
>
> Well I've just toyed with the Github setup primarily because that's
> where I've (and lots of people) have accounts - so there is a network
> effect to consider.

True, but fsf accounts are easy, and don't require one to agree to
indemnify a for-profit company.



signature.asc
Description: PGP signature
--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551=/4140___
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] RFC: what about SourceForge?

[Greg Troxel]

Guilhem Bonnefille  writes:

> So I think it is probably time to leave this hosting for somewhere else.
> What's your opinions?

Agreed it's time to go.

> Any idea for the best new hosting solution?
> - Github
> - Bitbucket
> - GitLab
> - http://savannah.gnu.org/

Of these, I prefer savannah.nongnu.org (unless viking becomes a GNU
project, which would be ok too).  Generally, I think that Free Software
projects should be hosted by a charitable organization whose charter is
the advancement of Free software.

> - some hosting solution related to GPS/Geoinformation

There is osgeo.org, I think.   I don't know if viking fits their mission
but it woudl be ok.

> - auto-hosting (if someone as space or money)

That's harder, and I don't think the project has critical mass for it.


pgpVAuDJlCf9u.pgp
Description: PGP signature
--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140___
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] Viking Map Generation with Mapnik C++ Library.

[Greg Troxel]

Robert Norris rw_nor...@hotmail.com writes:

 Tiles are cached in directory specified in the Mapnik Rendering layer
 property (it defaults to ~/.viking-maps/MapnikRendering - so for
 different stylesheets it's wise to change this to a specific directory
 per style) - the cache is always in the OSM Slippymap layout
 (zoom/x/y.png)

I have not yet gotten mapnik set up, so this may be confused, but if
it's possible to have viking specify the named stylesheet, and have that
be part of the cache name, that would be great.  Then one could have
multiple layers.  Basically my point is that local mapnik is not
actually specific - it's a rendering engine that can have multiple
styles.  So one might want a number of local layers, especially if
using this as part of hacking on stylesheets.


pgprdLROifnNw.pgp
Description: PGP signature
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
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] Viking Map Generation with Mapnik C++ Library.

[Greg Troxel]

Wow, that's very cool.

It would be really nice if the mapnik dependency could somehow be
additional rather than either/or.  From a packaging viewpoint, I'd like
to see a way to have

  base viking
  viking-mapnik

but perhaps what's unwarranted as it's not clear that mapnik is that
heavy.

Thinking about caching, it would seem that it might make sense to have
viking fetch tiles from a local mapnik server, but I guess you can
already do that with the way viking is now, and this is about having it
generate tiles on the fly without having the server part of the mapnik
stack set up.
And maybe if there is only one user, caching doesn't really that help
that much.

How do you find the render speed, and are these tiles cached like the
ones that are fetched?


pgpTt1vgXAVgI.pgp
Description: PGP signature
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
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] Windows - Removing GPSBabel from the Viking Install

[Greg Troxel]

That sounds fine; I think gpsbabel should not be included.For
packaging systems, it's far better to just make viking depend on
gpsbabel than to have an included copy, especially if there are security
issues in gpsbabel.

I would say that by default on Unix, it makes sense to try
$(PREFIX)/bin/gpsbabel, unless some other gpsbabel prefix is set at
configure time.


pgpyvSIQ8P781.pgp
Description: PGP signature
--
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk___
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] Segmentation fault with git HEAD

[Greg Troxel]

Nick Allen nick.allen...@gmail.com writes:

 Sorry, most of the technical stuff referred to is above my head, but I
 may be able to help with an explanation of why the technical people
 put a loop in.

 At one point, when the age limit for a tile was reached, and the
 programme was started, it immediately deleted the old tile(s) before
 it tried to download the new. No issue most of the time, but if for
 instance you downloaded tiles before going on a holiday so you could
 use viking whilst away but without internet, you could find after a
 week or so that all of your map tiles had deleted!

That's a good point.   So I think there needs to be two rules:

  if a tile is a wanted, and it's old enough (create data at the server)
  to be unfresh (30 days or at least 7, to be polite), fetch new, and
  **if successfull** replace

  if a tile has not been **read** (or written) in some long lifetime,
  then remove, and perhaps only if the tile cache is using too much
  space.  This lifetime should be more like 6m.

  perhaps have something that prunes the cache to no more than X MB,
  deleting the least-recently read/downloaded.



Separately, it would be cool to have a way to bring the OSM data and
render tiles on one's notebook.  For slow request rates (1 client) and a
smallish area, this should be doable resource wise and the big hurdle is
having packaging set up to make it easy.


pgpjw6FKGy8Ix.pgp
Description: PGP signature
--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk___
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] A shared tile cache

[Greg Troxel]

Robert Norris rw_nor...@hotmail.com writes:

 For the tile servers currently offered on the main osm.org website I would 
 name them:

 MapQuest_Open
 OSM_Cycle
 OSM_Humanitarian
 OSM_Mapnik
 OSM_Transport

sounds fine.

 Of course one could use spaces instead of underscores to make things 
 interesting... 

I hope you're joking.  My view is that spaces are highly unfriendly to
using command-line tools, and IMHO have no place in file or directory
names on a unix/posix system.
I do know how to write something like

  find . -type f -mtime +7 | xargs ls -ltr

so that it works with spaces.  But there's no reason to make people go
through that.



pgpWfumx9xUNX.pgp
Description: PGP signature
--
___
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] Proposed Minor Features

[Greg Troxel]

Robert Norris rw_nor...@hotmail.com writes:

 A deeper question is how maps.xml extension file is distributed, since
 Viking doesn't directly control this, although the data/maps.xml is
 designed to be installed into /usr/share/viking or whatever the path
 is.

I don't follow doesn't directly control this.  It seems that it's in
the release tarball, and the straightforward install installs it.  So
when a new maps.xml is in a release, and people update, they'll have the
new default config.  That seems obviously sensible.

 Note the Window's install doesn't do anything about it.

So that's broken :-)  But I don't think the windows' installer not doing
the right thing should matter much in what happens.

 ATM The maps.xml file could change rapidly but it probably won't be
 picked up by users until the next formal Viking release.

True, but that would be true of a list that was in the source code.  If
there's an urgent change, then a release could be made.

 I think anything added into data/maps.xml file should have 
 explicit permission.

Agreed; that sounds like a safe and polite policy.


pgpL2Q5ba0ni6.pgp
Description: PGP signature
--
___
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] A shared tile cache

[Greg Troxel]

Yuri D'Elia wav...@thregr.org writes:

 I'd like any of the developers to read this draft about a common shared
 cache that I'd like to implement in JOSM:

 https://josm.openstreetmap.de/wiki/SharedTileCache

Generally this seems sensible.  A few comments:

There should be a way to configure the max size used by the cache, or
maybe the min free space in the fs, or both.

There's an OSM, but really this isn't about OSM.  It's about TMS.
Bing isn't about OSM (even though they graciously let us edit based on
it).

So I'd use TMS rather than osm/tiles.

I think zoom/x/y is good.  I really don't like the way viking does it
now, which I can never easily remember.

A conversion program to read an old cache and move it to the new format
would be nice.  But for me not a big deal

A big issue is caching lifetime, in terms of when to recheck the server
vs just accessing without checking.  Your description of minimum tile
age seems to be this, but really the question is:

  what's the parameter that says if the difference between now and the
  time this tile was last verified to be valid is  X, then just use it.

  what is the mod date on the tile file?
- Origin server's generation timestamp (I like this)?
- When Fetched the first?
- When validated?

  when a tile is old enough to check, and the origin server says it's
  unmodified, how is this recorded?  Is there a second file?  In the
  .ini for the tile?  sqlite?


Your point about storing view count (and last view time) is a good one.
Probably LRU pruning would be good, maybe in a background process.


I don't mean to sound negative - my comments are pretty minor.


pgpNnXTwZMMo1.pgp
Description: PGP signature
--
___
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] Viking cache directory

[Greg Troxel]

  I'm also using JOSM heavily when contributing to OSM, and I'm trying to
  save on bandwidth by trying to share the imagery cache between them.

  I've already submitted the changes to JOSM's tracker, so that it simply
  creates a directory hierarchy in the classical on-disk tile format
  (Z/X/Y.png). JOSM adds some additional (useless) files into it, but
  that's about it.

I think sharing caches is a good idea.  I am guessing viking is a
relatively minor player in this area (but perhaps not).  So the idea of
letting JOSM be the defacto standard seems sensible.

  This way I can just symlink the directories between the two programs,
  which is a true boon.

One could even have viking look in the josm default area, and save to it
if possible, as default behavior.

  No user-visible changes, except that the old cache won't be used due to
  the name change.

I'm not sure that matters all that much.  But we could also make the new
behavior be:

  look in josm cache using new format
  look in viking cache in old format

  when saving new files, save in josm cache in new format

and that would provide a soft transition without a lot of code.

  


pgp_RAOc29zKc.pgp
Description: PGP signature
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech___
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] Alternative Route Finder Tool

[Greg Troxel]

It's great that you've added a feature.  I will try to find time to play
with it.

One comment, perhaps not apt, but it would be nice in the user interface
somehow for a user to be clearly aware of what information is being sent
off machine.

Another thought, is that OSMand has route calculation code that seems to
work pretty well, but with vector maps.  viking so far is only tile
maps.
So mabe that thought is off base.

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
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] Export via GPSbabel

[Greg Troxel]

Robert Norris rw_nor...@hotmail.com writes:

 I note it says IMPORTANT: Do not port to the new system if the
 application still needs to run under GNOME 2. Yelp 2 does not
 recognize the new help system.

 Is this important for us? I guess it means help wouldn't work on a
 MATE desktop.

My opinion is that while using gnomish things is the preferred path, to
the extent viking works with gtk2+ without needing all of gnome, that's
a big positive.  On my system the viking binary has a vast number of
libs but not gnome.  Perhaps I'm help-deficient.


pgpB_g4pXNfiU.pgp
Description: PGP signature
--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk___
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] Export via GPSbabel

[Greg Troxel]

  There is many things to do now. For example, allowing such export feature
  at the File-Export level. I also realized that this is one more export
  sub-menu entry. From the simple user point of view, a single Export
  dialog would certainly be better, allowing export to GPX, KML and any other
  file format known by gpsbabel or viking.

My opinion is that GPX is the one true format, and the others are useful
but can also be distracting.  So I think export to GPX should be able to
happen with no adtitional barriers.  Perhaps if gpx is preselected so
you can just hit return once the file is specified that's ok.

Basically I'm saying that logically I see options as

  export as gpx
  export to some other format, with a dialog to choose it




pgppDDbw30Dlh.pgp
Description: PGP signature
--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk___
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] Viking 1.5 Released

[Greg Troxel]

Robert Norris rw_nor...@hotmail.com writes:

 In order to support Relative Filenames (within primarily Viking files)
 and to (re)opening from where one last opened a file,
 Viking changes it's working directory to the last successfully opened
 directory.

At first glance this sounds broken.

 In the specific use case above, this can be worked around using pwd to
 ensure a full path filename is used e.g.:

 viking gpx.viking `pwd`/ETREX30-archive/2013-10-01\ *

That's a very unusual user interface.  I have never seen another
command-line program that took multiple filenames where each filename
was interpreted relative to the previous directory.

 See commit SF#3028797: Remember last directory used when saving /
 opening main files. for when this was introduced:
 https://sourceforge.net/p/viking/code/ci/317298355967f8465d2ddff8ae61b428a188778f

 Perhaps to the best way is mitigate this issue is to only change the
 directory only when opening a .vik file type.

Perhaps the previous-directory behavior should be strictly limited to
the cases where it is documented to do that.  I wonder if there is prior
art in other programs, and if some token in filenames should mean
relative to the .vik file.  But I can see how all filenames that don't
start with / in a .vik file should perhaps be relative to the .vik.


pgpszeiFC6C1w.pgp
Description: PGP signature
--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___
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] Viking 1.5 Released

[Greg Troxel]

Robert Norris rw_nor...@hotmail.com writes:

 After some thought, I think I was conflating two issues - such that
 the change directory answer, works only in limited cases.

 In the code, the use of GTK function
 gtk_file_chooser_set_current_folder() on opening files via the GUI,
 should address the SourceForge issue above - the change directory is I
 think unnecessary for this.

 Then to support relative paths, change to the directory when opening a
 .vik file but then simply return to the previous working directory
 (which it does not do ATM) so there no unintentional side effects.

 Thank you for taking time to report this issue.

 I will incorporate this fix in v1.5.1 with some other small fixes.

Thanks - that approach sounds good to me.

Separately, though, I think there may be a files-with-spaces bug,
because I got different behavior renaming them to a.gpx and b.gpx.  But
I could have been confused and changed too many things when trying to
check this.

I'll recheck with 1.5.1 and update pkgsrc then.

--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
___
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] Viking 1.5 Plan to Release by Sept 6th

[Greg Troxel]

Building (on netbsd-5, i386, gtk2+-2.24.17nb5), it basically seems to
work.   However, before I reran autogen and configure1, it failed with:

garminsymbols.c:117: error: 'wp_exit_large_pixbuf' undeclared here (not in a 
function)
garminsymbols.c:302: error: 'wp_helipad_large_pixbuf' undeclared here (not in a 
function)

even after make clean.


pgpawhRQ2fuC8.pgp
Description: PGP signature
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk___
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] Gnome Maps and GeoClue 2

[Greg Troxel]

Guilhem Bonnefille guilhem.bonnefi...@gmail.com writes:

 [1] https://wiki.gnome.org/Maps
 [2] http://cgit.freedesktop.org/geoclue

 The first event brings a new competitor to viking, depending the goals of
 the project. We can also consider the opportunity to revise the viking's
 goals in order to avoid duplication and start collaboration with this
 project. But we can stay as is and consider viking is a standalone
 application, a Gtk application and not a Gnome application.

I think viking should stay as a GTK program.  Gnome is a far
heavier-weight set of dependencies.I would expect that Gnome will
want to have a simple program that lacks confusing extra features,
intended for everyday users, whereas I see viking as aimed at map nerds
who are likely to be people who might even edit osm.

Looking at the page, this looks like a very early-stage program and I
see no discussion of GPX.  It's not clear how it differs from
  https://projects.gnome.org/emerillon/

I would suggest writing to the author and making them aware of viking.

 The second event can be the opportunity to add a new backend to viking. I
 already have such an idea, but never bring it to reality.

I looked into geoclue a while ago, probably in the context of gpsd.  I
don't remember exactly why (portability/packaging perhaps), but I
decided to stop pursuing it as it seemed the difficulty outweighed the
benefit.  If someone wants to write a patchset that lets viking use
geoclue as a way to center the map on one's position (vs. using gpsd),
that seems fine.  It appears to increase the required set of
dependencies (at least dbus), so I would tend to make it optional and
defaulting to off, but that's trivial for people building or packaging
to --enable-geoclue as they wish.



pgpFQcccjGZU9.pgp
Description: PGP signature
--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk___
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] Viking 1.4.2 Released

[Greg Troxel]

Packaging nit comments:

  I'd prefer to see sources in the same place, rather than a new
  directory.   But I've now adjusted pkgsrc to expect the version.   So
  in the future, please either move to a src directory that just has all
  versions, with no structural changes, or always use the version.

  The release switched to .tar.bz2 from .tar.gz.  This wasn't hard to
  switch, but it would be nice if that's now stable.

But other than these trivial-to-cope-with things, updating pkgsrc to
1.4.2 was trivial.  Thanks for pushing out the bugfix release.


pgp3qRyop0dJZ.pgp
Description: PGP signature
--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk___
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] translation update

[Greg Troxel]

Robert Norris rw_nor...@hotmail.com writes:

 Hello, 
 I step in the translation of viking after some time and I'm not sure  
 how to distinguish translation of 
 Track and Route. 

 Thank you very much for the translation efforts.

 I expect that basic difference is that Track comes from device (and  
 have timestamps), while Route I create in viking and later save to  
 device?

 Generally yes.

 I think of a Track as a path I've already been on, whereas a Route is
 a path I'm planning to take.

I can see the point in that distinction, but I see it as

  Track is a sequence of points that is perhaps a record of where a
  device has been.  It will typically but not always have elevations and
  timestamps.

  A route is a sequence of points that defines a way to get from here to
  there.  It's more of a recipe for getting somewhere

So I've pretty much agreed with Robert, but I find the
have-been/planning secondary to the kind of data it is.  One could
generate a track object from a route, with timestamps, to be the track
object that might be created from a person following the route.

You can think of a track as maybe having thousands of points, whereas a
route will typically have less than 10.


pgp7zVAkdqn55.pgp
Description: PGP signature
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb___
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] Viking 1.4 Released

[Greg Troxel]

Thanks for making a release.

It builds ok for me on NetBSD/i386 5.2_STABLE, but the install does
something odd.  I get:

$ ls -l work/.destdir/usr/pkg/share/gnome/help/viking/C/*

-rw-r--r--  1 gdt  users3902 Feb 11 20:03 
work/.destdir/usr/pkg/share/gnome/help/viking/C/legal.xml
-rw-r--r--  1 gdt  users  102280 Feb 11 20:03 
work/.destdir/usr/pkg/share/gnome/help/viking/C/viking.xml

work/.destdir/usr/pkg/share/gnome/help/viking/C/figures:
total 0
lrwxr-xr-x  1 gdt  users  21 Feb 11 20:03 *.jpg - ../../C/figures/*.jpg
lrwxr-xr-x  1 gdt  users  21 Feb 11 20:03 *.png - ../../C/figures/*.png

The problem seems to be that the *.jpg and *.png in help/Makefile.am
aren't getting expanded, so the files themselves aren't installed.
But then there was symlink with name *.jpg (an actual * in the filename).

With the following patch, I created a distfile and then got installed
figures.

commit 1f2516923e1d8cf4c8d63250a2c665cdb3df3b32
Author: Greg Troxel g...@lexort.com
Date:   Mon Feb 11 20:17:53 2013 -0500

help/Makefile.am: explicitly list figures.

diff --git a/help/Makefile.am b/help/Makefile.am
index 993e671..39ef073 100644
--- a/help/Makefile.am
+++ b/help/Makefile.am
@@ -14,5 +14,26 @@ dist-hook: get-icons doc-dist-hook
 DOC_MODULE = viking
 DOC_ENTITIES = legal.xml
 DOC_INCLUDES =
-DOC_FIGURES = figures/*.png figures/*.jpg
+DOC_FIGURES = \
+figures/addtr_18.png \
+figures/addwp_18.png \
+figures/demdl_18.png \
+figures/edtr_18.png \
+figures/edwp_18.png \
+figures/geomove_18.png \
+figures/geozoom_18.png \
+figures/map_tile_info_dialog.png \
+figures/mapdl_18.png \
+figures/mover_22.png \
+figures/properties_degree.png \
+figures/properties_units.png \
+figures/route_finder_18.png \
+figures/ruler_18.png \
+figures/select_18.png \
+figures/showpic_18.png \
+figures/trw_statusbar.png \
+figures/vik_new_route_18.png \
+figures/zoom_18.png \
+figures/zoom_status_popup.png \
+figures/Viking-OSM-CycleMap-ManyTracks.jpg
 DOC_LINGUAS =



pgpDGJAH3RtlM.pgp
Description: PGP signature
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb___
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] Imminent Viking 1.4 Release

[Greg Troxel]

Robert Norris rw_nor...@hotmail.com writes:

 The NetBSD nan patch is integrated; thanks again (I'm sure I sent this
 in a long time ago :-).

 Not sure when ( almost before my time! )

Sorry, I am confused.  It is in my local tree as a patch that I rebase,
and hence in the tarball I generated.

 make distcheck fails because it doesn't carry the CPPFLAGS from the
 invocation of configure. (Not sure if that's legimately a bug, and I
 don't expect any of you to fix it, but thought I'd mention it.)

 Interesting observation - my CPPFLAGS '-O0 -g' to make debugging easier.
 This is carried over into make distcheck, on a Debian Unstable AMD64
 make --version
 GNU make 3.86

Hmm.  I'll have to check that harder.

 Hmm, I think I have may have (indirectly) removed help from tarball in
 trying to simplify the build dependencies.

 In principal *only* a 'full' build generates the help PDF from the
 DocBook XML help - this is more of a Windows build
 simplification/avoidance, especially since the help Makefile relies on
 ../gnome-doc-utils.make' which may not be available - how to do
 conditional 'includes' in a Makefile anyone?).

 Unfortunately I now see that some of the 'src' depends on the XML if
 you have 'xsltproc' available on your system, as then documenters.h is
 generated by processing the xml file.

 Personally I find automake Makefile.am a horrid interwoven web of
 implicit Macros in an obscure language I don't use anywhere else - so
 it's hard to know what's right!

 I'd like to put the XML help in the source generation, but not
 actually use it in a build but how (given the Makefile has an
 include statement) ?

I'm not sure what to do, but I wonder if making the xsltproc part of the
build non-optional would help.  gtk doc tools and xsltproc are pretty
normal on any machine beefy enough to run viking, I would think.

I think gnome-doc-utils.make is available in the tarball.  Or are you
worried about Windows users building from source when they don't have
the doc tarballs?

I wonder if it's easy to omit the build rules, but to leave the
additions to the distfiles.


pgpy8DfhuXhAk.pgp
Description: PGP signature
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb___
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] [RFC] Releasing 1.4 before Christmas

[Greg Troxel]

Sounds fine to me, especially if you mean release what's on master vs
merge a ton of stuff and then release in a rush :-)



pgps8MaqruS8t.pgp
Description: PGP signature
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
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] Out of date maps

[Greg Troxel]

Phil phil_...@bigpond.com writes:

 On 09/11/12 11:06, Greg Troxel wrote:

 You could edit OSM to make your town up
 to date (without copying from proprietary maps, of course).  I've done
 that in my town, including entering trails, so that OSM is now the best
 map available.


 It turns out that adding a couple missing streets to OSM was nowhere 
 near as difficult as I had imagined.

I'm glad to hear it.  I hope you will find it fun to keep adding other
details.  I had a plan to make trail maps all by myself, long ago
(around 1999), but found it too daunting and never got to it, and was
glad to discover OSM, with tools, the database, and the community
already there.

A bit OT, but something I think most viking users would find
interesting: the program mkgmap (described on the OSM wiki) converts OSM
data to Garmin format, for use with etrex/nuvi/oregon/etc.  There is
also 'osmand' that runs on android to display maps (from offline vector
data).

 The only minor problem that I have not solved yet is how to have Viking 
 download the new map rather than use the existing cached map. If I 
 change the zoom level then the new map is downloaded. Perhaps the 
 simplest option is to delete the cached map?

Right-click on the 'mapnik' layer on the layer pane, and find 'reload
all onscreen maps'.  I think that will cause you to reload tiles that
you know are out of date, but not burden the server re-requesting
everything.

By default, viking caches OSM tiles for a long time, to comply with
OSM's tile usage policy (basically due to limited resources to provide
tile service to the world).


pgpcZJY2Ek3r3.pgp
Description: PGP signature
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov___
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] OSM License Attribution Change? (ODBL)

[Greg Troxel]

If we can make the attribution have a link to OSM's license page, then I
think we will have done reasonably at satisfying the intent.

--
How fast is your code?
3 out of 4 devs don\\\'t know how their code performs in production.
Find out how slow your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219672;13503038;z?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
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!

[Greg Troxel]

  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!

[Greg Troxel]

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/

[Viking-devel] [Greg Troxel] CVS commit: pkgsrc/geography/viking

[Greg Troxel]

In case anyone else is using pkgsrc...

I've updated pkgsrc to 1.3, and it works ok on NetBSD/i386.

---BeginMessage---
Module Name:pkgsrc
Committed By:   gdt
Date:   Tue Apr 24 01:19:58 UTC 2012

Modified Files:
pkgsrc/geography/viking: Makefile PLIST distinfo

Log Message:
Update to 1.3.

Viking 1.3 (2012-04-22)
New features since 1.2.2
* Be consistent in that track and waypoint list dialogs are always
  sorted alphabetically.
* Add OSM Transport map as a built in map option.
* Add supported MIME types to the desktop file specification.
* Add example script that can be used to upload a track as a route to
  a predefined GPS device.
* Display the average moving speed for a track in the track
  properties.
* Add ability to open a TrackWaypoint layer with another external
  program (default merkaartor).
* Add ability to open a TrackWaypoint layer with an external program
  (default JOSM).
* Use map default: OSM MapQuest tileserver.
* Add and use a preference for the associated image viewer program.
* Add and use KML File Export units option.
* Add ability to geotag images interpolating times against tracks.
* Acquire Geotag Images via TRW Layer
* Ensure vtl created in acquire operation runs post read stage.
* EXIF read implementation for geotagged images (libexif).
* Add new process stage for acquire methods.
* Enable reversing a track from the track menu.
* Display compact message on the statusbar for the selected trackpoint
  or waypoint. (SF#3314888)
* Enable multiple selection and deletion.
* Scale waypoint icons to give large or small icons as necessary.
* Add Yahoo! Maps webtool link.
* Extend webtools with a bounds version for the URL which takes four
  string parameters.
* Add webtool for Bing maps.
* Add Acquire OSM option into the Track/Waypoint layer operations.
* Add used geo-* scripts as they are public domain.
* Continue geocaching.com support via third party tools.
* Show elevation gain/loss on track creation 'tooltip' (as per
  SF#2838561 request), when such data is available.
* Automatically attempt to set elevation data from the DEM layer
  whilst a track is being created.
* When creating a track, display the total distance of track (via a
  tooltip like text) on the main display.
* Allow to import any file known by gpsbabel
* Add support for any device known by gpsbabel
* Add experimental support for GPSD_API_MAJOR_VERSION 5.
* Add ability to acquire GPS traces stored on OSM
* Enable copying layer/sublayer names as plain text, so that it can be
  pasted into external text handling applications.
* Enable getting of the statusbar from the window.
* On creating a new waypoint always attempt to auto set the altitude
  if DEM data is available.
* Enable the escape key to remove/reset the ruler tool.

Fixes since 1.2.2
* Remove Tiles@home support as the service has stopped.
* cleanup: Remove unused and out of date 'viking-remote' script and
  related files.
* cleanup: Remove *very* old documentation and don't bother
  distributing any of it which is all old.
* Fix Track Properties graph blob marker drawn at wrong elevation when
  elevation graphs have different min/max heights.
* Fix Track Properties graph DEM points drawn at wrong elevation when
  lowest elevation is not zero.
* Use an intermediary program which will invoke the system's default
  for opening images.
* Fix opening of external web sites via center method when the zoom
  level is less than 1 mpp.
* Fix crashing on opening a file via recent menu after a .vik file is
  opened.
* Fix too easy to accidently move a waypoint with an image with the
  select tool - must use shift key.
* Fix can not immediately select another layer if currently selected
  layer's visibility changes.
* Fix compilation with curl 7.21.7 (SF#3376584)
* Improve libgps test with the consistently available function:
  gps_close
* Fix GTK 2.24 combo box usage.
* Fix crashing on opening multiple files after a .vik file is opened.
* Solution for SF#2766266 - Give user feedback about OSM uploads
  (success/failure).
* Fix: send VLP's update signal when adding a layer
* Fix: Don't abort program when attempting webtool center with
  different x  y factors.
* Fix Join Tracks functionality.
* Fix SF#3408170: Selected Track Thickness is Always 1px
* Fix tracks not shown over map when map layer is dragged to the end
  of the treeview list.
* Refuse to load unsupported file types.
* Restore broken GPS power off command.
* Fix: SF#3042692 - Tiles May Get Deleted During Offline Usage.
* Fix some tracks elevation profile may display no altitude, despite
  all altitudes available in the track.
* Fix SF#3387590: Top Layer cannot be renamed
* Enable merging tracks without timestamps to other tracks that do not
  have timestamps. (SF#2886231)
* Prevent track merge by time requests when there are no other
  suitable tracks.
* Improve track name when split from Track Properties window.
* Replace 'Magic Scissors' by a more accurate name - 'Route Finder'.


To 

Re: [Viking-devel] skip-same patch

[Greg Troxel]

Nick Allen nick.allen...@gmail.com writes:

 All my tracks, hiking, car  cycle, are 1 second interval,  I
 frequently deal with multiple tracks created during the course of a
 days cycling or walking.

 The majority of my tracks are created by a Garmin Oregon 300. When I

That's basically what I do, with Oregon 450 or Etrex Vista HCx.

 Load the tracks (generally using file / append) my laptop screen dims

But, what I do is

  viking gpx.viking track.gpx waypoint.gpx

and start each time.  I don't try to have a huge viking file with all of
my tracks.


Are you loading many tracks, and then trying to figure out which ones
are ok to form a track to upload?  If you could quantify what causes
trouble that would help.

I also map in osm (user gdt), but I just draw in josm with a track in
the background.  (Most of the ways I draw for which there isn't good
imagery are in the woods, and being off 5m is totally unimportant
compared to having the geometry/connectivity and rough position right.)
I then look at later trips with viking, and if I see something that
needs mapping/fixing, I load that trace in josm.   (I don't upload gpx
tracks at all.)

  everything freezes for several seconds, but always recovers. If
 there are several tracks with many waypoints the programme may become

I am not sure what's going on here.   But I think that the issue is that
viking makes lots of requests to X, and the X server spends lots of CPU
time fulfilling them.   And viking may be triggering memory leaks in X
(but I have no evidence for that).

When it is slow, does top/etc. show that viking or X is using all the
cpu time, or something else, or ?

 slower but still functions. However, I need to save the file at an
 early stage, and then keep saving at regular intervals as I edit the
 tracks, combining them, removing duplicates, and uploading them to OSM
 etc. If I don't regularly save the whole laptop will freeze and not
 recover, necessitating holding the power button for a few seconds to
 switch it off, and then starting again. I don't have evidence of this,

In theory viking cannot cause this.  In practice I bet there is a kernel
or X bug that is being triggered by viking.  Does your computer have
problems with anything else?  It almost sounds like it could be a weak
power supply.

I use NetBSD, with an old graphics card (Intel 845 motherboard from
2006).  I find that redrawing the viking window seems to be very slow,
but I have not had any real computer/X instability issues.  Tons of
people use viking on ubuntu, it seems, so your issue is likely more
localized.

 but creating a track/route seems to use even more resources, so my
 laptop may crash more often - again frequent saving stops this.

 It may be that a feature that regularly saves to disk at 2 minute
 intervals would alleviate this?

Sure, but only if saving only happens if the user asks for this somehow.
I don't want to edit in viking - just examine mostly - but that's me.

 I hasten to add, this is not a complaint - you asked, so I'm
 answering. I'm a long term fan of viking  recommend it to friends. I
 also think that Ubuntu may be partially to blame here, as the
 performance of the laptops seems to have reduced over the last 2
 versions of Ubuntu. It's difficult for me to say if other programmes
 can cause similar effects, but I do know that 'Evolution' the PIM
 programme is resource heavy and can slow my system causing similar
 problems. I think the problems partially depend on the other
 programmes running - Thunderbird causes less problems than Evolution,
 Chromium causes less problems than Firefox.

Thanks for speaking up - I would say that while there's a non-viking
bug, it seems pretty clear that viking uses more resources than people
would like.

 My computer is a laptop, Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz  with
 4GB of ram, running Ubuntu 11.10 (can also boot into windows 7, where
 there is a version of Viking as well, but I rarely do this  don't
 know if a similar problem exists). My laptop currently uses Viking
 1.2.1 from the ubuntu repository, but I have used other versions
 loaded from git with the same results. I also make use of other
 laptops of various specs.  other versions of viking with similar
 results.

That's a resaonably beefy machine.  Mine is a single-core 3.4 GHz
(desktop mobo) with  2G of ram.

 I'm quite happy to try different versions, but you may have to keep
 the instructions simple as I'm definitely a user as opposed to a
 programmer!

I have been struggling to find spare time to hack on things - but
perhaps I will get to adding logging about start/stop redraw times in
the track/waypoint layer.


pgp85Qigw3xpX.pgp
Description: PGP signature
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy 

[Viking-devel] skip-same patch

[Greg Troxel]

It looks like someone (Rob?) has integrated my skip_same patch to only
draw points if they are different from the previous - thanks!

I am curious what people think of the drawing speed, especially those
who routinely take 1s tracklogs when hiking.




pgpphulTRnZmt.pgp
Description: PGP signature
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___
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] Google Maps

[Greg Troxel]

Jordi Hortigüela jb...@earcon.com writes:

 I use viking to build tracks for walking, biking whatever unfortunatelly all
 maps collection that comes with default with no cover my local area near
 Barcelona.

I would suggest learning about openstreetmap and fixing the map in your
area.

Downtown looks very well mapped already:

  http://osm.org/go/xUbR2gM


pgpVdEddBnPJm.pgp
Description: PGP signature
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2___
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] Import file via gpsbabel

[Greg Troxel]

Robert Norris rw_nor...@hotmail.com writes:

I will try to take a look.   One concern is that gpsbabel seems inclined
to require QT for the command-line version!   But it seems likely better
to put up with that bloat than to do anything else.


 It shouldn't do, depending on how it's packaged.

 For Debian it's split into gpsbabel + gpsbabelfe programs.

 Dependencies for the command line program:
 $ldd /usr/bin/gpsbabel
     linux-vdso.so.1 =  (0x7b9ff000)
     libusb-0.1.so.4 = /lib/libusb-0.1.so.4 (0x7fa869dd5000)
     libz.so.1 = /usr/lib/libz.so.1 (0x7fa869bbe000)
     libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7fa86993b000)
     libexpat.so.1 = /usr/lib/libexpat.so.1 (0x7fa869713000)
     libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7fa86938f000)
     /lib64/ld-linux-x86-64.so.2 (0x7fa86a002000)

 Whereas the gpsbabelfe has all the GUI dependencies (can't be bothered
 to list them - as there are 61 of them).

Sorry, I realize that's how it is now (similar on NetBSD).

On the gpsbabel list, Robert said that he was going to use QT for basic
data structures and thus cause the command-line version to depend on QT.


pgpL1cDegcmuO.pgp
Description: PGP signature
--
Using storage to extend the benefits of virtualization and iSCSI
Virtualization increases hardware utilization and delivers a new level of
agility. Learn what those decisions are and how to modernize your storage 
and backup environments for virtualization.
http://www.accelacomm.com/jaw/sfnl/114/51434361/___
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] tile age 30s ???

[Greg Troxel]

  I've just found the Tile usage policy of OSM. They request
  downloaders use HTTP Expiry Header or 1 week age per default. We have
  to change the value in Viking's code.

  http://wiki.openstreetmap.org/wiki/Tile_usage_policy

OK, so in order to be good OSM citizens

  change the units to days (I don't see why not)

  set the default value to 7 (days) (definitely)

  only allow 7 and up for a config (probably)

  people who want to reload things can use 'reload all onscreen tiles'


pgp60Ko8uU24b.pgp
Description: PGP signature
--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1___
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] Using local maps: how?

[Greg Troxel]

  But probably implies local adjustments?  That would explain some
  discrepancies in scale I am seeing.  In theory I should have 5 meters
  per pixel but end up having to say 7 for a better match.

  All these local adjustments will render my automation quite difficult.
  Ideally, I would like to cover an area that is roughly 250km x
  250km...

So probably viking converts lat/lon to UTM, and then just uses the
georef map as if it is the right zone.

I think what you need to do is to find the upper left pixel in WGS84
UTM.

Check out the following program - probably viking should use it at some
point, but it's the standard approach to coordinate conversion in the
open source world:

http://trac.osgeo.org/proj/


pgphE0QtBmJ7G.pgp
Description: PGP signature
--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay___
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] Using local maps: how?

[Greg Troxel]

  Viking displays the map in every UTM zone. In practice this is rarely an
  issue since most people don't have maps that cover more than one zone.

Probably true.  USGS DRGs are free, so if I were more together I'd have
more of them and would suffer aliasing.


pgphz0eP2LW3p.pgp
Description: PGP signature
--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay___
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] Viking 1.0.2 and 1.1 Projections

[Greg Troxel]

  FWIW: I tried converting the gpx files from WGS84 to NAD27 and
  using the geotiffs with those tracks under viking.  That still
  didn't work, even though the gpx transforms looked correct.

That may be because NAD27 uses a different ellipsoid, so converting
coordinates that are in NAD27 but treated as WGS84 to WGS84 UTM does not
give you the NAD27 UTM coordinates.   IIRC this effect is bigger than
the actual surface datum shift in meters.

  I have the gpsbabel scripts I used for that if any one is interested.
  Basically one has to use gpsbabel to convert to unicsv and then
  make a new unicsv with the datum transform then conver the unicsv
  back to gpx.

  So, next I tried converting the World File (tfw) for the geotiff
  from NAD27 to WGS84.  That seems to work.

So then you have the geotiffs georeferenced in WGS84.  But, it is lined
up with the NAD27 UTM grid instead of the WGS84 UTM grid.  That's
probably not detectable.

I had been thinking about how to do this right, within viking.
Transforming the way the map lines up makes more sense, since then you
can alpha composite with other maps.   So, having a projection selector
for georeferenced maps and transforming the origin of the world file on
read seems like a plausible approach.


pgpoSJVa52QAd.pgp
Description: PGP signature
--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay___
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] Viking 1.0.2 and 1.1 Projections

[Greg Troxel]

I haven't tried geotiff, but I do have DRG images for my region (in
NAD27).   If you could send a note how you configure that, I'll try it.

I wonder if viking should depend on proj.


pgpTNWHc5IXqh.pgp
Description: PGP signature
--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay___
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] Viking 1.0.2 and 1.1 Projections

[Greg Troxel]

Guilhem Bonnefille guilhem.bonnefi...@gmail.com writes:

 2011/5/14 Greg Troxel g...@ir.bbn.com:

 I haven't tried geotiff, but I do have DRG images for my region (in
 NAD27).   If you could send a note how you configure that, I'll try it.

 I don't know what NAD27 is. AFAIK, currently, viking only support 3
 projections: UTM, Mercator and LatLon (I don't have corresponding
 codes as I' writing).

Those are projections, which are ways to convert coordinates in lat/lon
to numbers on some plane.  NAD27 is a datum, which is a separate
concept, about how particular lat/lon coordinates are assigned to
particular places.

Today, WGS84 is used for most things, and it's ~= to ITRF00 at the few
mm level.   There is also NAD83, the official datum of the US, which is
a few meters different, and other datums in other places around the
world.

NAD27 is from 1927, and coordinates differ by tens of meters.  It was
the official datum of the US before NAD83, and many USGS topo maps are
in NAD27.  Plus NAD27 uses a different ellipsoid.  So one has to
transform to/from WGS84 to NAD27 to use USGS DRGs with GPS data.

What I don't understand is how this ever worked.

I wonder if the GPS data had been transformed to NAD27??  Perhaps
gpsbabel can do that.

Long term, viking should be projection and datum aware.

 I wonder if viking should depend on proj.

 I think so. I started to look a the proj4 library, but it is certainly
 a significant change, reclaiming long time invest. And I don't have
 this time currently. But proj support will certainly be a great add.
 Anynbody working on this would gain all my support.

 Note that I started to wrote notes about this on the following wiki page:
 https://sourceforge.net/apps/mediawiki/viking/index.php?title=Idea:gdal

 Feel free to contribute (on code or on this page).

I have used proj, and it's pretty easy.

The key question is if it's ok to depend on it, which requires anyone
using viking to have it.  But I think most geo software does already.

I am generally in favor of requiring it, but I think we should
understand/plan a bit better first.


pgp095ZlGDzHh.pgp
Description: PGP signature
--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay___
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] Enable Viking Forums on SourceForge?

[Greg Troxel]

Robert Norris rw_nor...@hotmail.com writes:

 Is there any reason *not* to enable some forums about Viking on the
 SourceForge website?

The only issue is the great cultural divide between the old-school
internet users who use mailinglists, and the web generation who find
forums more natural.  I tend to a) ignroe forums and b) not participate
in projects where forums are the main community, but that shows just how
old-fashioneed I am.

As long as you're talking about adding a forum and not changing th
mailinglist, it seems fine.  Perhaps the forum welcome text should point
to the mailinglist.


pgpJpPKDCE00b.pgp
Description: PGP signature
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb___
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] Help needed on translation management

[Greg Troxel]

I don't think there is any ethical issue.  Making fixes in
code/etc. that you mostly understand but don't quite, because people who
really understand are too busy/not available, is a long tradition.



pgpH635YYS3Ls.pgp
Description: PGP signature
--
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev___
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] [PATCH] Make more portable .vik file, as don't save the map cache directory if it's the map cache default directory.

[Greg Troxel]

Guilhem Bonnefille guilhem.bonnefi...@gmail.com writes:

 IMHO, the current cache in viking serves two distinct roles:
 - a cache like any web browser has (in order to keep files locally for
 the session);
 - a local tilecache to allow cross session caching but also *offline* reading.

Agreed; these are the two standard uses of caches.

From this discussion I still don't see why we want this cache to be
anything but per-user.

 dreaming
 As many other project uses a local *tilecache* (tangogps,
 nerongps...), perhaps can we imagine a future project, offering such
 services in a DBus manner.
 /dreaming

I would go the other way, and say that the right answer is an actual
tilecache that can be set up with zero hassle and then viking would
point to it and skip all this caching stuff.

But maybe there should be a way to do an rpc to it do you have tile x,
and what's the pathname to avoid turning it into/outof a web fetch.



pgpA0Vg5s6GTa.pgp
Description: PGP signature
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2  L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb___
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] Plans for 1.0

[Greg Troxel]

The release plan sounds good.  I've been meaning to try out all the
rnorris topic branches (and I think his plan of having a bunch of
independent topic branches to be merged is exactly right) but haven't
had time.  But, I think it makes sense to get a 1.0 out and then get
most/all of those integrated, plus changes from other people, and then
have a second stabilization period before 1.1.  There's no rule that
says 1.1 can't follow in a few months.



  Currently, Ctrl-W and Ctrl-Q have strange behaviour. This is mainly
  because viking is (still) not able to decided if document worth a save
  or not. We already discuss about this, but it seems that nobody find
  time to address this issue.

  Someone interested? Or should I just ignore this?

This isn't a regression from the past - it's just still very odd.

If someone has time, I would make ^W close one window and ^Q exit, and
both of them do a popup that says document may or may not have been
modified with discard save cancel.  Sort of what you would do if you
knew it was modified, but always.

After thinking a bit I'm inclined to release 1.0 without changing this.
It feels like an intermediate solution is just a mess.





pgpWZTgKIiqQv.pgp
Description: PGP signature
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev___
Viking-devel mailing list
Viking-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viking-devel
Viking home page: http://viking.sf.net/

[Viking-devel] [PATCH] Fix bashisms.

[Greg Troxel]

Change shell to /bin/sh.  Adapt to POSIX shell function syntax.
---
 test/check_degrees_conversions.sh |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/test/check_degrees_conversions.sh 
b/test/check_degrees_conversions.sh
index 1b675ef..a6a0b88 100755
--- a/test/check_degrees_conversions.sh
+++ b/test/check_degrees_conversions.sh
@@ -1,6 +1,6 @@
-#!/bin/bash
+#!/bin/sh
 
-function check_success()
+check_success ()
 {
   expected=$1
   shift
@@ -16,7 +16,7 @@ function check_success()
   done
 }
 
-function check_failure()
+check_failure ()
 {
   expected=$1
   shift
-- 
1.7.0.5



--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev
___
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] [PATCH] Document VikSlippyMapSource

[Greg Troxel]

Guilhem Bonnefille guilhem.bonnefi...@gmail.com writes:

 As you can see, as I invested some time in learning TMS related stuuf,
 I decided to add some documentation.

 Greg, as I know you're both interested in more documentation and have
 some knowledge of geographic stuff, can you give me your opinion about
 this documentation?

will do - any reason you haven't pushed to master?


 PS: it is my really first Gtk-doc comment. I used this even if viking
 is not yet ready for gtk-doc, but seems a reasonable tool for
 documenting Gtk code.


seems fine to me.


pgp0fLJvwVID7.pgp
Description: PGP signature
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev
___
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] [PATCH] Document VikSlippyMapSource

[Greg Troxel]

The wikipedia reference has no useful content; I'd delete it.

I think vikslippymapsource.c probably does not support arbitrary TMS
(meaning parsing the metadata and coping), but instead supports the
common profile of how maps are available on the web.

It would be great if there is a web reference to how osm and others do
something other than what the TMS spec says.

http://www.gdal.org/frmt_wms.html
http://www.gdal.org/frmt_wms_openstreetmap_tms.xml


http://wiki.openstreetmap.org/wiki/Setting_up_TMS



pgpxiLJ5WN5fK.pgp
Description: PGP signature
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev
___
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] [PATCH] Document VikSlippyMapSource

[Greg Troxel]

also, since osm is arguably one of the more important pseudo-TMS
services:

http://wiki.openstreetmap.org/wiki/Slippy_map_tilenames


pgptwIS3OJROX.pgp
Description: PGP signature
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev
___
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] EPSG:4326 support

[Greg Troxel]

I'm not really clear on this myself, but I would suggest that a good way
forward is to try to grasp things and spiff up the comments/docs.

There are several things out there:

  WMS: arbitrary areas and scales
  WMS-T  : above, *usage* constrained to a subset
  TMS: really is tiles with specific 2^-k type alignment/size

I think the OSM tiles are in 'google spherical mercator', which is
certainly supported by proj (which viking doesn't seem to use), and is
basically a mercator projection that assumes a spherical earth.

http://docs.openlayers.org/library/spherical_mercator.html


So I would ask: where is the code that turns lat/lon into spherical
mercator coordinates to then bin them into tile indexes?


pgpDrl4DxlJsg.pgp
Description: PGP signature
--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd___
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] bounds checking!

[Greg Troxel]

Robert Norris rw_nor...@hotmail.com writes:

 check out this url

 ** (viking:12203): WARNING **:
 curl_download_uri: http response: 404 for uri
 http://tile.openstreetmap.org/3/-2/4.png (time_condition = 0)

 Yes, well sometimes I get '-N' items to download (as reported in the
 status bar)!

I suppose that could happen.  I guess I really meant that some tile
servers have constraints and it would be good to understand and encode
them and avoid sending requests that won't work.


pgpJNxybdTAti.pgp
Description: PGP signature
--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d___
Viking-devel mailing list
Viking-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viking-devel
Viking home page: http://viking.sf.net/

[Viking-devel] bounds checking!

[Greg Troxel]

check out this url

** (viking:12203): WARNING **: curl_download_uri: http response: 404 for uri 
http://tile.openstreetmap.org/3/-2/4.png (time_condition = 0)


pgpYduH5IXOwI.pgp
Description: PGP signature
--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d___
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] My Viking Github is BackUp

[Greg Troxel]

The URL for git is:

  http://github.com/rnorris/viking.git


so one should do:

git remote add rnorris http://github.com/rnorris/viking.git
git remote update



pgpb5kyU2o9ya.pgp
Description: PGP signature
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___
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] Real-time GPS support?

[Greg Troxel]

It makes sense to be able to use geoclue, but IMHO straight gpsd support
should remain.  The crash problems are likely not about the particular
provider anyway.


pgpkbgwPwy0qM.pgp
Description: PGP signature
--

___
Viking-devel mailing list
Viking-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viking-devel
Viking home page: http://viking.sf.net/

[Viking-devel] different cache lifetimes for different maps?

[Greg Troxel]

It seems I can only set 'tile age' in global prefs to 1.  This seems
way too short.  I'd like to set if for 86400s for OSM, and to perhaps
infinity for terraserver topos and DRGs.  At least the DRGs are not
likely to ever change, and it seems a waste of time to query for
updates.  Perhaps tile age per map image (or unset), and allow the
global one to go to 1 year?



pgpg9nuTARDIw.pgp
Description: PGP signature
--

___
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] small wishlist items

[Greg Troxel]

Robert Norris rw_nor...@hotmail.com writes:

 The way I was thinking would be for whatever 'gpx' like thing was
 loaded or acquired (i.e. TrackWaypoint Layer) , zoom out to a level
 that would show all waypoints and/or trackpoints.  There already is a
 'vik_trw_layer_find_center' function which knows the bounds of the
 layer, just need some kind of method to convert from bounds to zoom
 level. May have to loop through zoom levels until we find one that
 that's within (vikviewport) view.

 If there's lots of TrackWaypoint Layers (potentially in a .vik file or
 loading *gpx), may want to delay this until the final TrackWaypoint
 Layer is processed.

That all makes sense, and I'll suggest that if there are multiple
TrackWaypoint layers, then if at least one is track only then zoom
should be determined only from tracks, or something like that.


pgppQtYX8X7GB.pgp
Description: PGP signature
--

___
Viking-devel mailing list
Viking-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viking-devel
Viking home page: http://viking.sf.net/

[Viking-devel] google cookies

[Greg Troxel]

(btw, thanks for the hint about garmin waypoints.)

I find that opening viking on a file with osm, terraserver topos and
terraserver aerieals results in a file being writting in
~/.viking/cookies.txt


# Netscape HTTP Cookie File
# http://curl.haxx.se/rfc/cookie_spec.html
# This file was generated by libcurl! Edit at your own risk.

.google.com TRUE/   FALSE   1334106458  PREFID=[redacted]



Why is this?  I wasn't trying to configure anything to talk to google,
and I didn't decide to take/store/resend a cookie.

I see it it curl_download.c:get_cookie_file, but there are no comments
explaining why.






pgp0tdxS9zb3G.pgp
Description: PGP signature
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
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] Bug squashing for v1.0

[Greg Troxel]

  One solution is to change the current PARAM_PORT parameter nature.
  Currently, it is an integer, used as index for a predefined list of
  ports. I suggest to replace it with raw string, storing the effective
  port value (/dev/ttyUSB3 for example).

  Such change will brake compatibility between versions. Perhaps can we
  find a way to stay ascendant compatible.

It doesn't make sense to encode pathnames to special files anyway,
because it isn't portable.  On NetBSD, it's /dev/dtyU0 or /dev/ttyU0
instead.  So I agree that having a string and removing the magic list
makes sense.

Probably gpsd should be the main documented approach anyway.



pgpMh369CAygW.pgp
Description: PGP signature
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev ___
Viking-devel mailing list
Viking-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viking-devel
Viking home page: http://viking.sf.net/

[Viking-devel] build failure with gpsd 2.90

[Greg Troxel]

viking 0.9.9 uses gps_query() which appears to have been withdrawn in
gpsd 2.90.

Has anyone been able to build 0.9.9 with gpsd support against gpsd 2.90?

Should I be filing this in a tracker?



pgpuizG2oY66n.pgp
Description: PGP signature
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev ___
Viking-devel mailing list
Viking-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viking-devel
Viking home page: http://viking.sf.net/

[Viking-devel] assorted comments on viking

[Greg Troxel]

I wrote the following comments in June while on a long flight and have
been meaning to send them to the list.

Also now that I realize massgis has a wms in mass state plane with 15cm
color orthophotos, I want to be able to switch to that coordinate system
and use it.




I've been starting to use viking and have a few comments and
suggestions.  I am finding the program very useful, so please don't
interpret my comments as negative.  I would like viking to work better
offline; it's already pretty reasonable.  I'm writing this from
running viking 0.9.8 on a Mac (built from pkgsrc), but I also use it
on NetBSD.  I don't know when I'll have spare time to implement any,
so I thought I'd send the suggestions to the list in case anyone finds
them useful.  Priority comments are about where I'd put in time - I
certainly don't expect others to write code I want unless of course my
suggestions make them want that code too.

* I know I'll probably be told to run from CVS/SVN instead of 0.9.8,
  but if that's the right advice a release is overdue.

* I'd like to have a preset standard set of map layers and be able to
  invoke viking on a gpx file.  Basically in this use case I want to
  use viking as a viewer and not create a viking file to manage
  waypoints - I just want map underlay behind my tracks and waypoints
  so I can look at them.  I don't mind a different command, but I'd
  like to basically do 'viking-osm 20090601.gpx' and have a viking
  window come up with the waypoint/track layer on top with osm tiles
  under it.  This is perhaps equivalent to having a file with just
  maps and running viking maps.viking --merge foo.gpx, with the
  caveat that the gpx has to be on top.

  [This is what I would work on first; it would make the default issue
  not so important because I could set up the file once.  I realize I
  can open a file and the open/merge the gpx file.]

* The default zoom and pan choices when opening a gpx file do not
  seemto make sense.  The scale says 500m, and zoom 4 (z15), and the
  position seems to be the middle of the bounding box.  For a GPX file
  of A-B on highways, the resulting view had none of the trackpoints.
  My preference is to zoom to track, and I suppose zoom to waypoints
  if there are fewer than some number of trackpoints.  I see a center
  on layer option, but nothing to adjust zoom.  When opening a GPX
  file with waypoints, the center appears to be the center of the
  waypoints, and because I haven't yet deleted the all import Garmin
  US/Europe/Taiwan, that's someplace not all that interesting (with
  apologies to those at 38N 13E :-).  I can only zoom out to 8192,
  which is I think z4.  So it's awkward to get back to the US (I
  realize I can goto a waypoint).  Why can't I see the global-scale
  tiles?

* I would like map layers to default to saving tiles someplace
  standardized and sensible, and to autodownload.  I realize that not
  everyone will feel this way, but I think most people will.  I save
  tiles in ~/VIKING/MAPNIK for osm mapnik tiles.  I realize the whole
  issue of cache purging and max size is hard, but I think that's
  separate from the question of defaulting to save tiles.  Perhaps a
  single global preference to save tiles should cause map layers to be
  configured to save tiles and maybe autodownload.

* Deal better with failed downloads.  viking should be more prepared
  to have no or flaky net access, including captive proxies at
  airports.   If it doesn't get a valid PNG file or some other valid
  tile data, it shouldn't create a cache file.   Cache files of zero
  length should be removed when noticed.

* Show tiles from cache before waiting for downloads to fail, if
  downloads have been failing.  Perhaps an offline mode to use cache
  only would be 99% of the value with a lot less work.

* Keep a log of tiles that were requested when offline and be able to
  fill the cache when online.  Needs some kind of rate limiting to
  avoid being abusive.  Perhaps waiting longer of 1s or the last tile
  service time between requests would be ok.

* It would be nice to have Some other kind of cache filling support,
  perhaps various scales around waypoints and tracks, but this seems
  fraught with perils, both in terms of server abuse and privacy
  issues.  Definitely low priority.

* From the above two comments obviously I need the planet dump and a
  tile server on my laptop and will get to that at some point; there's
  no reason not to have the data with me.  But the map layer add
  dialog doesn't have a custom URL.  Maybe a localhost standard place
  where osm people normally put their local tile server would be a
  good thing to add to the defaults, plus having arbitrary URLs.

* I was confused about how to create a new track/waypoint layer (that
  I'd want to export separately).  I generally find the map layer
  names confusing, and I wrote the following while trying them
  all.. Probably this is my fault 

Re: [Viking-devel] [legal] Copyright mention

[Greg Troxel]

In the US, and I think most Berne Convention places, works (such as
code) are copyright by those who created them.

So, if Evann wrote stuff and stopped in 2007, it's not appropriate to
add 2008, 2009 to those copyright notices.  When others write code,
their names should be added with the years in which the contributed code
was written.

Basically you should never remove copyright notices.

(IANAL, TINLA, blah blah)



pgppSFpQExgjH.pgp
Description: PGP signature
--
___
Viking-devel mailing list
Viking-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viking-devel
Viking home page: http://viking.sf.net/