Optimizing WordPress for Geographic Data: Best Practices for Structuring Regions

Taxonomies are for helping us logically organize post type objects. A post type object might be a particular business. Businesses could be organized by a hierarchical location taxonomy which includes terms such as country, region, and city names.

In this example, where would GPS coords best be saved? The common answer is either term or post meta, depending on what you’re locating. However, WP meta data is not a very efficient schema. If your queries are primarily for post or term objects where you incidentally also collect associated meta data, the schema is workable. But if you need to query by coordinates to get nearby posts or businesses, such as all businesses within 100km of an arbitrary location, the schema works, but quite poorly.

If you anticipate frequent queries by meta data, I advise instead keeping coordinate data in a custom table related by post or term ID. Also, store the coords as full decimal values, don’t use deg min sec format. Address the N E S W aspects as positive or negative degrees. By convention N & E values are all positive.

Hello and thank you for that, is that okay that I have 36.000 cities in taxonomies?

I’ll store metadata for each post in posts’ metadata and will use decimal format yes.

In theory it’s OK, but it’s not ideal. It’s not easy to manage that many terms using the usual WP UI, but it’s doable. At least use a hierarchical taxonomy so you can use the post editor’s category type search feature. Your DB server resources need to be up to the task. Even if you have adequate storage space, unless the DB engine is optimized for very large tables, you’re likely going to see very slow queries. Partly because the WP meta data schema is inefficient. The term schema itself is good, it’s meta data where inefficiency creeps in. It’s OK for most WP users, their data volume is usually not that large. The larger the data volume, the more any inefficiency becomes an issue.

Even if you do not anticipate making queries by coordinates, because of the data volume I still advise keeping coords in a custom table instead of meta data. It may not seem like much difference by having coords each in their own column instead of by meta key, but when processing 36k records, it’s a huge difference to the DB engine.

You can keep other term data in term meta or term objects, only the coords should be in a custom table. But since you have it, you could choose to also keep other frequently used meta data in this table, each in its own column. To save city term coords in a custom table, you only need 3 columns. An indexed term_id column along with one for latitude and one for longitude.

For best accuracy, all of your coordinates should utilize the same datum (WGS 84 is the most common). Should be the case if they all have a common source. If they are not all in the same datum, probably no need to worry, the differences likely do not matter at the scale you’re likely dealing with.

If you need to calculate distances, spherical methods are usually adequate. The more accurate ellipsoidal methods are much more complicated and are typically unwarranted.