TZT3 Export CSV File Bug

Boneyard

New member
Just wanted to share a problem I found while playing with file import and exports while learning file structures to write some software. You can create a waypoint for each symbol that is an option in the symbol list. Then export out as CSV and import right back in and the waypoint symbol is different. This happens with the last bunch of symbols in the list. About the first 31 work then after that it depends on which ones you choose. I confirmed it is only an export problem, the import function actually works fine if manually creating the CSV file. It appears as though the export CSV code is using sequential numbers (the ID of the symbol) from 0-48 I believe from memory. But in reality there are gaps so they need to be 0-31, 51-57, 60-64 etc. I have the exact layout but it is easy to see if you create a waypoint and assign each symbol in the list to them so that you have a waypoint for each symbol (approx 48 I believe). Then export to GPX and CSV. These are both text files readable in notepad. You can see the symbol ID discrepancies. The GPX will import fine, the CSV won't. If you manually change the CSV file symbol IDs to match the GPX file symbol IDs then import the CSV it works fine. It would be nice if Furuno fixed this its an easy bug to replicate and fix. Thanks
 
Interesting. We will test and report it. Normally we recommend the multi-layer formats like TZD and TZX but if exporting; using something else more general, GPX is a pretty widely accepted standard. The CSV is very limited structure that is a holdover from the old NN3D system. It is mainly there so people with older systems can import into the newer systems. After that point, I don't recommend anyone use CSV because it will not hold as many waypoints as the other formats. It figures that the issue has been unreported because most wouldn't export in that format. I will suggest to product development remove CSV export, and since importing works and main purpose it is there; keep that. Thanks for reporting it.
 
Interesting. We will test and report it. Normally we recommend the multi-layer formats like TZD and TZX but if exporting; using something else more general, GPX is a pretty widely accepted standard. The CSV is very limited structure that is a holdover from the old NN3D system. It is mainly there so people with older systems can import into the newer systems. After that point, I don't recommend anyone use CSV because it will not hold as many waypoints as the other formats. It figures that the issue has been unreported because most wouldn't export in that format. I will suggest to product development remove CSV export, and since importing works and main purpose it is there; keep that. Thanks for reporting it.
Thank you sir. The main reason I used it and found the problem is because I was trying to document the file structures for my own use. Back in the old days (1990s) when I had your equipment I wrote software that pulled my data from a database and created the content to be serially wired into my screen. Every time I went fishing I updated the database and then cleared the unit and re-uploaded the waypoints which then included the updated info. I agree GPX is a better standard way to accomplish what I am doing just takes more work lol. It would be cool if they could just fix rather than remove the csv code though. Never know when it might come in handy. At least someone could dump the file and load in excel or something and check it out rather than the more complex XML GPX file. But either way I have what I need just wanted to share. If you can get the column info from somewhere that would be cool. few of them I have not been able to figure out what data its for. Have a great weekend!
 
Back
Top