Merge branch 'main' of https://github.com/arangodb/docs-hugo into oem2

Author: Simran-B

site/content/arangodb/3.11/aql/functions/geo.md

@@ -615,6 +615,21 @@ support the VelocyPack format. The cluster replication has been changed to use
 VelocyPack instead of JSON to avoid unnecessary conversions and avoiding any
 risk of deviations due to the serialization.
 
+## Optional elevation for GeoJSON Points
+
+<small>Introduced in: v3.11.14-2</small>
+
+GeoJSON Point may now have three coordinates: `[longitude, latitude, elevation]`.
+However, ArangoDB does not take any elevation into account in geo-spatial
+calculations.
+
+Points with an elevation do no longer fail the validation in the `GEO_POLYGON()`
+and `GEO_MULTIPOLYGON()` functions. Moreover, GeoJSON with three coordinates is
+now indexed by geo indexes and thus also matched by geo-spatial queries, which
+means you may find more results than before.
+
+Also see [Geo-spatial functions in AQL](../../aql/functions/geo.md).
+
 ## JavaScript API
 
 ### Database creation

site/content/arangodb/3.11/release-notes/version-3.11/incompatible-changes-in-3-11.md

@@ -1402,6 +1402,24 @@ connections. Some memory is pre-allocated at startup for higher efficiency. If t
 `--server.statistics` startup option is set to `false`, then no memory will be
 allocated for connection and request statistics.
 
+### Optional elevation for GeoJSON Points
+
+<small>Introduced in: v3.11.14-2</small>
+
+The `GEO_POINT()` function now accepts an optional third argument to create a
+GeoJSON Point with three coordinates: `[longitude, latitude, elevation]`.
+
+GeoJSON Points may now have three coordinates in general.
+However, ArangoDB does not take any elevation into account in geo-spatial
+calculations.
+
+Points with an elevation do no longer fail the validation in the `GEO_POLYGON()`
+and `GEO_MULTIPOLYGON()` functions. Moreover, GeoJSON with three coordinates is
+now indexed by geo indexes and thus also matched by geo-spatial queries, which
+means you may find more results than before.
+
+Also see [Geo-spatial functions in AQL](../../aql/functions/geo.md).
+
 ## Client tools
 
 ### arangodump

site/content/arangodb/3.11/release-notes/version-3.11/whats-new-in-3-11.md

@@ -615,6 +615,21 @@ support the VelocyPack format. The cluster replication has been changed to use
 VelocyPack instead of JSON to avoid unnecessary conversions and avoiding any
 risk of deviations due to the serialization.
 
+## Optional elevation for GeoJSON Points
+
+<small>Introduced in: v3.11.14-2</small>
+
+GeoJSON Point may now have three coordinates: `[longitude, latitude, elevation]`.
+However, ArangoDB does not take any elevation into account in geo-spatial
+calculations.
+
+Points with an elevation do no longer fail the validation in the `GEO_POLYGON()`
+and `GEO_MULTIPOLYGON()` functions. Moreover, GeoJSON with three coordinates is
+now indexed by geo indexes and thus also matched by geo-spatial queries, which
+means you may find more results than before.
+
+Also see [Geo-spatial functions in AQL](../../aql/functions/geo.md).
+
 ## JavaScript API
 
 ### Database creation

site/content/arangodb/3.12/release-notes/version-3.11/incompatible-changes-in-3-11.md

@@ -1398,6 +1398,24 @@ connections. Some memory is pre-allocated at startup for higher efficiency. If t
 `--server.statistics` startup option is set to `false`, then no memory will be
 allocated for connection and request statistics.
 
