-- forked from #1404876: Fatal error: Unsupported operand types in countries_regions/countries_regions.admin.inc on line 177 --

Some docs about the pros and cons of countries_regions and location_taxonomize would be helpful.

Comments

alan d.’s picture

alan d. commented
Status: Active » Needs work

I have attempted to create a taxonomy based regional db twice, and both times, core implementation factors have meant that the vocabulary was not editable due to memory issues and other factors. This is the reason why I discarded taxonomy and created the custom rendering. However, the core internal db structure is approx. the same, with the exception of having a country tag per region / term.

This is a rough comparison from reading the readme of Location Taxonomize.

Feature Location Taxonomize (LT) Countries regions (CR)
Maintained Yes Unsure - Lost motivation after the other module was published and project that I was developing this for became stalled.
DB Structure Similar schema
LT uses core functionality		 Similar schema
CR uses a custom implementation. CR will have the ability to decide on a better storage model at a latter date, though initial work on this was dropped. Note that I have decided to drop any implementation of a graph based algorithm to stay with a tree based algorithm with computed maintained multi-parent relationships. All four of the first first countries looked at needed this ability for a complete representation.
Multiple vocabularies No, but this could happen No
Maintains structure Yes. Optional and fixed to the regions depth. Yes. Optional, not fixed to tree depth.
Supports auto-calculation of these and also different versions per country.
Depth Unlimited (maybe locked to chosen regional structure) Fixed to 13 Region - City - Suburb category levels but you can override any depth classification and nest however you what. (These are just flags).
Multi-parent No
I think this was dropped from D7 taxonomy, so not possible		 Yes
Via placeholder regions instances that are coupled to a single region.
Structural changes Locked when defining vocab Dynamic and configurable per country.
Node taxonomy integration Yes No
Location Fully integrated No
Address Field Fully integrated No
Listings Core Custom with configurable child depth per country settings. It makes sense to list all of the Cook Island records on a single page, but You would kill the server and / or browser trying this on Russia with a fully populated database from Geonames project.
alan d.’s picture

alan d. commented

To paraphrase, LT is 95% fully functional and CR is only 40%. LT will have limitations to extend, but CR doesn't as it has the freedom to do this outside of core (it hasn't even started to tackle these though).

The big issues are memory considerations and editability, plus multi-parent relationships.