How to eliminate Names and other Waypoint attributes in GPX files

[fgd3]

Originally Posted by wholybee

Suggesting it is up to the "consumer" is very unfriendly.

I think you misunderstood "consumer". I believe "consumer" refers to the device which will be using the data, not the person who directs the data to the device. The point is that OpenCPN complies with the standard for creating GPX files. If other devices fail to conform to that standard why should it be incumbent on OpenCPN to diverge from the standard in order to compensate for the failure of other devices to properly process properly formatted GPX data?

[CaptTom]

I don't think the misunderstanding is with the term "consumer."

The misunderstanding is that it's not very friendly to cling to the defensive "it's perfectly legal" argument.

Nobody is suggesting it isn't standard compliant. The suggestion is that there's a better way to do this, which makes things easier for the user and avoids bloated GPX files.

Before I get misunderstood again, I'm not saying there shouldn't be a way to include data which may be of value to someone, somewhere. But it's clear that the vast majority of the data is of very limited value in almost every use case. The very fact that there are so many ways to strip it out shows that this is a common issue for users.

Being dismissive of user needs doesn't seem consistent with the spirit of the OpenCPN project.

[nohal]

Let's see it it the other way: The complete lack of tools doing exactly what you want exactly the way you want shows that your use case is not common. General availability of tools to manipulate XML is really not proving your point.

[Portage_bay]

Derfy,

Getting back to your original question and avoiding the ensuing discusson I can offer a solution to strip out the unwanted lines in a standard .GPX file. This solution assumes you are transfering GPX files to your Raymarine system. I will admit upfront to being ignorant of Raymarine. This is a variation on a process I have used for many years.

1. Create your route in any app you wish, in your case Navionics.
2. Export the route file to storage media which depends upon the hardware you are using.
3. Open the GPX file in GPS Utility
4. Edit anything if you wish
5. Export to the file format you require
6. Send it off to your Raymarine device

Once you have got this up and running and have a bit of experience with it, it becomes quick and easy. The younger crowd may well tell me there online utilities to do the same task. I'm old fashioned.

Attached you will find a simple route created by Navionics autoroute from Tacoma Wa to Elliot Bay Marina in Seattle, opened in OpenCPN and finally cleaned up ready for Raymarine.

• <Tacoma to Elliot Bay Navionics.gpx> is the auto route generated by Navionics.
• <Tacoma to Elliot Bay OpenCPN.gpx> is the route saved in OpenCPN's output format.
• I would like to attach <Tacoma to Elliot Bay Raymarine.rwf> which is the final product. However the forum software won't allow it. At the end of this post see a copy paste of the .rwf file.

GPS Utility is available shareware or paid. The shareware version is fully functional with limits on the # of waypoints etc. The author Alan Murphy is quite helpful especially if you've paid the fee. He will if asked nicely modify GPS Utility to work as you need it to. For example if your new Axiom device can't read the rwf format. He added the Furuno NavNet 3D format when I needed it many years ago. He added a depth record for work I was doing long ago.

The two drawbacks I see to GPS utility are first it has a learning curve that some struggle with. Second Alan is the only author. While he maintains and improves the product who knows how much longer he will carry on.

Below is the raymarine.wrf file generated by GPS Utility. You can see it is the bare minimum.

[Wp0]
Name=W001
LAT=47.2613880
Long=-122.4370460
[Wp1]
Name=W002
LAT=47.2636380
Long=-122.4385820
[Wp2]
Name=W003
LAT=47.2995020
Long=-122.4464960
[Wp3]
Name=W004
LAT=47.3005410
Long=-122.4467030
[Wp4]
Name=W005
LAT=47.3054360
Long=-122.4471160
[Wp5]
Name=W006
LAT=47.3055760
Long=-122.4471250
[Wp6]
Name=W007
LAT=47.3060220
Long=-122.4470890
[Wp7]
Name=W008
LAT=47.3062180
Long=-122.4470080
[Wp8]
Name=W009
LAT=47.3077150
Long=-122.4456610
[Wp9]
Name=W010
LAT=47.3860640
Long=-122.3714810
[Wp10]
Name=W011
LAT=47.3861740
Long=-122.3713910
[Wp11]
Name=W012
LAT=47.3881260
Long=-122.3709780
[Wp12]
Name=W013
LAT=47.3882120
Long=-122.3709780
[Wp13]
Name=W014
LAT=47.5713630
Long=-122.4259970
[Wp14]
Name=W015
LAT=47.5714050
Long=-122.4260060
[Wp15]
Name=W016
LAT=47.5765420
Long=-122.4235000
[Wp16]
Name=W017
LAT=47.6264290
Long=-122.3864640
[Rt0]
Name=Route 001
Mk0=W001
Mk1=W002
Mk2=W003
Mk3=W004
Mk4=W005
Mk5=W006
Mk6=W007
Mk7=W008
Mk8=W009
Mk9=W010
[Rt1]
Name=
Mk0=W010
Mk1=W011
Mk2=W012
Mk3=W013
Mk4=W014
Mk5=W015
Mk6=W016
Mk7=W017

