Regions and polygons boundaries for beam-layout optimization

Open data API in a single place

Provided by Camille Lescuyer

Get early access to Regions and polygons boundaries for beam-layout optimization API!

Let us know and we will figure it out for you.

Dataset information

Country of origin
Updated
2026.03.04 17:43
Created
2026.02.28
Available languages
English
Keywords
polygon, limites-decoupages, region, polygone, telecommunications-spatiales
Quality scoring

Dataset description

This directory contains a collection of **benchmark instances for the beam-layout optimization problem in a satellite telecommunication context.** Each instance represents a different geographical region on the earth surface, divided into a set of polygons. The use cases differ from their geographical positions and number of polygons and are designed for algorithmic experimentation and to evaluate optimization methods. <br /> The dataset is organized into **individual instance folders**, where each folder follows a marked format and includes multiple representations of the same spatial data to support different processing and visualization needs. *** ### Contents of an Instance Folder Each instance directory contains the following files: * **“regions_long_lat.geojson“**\ This file stores the geographical coordinates of the points or regions to be covered, expressed as **longitude and latitude** in standard **GeoJSON** format. It is already intended for vizualization. * **“regions_long_lat.geojson“**\ This file provides the same spatial information using the **GeoJSON** format, with coordinates expressed as *(thx, thy)*. It is intended for algorithm processing. <br /> The file **“Instances_characteristics.xlsx“** summarizes the main properties of all instances and provides indicators of their relative difficulties. Since computing the full beam database can be computationally prohibitive for large instances, a theoretical yet informative approach is adopted. The difficulty of an instance is observed by: * constructing the **reflector graph** considering only beams that cover a **single polygon**; * extracting key graph-theoretic and geometric metrics from this reduced model. The resulting values serve as **lower bounds** for the complete beam-layout optimization problem. In particular, the Squared Radius Sum (SRS) obtained from this restricted setting is guaranteed to be no larger than the SRS of any feasible solution covering all polygons. The spreadsheet includes the following columns: ***Instance**: name of the instance * **Nb polygons**: number of regions or polygons to be covered * **Nb edges**: number of edges in the reflector graph when considering only beams covering one polygon * **Chromatic number**: chromatic number of the reflector graph under the same restriction * **Max radius (Lower bound)**: lower bound on the maximum beam radius required to cover a single polygon * **SRS (Lower bound)**: lower bound on the Squared Radius Sum for beams covering only one polygon These metrics provide valuable insight into the **structural complexity** and **expected difficulties** of each instance. <br /> All instances are defined under a common set of parameters: * **Number of reflectors**: 4\ This value represents a practical compromise between satellite payload weight and communication performance. * **Kappa (κ)**:\ Kappa is a scaling factor that increases the beam size in order to model the projection of the radio-frequency source placement on the antenna. This enlargement makes it possible to identify beams that are incompatible when needed to the same reflector. * **Minimum beam radius (smin)**:\ The minimum allowable beam radius is set to **0.1**, based on satellite antenna analysis constraints, guaranteeing physical feasibility.
European data infrastructure with broad catalog discovery, free evaluation access and production-grade API options.
190K+
indexed dataset pages
32
countries and EU institutions
2019
API-first since
Free API quota
for evaluation and prototypes
SLA
history and push on production APIs
FAQ

Questions before production use

Practical answers on evaluation, licensing, freshness, versioning and support.

api.store is built and operated by Apitalks s.r.o. Company details and a direct contact path are linked in the footer for vendor checks and procurement review.
Yes. Selected APIs include a free API quota, so your team can validate coverage, freshness, response shape and workflow fit before asking for a production plan.
Often yes, but usage rights depend on the source license and dataset. We surface source, license and update metadata where available, and can help review terms before a production integration.
Maintained APIs include update metadata where available. For production integrations, we can add history, monitoring and push updates so changes are easier to detect and act on.
Production APIs can add SLA, stable identifiers, versioning support, history, push updates and direct support around the data your product or AI workflow depends on.

Didn't find the API you need?

Let us know and we will figure it out for you.

European data discovery with free evaluation access and production-grade API options.

Copyright © 2026. Made by Apitalks