I tried another approach and the results seem promising... zero manual editing and good performance...
I wrote two simple Python scripts:
Script 1 reads an NTMChartCorrections.csv file as downloaded from NGA Maritime Safety
Information web page, for any chart set, with coordinate format chosen as decimal minutes, PC format. The script does the following:
- splits file contents into individual .txt files per chart per NtM
- writes the individual notices into a directory tree with 10 subdirectories: one for every region 1-9, and one (0) for all other charts
- within every region creates directories for referenced charts, and writes there files with NtM texts
- generates a .csv file with all coordinate points found anywhere in the notices, referenced to chart number, NtM number, NtM type and NtM text file location
Script 2 converts the above produced points .csv into .gpx with "Additional Information" links pointing to NtM text.
The purpose of this excercise was to get a feeling as to the numbers involved and any performance issues. Certainly this is not a definitive way of handling NtMs, but it works surprisingly well.
I tried this with a real folio of ca. 60 NGA charts I had been maintaining for some years.
I downloaded all NtMs for this set, starting at the original editions, plus the full NtM of week 52/11, ca. 180 charts in all. This resulted in 1500 Notices (i.e. cases of application of a Notice to a Chart).
Script 1 produced 180 directories and filled them with 1500 files (<30 seconds, including logging to console).
Script 1 produced also the .csv file with ca. 4000 points.
Script 2 converted this into a 1200 KB file, that can be loaded into OCPN as a Layer, again in a couple of seconds.
Results for Region 5 and NtMs for past 12 months: 350 charts, 800 Notices, 3000 correction points, <5 seconds total compute time.
OpenCPN 2.5.0 handles the 4000 waypoints layer very well. The potentially limiting factor is generating the WP names in the Route Manager Dialog Tab. Without listing individual names (not really needed) there is no performance problem in OCPN.
The directories with text files are useful anyhow to store and browse individual Notices.
The Notice Texts might in some cases still be parsed further, but I doubt if this is needed or worthwile to do now.
Some more difficult points still need to be addressed:
1. instead of having one layer with all notices, the display should be adapted to the scale currently shown on screen
2. as much help as possible should be offered for handling of the chartlets supplied with NtMs
These will not be possible with simple GPX approach... a plugin interfacing to some database is needed here...
Anyhow, writing Python is probably a lot easier than using spreadsheet macros...