Expertise · Geospatial data

Earth observation layers over a territory, each with the source, read time and limit written next to it.

We build the operational map of a territory from public Earth observation sources — Copernicus, OpenStreetMap, orbital catalogues, government orthophoto — and attach to each layer the provenance, the time of the last successful read and what it cannot show. The measurements are published together with the method that produced them.

Discuss a project

Already builtThree in-house implementations, which can be opened externally today. FlowMind runs on its own VM and has 109 API routes, nine of which speak directly to Copernicus Data Space Ecosystem (`src/app/api/copernicus/`, verified by counting on disk). Relieva returns 200 and requests a live Sentinel image on every page load (680,122 bytes, verified with curl on 06.09.2026). Orbital Nexus is public at `https://www.megapromoting.com/satelit/` and locally propagates a catalogue of approximately 11,900 objects. The reserve that must be said in the first sentence: we do not own any satellite or any sensor. Copernicus is a public programme of the European Union, and the orbital catalogue comes from CelesTrak, which redistributes data maintained by the US Space Force. What we built is the layer on top.

A territory — a city, a district, an infrastructure area — can be read from data that already exists publicly: satellite images, street geometry, terrain models, cadastral orthophotos, orbital catalogues. This service brings them together in a single operational map and, more importantly, keeps track of what each layer means: which sensor produced it, at what resolution, how often it is refreshed and when it was last successfully read.

It must be stated clearly, because it is easy to misunderstand and because it is a claim some make without right: **Copernicus is not ours.** It is the European Union's Earth observation programme, with its satellites, sensors and archive. We authenticate to Copernicus Data Space Ecosystem with our own `client_credentials`-type credentials and request processed products via API. Resolution, revisit frequency, cloud cover and radiometric quality belong to the mission, not to us. The same applies to the orbital catalogue: it comes from CelesTrak, with attribution displayed, because their policy requires it. What we keep are authentication, the correct request, computation, rendering, provenance guarding and interpretation.

The content rule is the same everywhere: a number is published together with the method that produced it. The slope of a street means something else if it was calculated with the Horn 3×3 kernel on a 25 m raster than if it was read from two points 30 m apart. The height of a building means something else if it is declared in OpenStreetMap than if it is estimated from the number of storeys. Mixing the two categories under the same colour is the most common way to deliver a map that looks good and lies.

When a source does not respond, the layer is marked OFFLINE, with the reason, and is not filled with a plausible value. In FlowMind the rule has an automatic guardian, `noFakeLive`, which refuses to label a layer LIVE without proof of a successful reading. An empty pixel means “we did not observe here”, not “there is nothing here”.

What it covers

The work, by component

The question chooses the sensor, not the other way round

The first stage is not technical. “Where vegetation is degrading”, “where a wheeled vehicle can climb”, “where the surface changed between two dates” and “what happens at night or under clouds” call for different tools. Multispectral optical at 10 m for vegetation and water, C-band radar for conditions in which optical cannot see, thermal band at kilometre scale for surface contrast, terrain model for slope. A wrongly chosen sensor produces a result that seems correct and is not.

We request the processed product, on the requested bounding box and time window

We do not download entire scenes just to cut them locally. The request to Copernicus contains the geographic bounding box, the time interval and an evaluation script that says exactly which band goes in and what comes out as a pixel. In FlowMind, Sentinel-2 requests go to collection `sentinel-2-l2a` at endpoint `https://sh.dataspace.copernicus.eu/api/v1/process`; Sentinel-1 to `sentinel-1-grd`, Sentinel-5P to `sentinel-5p-l2`. NDVI is calculated from B08 and B04, NDWI from B03 and B08 — in evalscript, at source, not from an already compressed image.

We publish the figure with the method attached to it

