Config information (CRS, units, etc.) should be associated with datasets

[ianberg-volpe]

Currently configuration information is stored in gmns.spec.json, and the default values included within are assumed to apply to all datasets that are being validated against that version of the spec.

https://github.com/zephyr-data-specs/GMNS/blob/6ec8c5e85dde95402852cc6b28b8b7a810902047/Specification/gmns.spec.json#L147-L173

It would make more sense for this information to

1. be stored entirely at the dataset level, or
2. be overridable when datasets need to differ from the defaults.

That way, a user won't need a separate copy of the spec if they have multiple datasets with different coordinate systems, units, etc. Indeed, some of our example datasets (Arlington and Lima) don't follow the defaults we've chosen in the spec file.

Is there a preference between option 1 or option 2? Does it make sense to integrate these into an existing defined table, or is a new table needed?

[AntoineGrapperon]

Thanks for reporting this issue here. The issue with the coordinate reference system will be the same for any other recommended config: currency, speed etc.

I like the option 1 better (or at least forcing having a spec file, even an empty one), maybe stored as a "config.spec" alongside the network files.

2 thoughts:

• I think a stricter format is better for data consumers: having to support many types of geometry_field_format, speeds etc makes it more work to maintain
• maybe it is worth including a version_number in config.spec. That way, datasets produced today with the current format specification could be updated and still be valid in case the format evolves.