No Clocks

Arrow VSI file system Added in version 3.10. Starting with GDAL 3.10 and Arrow 16.0, any GDAL Virtual File System can be used (in a read-only context) wherever the Arrow C++ library expects a URI, in particular outside of the context of the OGR Arrow driver, by: loading the libgdal.so/dll library (or the ogr_Arrow.so/dll plugin library if the Arrow driver is built as a library) with the arrow::fs::LoadFileSystemFactories() function (cf Defining new filesystems) Note: if the Arrow driver is fully loaded, e.g. by querying GetGDALDriverManager()->GetDriverByName("ARROW")->GetMetadata(), the Arrow VSI file system will be also registered. Prefixing any GDAL file name with the gdalvsi:// URI scheme prefix. In addition to any potential vsi prefix in the GDAL file name. So the /vsicurl/http://example.com GDAL file name becomes the gdalvsi:///vsicurl/http://example.com Arrow URI.

Starting with GDAL 3.12, gdal vector info can be used as the last step of a pipeline.

-f, --of, --format, --output-format json|text

Which output format to use. Default is JSON, and starting with GDAL 3.12, text when invoked from command line.

-l, --layer, --input-layer <INPUT-LAYER>

Name of one or more layers to inspect. If no layer names are passed and --sql is not specified, then all layers will be selected.

--summary

Print a summary with the list of layers and the geometry type of each layer. This option is mutually exclusive with the --features option.

--features

List all features by default, unless limited with --limit. Beware of RAM consumption on large layers when using JSON output. This option is mutually exclusive with the --summary option.

--limit <FEATURE-COUNT>

Limit the number of features reported per layer. When set, this implies --features.

--sql <statement>|@<filename>

Execute the indicated SQL statement and return the result. The @<filename> syntax can be used to indicate that the content is in the pointed filename (e.g @my_select.txt where my_select.txt is a file in the current directory). Data can also be edited with SQL INSERT, UPDATE, DELETE, DROP TABLE, ALTER TABLE etc if the dataset is opened in update mode. Editing capabilities depend on the selected dialect with --dialect.

--where <WHERE>|@<filename>

An attribute query in a restricted form of the queries used in the SQL WHERE statement. Only features matching the attribute query will be reported. The @<filename> syntax can be used to indicate that the content is in the pointed filename.

Example of --where and quoting: --where "\"Corner Point Identifier\" LIKE '%__00_00'"

This option is mutually exclusive with the --sql option.

SQL dialect. In some cases can be used to use (unoptimized) OGR SQL dialect instead of the native SQL of an RDBMS by passing the OGRSQL dialect value. The SQL SQLite dialect can be selected with the SQLITE and INDIRECT_SQLITE dialect values, and this can be used with any datasource.

This is likely the acquisition (in the case of single camera type captures) or the 'nominal' or representative time in the case of assets that are combined together. Though time can be a complex thing to capture, for this purpose keep in mind the STAC spec is primarily searching for data, so use whatever single date and time is most useful for a user to search for. STAC content extensions may further specify the meaning of the main datetime field, and many will also add more datetime fields. All times in STAC metadata should be in Coordinated Universal Time (UTC). If there's clearly no meaningful single 'nominal' time, it is allowed to use null instead. In this case it is required to specify a temporal interval with the fields start_datetime and end_datetime from common metadata. For example, if your data is a time-series that covers 100 years, it's not very meaningful to set the datetime to a single timestamp as it would not be found in most searches that searches for a decade of data in that period although the Item actually covers the decade. See datetime selection in the best practices document for more information.

The Field Boundaries for Agriculture (fiboa) project is focused on making field boundary data openly available in a unified format on a global scale. We believe that the fiboa specification is a foundational aspect of agricultural field boundary data interoperability which enables and accelerates additional layers of collaboration and detail via custom extensions.