Originally Posted by derfy

I use GPX route files all the time, moving them from Navionics into OpenCPN and onto my Raymarine Axiom (to drive the boat).

I find the OpenCPN exported GPX files are full of clutter for each waypoint (technically these are route points). Attributes like <time>,<name>,<sym>,<type>,<extensions>, making the files much larger than need be.

Worse, the silly Raymarine chartplotter dutifully shows me each and every route point name on the screen - cluster I don't need.

So I manually edit out all this stuff, but it is too big a job.

Q: Can I suppress the export of all these extra attributes and just get route point lat and lon?

Q: Is there a good editor or script that can do this. I have tried some xml editors but they did not work out. Maybe there is a good one? Or just a nice script someone has written?

[Be Free]

Please correct me if I misunderstand the situation.

As I understand it, OpenCPN exports GPX files that are consistent with the published standard and which, when imported back into OpenCPN, will be properly inserted into the proper data structures without duplication or loss of data.

If the "extraneous" information were to be stripped out of the GPX file and then the file were to be imported back into OpenCPN then there would be missing data and/or duplicated data.

If I understand the OP, the Raymarine device has no issue with the GPX file. It imports the GPX file without error or complaint and ignores any data that it does not need or understand.

As I understand it, the problem that the OP is trying to address is that the foreign (not OpenCPN) program is properly interpreting the data and displaying it on the screen even though the OP does not want to see it. If that is the case then I would have to agree that it is a problem with the "consumer" of the GPX file, not the creator of it.

Any feature added to OpenCPN that would allow it to export a file that, when imported back into OpenCPN, resulted in either loss or duplication of data would (in my opinion) be extremely disruptive. I don't think that it is unreasonable to expect that a file that is exported from OpenCPN and then imported (unchanged) would add that data back to OpenCPN while neither losing nor duplicating any data.

[nohal]

Your understanding is correct. The whole logic is based on the fact that eliminating data not necessary for a paticular workflow is possible (In case of the XML based GPX format very easily), but recovering non existent data is not.

[derfy]

Originally Posted by wholybee

Check out GPS Babel. It will convert and filter GPX files. It is very powerful and much easier than manually editing anything.

https://www.gpsbabel.org/

I do agree that when exporting a GPX file, there should be a dialog with some check boxes asking what to include. Suggesting it is up to the "consumer" is very unfriendly. That leads to complicated workflows, incompatible software, and time sucks for the "consumer." I would also like to suggest a similar dialog for GPX import. For example, when I import a route from Predictwind, it plots not only the route, but all the waypoint icons and names each of them on the screen. It is basically unusable without a large amount of work (or using some other program to convert it)

A while back there was a thread on OpenCPN interoperability and what changes/features should be there. I'm not sure this made it on that thread, but it really needs to be, and in the scheme of things, features to add, etc. shouldn't be that hard. Please do not dismiss it so casually.

I am happy to submit a feature request. I will have to find the place to do it. If you know where to do it (a link) that would be helpful. Otherwise I am just searching for it.

I tried this app. It is a nice app, but I did not find the ability to scrub out the route point names. I looked for quite a while. Maybe I missed something?

[derfy]

Originally Posted by Be Free

Please correct me if I misunderstand the situation.

As I understand it, OpenCPN exports GPX files that are consistent with the published standard and which, when imported back into OpenCPN, will be properly inserted into the proper data structures without duplication or loss of data.

If the "extraneous" information were to be stripped out of the GPX file and then the file were to be imported back into OpenCPN then there would be missing data and/or duplicated data.

If I understand the OP, the Raymarine device has no issue with the GPX file. It imports the GPX file without error or complaint and ignores any data that it does not need or understand.

As I understand it, the problem that the OP is trying to address is that the foreign (not OpenCPN) program is properly interpreting the data and displaying it on the screen even though the OP does not want to see it. If that is the case then I would have to agree that it is a problem with the "consumer" of the GPX file, not the creator of it.

