Import GPX Tracks Crash

[Bluesipp]

Hi
I find that trying to import .gpx files larger than about 1.5MB to Route Manager causes 2.5.0 to freeze. And the only way out seems to be uninstall/install.
Is this a known issue or is there a stated limit to file size?

[nohal]

Bluesipp,
No limit set. I did my testing using files in 1MB range and they import instantly even on my slowest Atom machine.
Could I have a look at your GPX file? You can send it to me by mail, which is to be found on the Authors tab in OpenCPN's About box.

Thanks

Pavel

[Bluesipp]

Pavel - very many thanks, it's on its way
john

[Bluesipp]

Pavel - again many thanks. Eventual solution awaited
John

[j ferguson]

I have similar problem. Track GPX's generated by PolarView load, Track GPX's from other sources 5 to 9MB lock up 2.5. Rather than getting into a discussion about GPX file formatting issues, it would be a lot simpler to be able to load csv track files. After all, who needs more than lat,lon fields? Think about it. a file with two comma delimited fields for each trackpoint. something easy to get out of almost any nav program.

I will work out the gpx formatting issues myself if i can be assured that there REALLY is no size limitation on imported track files.

Assuming someone knows for sure that there is no imported track.gpx file size limitation, then I have a gpx problem. Is there a sample (known to be good) big track gpx file that i might download to help me fix my formatting issue?

I ask because it looks like OpenCPN does a few things better than what I'm using now and I would migrate if i can get 10 years of tracks into opencpn.

sorry to be a bother, john

[PjotrC]

I import successfully 13MB of tracks in a single file. The longest track is 22000 trackpoints. Takes some time, but no problem.

Out of 13MB, some 20% of text is GUIDs, what I think is not useful now, but I definitely need the timestamps, colors, mark symbols.

It is a bit of work, but it should be possible to split GPX into smaller chunks, if necessary, and it is easy to generate a GPX track from a list of (lat,lon) pairs. I use a simple Python script for this.

Piotr

[sinbad7]

Unless I'm mistaken,you can Extend or Split tracks in OCPN.
GPSPrune is also a handy program for editing tracks.

I can also confirm that I have no problems importing .gpx files in the MB size.

Tore

[j ferguson]

Gentlemen,
I am happy to hear it is possible to bring in long track files. Now I can be certain that the problem is with the gpx formatting on my files. I am beginning to work with gpsprune and should have it under control in a day or two.

thank you for responding,

john

[j ferguson]

Well it wasn't a crash or lock-up after all. OpenCPN takes an INCREDIBLE amount of time to load a 12 Mb track.gpx. It may have been 45 minutes. I don't know because we left the machine running while we were out provisioning.

I started by using gpsPrune to cut the file down to 1 mb, which loaded in a minute or two, then cut same large file down to 6 mb which took quite a while, then tried the whole thing.

I'm running ubuntu 10.10 on an HP G-40 with 2.7 gigs ram, 30 gigs available disk, Athlon !!, P340 dual core processor.

To my mind, there cannot possibly be any good reason why processing a 12 meg list should take anything like this much time.

this is not at all a good sign.

[bdbcat]

j

OK I guess we need to see your huge GPX file, and get some instrumentation on it. I wonder what's going on....I love mysteries....

Not possible to attach such a large file to this thread. Maybe a .zip of the file could be emailed to me directly? Or in a drop box of some kind....

Lets start with a 1 MB version. A minute seems just too long to look at, after all, only a million characters.

My address is in Authors tab

Thanks
Dave

[j ferguson]

bear with me, Dave. I'm doing a fresh install of 32 bit ubuntu 10.10 v2.5, after removing all earlier stuff. I also have an XP installation on same machine and I'm testing this stuff on that as well. I'll be back with update late tomorrow - underway don't you know but have a lay day for weather.

john

[bdbcat]

Folks....

I've studied one of the large GPX files question.

Conclusion:
OpenCPN 2.5 does some things well, some not so well.

One thing we do not do well is this:

Single tracks of 1000 miles with trackpoints every 60 ft. (i.e. about 100,000 points in a single track) are not well supported by OpenCPN.
They work OK, but load too slowly to be usable.

It's a design decision driven by portability and conformance to industry standards. We store extended XML information for all trackpoints and waypoints in our navobj.xml files using a common format. The processing cost eventually becomes unreasonable for the resulting XML files when tracks of this size are imported.

If this is a general problem for enough users, then it may be posted as a FlySpray bug for further consideration in future versions.

Sorry, but there it is.

Thanks
Dave

[j ferguson]

Dave,
I concede that these tracks sound bizarre. For the benefit of the guys who mostly sail offshore, i use these tracks to navigate the Intra Coastal WaterWay on the east coast of the US. The Waterway has a few tricky sections and the anchorages tend to be shallow. We run north in the spring to Maine and south to the Keys in the fall. We have favorite anchorages and like to reuse them. I use my present software to make a single trackfile for nothbound trip and another for southbound, for example. NB2008.trk and SB2008.trk. This way if we want to reuse an anchorage we used southbound in 2008, i load that track and can see how we got into the anchorage. I have 10 years of these tracks.

I don't think a lot of other people do this, so making it work in OpenCPN is probably a waste of time given the need to re-architect the code to make it practical.

Thanks for looking at it for me.

john ferguson m/v arcadian anchored Cedar Creek, NC

[sinbad7]

j ferguson..

You can use the FREE RouteConverter to reduce the number of waypoints in your track.

http://www.routeconverter.de/wiki/track_to_route-en

Tore

[j ferguson]

Tore,
for the ICW, 60 foot intervals are useful. It might be that using time intervals instead of distance to create the tracks would make more sense because i would get higher resolution when going slower, but then the difference between 6 knots and 2 or 3 is not that great.

i have no problem with these large track files with the software i now use, which also runs on Linux. I have all 10 years of tracks available on a tab (twenty - most of which are more than 6 megs) and i can easily display 2 or 3 while recording the "current" track.

From discussions with other software developers, my use of tracks is not a high-demand feature.

OpenCPN was highly recommended by a friend whose opinion i respect, but he couldn't understand why i wanted these big tracks either. Ah well..

john