How to index and query complex spatial types in CosmosDB? - indexing

Question

I have a CosmosDB database/collection with the partition key on /id and spatial indexing enabled using the Geography configuration. When I query for objects with a LineString property within a given LineString or Polygon, the query retrieves all of the documents in the collection before returning those that are within the LineString/Polygon (retrieved is greater than output). The RU's consumed grow as the number of items within the collection grow, which signals to me that it's basically doing a scan and the index is not working.
CosmosDB documentation states the following:
Azure Cosmos DB supports indexing of Points, LineStrings, Polygons, and MultiPolygons
However the documentation does not have any examples that don't use the Point type and I am unable to query using permutations of exclusively non-Point types and hit the index.
To test spatial indexing is working I have an additional Start property on the item with the value of the first Point in the LineString, and I can query if this is within the Polygon at a constant RU consumption.
Here is the index:
{
"indexingMode": "consistent",
"automatic": true,
"includedPaths": [
{
"path": "/*"
}
],
"excludedPaths": [
{
"path": "/\"_etag\"/?"
}
],
"spatialIndexes": [
{
"path": "/*",
"types": [
"Point",
"LineString",
"Polygon",
"MultiPolygon"
]
}
]
}
Here is the needle. The haystack is about 1,000 objects with random LineStrings.
{
"id": "test",
"Start": {
"type": "Point",
"coordinates": [ 1, 3 ]
},
"Points": {
"type": "LineString",
"coordinates": [ [ 1, 3 ], [ 1, 4 ], [ 1, 5 ] ]
}
}
Here is the search within a Polygon:
SELECT *
FROM items i
WHERE ST_WITHIN(i.Points, {
"type":"Polygon",
"coordinates": [[[0, 10], [0, 0], [2, 0], [2, 10], [0, 10]]]
})
---
Request Charge: 127.4 RUs
Retrieved document count: 992
Retrieved document size: 1219980 bytes
Output document count: 1
Output document size: 441 bytes
Index hit document count: 0
Index lookup time: 3.77 ms
Here is the search within a LineString:
SELECT *
FROM items i
WHERE ST_WITHIN(i.Points, {
"type":"LineString",
"coordinates": [[1, 3], [1, 4], [1, 5]]
})
---
Request Charge: 122.53 RUs
Retrieved document count: 992
Retrieved document size: 1219980 bytes
Output document count: 1
Output document size: 441 bytes
Index hit document count: 0
Index lookup time: 3.0100000000000002 ms
Here is the search for a Start within the same Polygon as above, showing that spatial indexing is enabled and working:
SELECT *
FROM items i
WHERE ST_WITHIN(i.Start, {
"type":"Polygon",
"coordinates": [[[0, 10], [0, 0], [2, 0], [2, 10], [0, 10]]]
---
Request Charge: 8.1 RUs
Retrieved document count: 1
Retrieved document size: 343 bytes
Output document count: 1
Output document size: 392 bytes
Index hit document count: 1
Index lookup time: 2.79 ms

Answer 1

I create a container and add your sample document,but the result is different with yours.
First sql result:
SELECT *
FROM items i
WHERE ST_WITHIN(i.Points, {
"type":"Polygon",
"coordinates": [[[0, 10], [0, 0], [2, 0], [2, 10], [0, 10]]]
})
---
Request Charge: 10.53 RUs
Retrieved document count: 1
Retrieved document size: 349 bytes
Output document count: 1
Output document size: 398 bytes
Index hit document count: 1
Index lookup time: 1.6800000000000002 ms
Second sql result:
SELECT *
FROM items i
WHERE ST_WITHIN(i.Points, {
"type":"LineString",
"coordinates": [[1, 3], [1, 4], [1, 5]]
})
---
Request Charge: 7.24 RUs
Retrieved document count: 1
Retrieved document size: 349 bytes
Output document count: 1
Output document size: 398 bytes
Index hit document count: 1
Index lookup time: 1.1399000000000001 ms
Third sql result:
SELECT *
FROM items i
WHERE ST_WITHIN(i.Start, {
"type":"Polygon",
"coordinates": [[[0, 10], [0, 0], [2, 0], [2, 10], [0, 10]]]
})
---
Request Charge: 10.53 RUs
Retrieved document count: 1
Retrieved document size: 349 bytes
Output document count: 1
Output document size: 398 bytes
Index hit document count: 1
Index lookup time: 1.6500000000000001 ms
According to my test,each sql hit the index.
By the way,my index is same to you and geospatial configuration is Geography.You can try again and if the result is similar with yours above,please let me know more detail,such as sdk or detail of your document(I test this on Azure portal).