Any feature added to OpenCPN that would allow it to export a file that, when imported back into OpenCPN, resulted in either loss or duplication of data would (in my opinion) be extremely disruptive. I don't think that it is unreasonable to expect that a file that is exported from OpenCPN and then imported (unchanged) would add that data back to OpenCPN while neither losing nor duplicating any data.

I can clarify.

The feature I seek is the ability to scrub a gpx file of all the Route Point Names.

Why? I create routes in Navionics and export their GPX files to my Raymarine for use driving the boat. These files have no route point names and work fine on the Raymarine. Often the routes have many closely spaced waypoints when I am in inland waterways.

Sometimes I send these GPX files to OpenCPN for further review and editing using different charts, etc. OpenCPN generates a lot of extra data for each route point, but the problem is the machine-generated Route Point Names. These are visible in my Raymarine and clutter the screen with meaningless text. So, I just need to suppress the export of Route Point Names. The other stuff is not needed, but not causing problems. In my older C-Series Raymarine memory was a premium and I would get rid of all that extra stuff.

For driving the boat, you just need the route name and route point lat and lon. Everything else if for something else.

[derfy]

Originally Posted by Capt.Don

This is a topic I've pondered for a while. Notepad++, my favorite Windows text editor, supports search and replace using regular expressions. A brief internet search returns a regex search condition that replaces text between tags. Note, this doesn't support nested tags.

In my archived opencpn and navionics gpx route files, I wanted to remove <ele>...</ele> and all the <extensions>...</extensions>.

Here's the search regex to remove the <ele> tags,
<ele>[^<>]+</ele>

Because the <extensions> have nested tags, I used a similar regex to remove the embedded tags, then the extensions.

For navionics gpx files,
<navionics_speed>[^<>]+</navionics_speed>
<navionics_haccuracy>[^<>]+</navionics_haccuracy>
<navionics_vaccuracy>[^<>]+</navionics_vaccuracy>
<extensions>[^<>]+</extensions>

For opencpn gpx files
<opencpn:guid>[^<>]+</opencpn:guid>
<opencpn:viz_name>[^<>]+</opencpn:viz_name>
<opencpn:arrival_radius>[^<>]+</opencpn:arrival_radius>
<opencpn:waypoint_range_rings[^<>]+/>
<opencpn:scale_min_max[^<>]+/>
<extensions>[^<>]+</extensions>

For now, I'm only removing the <ele> tags and will think about the rest.

Don

This is very helpful. I am able to scrub the machine-generated route names using the regex <name>0[^<>]+</name> in the Replace menu. The 0 identifies the machine-generated route point names, while leaving my route names alone. I had to use the regex <name>1[^<>]+</name> to get rid of the route point names for routes with more than 100 route points (I have a couple of these in the ICW).

I scrubbed a huge file with 80 routes, and thousands of route points with one search and replace. Very helpful, Captain.

[CaptTom]

Originally Posted by Be Free

...If the "extraneous" information were to be stripped out of the GPX file and then the file were to be imported back into OpenCPN then there would be missing data and/or duplicated data...

Any feature added to OpenCPN that would allow it to export a file that, when imported back into OpenCPN, resulted in either loss or duplication of data would (in my opinion) be extremely disruptive.

I think a there's a lot of misunderstanding going on here.

I strip the extraneous data out of all my GPX files after exporting them. I have hundreds which I use all the time, importing, modifying, exporting in OpenCPN and other systems and devices. OpenCPN has absolutely no problem importing my bare-minimum GPX files, whether they were created there or elsewhere.

Originally Posted by nohal

Your understanding is correct. The whole logic is based on the fact that eliminating data not necessary for a paticular workflow is possible (In case of the XML based GPX format very easily), but recovering non existent data is not.

I think this misstates what I was trying to convey. Again, it's not that there is any kind of error condition. The point is that the vast majority of the data are absolutely useless. All those OpenCPN-specific fields have no value in any other software or device. The dates and times that the waypoints were created, also have no value in a planned route.

This is true whether the GPX files are going to be used in some other system, or imported back to OpenCPN. For the vast majority of use cases I can think of, the data are simply useless. I'm apparently not the only one who thinks this or there wouldn't be so many different ways to strip these data out.

You can certainly make the argument "storage is cheap" and therefore it's OK create files bloated with information which is rarely needed.

But that doesn't justify being dismissive of the legitimate request to make exporting those data optional.

[nohal]

Again... The data you call "absolutely useless" is not absolutely useless. That is the only misunderstanding here.