+### Optional elevation for GeoJSON Points
+
+<small>Introduced in: v3.11.14-2</small>
+
+The `GEO_POINT()` function now accepts an optional third argument to create a
+GeoJSON Point with three coordinates: `[longitude, latitude, elevation]`.
+
+GeoJSON Points may now have three coordinates in general.
+However, ArangoDB does not take any elevation into account in geo-spatial
+calculations.
+
+Points with an elevation do no longer fail the validation in the `GEO_POLYGON()`
+and `GEO_MULTIPOLYGON()` functions. Moreover, GeoJSON with three coordinates is
+now indexed by geo indexes and thus also matched by geo-spatial queries, which
+means you may find more results than before.
+
+Also see [Geo-spatial functions in AQL](../../aql/functions/geo.md).
+
 ## Client tools
 
 ### arangodump

site/content/arangodb/3.12/release-notes/version-3.11/whats-new-in-3-11.md

@@ -920,8 +920,21 @@ RocksDB-related startup options have been changed:
 
 - `--rocksdb.pending-compactions-slowdown-trigger` has been changed from 128 KiB to 1 GiB.
 - `--rocksdb.pending-compactions-stop-trigger` has been changed from 16 GiB to 32 GiB.
-- `--rocksdb.partition-files-for-documents` has been changed from false to true.
 - `--rocksdb.throttle-slow-down-writes-trigger` has been obsoleted.
+- `--rocksdb.partition-files-for-documents` has been changed from false to true.
+
+{{< warning >}}
+If the `--rocksdb.partition-files-for-documents` startup option is enabled, it
+causes RocksDB to use separate `.sst` files for every collection/shard to store
+document data. This can create a very large number of files and use the same
+amount of file descriptors for deployments with many collections/shards and a
+high write load.
+
+It is recommended to disable the feature explicitly with
+`--rocksdb.partition-files-for-documents false` in versions from 3.12.6 through
+3.12.7 where it is enabled by default. From 3.12.7-1 and 3.12.8 onward, it is
+again disabled by default.
+{{< /warning >}}
 
 ## Optional elevation for GeoJSON Points
 

site/content/arangodb/3.12/release-notes/version-3.12/incompatible-changes-in-3-12.md

