"Theodore B. Ruegsegger" <tbr...@gmail.com> 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 getting the others?
track and waypoint are just regular gpx files, from the GPSr. gpx.viking is a viking file that has the map layers I want. When I start up this way, I get my tracks/wpts overlaid on my standard map layers. > Greg: >> and start each time. I don't try to have a huge viking file with >> all of my tracks. > > Is this a bad thing to do? I have a Viking file for exactly that > purpose! And even my files for specific areas get pretty large after > years of hiking and geocaching. Well, I'm not sure. I don't want to use viking to store my data - I keep the original files instead. > I don't know a lot about XML; are you saying XML doesn't scale well? no. It's not about xml, but about viking having huge numbers of trackpoints in memory and drawing them. I think it's mostly about the drawing. > I would love to find a utility, perhaps a simple set of shell scripts, > that would: > > 1. Parse a Viking XML file and generate SQL to insert all the tracks > and waypoints into a relational database like PostgreSQL or mysql, > preferably using simple-enough SQL that I get to choose which DBMS > to use. I have been thinking about that, and in particular using postgresql/postgis, so that viking can query for all tracks that are in the viewport. > 2. Convert the results of a database query into Viking-readable XML > so that I can load it and display and manipulate its contents. I was thinking of letting viking have a database layer, but your idea has merit (simpler first step). > Then I could use the full power of a relational DBMS to find tracks > and waypoints by name, by date, by location, etc, and load only those > into Viking so it's not burdened by a huge file of data I'm not using > at the moment. > > Does anything like that exist, somewhere? I am pretty sure it does not. > Nick: >> > & everything freezes for several seconds, but always recovers. If >> > there are several tracks with many waypoints the programme may >> > become > > Greg: >> When it is slow, does top/etc. show that viking or X is using all >> the cpu time, or something else, or ? > > Viking is usually high in the list, but X is the one with huge CPU. > Sometimes, oddly, kmail (I use Kubuntu) has a high CPU hit as well. > Killing kmail doesn't give me back the machine. I still have to wait > it out or, like Nick, power-cycle. So this is seeming consistent. Have you updated to recent git that has the skip_same patch? > My workaround is to have a small file just for loading the tracks from > the GPSr, selecting the ones I want, renaming them, and only then > loading the big file of all my tracks and copying them over. That > mostly avoids the slowups, except when I zoom several increments at a > time. That can bring my machine to its knees. I think you too are avoiding the scaling issues (which makes sense). > Greg: >> In theory viking cannot cause this. > > Why not, in theory? I should have said "If the OS and server code are correct, 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'm adding my comments just to establish that Nick isn't the only one > seeing these problems. > > My details: Kubuntu 11.04 Natty Narwhal on a Lenovo T41 Thinkpad, > Intel Pentium M 1.86GHz, 2GB memory. Viking 0.9.94. that's really old viking! > Yeah, I need to get around to upgrading to the newer Ubuntu which > finally has a Viking version that begins with 1! But I've noticed > these slowdown problems over many Ubuntu and Viking versions, and it > sounds like they're still there, even if limited to a few lucky users > like me and Nick! I think the big change is the skip patch. The idea is that viking will not draw a trackpoint if it has the same screen coordinates of the previous trackpoint. With 1s tracklogs, especially when not zoomed in all the way, this happens a lot. > It's of course possible that Nick and I have the same non-Viking bug > which only appears when we run Viking, but perhaps it may be a Viking > bug after all. It's not clear from Nick's post but perhaps he, too, > has a big file of tracks. BTW it doesn't need to be that big for these > problems to manifest. I think it's a combination of viking asking for a lot of drawing and the X server not coping all that well.
pgpvuN2Ezf2IS.pgp
Description: PGP signature
------------------------------------------------------------------------------ RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2
_______________________________________________ Viking-devel mailing list Viking-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viking-devel Viking home page: http://viking.sf.net/