[Be Free]

Originally Posted by derfy

I can clarify.

The feature I seek is the ability to scrub a gpx file of all the Route Point Names.

Why? I create routes in Navionics and export their GPX files to my Raymarine for use driving the boat. These files have no route point names and work fine on the Raymarine. Often the routes have many closely spaced waypoints when I am in inland waterways.

Sometimes I send these GPX files to OpenCPN for further review and editing using different charts, etc. OpenCPN generates a lot of extra data for each route point, but the problem is the machine-generated Route Point Names. These are visible in my Raymarine and clutter the screen with meaningless text. So, I just need to suppress the export of Route Point Names. The other stuff is not needed, but not causing problems. In my older C-Series Raymarine memory was a premium and I would get rid of all that extra stuff.

For driving the boat, you just need the route name and route point lat and lon. Everything else if for something else.

I understand that is what you use the GPX export function for, but do you see that is not the only use case? OpenCPN exports its data in a format that it will need to import that same data in the future without losing any of the information or duplicating it. The GPX import/export function has been specifically designed to accomplish this.

It is certainly a valid and reasonable use of those GPX files to import them into another program that has that feature. However, it is up to the importing program to ignore any data that it does not understand (the OpenCPN specific schema items for instance). That is part of the standard.

As far as I can tell your Raymarine device is working exactly as the standard specifies it should. It is only importing data that it understands and knows how to display. The problem is that the file contains data that you don't want to display on that particular device. If your Raymarine does not have the ability to suppress the valid data that you don't want to see and does not give you the option of not importing it then it is up to you to remove the data before it is imported.

As Capt.Don has demonstrated, it is trivial to strip out the data you wish to suppress. That is why the file is in a format that is readable by any text editor. It is supposed to be edited by the consumer to fit their specific use case if there is a problem. Notepad ++ has a wonderful macro function that will let you do it with just a couple of keystrokes.

If, and it's a big if, the same functionality were to be added to OpenCPN it would make much more sense to put that functionality into a plugin, not into the base code or even into the track and route manager plugin. The existing plugin does exactly what it should do: it exports OpenCPN routes, tracks, and waypoints without losing data and it imports those same routes, tracks, and waypoints without duplicating data.

If you are proposing a stripped-down-barebones-export plugin or even a comprehensively-customizable-export plugin that is certainly something which could be discussed. It is my opinion and expectation that it would be a low-priority project due to the fact that tools like Notepad++ and even the existing javascript plugin can be used with very little effort to produce the same results. You are welcome and encouraged to make your case as to why this is a function that is needed but at this point I'm not convinced.

OpenCPN is not a Swiss army knife universal import/export tool. It imports and exports data primarily for its own use and for the use of any other standards-based utility. Part of that standard is the expectation that it is incumbent on the importing program to ignore any data that it does not understand or want. Raymarine understands and wants those waypoint names as evidenced by the fact that they imported and displayed them.

OpenCPN GPX files are not "bloated"; they contain exactly the data that OpenCPN understands and wants. The data in those files is not to useless to OpenCPN; it is there because OpenCPN wants and needs that data. It is not a matter of "cheap storage" it is the fact that data that is not in the file cannot be imported and while your Raymarine does not need that data OpenCPN does. They are different programs with different requirements.

[Grigory]

Originally Posted by derfy

...Attributes like <time>,<name>,<sym>,<type>,<extensions>, making the files much larger than need be.
...
So I manually edit out all this stuff, but it is too big a job.

You can use any text processor with macro possibilities (I have use MS Word 2003...) to delete all strings starting with some <tag>, or erase content between <tag> and </tag>.
Impotant: you should open and save files in plain text mode only.
Before work will you rename or copy file from myfile.gpx to myfile.txt, after saving vise versa. be carefully to dont destroy any header or another useful strings.
Need to check, is edited file good or not for usage.

[derfy]

Originally Posted by Be Free

I understand that is what you use the GPX export function for, but do you see that is not the only use case? OpenCPN exports its data in a format that it will need to import that same data in the future without losing any of the information or duplicating it. The GPX import/export function has been specifically designed to accomplish this.

It is certainly a valid and reasonable use of those GPX files to import them into another program that has that feature. However, it is up to the importing program to ignore any data that it does not understand (the OpenCPN specific schema items for instance). That is part of the standard.

As far as I can tell your Raymarine device is working exactly as the standard specifies it should. It is only importing data that it understands and knows how to display. The problem is that the file contains data that you don't want to display on that particular device. If your Raymarine does not have the ability to suppress the valid data that you don't want to see and does not give you the option of not importing it then it is up to you to remove the data before it is imported.