At the heart of the wk philosophy is the concept of a handler, whose job it is to respond to bits of geometric information as they are iterated over by the reader. These bits of information have a very specific structure and order such that the messages can be guaranteed to be backward-compatible for all time (for each version of the API). This means that the reader can focus on iterating over the data structure and handlers can focus on computing a value (usually) based on the geometries. The advantage of this system is that readers and handlers can be mixed and matched so that handlers can be used with many data structures! As an example, the wk package itself uses readers and handlers to power validation of and conversion among wkt(), wkb(), xy(), and rct() classes.

The wk API works with a vector of features: readers iterate over such vectors and handlers compute a value based on some or all of the features in the vector. Each feature can be NULL or contain exactly one geometry (although this geometry can be a collection or multi-geometry which can contain a tree of other geometries). A good way to visualize the structure, order, and type of messages passed to a handler is to use the wk_debug_filter() on some well-known text (WKT):

The concept of a vector was inspired by the sf::sfc() data type and draws heavily from the vctrs framework. The concept of a feature draws from the implementations of the simple features specification in most databases and the support in R for “missing” values, which are not quite the same as an EMPTY geometry (in the same way that NaN and NA can be distinguished in R). The concept of a geometry is very much tied to (and was inspired by) the definition of a geometry in the (E)WKB, (E)WKT, and TWKB format specifications such that most of the information provided by these formats is passed along to handlers if it is available

ALTREP: Alternative Representations for R Objects

The ALTREP branch of the R svn repository provides an experimental framework for developing alternate representations of basic R objects. Some examples of intended uses would be to allow vector data to be in a memory-mapped file or distributed; allow compact representation of arithmetic sequences; support adding meta-data to objects; support alternative representations of environments.

Until now, parallel R has meant serializing your data to every worker and duplicating it in each worker’s RAM. Eight workers × 1 GB is 8 GB, plus the serialization, transfer, and deserialization cost to get it there. R processes don’t share memory — each has its own heap, so data crosses between them through a serialization pipe.

mori changes that. It places an R object once into OS-level shared memory and lets every process on the machine read the same physical pages directly — with no data copying between processes.

mori is built on R’s ALTREP (Alternative Representation) framework, which lets a package expose a custom vector backend that reads its data from somewhere other than ordinary R memory — a memory map, a database, a compressed store, or in this case, OS shared memory.

The entry point is share(). You pass it an R object, you get back a shared version that you can use in the same way as the original:

share() works on atomic vector types, lists, and data frames — it writes them directly into shared memory with attributes preserved. In practice that also covers tibbles, data.tables, factors, dates, and matrices, since they’re built on those types. Environments, functions, S4 objects, and external pointers are returned unchanged, since their state can’t be meaningfully exposed as raw bytes in shared memory.

mori pairs naturally with mirai. When you send a shared object to a local daemon, only the shared-memory name crosses the wire; the daemon maps the same physical pages and sees the full data with no deserialization cost. The same is true for any other parallel backend that uses R serialization.

Shared memory is tied to R’s garbage collector. As long as the shared object (or anything extracted from it) is live in R, the data stays available; when the last reference is dropped, it’s freed automatically with no manual cleanup. The process that called share() needs to hold its reference until a consumer has mapped a view — from that point on, the view itself keeps the shared memory alive.

Mutations go through R’s normal copy-on-write: editing a value inside a shared vector produces a private copy of that one vector, leaving the rest of the shared region untouched.

R has had partial answers to cross-process data sharing before. bigmemory offers shared big.matrix objects — effective, but limited to numeric matrices. SharedObject on Bioconductor targets a similar goal with its own memory-sharing machinery, oriented around BiocParallel workflows. Arrow ’s memory-mapped Parquet gives zero-copy columnar reads across processes, though the data lives on disk. On Unix, parallel::mclapply gets shared memory via fork copy-on-write (until a worker writes to a page), with the usual fork caveats (unsafe in GUI sessions, with open DB connections, or alongside multithreaded libraries), and with no equivalent on Windows.