Each result block carries a provenance label. In Relieva there are three: measured, from sources and proposed. Under the slope map it says literally “COP-DEM GLO-30 · UTM 35N 25 m · Horn 3×3”, and under the relief scene it says vertical exaggeration ×3.5, precisely because exaggerated relief is beautiful and misleading. A buyer who wants to verify a figure must be able to retrace the path back to it.

Cloud mask, not cloud removal

Sentinel-2 requests reject from the start scenes with more than 40% cloud cover (`MAX_CLOUD_COVERAGE = 40`). In evalscript, the pixels that the scene classification band SCL marks as cloud, cloud shadow, cirrus or snow — classes 3, 8, 9, 10 and 11 — are returned fully transparent. The convenient alternative, filling the gap from an older scene, produces a continuous image that mixes two moments. We prefer the gap, because it can be read correctly.

Radar when optics cannot

Sentinel-1 C-SAR passes through clouds and works at night, at 10 m, with a revisit of around 6–12 days. In our products, the ratio between VV and VH polarisation is used as a single-scene screening: it shows differences in surface and moisture. It is not interferometry. Millimetric ground displacements require ascending/descending pairs, orbit files, a terrain model and a phase unwrapping step — a separate job, marked as such in our product catalogue, not something we deliver from a tile request.

The surface model is not the terrain model — the trap that gives no error

Copernicus DEM GLO-30 is a digital surface model: in a dense block it returns roof elevation, not carriageway elevation. Nothing flags the problem; only the figures come out wrong. That is why the geometry that must sit on the ground is placed on a filtered surface, and the slope is measured on a long baseline — below about 60 m between points, the raster noise is measured, not the terrain. The complementary rule is just as important: if the published statistics were calculated on the raw model, they stay on the raw model and the page says so. Mixing the two bases in a single set of figures makes them inconsistent.

City geometry from OpenStreetMap, with height provenance kept separate

Building footprints and the street network come from OpenStreetMap, with the snapshot date noted. In the 3D scene of central Chișinău, out of 9.506 footprints only 1.128 have the height declared in OSM; the remaining 8.378 are estimated from the number of storeys multiplied by 3.2 m. The two categories are coloured differently in the scene. Each building sits on the terrain elevation below it, not on a flat slab — that is why the blocks rise towards the cathedral park instead of appearing aligned.

Orbital positions calculated locally, with the age of the data visible

The points on the globe are not positions transmitted by satellites. They are calculated positions: one starts from orbital elements valid at a moment in the past and propagates them with the SGP4 model to the current clock. The error grows with each day elapsed since the last update, and the application shows it in kilometres for the selected object. In FlowMind, the age of the elements is explicitly labelled fresh / stale / expired. The calculation runs on a separate thread, so the interface does not freeze.

Map background without paid keys

The 3D scene drapes the government orthophoto from `geodata.gov.md` (WMS, Land Relations and Cadastre Agency) over a terrain model from public tiles on AWS Open Data, rendered with MapLibre GL. No API keys and no cost per display. The background is visual orientation; Copernicus products remain separate layers, each with its own satellite, sensor, resolution and limitations.

What it looks like

The path, step by step.

We delimit the territory and write the question the map must answer

A geographic box, a short list of operational questions and, for each, the verdict on whether there is a public source that can answer it. We deliver the inventory of sources with the resolution, cadence and limit of each one — including the lines that say “there is no public source for this”. Those lines are the most useful part of the inventory.

We connect the sources and put the guardian in place before the first nice layer

Authentication, server routes, cache and — obligatorily in this order — the rule that forbids marking a layer as LIVE without proof of a successful read. The guardian is written before layers, because after that no one adds it. We deliver working routes and a source health report that can be queried.

We measure once, in full, with the method written beside the result

Reprojection, calculation, thresholds chosen on explicit criteria — not aesthetic ones. In the slope map of Chisinau the thresholds are 8.33%, that is the accessibility ramp 1:12, and 12%, above which sidewalk robots rated at 10–15% no longer climb. We deliver the figures, the scripts that regenerate them from source and a page that marks each block as measured, from source or proposed.