As Capt.Don has demonstrated, it is trivial to strip out the data you wish to suppress. That is why the file is in a format that is readable by any text editor. It is supposed to be edited by the consumer to fit their specific use case if there is a problem. Notepad ++ has a wonderful macro function that will let you do it with just a couple of keystrokes.

If, and it's a big if, the same functionality were to be added to OpenCPN it would make much more sense to put that functionality into a plugin, not into the base code or even into the track and route manager plugin. The existing plugin does exactly what it should do: it exports OpenCPN routes, tracks, and waypoints without losing data and it imports those same routes, tracks, and waypoints without duplicating data.

If you are proposing a stripped-down-barebones-export plugin or even a comprehensively-customizable-export plugin that is certainly something which could be discussed. It is my opinion and expectation that it would be a low-priority project due to the fact that tools like Notepad++ and even the existing javascript plugin can be used with very little effort to produce the same results. You are welcome and encouraged to make your case as to why this is a function that is needed but at this point I'm not convinced.

OpenCPN is not a Swiss army knife universal import/export tool. It imports and exports data primarily for its own use and for the use of any other standards-based utility. Part of that standard is the expectation that it is incumbent on the importing program to ignore any data that it does not understand or want. Raymarine understands and wants those waypoint names as evidenced by the fact that they imported and displayed them.

OpenCPN GPX files are not "bloated"; they contain exactly the data that OpenCPN understands and wants. The data in those files is not to useless to OpenCPN; it is there because OpenCPN wants and needs that data. It is not a matter of "cheap storage" it is the fact that data that is not in the file cannot be imported and while your Raymarine does not need that data OpenCPN does. They are different programs with different requirements.

Please help me understand, using your best example, of how any of the information elements in this exported OCPN gpx route point (other than the lat and lon) are of use by an external application that uses routes. Please be specific. I want to understand your point.

Recall that we are exporting a route, not a track or waypoint.

<rtept lat="44.237194908" lon="-69.015408719">
<time>2023-05-01T12:56:29Z</time>
<name>001</name>
<sym>diamond</sym>
<type>WPT</type>
<extensions>
<opencpn:guid>243f0000-d93f-4100-a4ce-60365d74ffff</opencpn:guid>
<opencpn:auto_name>1</opencpn:auto_name>
<opencpn:arrival_radius>0.050</opencpn:arrival_radius>
<opencpn:waypoint_range_rings visible="false" number="0" step="1" units="0" colour="#FF0000" />
<opencpn:scale_min_max UseScale="false" ScaleMin="2147483646" ScaleMax="0" />
</extensions>
</rtept>

[Be Free]

Originally Posted by derfy

Please help me understand, using your best example, of how any of the information elements in this exported OCPN gpx route point (other than the lat and lon) are of use by an external application that uses routes. Please be specific. I want to understand your point.

Recall that we are exporting a route, not a track or waypoint.

<rtept lat="44.237194908" lon="-69.015408719">
<time>2023-05-01T12:56:29Z</time>
<name>001</name>
<sym>diamond</sym>
<type>WPT</type>
<extensions>
<opencpn:guid>243f0000-d93f-4100-a4ce-60365d74ffff</opencpn:guid>
<opencpn:auto_name>1</opencpn:auto_name>
<opencpn:arrival_radius>0.050</opencpn:arrival_radius>
<opencpn:waypoint_range_rings visible="false" number="0" step="1" units="0" colour="#FF0000" />
<opencpn:scale_min_max UseScale="false" ScaleMin="2147483646" ScaleMax="0" />
</extensions>
</rtept>

I can explain it, but I don't think you are not going to like it.

First, thank you for remaining engaged.

Second, a minor point of clarification: You are not exporting a route, you are exporting a series of waypoints wrapped in a particular group of standard tags that indicate that they should be treated as a route rather than a track or even just a list of waypoints. It is the schema, the specific ordering of those tags, that turns a list of waypoints into a route. It is the schema, the standard, which allows the interchange of data.

Part of that standard is the expectation that there may be data in the file that is of no interest to the program that is importing it. In fact, I would go so far as to say that the only time that a program that is importing a GPX file should expect that there will be no more and no less data than it absolutely needs is if it is importing a GPX file that it created. Discarding data in the GPX file that is not needed for the current operation is an integral part of the import process.

