NDS: Specifications for the global navigation data standard
We've been working with parson for almost 20 years, and it shows. The team knows our standard inside out, provides valuable input on the ongoing development of the data model, and stays up to date with new tools and AI technologies.
The challenge
The Navigation Data Standard defines how map data is exchanged between manufacturers, data providers, and vehicles. NDS.Classic specifies a physical database format stored in the vehicle. NDS.Live replaces this model with a service-oriented approach: Map data is organized into functional modules and delivered through services. Vehicles retrieve exactly the data they need at any given moment, whether from a cloud backend, local storage, or a combination of both.
This calls for a fundamentally different approach to technical documentation. Specifications need to be available where developers work: in the code itself. Documentation must be integrated directly into the development process so that it evolves alongside the implementation, allowing changes to code and documentation to be reviewed together.
NDS.Live also requires comprehensive system documentation that describes the standard as a whole, explains key concepts, and covers use cases spanning multiple modules. Another requirement is the ability to validate the data layers modeled in YAML for these use cases against the data schema using NDS's own tools.
Our approach: Docs in Code
For NDS.Live, we have integrated the module specifications directly into the schema. The data model is defined using the zserio schema language, with explanations, concepts, and examples embedded as structured comments alongside the definitions they describe. The schema and its documentation are stored in the same files and are versioned, reviewed, and published together.
Our core approach has remained largely unchanged since NDS.Classic: researching content alongside development in working groups, collaborating closely with architects and developers, maintaining consistent terminology, and managing work through tickets. The tools have changed, but our commitment to quality hasn't.
Here's what this looks like in practice:
- One source, no synchronization needed. Descriptions and the data model are stored in the same file, making it easier to keep them consistent.
- Technical writing as part of development. We work with Git, feature branches, and pull requests. Documentation changes go through the same review process as source code. We also review changes developers make to the data model.
- Testable rules instead of ambiguous prose. We express normative requirements as individual, uniquely identifiable rules within the schema. These form the basis for certification, as each rule can be translated into a test case.
- Automated quality assurance. Terminology, writing conventions, cross-references, and illustrations are checked automatically whenever changes are made. Errors are caught during authoring rather than at release time.
- Publishing to the Developer Portal. NDS's custom-built Developer Portal is generated automatically from the schema files and supplementary Markdown chapters. It gives developers a single, searchable, versioned resource for system documentation, module references, normative rules, and best practices.
- Documentation framework with AI integration. We author all documentation in Visual Studio Code, using AI assistance to generate drafts and code examples, check writing conventions, extract information from tickets, and trace commits in Git. Custom skills developed for the team help streamline quality checks and ensure that generated diagrams follow our style guidelines. The team always retains responsibility for technical accuracy and editorial quality.
The results
The data model and documentation are now maintained, reviewed, and versioned together. The Developer Portal brings module specifications, system documentation, normative rules, and implementation examples into a single, searchable resource for developers.
This ensures that the data model and its documentation stay in sync. Automated checks support quality assurance, while close integration with the development process reduces the need for coordination.
Services provided
NDS.Live
- Content research through interviews, workshops, and working group meetings
- English-language specification content written directly in the zserio schema, along with system documentation in Markdown
- Technical and editorial review of schema and data model changes in pull requests
- Definition of normative rules as the basis for conformance testing and certification
- Terminology and style guide maintenance, including automated checking tools
- Information architecture and content strategy for the Developer Portal
- Design and creation of diagrams and illustrations
- Best practices and implementation examples addressing common development questions
- Ticket management, meeting facilitation, and documentation of working group meetings
NDS.Classic (frozen version)
- Participation in working group meetings to identify the need for known-issue documentation
- Creation of known-issue documentation in DITA XML using Oxygen XML Editor
- Generation and upload of PDF and HTML output formats
Learn more: We presented our Docs in Code approach at the tcworld conference 2022 (in German):
About Navigation Data Standard (NDS) e.V.
NDS e.V. is an international consortium of automotive manufacturers, suppliers, map data providers, and navigation system manufacturers. Since 2007, the organization has been developing a vendor-independent standard for map data. With NDS.Live, it is transitioning the standard to a service-oriented architecture that supports continuously updated map data and vehicle-related services.