We hand over with the limits in front, not in the footer

What the map cannot show, how often each layer ages, what happens if a public source changes its terms or disappears, and what it would take to move from screening to fine measurement. We deliver the refresh procedure and the list of external dependencies with their breaking point.

Layers over the same territory, one over another: the terrain model at the base, the street geometry and building footprints above, optical and radar imagery as separate layers — each with its own label for resolution, cadence and the time of the last successful read.

The data

What we touch, where it lives, and how long it stays

The questions anyone with a data protection officer would ask — asked here before they do.

What kind of data the work touches: Normally, data about territory, not about people: multispectral reflectance, radar backscatter, terrain elevations, street geometry, building footprints, orbital elements. All of it comes from public archives — Copernicus Data Space Ecosystem, OpenStreetMap, AWS Open Data, CelesTrak, the state geodata portal.
Where the credentials are kept and why they do not reach the browser: Access to Copernicus is done with a client identifier and secret, through the OAuth2 `client_credentials` flow at `identity.dataspace.copernicus.eu`. The token request leaves only from the server, with a 10-second timeout and with the token refreshed 60 seconds before the real expiry. The browser never sees the secret; it asks our route, and the route asks Copernicus. Without configured credentials, the route returns 503 and the rest of the page works.
What is kept with us: The image tiles are kept in a process cache, with headers that say which product and which resolution were returned. The large catalogues load after the map is already on screen and are kept locally, with a term: the orbital catalogue object sheet, almost 7 MB, stays in the browser’s local memory for a day. The derived measurements — slope, isolines, elevation profile — are regenerated from source through scripts, not edited manually.
Attribution is not optional: Public sources come with terms. The CelesTrak policy requires attribution and forbids bulk redistribution of the catalogue; that is why the source panel in the interface is a requirement, not a decoration. Copernicus and OpenStreetMap have their own terms of use and attribution. In a delivery, checking these terms is done at the start, not at launch.
When personal data still appears: It happens with only one type of layer: public video feeds and images taken from the street. There the work is no longer just geospatial — face and licence plate blurring at ingestion, keeping only derived geometry, and an impact assessment before the first camera come in. Satellite imagery at 10 m does not have this problem: one pixel covers ten metres of ground.

A case

A flat boulevard measured at 13.5% slope

The situation

In an in-house terrain-measurement piece for the municipality of Chişinău, street slope was calculated directly from the public 30 m digital model, taking consecutive points from the street geometry. The result looked convincing and was ready to publish.

What we built

On verification, one of the central boulevards — practically flat for anyone walking on it — came out at 13.5% slope. The cause was quiet: the public model is a surface model, so in a dense block it returns roof elevation. Two points 30 m apart, one landing on a cornice, produce an elevation difference that does not exist on the carriageway. The same defect appeared elsewhere: neighbouring buildings ended up on different “ground” by around 20 m, and roads came out a median 13 m below buildings and disappeared between blocks in the three-dimensional scene, because roads follow valleys and buildings stand on the plateau.

What came out

The geometry was moved onto an approximate terrain surface, obtained by filtering with a window wider than a block, and slope has since been measured on a long base, not between consecutive points that may be only a few metres apart — below raster resolution. The already published statistics remained stated on the raw model, and the page says so, because moving some of the figures to another basis would have made them inconsistent with one another.

What the case does not say

Nothing had thrown an error. The application programming interface had returned 200, the files were readable, the map was drawn. This is the pattern that matters most to us in geospatial data: the source works, and the result is subtly wrong. The only defence that holds is checking a known value — a boulevard you know is flat.

Questions

What people ask us before they call

Do you have your own satellites?