The program that creates the GPX file does not know and does not care what any other program (other than itself) is going to need from that file. The purpose of exporting data in a GPX file is to publish what the originating program knows about the route, track, and/or waypoint. There is a specified minimum number of data types which must be created in a valid GPX file but there is, by design, no maximum.

A GPX file is a resource which has been created in a standard format for the purpose of publishing as much or as little (as long as it meets the minimum requirements) information as the originating program chooses to provide. It is expected, but not required, that the originating program provide as much information as it can in the file. Withholding information, absent a compelling reason, is considered rude and not in the spirit of cooperation.

It is expected and supported by the standard that the originating program will include information in the GPX file that is of absolutely no use to any program other than the one which created the file. In your example all of that information is clearly tagged with "opencpn:xxxxx". All programs, other than OpenCPN, which import this data are expected (but not required) to ignore this data which was created for the express use of OpenCPN.

So, my first example is the data which has clearly been marked by OpenCPN as something which for its own internal use. Every one of those entries is for the express purpose of preventing data loss or duplication if this file is imported back into OpenCPN.

Does a generic autopilot need the data? Absolutely not.

Does OpenCPN (or any other program that exports data in this format) know (or care) that it will be used as input to a generic autopilot? Again, absolutely not.

The only program in the world that knows the data is being imported into a generic autopilot is the generic autopilot. The data is clearly marked as "not meant for you" and it is up to the generic autopilot to do with the data as it sees fit. The expected behavior of the autopilot is that it will ignore data that is clearly marked as "not meant for you".

That leaves us with:
<time>2023-05-01T12:56:29Z</time>
<name>001</name>
<sym>diamond</sym>

The <time> entry indicates the time that the waypoint was created. A valid use of this field could be to replace an older waypoint with one that was perhaps moved and saved at a later date.

Does the generic autopilot care when the waypoint was created? Maybe. If it does not then it is free to ignore it. OpenCPN certainly cares when the waypoint was created and will use that information if the GPX file is imported.

The <name> entry (obviously) indicates the name of the waypoint. A valid use of the field may be to standardize the names of your waypoints between programs. I find it very useful to call the same waypoint by the same descriptive name regardless of which program or device I'm working with.

Does the generic autopilot care what name another program called a waypoint? Probably. If it does then it is free to use the name in the GPX file. If it does not then it is free to generate one on its own. OpenCPN certainly cares and will use it if the GPX file is imported.

The <sym> entry indicates the preferred symbol to be displayed when the waypoint is shown on a screen. A valid use of the field may be to standardize (as much as possible) the symbols used to display your waypoints. There are a number of generally recognized symbols that are used by a wide range of manufacturers. The symbols are not all identical, but they are at least recognizable.

Does the generic autopilot care what symbol was used to represent the waypoint on another program? Possibly. If it does then it is free to use a symbol with the same name from its own images. If it does not, or if it has nothing by the same name, then it is free to use any symbol is chooses (or none) to represent the waypoint on the screen. OpenCPN certainly cares and will use the information to associate the same symbol with the waypoint if the GPX file is imported.

I would also like to mention that there are a lot of other data types that OpenCPN does not generate when it exports data. This is not because it could not determine the data, its because it is of no use to OpenCPN. One example that comes to mind is altitude. There is a very good chance that the current altitude could be determined from equipment found on most boats. The fact remains though that OpenCPN does not need, use, or care about it (at this time) so it does not include it in the GPX file even though there is a spot there for it. I've not tested it but I expect that if you were to import a GPX file that included altitude that OpenCPN would ignore it.

It might help to think of the GPX file as a reference book (or a web page if you prefer). The author knows something, perhaps a great deal, about something that you are interested in. The author has no idea who is going to read this or what parts they will be interested in.

He has created this reference book for his own use but has graciously presented everything he knows in clearly marked chapters and sections with tabs so you can pick and choose what you are interested in and easily (some might even say, "trivially") skip over everything you don't need.

In fact, this reference material is so clearly and thoroughly organized that if you change your mind you can easily get information that you previously skipped, skip information that you previously needed, or even add your own notes in the book (which may or may not be of interest to the author or anyone else).

My point, which I hope I've presented clearly, is that a GPX file is meant to be a comprehensive repository of knowledge, clearly indexed and easily accessed.

Knowledge that is not needed by a particular application at a particular time is meant to be skipped over. Knowledge that was never in the file cannot be accessed by any application at any time.

The exporting program exports everything it knows. The importing program takes what it needs and ignores the rest because it is the only one who knows what it needs. Any other configuration requires coordination between the exporting and importing program and only serves to complicate the process.