@prefix sioc: <http://rdfs.org/sioc/ns#> .
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix content: <http://purl.org/rss/1.0/modules/content/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

<https://lhero.org/portfolio/lh-places/>
  a sioc:Post ;
  dc:title "Data and storage" ;
  dcterms:identifier 149921 ;
  dc:modified "2026-10-11T15:45:15Z"^^xsd:dateTime ;
  dc:created "2026-10-11T15:45:15Z"^^xsd:dateTime ;
  sioc:link <https://lhero.org/portfolio/lh-places/data-and-storage/> ;
  sioc:has_creator <https://lhero.org/author/1/#account> ;
  sioc:has_container <https://lhero.org/#posts> ;
  content:encoded """<ul class="lh_portfolio-meta"><li><strong>Part of:</strong> <a href="https://lhero.org/portfolio/lh-places/">LH Places</a></li></ul>
<h2 class="wp-block-heading">Post meta</h2>



<figure class="wp-block-table"><table><thead><tr><th>Key</th><th>Holds</th></tr></thead><tbody><tr><td><code>geo_latitude</code></td><td>Decimal latitude (WordPress geodata standard).</td></tr><tr><td><code>geo_longitude</code></td><td>Decimal longitude (WordPress geodata standard).</td></tr><tr><td><code>geo_address</code></td><td>A human-readable address, sanitised as plain text.</td></tr><tr><td><code>geo_json</code></td><td>A GeoJSON Feature, FeatureCollection or bare geometry. Anything else is rejected on save, and whitespace is normalised.</td></tr></tbody></table></figure>



<p class="wp-block-paragraph">All four are single string values registered with <code>show_in_rest</code> on every supported post type, so they can be read and written through <code>/wp-json/wp/v2/{type}/{id}</code>. Writing them needs <code>edit_posts</code>. They remain ordinary post meta: get_post_meta() works as usual, and nothing about them depends on this plugin staying active.</p>



<h2 class="wp-block-heading">Spatial tables</h2>



<p class="wp-block-paragraph">The bundled wp-geometa-lib (0.4.0) mirrors any meta value that is GeoJSON into spatial copies of the meta tables: <code>{prefix}postmeta_geo</code>, <code>{prefix}commentmeta_geo</code>, <code>{prefix}termmeta_geo</code> and <code>{prefix}usermeta_geo</code>. Values are stored as GEOMETRYCOLLECTION with a spatial index (<code>meta_val_spatial_idx</code>). The tables are created on activation and again by the one-off <code>lh_places_initial_run</code> cron event. They can be rebuilt from geo_json at any time, so they are an index rather than a source of truth.</p>



<p class="wp-block-paragraph">The library caches which spatial SQL functions the database supports in the <code>wp_geometa_capabilities</code> option. If ST_AsGeoJSON is missing from that list, users with install_plugins see an admin notice with a <strong>Re-scan database capabilities</strong> link, which clears the cache and tests the database again. A stale cache is the usual cause.</p>



<h2 class="wp-block-heading">Requirements</h2>



<p class="wp-block-paragraph">Spatial indexing and ST_AsGeoJSON need MariaDB 10.2.8+ or MySQL 5.7.8+. Storing and showing geodata works without them.</p>



<h2 class="wp-block-heading">Local changes to wp-geometa-lib</h2>



<p class="wp-block-paragraph">The bundled library (<code>lib/wp-geometa-lib</code>, from BrilliantPlugins/wp-geometa) carries one local patch, marked &#8220;LH patch&#8221; in the code. In 1.30.1, <code>WP_GeoUtil::merge_geojson()</code> 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.</p>
"""^^rdf:XMLLiteral ;
  sioc:content """Part of: LH Places
Post meta



KeyHoldsgeo_latitudeDecimal latitude (WordPress geodata standard).geo_longitudeDecimal longitude (WordPress geodata standard).geo_addressA human-readable address, sanitised as plain text.geo_jsonA 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 &#8220;LH patch&#8221; 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.
""" ;
  sioc:topic <https://lhero.org/?taxonomy=author&term=cap-1> .

<https://lhero.org/author/1/#account> rdfs:seeAlso <https://lhero.org/author/1/?feed=lhrdf&format=turtle> .
<https://lhero.org/?taxonomy=author&term=cap-1> rdfs:seeAlso <https://lhero.org/?taxonomy=author&term=cap-1&feed=lhrdf&format=turtle> .