Yeah, you should update your SG/FG/FGDATA checkouts and rebuild your binaries.
Deleting labels/symbols is not an issue as long as you also remove all references to them in your style.
However, keep in mind that the update() method may contain a few hard-coded references.
For starters, I'd probably leave them as is and focus on new additions rather than removing redundant stuff.
A good compromise would be simply hiding all unneeded symbols via .hide() - that way, there shouldn't be any errors due to missing symbols, and you'll still get a "blank" ND that you can populate.
Right thank you, I did that but I still feel that it's a better idea to let the aircraft/instrument developers be able to keep the data on an external file in their aircraft directory.
I would agree with you, maybe, 5+ years from now - but given the state of Canvas, MapStructure and the ND, it would be premature to allow that.
Just look at things like XML, the property tree, Nasal etc - these are all powerful technologies, but they are too much "free-form", i.e. these days our main problem in FlightGear is lack of consistency and lack of backward compatibility, we have a ton of great features, that end up being inconsistent more often than not - even though mainy features are heavily related/overlapping, or even identical.
Things like the "route manager" issues you keep mentioning are exactly because of this: people no longer have to use proper interfaces to use a feature, they will come up with code to use the feature, without using encapsulation that would shield/protect them from future changes and additions.
And that's something that we've been seeing in a ton of places in FlightGear lately. XML, properties and Nasal make it far too easy for people to end up with a working feature, without thinking about general designs and reusable components. Gijs went through the same experience when he came up with the original ND code: it wasn't generic at all, it was highly specific to a single aircraft, it used a ton of hand-written code, without any abstractions/helper, and it would only support a single aircraft and a single instance.
We've been working towards improving this - and we're basically almost there now, Gijs has recently done a lot of work and refactored the navdisplay.mfd file to move aircraft specific code out into the style-file. So there really isn't much left that needs to be done now.
But the instant we allow/encourage people to use separate files, we'll the same thing happen again.
Just look at the way MapStructure is structured: it is all about modularity, code reuse and encapsulation: anybody can now easily create custom layers, and use them on arbitrary aircraft, and even on arbitrary GUI dialogs. And the whole thing is designed to support styling and customizing right from the beginning, and even supports multiple instances. And all that in under 1k lines of Nasal codes.
This is a huge step and a huge accomplisment. Over time, this means that collaboration will be more streamlined, and that people may benefit from related/similar contributions automatically. For instances, Gijs' original work has meanwhile benefitted at least half a dozen of different aircraft developers (some of whom now got involved in ND development/maintenance), and the same work has also helped unifying the 2D rendering back-end by re-implementing the hard-coded Map dialog.
This is how, and why, collaboration scales so well if done properly.
We could trivially support external files, styles etc - but it would not be a good decision for the time being, for all the reasons I mentioned above: we would end up losing all the collaboration that's currently going on. We've got some extremely talented aircraft developers, including some who write exceptionally clean Nasal code - just look at some of the recent work done by the extra500 developers and their Avidyne Entegra R9: it's an awesome piece of work, but people are basically unable to fly the aircraft with >= 20 fps because it is suffering from implementation problems, many of which we've solved already on the MapStructure/ND side, and others we know how to solve easily.
Canvas is a relatively recent and novel addition to FlightGear, and it is not about certain instruments or displays like a PFD, ND, CDU or EICAS - it's just the foundation for other people to develop frameworks on top. But once we encourage/support a non-modular development strategy, we'll see the same thing happening that happened when the Route Manager got updated: people will start yelling at us that something no longer works, and that they need to update their aircraft, for which they don't have the time - without understanding the real culprit, namely their inadequate implementation strategy and original approach.
Canvas is not about a single instrument or display, which is why we have to come up with scripted frameworks for these purposes - once we encourage collaboration (shared/common code base), we can easily extract buidling blocks to help shape a framework and an API for the most-common purposes. This is what happened when Gijs' started his original ND work: it's meanwhile become 2 frameworks already: one for mapping/charting (MapStructure) and 2) one for NDs.
It would take us 2-3 hours to generalize this a little more and turn the same code into a framework for creating PFDs or other MFD-style displays, as long as the same approach is used (SVG elements animated via Nasal callbacks), it's as simple as that.
At that point, there will be 3-4 frameworks, all based on the same work created by the same developer, but with potentially 5-7 additional contributors, like Hyde, Soitanen, Michat, Philosopher or myself.
Gijs has demonstrated that he's meanwhile able to help create, edit and maintain MapStructure layers - and he'll immediately benefit from any other work related to this. And people won't have to come up with their own solutions to work around common issues - the Avidyne Entegra R9 developers are re-inventing the wheel and adapting MapStructure/ND code in a Copy&Paste fashion - which means that they'll inevitably have to update their own code once certain Canvas optimizations become available - all MapStructure-based displays (like the ND), but also any other framework-based solutions, will automatically benefit from such additions, because it is just the underlying framework that will be updated.
Just look at the amount of code that is needed to create independent ND instances these days - most of it even being boilerplate, i.e. you can basically strip it down to less than 50 lines of code, and it will continue to work, no matter what's changed on the Canvas side of things. Aircraft developers will not have to update any custom code at all, it's all delegated to framework developers/maintainers.