Details
-
New Feature
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
-
None
-
2026-planning
Description
Integrate a flexible to_mesh function.
So instead long conversions like
SELECT CONCAT(FLOOR(lon), ',', FLOOR(lat), ':', MOD(FLOOR(lon * 10), 10)...) FROM large_spatial_table; |
|
A function should do the job like
SELECT TO_MESH(lon, lat, 4) FROM large_spatial_table; |
To remain flexible for proprietary systems (like the user's 10,10,10,4 pattern), the function could accept a bit-packed integer or a simple string flag as a schema-selector: |
|
|
ST_GeoMesh(lon, lat, depth, '10,10,10,4') |
Suggestion from gemini:
Mathematical Logic for Distributed Execution |
|
|
The core logic of the TO_MESH function can be vectorized. Instead of a WHILE loop with dynamic JSON extraction, the engine should use a pre-compiled array of subdivision factors.
|
|
|
Logic (C++ Pseudo-code for PM integration): |
|
|
// Static or configurable subdivision factors
|
const int mesh_factors[] = {1, 10, 10, 10, 4}; // Example for depth 0-4 |
|
|
string calculate_mesh(double lon, double lat, int depth) { |
// 1. Initial 1-degree grid (Base Layer) |
string key = to_string(floor(lon)) + "," + to_string(floor(lat)); |
|
if (depth <= 0) return key; |
key += ":"; |
|
|
// 2. Normalize to positive range for consistent MOD operations |
double v_x = lon + 180.0; |
double v_y = lat + 90.0; |
|
|
// 3. Hierarchical Scaling |
double scale = 1.0; |
for (int i = 1; i <= depth; ++i) { |
scale *= mesh_factors[i];
|
|
// Use optimized integer math for the mesh digits |
int digit_x = static_cast<int>(floor(v_x * scale)) % mesh_factors[i]; |
int digit_y = static_cast<int>(floor(v_y * scale)) % mesh_factors[i]; |
|
key += to_string(digit_x) + to_string(digit_y);
|
}
|
return key; |
}
|
Attachments
Issue Links
- relates to
-
MCOL-4258 Add support for user defined functions stored functions (UDFs)
-
- Stalled
-