GD Location Manager : Comment rendre les régions (gd_region) et les quartiers (gd_neighbourhood) hiérarchiques ?

Questions et réponsesSujet : GeoDirectoryGD Location Manager : Comment rendre les régions (gd_region) et les quartiers (gd_neighbourhood) hiérarchiques ?
Question posée par Bigue Niqueadminil y a 6 mois

L’extension GD Location Manager permet de gérer des «endroits» sur 4 niveaux :

  1. Pays (gd_coutry)
  2. Région (gd_region)
  3. Ville (gd_city)
  4. Quartier (gd_neighbourhood)

Ainsi chaque adresse (listing) est associée à une ville, qui est associée à une région, qui est associée à un Pays. Éventuellement, un quartier peut également être assigné.
C’est bien, mais c’est un peu limité. Sur (le nouveau) Fiat+⁄-Lux Local (en plein développement), j’aimerais être capable de hiérarichiser davantage la navigation. Voici un exemple de découpage hiérarchique envisageable (en voyant large) :

  • Groupes de pays (continents, eg. «Europe»)
  • Sous-groupes de pays (eg. «Europe du Sud»)
  • Pays
  • Province, Territoire ou État (USA)
  • Région administrative (Québec), Départements (France), County (USA), etc.
  • MRC (au Québec), Région métropolitaine, etc.
  • Ville, municipalité, localité, etc.
  • Arrondissements
  • Quartiers sociologiques

Au-delà des pays, c’est bon. On peut organiser un classement de façon semi-structurée autrement (présentation dans des pages, par exemple). Mais on voit qu’entre les pays et les villes, on peut souhaiter disposer de plusieurs niveaux hiérachiques. Même choses entre les villes et les quartiers : on pourrait souhaiter un découpage plus précis sans sacrifier l’intérêt d’un découpage intermédiaire. On pourrait même envisager de présenter les commerces par rue : c’est ce que je fais déjà sur (l’ancien) Fiat+⁄-Lux Local, et c’est à vrai dire excellent pour la SEO.

On remarquera aussi que la dénomination des sous-divisions est appelée à varier selon le pays ou l’application. Il faudra donc prendre cela en compte.

Voyons d’abord comment GeoDirectory Location Manager gère ses structures de données. Celui-ci utilise 4 tables :

  • {network_prefix}_countries
  • {blog_prefix}_geodir_post_locations
  • {blog_prefix}_geodir_post_neighbourhood
  • {blog_prefix}_geodir_location_seo

 

Pays

 

Une table (commune au réseau sur une installation multisite) de pays (`{prefix}_country`) qui sera populée des noms de pays (en anglais) et des métadonnées standard (capitale, gentilé, code 2 lettres, 3 lettres, fuseaux horaires, devise et signe, drapeau SVG, etc.). Cette table contient des données standard et est probablement utilisée pour interagir avec les services géographiques (Google API ou Open Street Maps). On ne peut donc pas se servir de cette table pour «étendre» le potentiel de la structure (eg. j’ai essayé d’insérer un pays «Québec» dans la base de données, question de voir si je ne pouvais pas y décaler les provinces pour disposer des régions pour un découpage intermédiaire, mais cela provoque plusieurs problèmes, notamment avec la localisation automatique des adresses, ce ne sera donc pas une option pour nous — sans un référendum en bonne et due forme).

Il faudra donc se servir des pays tels quels.

 

Villes

(à suivre)

 

 

Bigue Nique admin il y a 6 mois

Note: je suis en train de tester en même temps l’extension DWQA Question & Answer !