Connect data to AtlasEvo, work with it in Workspace, and send it where it needs to go

You do not need to begin with a protocol name. Begin with the thing you have and the result you need. AtlasEvo can then separate source, protocol, link, transport, representation, Workspace storage, and delivery so each part can change without forcing you to redesign the whole project.

Observation assets and existing data sources reach Atlas through connectivity and interface layers. AtlasEvo then adds spatial context, ingestion, rules, access controls, and Workspace organization before data is visualized, exported, used by applications, or shared with research and education communities.

The operational sequence is straightforward even when the hardware is not: identify the platform, establish its position model, describe the connectivity chain, define observations, test the path, and then make the resulting data available in Workspace. The Research wizard groups these jobs into five onboarding stages.

Connectivity changes availability, latency, bandwidth, addressing, power use, and whether the source can be reached continuously. It does not change what the observation means. Design a gateway or store-and-forward path that matches the link, then use an Atlas-facing access method that the current project actually supports.

Workspace is where normalized project records, geometry, layers, source relationships, and derived results become usable together. Preserve the original source and product identity even when the representation is converted before it reaches Workspace.

1. 1. Create or select the Workspace that represents the real project or operating context.
2. 2. Add a Source for the real origin: station, provider, agency service, Copernicus product, file collection, API, or partner system.
3. 3. Create/select the Dataset that should own the usable records. Keep unrelated sources in separate datasets when provenance or refresh behavior differs.
4. 4. Choose the ingestion path. Use direct GeoJSON import when appropriate; otherwise use Research REST, DataSynch, a source API/toolbox, or a verified connector to normalize records.
5. 5. Verify time, coordinates, vertical reference, units, observation meaning, source identity, and any standard/profile/version metadata before treating the data as ready.
6. 6. Create map layers only when a spatial view helps. The dataset remains the record container; a layer is a presentation/organization surface, not the source of truth.

A Workspace is the AtlasEvo project. The important hierarchy is not “a pile of layers”; it is a traceable chain from source data to usable project output.

The permanent navigation is intentionally compact. Project and data actions live in menus so controls never consume a large part of the map viewport.

A basemap is reference context, not your project database. Switching providers does not copy, rewrite, or re-import your AtlasEvo datasets.

Start by deciding whether the information is a new independent source or additional records for a source you already created. Then create or select the dataset that should hold the records. Spatial records can be placed into a layer; non-spatial records remain part of the dataset and can still be exported or moved through integrations.

1. 1. Open Data → Add source and name the real origin, such as “Kobo canal inspections” or “County parcels”.
2. 2. Select that source and use Data → New dataset for the specific record set you want to manage.
3. 3. Use Data → Add data for files or geometry, or use Connections/DataSynch when another system should supply the records.
4. 4. Create a layer when records need a map view. A project can use several layers from the same dataset when different visual organization is useful.
5. 5. Use the Sources, datasets & layers panel to move through the project hierarchy. Selecting a dataset makes it the active dataset for export and related actions.
6. 6. Use Data → Export active dataset when you need the records outside AtlasEvo as CSV, GeoJSON, or JSON.

Use Research onboarding for a physical or virtual platform that produces observations over time. The wizard records what the platform is, where it operates, what observations mean, how data moves locally, how Atlas accesses the gateway/source, and what the project may do with the resulting records.

Required fields vs. values that can come from telemetry

The list below deliberately distinguishes file/data representation, device protocol, web service, provider ecosystem, and geospatial product specification. “Covered” does not mean every item is a one-click Workspace parser. Use the support path shown for each family so the instructions match the current product.

Official references

Use the official specification/provider documentation below when implementing the external side of an integration. Atlas documentation explains how to fit the result into AtlasEvo; the standards organizations and vendors define their protocols, formats, products, and services.

Keep collecting in KoboToolbox. AtlasEvo connects those observations to the organization’s actual geography and lets the project decide whether Atlas results should ever be written back.

Values you need from KoboToolbox

How to connect KoboToolbox in DataSynch

Atlas capabilities can operate on project datasets without requiring the source application to become the analysis system.

Store derived results with lineage back to the source records used to create them.

A connection describes how AtlasEvo can exchange data with another system. A connection does not automatically authorize Atlasemoji to change that system.

DataSynch moves and orchestrates data. AtlasEvo stores the project, datasets, layers, provenance, and results. Either side can be the source or destination of a workflow.

Choose the sharing method based on what the recipient needs to do. A collaborator who needs to work inside the project is different from someone who only needs a file or a downstream system that needs structured records.

Safe refresh, comparison, and write-back depend on provenance. AtlasEvo assets and records should retain their source, dataset, external identity, import timing, and derived lineage.

1. 1Create a workspace for the real project, not for a single file.
2. 2Add the first source, for example KoboToolbox field observations.
3. 3Create a dataset for those observations.
4. 4Add reference geography such as canals, parcels, facilities, roads, or service areas as a separate source/dataset.
5. 5Create layers for the spatial views you need.
6. 6Switch basemaps to choose the best reference context; use 2D or 3D as needed.
7. 7Run Atlas analysis and keep derived results traceable to their inputs.
8. 8Review Connections before sending anything back to an external system.
9. 9Export or route the approved result to the next destination.