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
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 p
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)
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,
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 portab
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
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
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 M
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 - tha
Robert Norris writes:
> Good spot on the '==' issue.
Do you need a proper patch to configure.in, or is it easier for you to
just fix it.
> However the $RANDOM issue as far as I can tell is created by one of
> the 'random' autotools components, not in Viking itself. On my system
> (Automake ver
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 bu
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 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 cl
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
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 the
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
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.nong
Robert Norris writes:
> I'm debating about whether to include the interpolate times code: I
> wonder if you could describe the usage of the 'Interpolate Times' a
> bit more, as I'd also like to include a short description in the Help
> manual of why one may want to equalize the speeds across a t
Robert Norris 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
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.
Thinki
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/
Nick Allen 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
Robert Norris 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...
Yuri D'Elia 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
Robert Norris 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 s
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.
My leaning is that while having a tile sources list on the wiki is
great, the builtin set should be curated to be a good set for most
people. So that definitely means pruning ones that don't work, but also
being judicious about what to add. It might be reasonable to have the 5
layers that openst
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 c
Robert Norris 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 whi
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
Robert Norris 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 SourceForg
Robert Norris 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
I have prepared but not committed a pkgsrc update for 1.5. However, I
am seeing some odd behavior (on a mac, that I think I also saw on
NetBSD). I tend to do
viking gpx.viking ETREX30-archive/2013-10-01\ *
to display all the tracks from a given (UTC of course :-) day. Under
1.4.2, this wor
Robert Norris writes:
>> 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
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 he
Guilhem Bonnefille 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 an
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 versi
't work at zN and stop, sort of like Path MTU Discovery :-). Also,
we could enlarge the last level we have, instead of blank.
Greg Troxel
pgpCwjqRV5ZJF.pgp
Description: PGP signature
--
Symantec Endpoint Protect
Robert Norris 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
>>
nstalled
figures.
commit 1f2516923e1d8cf4c8d63250a2c665cdb3df3b32
Author: Greg Troxel
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
Robert Norris 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 distchec
An update:
I am confused about the netbsd NAN workaround patch. It was in my git
tree and thus in my tarball :-) I'll carry this in pkgsrc; please
disregard, at least for now.
If --enable-gtk-doc is not passed, gmake dist builds a defective
distfile without the help/ directory. Argua
Robert Norris writes:
> Thus as far as I'm concerned posting some messages to this mailing
> list about the release intention is good enough.
>
> NB I had already responded to Greg, and (I believe) he's happy with
> the git release method
That's fine. I package a lot of things, and sometimes I
When it's almost ready, can you make a candidate release tarball, using
the same mechanism as you will use for the release, and put it up as
viking-1.4rc0.tar.gz? That way I can test the packaging path, and
others can too, and we can fix anything small.
pgp_uy6GVpkBN.pgp
Description: PGP signa
[intersection problem]
It might be better to have a command-line program that takes a GPX file
and a file with:
true_bearing waypoint_name
and outputs a GPX file with a single waypoint.
See the program 'gama' which can do this, but not with GPX.
pgpwMVdkqVh31.pgp
Description: PGP signature
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 supp
Phil 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
>> m
Phil writes:
> On 09/11/12 11:06, Greg Troxel wrote:
>> As I understand it, the terms of service for google do not permit it to
>> be used with viking (directly, and they don't permit downloading and
>> saving bits, as I understand it).
>
> Thanks for the quick
Phil writes:
> I've played with Viking for a week or so and now I'm keen to get hold of
> a more recent map for the town than the one available from Open Street
> Map. Their map is at least 15 years old. On the other hand, the map from
> Google is up to date and correct.
>
> So my question is
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 produ
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 defa
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/s
In case anyone else is using pkgsrc...
I've updated pkgsrc to 1.3, and it works ok on NetBSD/i386.
--- Begin Message ---
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:
Guilhem Bonnefille writes:
> I think a good improvement would be to use a threadpool per maps
> provider. By this way, we can set the size of the pool for each maps
> provider, without reducing downloading performances when using
> multiple maps providers at the same time.
That sounds easy enou
"Theodore B. Ruegsegger" writes:
>> From: gdt
>> But, what I do is
>>
>> viking gpx.viking track.gpx waypoint.gpx
>
> It's not clear to me from the documentation what's going on
> here. You're loading three files, yes? I assume one of them
> (track.gpx?) is from the GPSr; where are you gettin
Nick Allen 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 4
I think am seeing what seems to be too many simultaneous downloads from
osm, but I'm not sure.
Where is the configuring for the max number of requests at once to some
site? I would think this should be 2 or 4, but not more. I am
wondering if I am getting throttled, and would like to set it to 1
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
So probably we should:
drop osm tiles from default menu
(probably) in the new version, make config files with the current
mapnik layer not get mapnik tiles
(maybe) make sure the user can configure a map layer with a tile
server URL easily
make sure the user-agent is recognizably di
Jordi Hortigüela 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
Robert Norris 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
http://repo.or.cz/w/viking/guyou.git/shortlog/refs/heads/import-via-gpsbabel
to grab that locally:
git remote add guyou git://repo.or.cz/viking/guyou.git
git remote update -p
pgpQXGqC5Z6BP.pgp
Description: PGP signature
--
As many of you already know, viking uses gpsbabel for many features.
Most of them concern format conversions. But, currently, only some
formats are offered via viking. I not really know why viking does not
support all formats supported by gpsbabel. And recently, I discovered
that gpsbabe
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 day
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
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
Robert Norris writes:
> Any one have an idea why the maps download default is off?
>
> . It seems unchanged since the original version (in 2005)
> . Possibly in the beginning Viking had problems if no internet
> connection available.
> . Most users would now always have an always on connection,
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 tre
Guilhem Bonnefille writes:
> 2011/5/14 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 don't know what NAD27 is. AFAIK, currently
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
E.g. I am on a bike tour, usually about 4 hours
I also get around 14400 track points.
The track that provoked my complaint was similar. Except I was visiting
town boundary markers as an official government function :-)
http://www.lexort.com/perambulation-2010/
In my Pentium 1.86GHz 2GB RA
Greg Troxel writes:
> I started up viking with a GPX layer of about 14000 trackpoints (1s
> tracklog), and on zooming in and out see Xorg busy for several seconds.
>
> This seems worse than it used to, but I'm not sure.
>
> I've long wanted to omit X drawing calls f
I started up viking with a GPX layer of about 14000 trackpoints (1s
tracklog), and on zooming in and out see Xorg busy for several seconds.
This seems worse than it used to, but I'm not sure.
I've long wanted to omit X drawing calls for adjacent trackpoints that
have the same screen coordinates.
The default for tile age seems to be 30s. This seems way too short.
While someone actively mapping in OSM might want to reload, it seems
like map tiles are relatively static over that kind of timescale. I
have set the tile age to 604800s (1 week).It seems rude to OSM to
recheck tiles more of
Robert Norris writes:
>> It looks like Rob is now working directly in the SF repo.
>
> Since I have commit privileges, 'simple' fixes / small changes get
> applied directly to the SF repo.
> This is a maintainer thing as they don't necessarily need any feedback
> before being applied.
That's to
I noticed 1.1 was released, but it's labeled "pilot" rather than stable.
But, I wonder if it works better than 1.0 for most users. Specfically,
I am contemplating updating pkgsrc to 1.1.
So, is a user who isn't paying attention to development issues better
served by 1.1, or 1.0.2?
(Also, there
Checking out viking on a mac is awkward due to viking-remote and
VIKING-REMOTE. Is there any reason VIKING-REMOTE can't have a different
name? It doesn't seem to be referenced in any other files, and seems to
be for by-hand use when not used with a packaging system that supports
desktop files.
(I'm starting to pay attention to viking again after a hiatus due to
Things Other than Geo needing time.)
I have some saved messages about git repositories, but I'm unclear on
the current practice. My local repo has the following remotes:
origingit://viking.git.sourceforge.net/gitroot/
gps_poll has been removed from gpsd, so now viking with gpsd support
won't build. Has anyone tried to convert it to gps_read?
pgpnLCxkRkXOS.pgp
Description: PGP signature
--
Enable your software for Intel(R) Active Mana
Guilhem Bonnefille writes:
> For 1.0, I tried to import the idea of "stable" release (I then
> released 1.0.1 and 1.0.2). I don't know if it was usefull or not, nor
> if viking is sort of software that need such effort. The main idea was
> to use even releases as stable ones and odd releases fo
Yes, it is what I tried to do.
To ensure this, I put the Makefile in a subdirectory not linked by
other Makefile. So, the "make" must be manually activated on this
directory.
sounds good
But I'm not really sure abou one aspect: dependencies. Is this change
brings some new dependencie
Quick review of the case change:
a large comment is removed, and there is no replacement comment
explainining the plan
in paricular, the missing new comment doesn't explain why the new way
causes no regressions
new procedures don't have comments explaining their purposes (even
thoug
If this is for building docs about the source code, a la doxygen, then
it would be nice if it's possible to easily build viking without this
documentation, while simultaneously allowing those who are hacking on it
to have the docs. Is that what you think you did?
pgp1hQ4wS4ObE.pgp
Description:
[top posting repaired]
>> Furthermore, you can experiment easily the resulting work by using the
>> following branch:
>> http://repo.or.cz/w/viking/guyou.git/shortlog/refs/heads/t/map/bing-maps
Lixus Zoran writes:
> But How can I clone the git bing-maps branch ?
> I am getting this error:
>
>
Robert Norris 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 fo
I remember we already discussed about this property in .vik file.
It could be interesting to have support for ~ or $HOME. But I fear
that such change will bring new issue (like previous try).
I feel that we have to find an other idea.
One idea I have is to move this path from .vik file
I have a gpx.viking file so I can do
viking gpx.viking foo.gpx
and get the map layers I want without having to configure them. This
generally works well. I put /home/gdt/VIKING as the map cache
directory, and this works fine on the BSD system is was written on. But
on my mac, it fails beca
Guilhem Bonnefille writes:
> I suggest you to reread this page, Rob reviews the introduction of
> this page. I think all is much more clear.
Yes, thanks - that's very helpful.
So we should probably put the example file into the distribution and
have it installed in $(prefix)/share/examples/vik
https://sourceforge.net/apps/mediawiki/viking/index.php?title=Maps
Thanks; I had never thought of adding toposm. But the Documentation
link is to a null page, and I'm guessing one drops the xml in some file,
but I'm not clear where.
pgpIzgpBfzMGx.pgp
Description: PGP signature
--
I tested 1.0 on netbsd-5 i386 and it worked fine, and I've updated pkgsrc
to 1.0.
pgptozFxKdWw9.pgp
Description: PGP signature
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3
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
---
Guilhem Bonnefille writes:
> As you can see, I released 0.9.96. I hope this version is the really
> last one before 1.0. I plan this release for the end of the week, if
> no major bug is found.
I did an update to 0.9.96 for pkgsrc, and it seems to work fine (for
what I do, which is look at gpx
Guilhem Bonnefille 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
Guilhem Bonnefille writes:
> It's an interesting point of vue. Currently, the map cache is
> associated to the *instance* of a map layer, not the map layer itself
> (as far as i know). For example, you can embed two Mapnik layers with
> different caches.
>
> As you spotted it, I think this is pr
how about:
user preference file (NOT a .vik) sets path to cached maps
each map layer just uses a standard place in the path, and there's no
config allowed.
pgpZByDysOHT3.pgp
Description: PGP signature
--
Beautifu
0.9.95 seems to work fine on NetBSD 5 i386 (using OSM layer, gpx
reading).
--- Begin Message ---
Module Name:pkgsrc
Committed By: gdt
Date: Wed Sep 22 12:43:48 UTC 2010
Modified Files:
pkgsrc/geography/viking: Makefile distinfo
Log Message:
Update to 0.9.95.
Viking 0.9
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 integra
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
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
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 referenc
1 - 100 of 133 matches
Mail list logo
