Post meta
| Key | Holds |
|---|---|
geo_latitude |
Decimal latitude (WordPress geodata standard). |
geo_longitude |
Decimal longitude (WordPress geodata standard). |
geo_address |
A human-readable address, sanitised as plain text. |
geo_json |
A GeoJSON Feature, FeatureCollection or bare geometry. Anything else is rejected on save, and whitespace is normalised. |
All four are single string values registered with show_in_rest on every supported post type, so they can be read and written through /wp-json/wp/v2/{type}/{id}. Writing them needs edit_posts. They remain ordinary post meta: get_post_meta() works as usual, and nothing about them depends on this plugin staying active.
Spatial tables
The bundled wp-geometa-lib (0.4.0) mirrors any meta value that is GeoJSON into spatial copies of the meta tables: {prefix}postmeta_geo, {prefix}commentmeta_geo, {prefix}termmeta_geo and {prefix}usermeta_geo. Values are stored as GEOMETRYCOLLECTION with a spatial index (meta_val_spatial_idx). The tables are created on activation and again by the one-off lh_places_initial_run cron event. They can be rebuilt from geo_json at any time, so they are an index rather than a source of truth.
The library caches which spatial SQL functions the database supports in the wp_geometa_capabilities option. If ST_AsGeoJSON is missing from that list, users with install_plugins see an admin notice with a Re-scan database capabilities link, which clears the cache and tests the database again. A stale cache is the usual cause.
Requirements
Spatial indexing and ST_AsGeoJSON need MariaDB 10.2.8+ or MySQL 5.7.8+. Storing and showing geodata works without them.
Local changes to wp-geometa-lib
The bundled library (lib/wp-geometa-lib, from BrilliantPlugins/wp-geometa) carries one local patch, marked “LH patch” in the code. In 1.30.1, WP_GeoUtil::merge_geojson() was changed to strip invalid UTF-8 with wp_check_invalid_utf8() instead of calling iconv() with an undefined source encoding. Re-apply it if the library is ever updated.