No, none, and no sensors either. Copernicus is the European Union’s Earth observation programme — the satellites, sensors and archive are its own. The orbital catalogue comes from CelesTrak, which redistributes data maintained by US Space Force. We authenticate with our own credentials, request processed products through the API and build what follows: the calculation, the map, the provenance guard, the interpretation. If someone tells you they have their own satellites in Moldova, ask for the NORAD number.

How often is the imagery updated?

It depends on the mission and the clouds, not on us. Multispectral optical at 10 m: on the order of 2–5 days when there is a cloud-free scene. Radar at 10 m: about 6–12 days, but it works at night and through clouds. Thermal band at kilometre scale and atmospheric products: daily or multi-daily. In a November with a closed sky for a week, the optical layer simply has nothing to show — and then it says that, it does not borrow an older image.

What does 10 m resolution mean in practice?

One pixel covers ten metres on the ground. You can see a block, an agricultural parcel, a heap, a construction site, a surface change. You cannot see a car, a person or a licence plate — and that is why satellite imagery in this category does not raise the issue of personal data. For atmospheric products the pixel is kilometre-scale: you read a trend over a city, not a street.

Can you give me the exact height of my buildings?

Not from these sources. The public 30 m model is a surface model — it returns the top elevation of what is there, including roofs and tree crowns — and it is too coarse for an individual building. What we can do: say on which ground elevation each footprint sits and, where OpenStreetMap declares the height, use the declared value, marked separately from the estimate. For precise heights, another acquisition is needed: LiDAR or drone photogrammetry. That is a field job, not an archive one.

Can you detect landslides?

We can build a prioritisation layer, not a verdict. A risk screen combines slope from a terrain model, radar coherence loss, change of surface in optical, and precipitation accumulation — and produces a list of areas to check. Confirming a real displacement requires interferometry: pairs of ascending and descending scenes, orbit files, phase unwrapping. That is a separate job. In our products the distinction is written explicitly next to the layer, so no one reads a prioritisation as a detection.

Why are there gaps on the map?

Because nothing usable was observed there — usually cloud, cloud shadow, cirrus or snow, filtered out from the scene classification band. The gap is information, not a defect. The alternative, filling from another date, produces a continuous image that mixes two moments and cannot be used for comparison. The same logic applies to failed sources: the layer says OFFLINE and gives the reason.

Is the satellite position on the map the real one, in real time?

It is a calculated position, not a transmitted one. It starts from orbital elements published at some point in the past and is propagated up to now with a standard model. The error grows with the age of the elements, and we display it in kilometres for the selected object and mark the age of the data. An object with elements a few days old can be tens of kilometres away from where the point shows it — which is why it is stated, not hidden.

What happens if the public source changes or disappears?

This is the real risk of this kind of work and it is handled in the contract, not at incident level. Public sources change their formats, usage quotas and terms. That is why we deliver the list of external dependencies with their breaking point, keep the access layer isolated in a single place in the code, and mark the failed source in the interface instead of letting the map seem functional. A platform that hides a dead source is more dangerous than one that stops visibly.

Do the data stay with you or with the client?

The derived results — maps, figures, calculated layers — belong to the client and are handed over together with the scripts that regenerate them from the source. The source data remain where they are, in public archives, under their licensing and attribution terms; we do not redistribute them in bulk, because some licences explicitly forbid that. Access credentials for Copernicus can belong to the client, on their own account, if they want full independence from us.

What the statements above rest on (21 sources)

https://www.megapromoting.com/satelit/ responds 200https://www.megapromoting.com/satelit/ · 2026-09-06
https://relieva.vercel.app responds 200 and serves 680.122 byteshttps://relieva.vercel.app · 2026-09-06

19 of them are code and files from our repositories. We don't publish their name or line: together, on a single page, they would describe too precisely how systems that aren't only ours are built. We go through them with you, in the repository, on request — verification stays possible, it just happens in a conversation.

How we work All services

What would you want to work better?

Tell us about your process. Together we decide what is worth building, what we can connect, and how we check the result.

Let's talk