Map external formats and standards into AtlasEvo without losing what they mean
This page describes the integration contract between an external format, protocol, product, or device ecosystem and AtlasEvo. The goal is practical: identify what arrives, show where it belongs in Atlas, and keep enough source context that a Workspace record remains traceable to the standard, product, device, and version that produced it.
M, C, and O describe the Atlas integration mapping on this page. They are not a replacement for the mandatory, conditional, or optional rules in an external standard. Edition-specific conformance remains defined by the standards body or provider.
The AtlasEvo integration contract
Across formats, Atlas tries to preserve the same core ideas: who produced the data, which standard or profile describes it, which record or feature it came from, where and when it applies, what the value means, which units and references apply, and how the Atlas representation was derived.
Provider, system, station, product, service, or file collection.
Standard, profile, edition/version, dialect, product or schema.
External feature, record, observation, array, message, or product identity.
Geometry, coordinates, CRS, vertical reference, observed time and validity.
Phenomenon, variable, attribute meaning, unit, scale and quality context.
How the Atlas record was selected, converted, normalized, or derived.
Source version, update identity, modified time or synchronization cursor.
How approved Atlas records are exported or routed without losing source context.
GeoJSON
Geospatial interchange format
GeoJSON is a direct Workspace-friendly representation. Atlas keeps feature identity and properties while mapping geometry into project records and layers. Longitude/latitude order and CRS assumptions should remain explicit in the integration documentation.
| Source element | Atlas mapping | AtlasEvo representation | Mapping notes |
|---|---|---|---|
| Feature.id / source record key | M | sourceRecordId / record identity | Use a stable external identifier when the source provides one so refreshes and reconciliation target the same record. |
| Feature.geometry | M | Workspace geometry | Preserve the GeoJSON geometry type and coordinate order used by the source. |
| Feature.properties | M | Dataset record properties | Map source properties without discarding fields needed for provenance, joins, classification, or later export. |
| Collection / source URI / file identity | C | Source and provenance metadata | Keep the collection, service, file, or provider identity when GeoJSON is only one representation of a larger source. |
JSON / CSV
Structured and tabular interchange
JSON and CSV become useful in Atlas when the integration describes identity, time, location, units, and field meaning. DataSynch is the normal mapping surface when source columns or object fields need to be translated into reusable Workspace records.
| Source element | Atlas mapping | AtlasEvo representation | Mapping notes |
|---|---|---|---|
| Stable source key | M | sourceRecordId / external identity | Choose the field or field combination that remains stable across refreshes. |
| Latitude / longitude or address/location fields | C | Position / geometry / location relationship | Map the location representation that actually exists in the source; coordinate validation and geocoding can be separate steps. |
| Timestamp / effective time | C | observedAt / source time / record metadata | Use the source time that matches the meaning of the record, not merely the import time. |
| Business or scientific fields | M | Dataset properties / observation values | Document source-to-Atlas field mapping, type, units and any conversion applied. |
NetCDF / CF
Multidimensional scientific data with CF metadata conventions
CF metadata gives Atlas useful semantic anchors for scientific variables, coordinates, units, time, and grid mapping. A project can select the variables and ranges it needs while keeping the source dataset, CF identity, coordinate system, and selection provenance attached to the resulting Workspace data.
| Source element | Atlas mapping | AtlasEvo representation | Mapping notes |
|---|---|---|---|
| Dataset / product identifier | M | Source identity / provenance | Keep the provider and dataset or product identifier so the selected records remain traceable to the original source. |
| Variable name + standard_name / long_name | M | Phenomenon / field semantic metadata | CF standard_name is especially useful when present because it identifies the physical quantity independently of a local variable name. |
| units | M | Observation / field unit | Keep the source unit and any explicit normalization or conversion used by the project. |
| Coordinate variables / coordinates | M | Position, time and vertical dimensions | Map the dimensions that locate each selected value in space, time, depth, altitude, pressure or other scientific axes. |
| grid_mapping / CRS metadata | C | Spatial reference metadata | Preserve the grid or coordinate reference information needed to interpret the source positions correctly. |
| _FillValue / missing-value semantics / quality flags | C | Quality and null handling | Carry missing-value and quality meaning into the mapping so unavailable or flagged source values are not treated as ordinary observations. |
Zarr
Chunked N-dimensional array storage
Zarr describes how N-dimensional arrays, groups, chunks, data types, codecs, and metadata are stored. Atlas normally maps the selected scientific content rather than treating storage chunking as the business meaning of the data. When CF-style metadata is present, the same variable, coordinate, unit, and grid mapping principles can be carried into the Atlas mapping.
| Source element | Atlas mapping | AtlasEvo representation | Mapping notes |
|---|---|---|---|
| Store URI / dataset identity | M | Source identity / provenance | Keep the store and provider identity plus the array/group paths selected for the project. |
| Array / group path | M | Dataset / variable source path | Record the exact hierarchy path so the Atlas record can be traced back to the source array or group. |
| shape / dimension names / coordinates | M | Dataset dimensions and spatial/time/vertical context | Map dimensions by meaning; storage chunk shape is useful operational metadata but is not itself a scientific coordinate. |
| data_type / fill_value | C | Field type / null semantics | Keep source data type and missing-value behavior when they affect interpretation or conversion. |
| attributes | C | Source and variable metadata | Preserve useful scientific, provider, CF, or project metadata carried in attributes. |
OGC API - Features / WMS / WMTS
Feature APIs and map services
OGC services serve different jobs. OGC API - Features exposes feature data; WMS returns georeferenced map images; WMTS returns tiled map imagery. Atlas keeps the service role and source collection or layer identity so a reference map is not confused with an editable feature dataset or telemetry feed.
| Source element | Atlas mapping | AtlasEvo representation | Mapping notes |
|---|---|---|---|
| Service URL + service/version | M | Source connection metadata | Keep the service endpoint and service family used by the project. |
| Collection / layer identifier | M | Source dataset or reference-layer identity | Map the collection or layer selected by the project rather than only storing the service root. |
| Feature identifier + properties | C | Dataset record identity and properties | Applies when the service returns feature records, such as OGC API - Features. |
| CRS / bounding box / tile matrix context | C | Spatial reference and request metadata | Preserve the spatial reference and request context needed to interpret returned features, images, or tiles. |
MAVLink / ArduPilot / ArduSub / BlueOS
Vehicle protocol and companion/gateway ecosystems
Atlas treats the vehicle protocol, local link, companion/gateway, and Atlas-facing transport as separate layers. MAVLink can travel over different underlying links. ArduPilot or ArduSub remains responsible for vehicle control; a companion computer or BlueOS can route or process telemetry and forward the approved observations that belong in AtlasEvo.
| Source element | Atlas mapping | AtlasEvo representation | Mapping notes |
|---|---|---|---|
| MAVLink system ID / component ID | M | Station/device identity metadata | Keep the source system and component identity used to distinguish vehicle and onboard components. |
| MAVLink message type + field | M | Observation family / value mapping | Document the specific message and source field that becomes each Atlas observation or telemetry property. |
| Message / vehicle time | C | observedAt / source time | Choose the time field that represents the measurement or vehicle state being stored. |
| Position fields | C | latitude / longitude / position | Moving platforms can supply position with each observation instead of relying on a fixed station coordinate. |
| Altitude / depth + reference | C | vertical.value / unit / reference | Record the vertical reference explicitly so altitude, depth, pressure-derived depth, and other vertical quantities remain meaningful. |
| Serial / radio / Ethernet / Wi-Fi / tether | C | connectivity.links | This describes how bytes move locally; it stays separate from MAVLink as the message protocol. |
| Gateway HTTP / WebSocket access | C | Atlas transport / integration metadata | The gateway can expose the approved observations to Atlas over an Internet-facing transport while keeping vehicle control local. |
Copernicus Marine
Ocean-data catalogue and data service
Copernicus Marine is the source and service ecosystem; the selected data can arrive in different representations. Atlas keeps the Copernicus product, dataset, variable, spatial, temporal, and depth selection context together with the representation used for the integration.
| Source element | Atlas mapping | AtlasEvo representation | Mapping notes |
|---|---|---|---|
| Product identifier | M | Source product identity | Keep the product identity used to discover the data. |
| Dataset identifier | M | Source dataset identity | Keep the selected dataset distinct from the broader product. |
| Variable identifier / metadata | M | Phenomenon / field mapping | Map the actual variable used by the project and preserve its source name, unit, and descriptive metadata. |
| Time / depth / spatial subset | C | Selection provenance | Record the subset boundaries that explain which part of the source dataset produced the Workspace records. |
| NetCDF / Zarr / other returned representation | C | Representation metadata | Record the representation used to retrieve or process the selected data; it is separate from the Copernicus source identity. |
IHO S-100 family
Hydrographic framework and product specifications
S-100 is the framework; S-101, S-102, S-103, S-104, S-111 and other S-1xx specifications define particular data products. Atlas keeps the specific product and edition with the mapped content. Exact feature and attribute mappings are edition-specific and should be generated from the product specification and feature catalogue used by the source.
| Source element | Atlas mapping | AtlasEvo representation | Mapping notes |
|---|---|---|---|
| S-1xx product identifier | M | standard.profile | Record the specific S-1xx product rather than only the S-100 family when the product is known. |
| Edition / version | M | standard.version | Keep the edition used by the source so later mappings can be interpreted against the correct product specification. |
| Dataset / exchange-set identity | M | Source identity / provenance | Preserve the source product or exchange-set identity used to create the Atlas records. |
| Feature / coverage / information object identity | M | sourceRecordId / mapped record identity | Keep the external object identity when the product provides one. |
| Geometry / coverage location | C | Workspace geometry / spatial coverage | Map the spatial representation required by the Workspace while keeping the source product relationship. |
| Attributes / values / units / datum | C | Dataset properties / observations / vertical metadata | Map the values the project needs and preserve the product-specific meaning, units and references that interpret them. |
| Portrayal / catalogue / encoding metadata | O | Standards extension metadata | Keep the references needed for traceability, portrayal, validation or later product-aware processing when they matter to the project. |
How the common S-1xx products usually land in AtlasEvo
ENC feature and geometry content -> dataset records / geometry; product, edition, source dataset and catalogue context stay attached.
Bathymetric surface -> coverage/raster or selected depth records; vertical datum, grid/source identity and edition stay attached.
Sub-surface navigation content -> mapped navigation features or records; product and edition remain part of the source context.
Water-level information -> time-aware observations or records with units and vertical reference/datum.
Surface-current information -> time-aware vector or value records with speed/direction meaning, units, depth/vertical context when present, and product provenance.
GGDM / DGIF / DGIM
Geospatial data-model and information-framework lineage
These models belong in the standards and schema layer, not the transport layer. Atlas can map the features and attributes needed by a project while keeping the supplied model, profile, implementation schema, version, source identity, and code-list context available for traceability.
| Source element | Atlas mapping | AtlasEvo representation | Mapping notes |
|---|---|---|---|
| Model / profile / implementation schema | M | Standard/profile metadata | Record the actual profile or implementation schema supplied with the data. |
| Feature class / type | M | Dataset record type / mapping rule | Document which source feature class maps to which Atlas dataset or record family. |
| Feature identifier | M | sourceRecordId | Preserve durable source identity when available. |
| Geometry | C | Workspace geometry | Map source geometry and retain the coordinate reference context needed to interpret it. |
| Attributes / code lists / domains | C | Record properties + mapping metadata | Keep source values and the mapping or code-list context needed to understand them. |
The mapping also works in the other direction
When Atlas data leaves a Workspace, the destination mapping should be just as explicit as the inbound mapping. File exports preserve the fields represented by the selected dataset. DataSynch can map Atlas fields into an enabled API, file, database, cloud service, or application destination. Where a destination requires a particular standard or schema, use an outbound mapping profile that identifies the target field, requirement, type, unit, transformation, and source Atlas field.