@@ -52,3 +52,4 @@ Note that this page does not list all open issues.
 | **Date Added:** 2025-01-30 <br> **Component:** arangod <br> **Deployment Mode:** Cluster <br> **Description:** If the invariant is violated that ArangoDB's data is not modified while a server is down, manually as well as automatically triggered operations such as moving shards can make a DB-Server the leader (again) even though it may not have the correct data. ArangoDB does currently not protect against certain cases like bringing a DB-Server back without data (by accident or on purpose), which can lead to this empty state getting replicated across the cluster and thus causing data loss. <br> **Affected Versions:** 3.11.x, 3.12.x <br> **Fixed in Versions:** - <br> **Reference:** N/A |
 | **Date Added:** 2025-06-25 <br> **Component:** Web interface <br> **Deployment Mode:** All <br> **Description:** Specifying an `X-Script-Name` HTTP header in requests to the web interface (`/_admin/aardvark`) to add a path prefix is non-functional. The feature was originally added in version 3.0 for basic proxy setups but doesn't adequately handle the requests of certain internal services. <br> **Affected Versions:** 3.11.x, 3.12.x <br> **Fixed in Versions:** - <br> **Reference:** N/A |
 | **Date Added:** 2025-12-09 <br> **Component:** arangod <br> **Deployment Mode:** Cluster <br> **Description:** When rapidly changing the `replicationFactor` of a collection, the server may unexpectedly reply a `Precondition Failed` error with code `412`. <br> **Affected Versions:** 3.12.x <br> **Fixed in Versions:** - <br> **Reference:** [BTS-2279](https://arangodb.atlassian.net/browse/BTS-2279) (internal) |
+| **Date Added:** 2025-12-11 <br> **Component:** arangod <br> **Deployment Mode:** All <br> **Description:** The storage engine-related `--rocksdb.partition-files-for-documents` startup option has a default of `true` since v3.12.6, causing RocksDB to use separate `.sst` files for every collection/shard to store document data. This can create a very large number of files and use the same amount of file descriptors for deployments with many collections/shards and a high write load. It is recommended to disable the feature with `--rocksdb.partition-files-for-documents false` in versions where it is enabled by default. <br> **Affected Versions:** 3.12.6 - 3.12.7 <br> **Fixed in Versions:** 3.12.7-1, 3.12.8 <br> **Reference:** [arangodb/arangodb#22181](https://github.com/arangodb/arangodb/pull/22181) |

site/content/arangodb/3.12/release-notes/version-3.12/known-issues-in-3-12.md

@@ -615,6 +615,21 @@ support the VelocyPack format. The cluster replication has been changed to use
 VelocyPack instead of JSON to avoid unnecessary conversions and avoiding any
 risk of deviations due to the serialization.
 
+## Optional elevation for GeoJSON Points
+
+<small>Introduced in: v3.11.14-2</small>
+
+GeoJSON Point may now have three coordinates: `[longitude, latitude, elevation]`.
+However, ArangoDB does not take any elevation into account in geo-spatial
+calculations.
+
+Points with an elevation do no longer fail the validation in the `GEO_POLYGON()`
+and `GEO_MULTIPOLYGON()` functions. Moreover, GeoJSON with three coordinates is
+now indexed by geo indexes and thus also matched by geo-spatial queries, which
+means you may find more results than before.
+
+Also see [Geo-spatial functions in AQL](../../aql/functions/geo.md).
+
 ## JavaScript API
 
 ### Database creation

site/content/arangodb/4.0/release-notes/version-3.11/incompatible-changes-in-3-11.md

@@ -1398,6 +1398,24 @@ connections. Some memory is pre-allocated at startup for higher efficiency. If t
 `--server.statistics` startup option is set to `false`, then no memory will be
 allocated for connection and request statistics.
 
+### Optional elevation for GeoJSON Points
+
+<small>Introduced in: v3.11.14-2</small>
+
+The `GEO_POINT()` function now accepts an optional third argument to create a
+GeoJSON Point with three coordinates: `[longitude, latitude, elevation]`.
+
+GeoJSON Points may now have three coordinates in general.
+However, ArangoDB does not take any elevation into account in geo-spatial
+calculations.
+
+Points with an elevation do no longer fail the validation in the `GEO_POLYGON()`
+and `GEO_MULTIPOLYGON()` functions. Moreover, GeoJSON with three coordinates is
+now indexed by geo indexes and thus also matched by geo-spatial queries, which
+means you may find more results than before.
+
+Also see [Geo-spatial functions in AQL](../../aql/functions/geo.md).
+
 ## Client tools
 
 ### arangodump

site/content/arangodb/4.0/release-notes/version-3.11/whats-new-in-3-11.md

@@ -920,8 +920,21 @@ RocksDB-related startup options have been changed:
 
 - `--rocksdb.pending-compactions-slowdown-trigger` has been changed from 128 KiB to 1 GiB.
 - `--rocksdb.pending-compactions-stop-trigger` has been changed from 16 GiB to 32 GiB.
-- `--rocksdb.partition-files-for-documents` has been changed from false to true.
 - `--rocksdb.throttle-slow-down-writes-trigger` has been obsoleted.
+- `--rocksdb.partition-files-for-documents` has been changed from false to true.
+
+{{< warning >}}
+If the `--rocksdb.partition-files-for-documents` startup option is enabled, it
+causes RocksDB to use separate `.sst` files for every collection/shard to store
+document data. This can create a very large number of files and use the same
+amount of file descriptors for deployments with many collections/shards and a
+high write load.
+
+It is recommended to disable the feature explicitly with
+`--rocksdb.partition-files-for-documents false` in versions from 3.12.6 through
+3.12.7 where it is enabled by default. From 3.12.7-1 and 3.12.8 onward, it is
+again disabled by default.
+{{< /warning >}}
 
 ## Optional elevation for GeoJSON Points