[SPIP Zone] Plugins géographie : nouvelle région

maieul · Octobre 11, 2019, 10:37

Holla,

le plugin géographie fonctionne toujours avec les anciennes régions.

Est-ce qu'il ne faudrait pas passer aux nouvelles régions ?
Pour des installations neuves, cela ne devrait pas poser de problème. En
revanche pour des installations plus ancienne, se pose la question de la
migration :
- pour les tables du plugin proprement dit, pas de souci
- en revanche pour les tables qui utilisent les identifiants des régions
comment faire ?. Je pense notamment aux champs extra éventuelle
(hypothèse relativement peu problable dans la mesure où il n'y a pour le
moment pas de possibilité d'ajouter un champ extra de région via
l'interface graphique). Ma proposition : le plugin fournirait une
function de migration
geo_migrer_region_2015($table, $colonne) qui s'occuperait
automatiquement de migrer si on l'appelle.

Dans une telle hypothèse, on poserait un sabot sur une branche 1, et les
nouvelles régions seraient dans la branche 2.

Avis bienvenus !

Maïeul

touti · Octobre 12, 2019, 10:12

Hello,

et pourquoi ne pas rajouter une table "nouvelles_regions" qui regroupe
les départements idoines et qu'on peut appeler seulement si on le souhaite ?

++

Le 11/10/2019 à 12:37, Maïeul Rouquette a écrit :

Holla,

le plugin géographie fonctionne toujours avec les anciennes régions.

Est-ce qu'il ne faudrait pas passer aux nouvelles régions ?
Pour des installations neuves, cela ne devrait pas poser de problème. En
revanche pour des installations plus ancienne, se pose la question de la
migration :
- pour les tables du plugin proprement dit, pas de souci
- en revanche pour les tables qui utilisent les identifiants des régions
comment faire ?. Je pense notamment aux champs extra éventuelle
(hypothèse relativement peu problable dans la mesure où il n'y a pour le
moment pas de possibilité d'ajouter un champ extra de région via
l'interface graphique). Ma proposition : le plugin fournirait une
function de migration
geo_migrer_region_2015($table, $colonne) qui s'occuperait
automatiquement de migrer si on l'appelle.

Dans une telle hypothèse, on poserait un sabot sur une branche 1, et les
nouvelles régions seraient dans la branche 2.

Avis bienvenus !

Maïeul

----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

cerdic · Octobre 12, 2019, 12:02

Hello,

je me demandais aussi quel était le chemin de migration le plus propre pour

• ne pas casser les sites existants
• permettre au nouveaux de se construire sur les nouvelles régions
• permettre à ceux qui veulent de migrer, ce qui implique effectivement une migration en base et du changement de code possiblement.

La proposition de touti à l’avantage de ne pas casser, mais on va se retrouver avec des id_nouvelles_regions qu’on va trainer des années, et à un moment ou à un autre il faudra renommer en « regions » car les « nouvelles régions » dans 10 ans ça sera un peu balot. Et alors on aura toujours/encore le soucis de migration, changement de code etc.

La proposition de maieul est pas mal, MAIS on risque d’avoir des upgrades involontaires parce que SVP dira « hé y a une version 2 du plugin geographies » et les gens cliqueront sur mise à jour sans savoir que leur base de données devient tout à coup incohérente.

Donc je pense qu’il faut aller un tout petit peu plus loin en mettant un nouveau prefixe sur la branche de la v2 pour éviter la proposition de migration automatique (et une balise <procure> sur le nouveau plugin pour qu’il dire qu’il procure bien les fonctions de geographies).
Et comme maieul le propose, une fonction de migration réutilisable pour permettre à ceux qui doivent migrer des tables en relation de le faire facilement.

--
Cédric
Le 12 oct. 2019 à 12:12 +0200, toutati <toutati@free.fr>, a écrit :

Hello,

et pourquoi ne pas rajouter une table "nouvelles_regions" qui regroupe
les départements idoines et qu'on peut appeler seulement si on le souhaite ?

++

Le 11/10/2019 à 12:37, Maïeul Rouquette a écrit :
> Holla,
>
> le plugin géographie fonctionne toujours avec les anciennes régions.
>
> Est-ce qu'il ne faudrait pas passer aux nouvelles régions ?
> Pour des installations neuves, cela ne devrait pas poser de problème. En
> revanche pour des installations plus ancienne, se pose la question de la
> migration :
> - pour les tables du plugin proprement dit, pas de souci
> - en revanche pour les tables qui utilisent les identifiants des régions
> comment faire ?. Je pense notamment aux champs extra éventuelle
> (hypothèse relativement peu problable dans la mesure où il n'y a pour le
> moment pas de possibilité d'ajouter un champ extra de région via
> l'interface graphique). Ma proposition : le plugin fournirait une
> function de migration
> geo_migrer_region_2015($table, $colonne) qui s'occuperait
> automatiquement de migrer si on l'appelle.
>
> Dans une telle hypothèse, on poserait un sabot sur une branche 1, et les
> nouvelles régions seraient dans la branche 2.
>
> Avis bienvenus !
>
> Maïeul
>
>
>
> ----
> spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

touti · Octobre 12, 2019, 2:37

Héhé, je pense qu’on en a pour un moment à garder les « anciennes » régions, leboncoin est toujours découpé à l’ancienne et ce n’est pas comme de parler en euros ou en francs.

Si c’est une question de nomenclature, une table regions_groupees irait très bien, mais bon, autant se casser la tête si vous aimez :))

rastapopoulos · Octobre 12, 2019, 10:25

Mais faudrait alors changer de préfixe à chaque fois qu'il y a des
changements dans les tables ? Pour les régions là, il se trouve que
c'est assez rare, mais en réalité pour les villes c'est… tous les ans
quasiment. Tous les ans il y a des villes qui disparaissent et
fusionnent avec d'autres, et des nouvelles qui apparaissent. Et le
plugin n'est jamais vraiment à jour.

À terme c'est la structure, l'architecture de comment c'est stocké qui
me parait pas super pérenne (déjà au moins pour la France on devrait
toujours faire appel à l'identifiant INSEE que ce soit pour région, dép,
ville, et pas aux id SQL… mais après pour les autres pays je sais pas
comment ça marche).

--
RastaPopoulos

eric_tonton · Octobre 13, 2019, 9:34

Hello,

Mais faudrait alors changer de préfixe à chaque fois qu’il y a des
changements dans les tables ? Pour les régions là, il se trouve que
c’est assez rare, mais en réalité pour les villes c’est… tous les ans
quasiment. Tous les ans il y a des villes qui disparaissent et
fusionnent avec d’autres, et des nouvelles qui apparaissent. Et le
plugin n’est jamais vraiment à jour.

À terme c’est la structure, l’architecture de comment c’est stocké qui
me parait pas super pérenne (déjà au moins pour la France on devrait
toujours faire appel à l’identifiant INSEE que ce soit pour région, dép,
ville, et pas aux id SQL… mais après pour les autres pays je sais pas
comment ça marche).

Absolument.
Pour toutes les nomenclatures, que ce soit pour les animaux, les pays, les langues… il est essentiel de n’utiliser que « id » unique fourni par la nomenclature qu’il soit un entier ou une chaine pour faire les liens avec les autres objets. Ainsi il est possible de recharger sans dommage les tables source de ces nomenclatures car en général si les id changent les id supprimés ne sont jamais réutilisés (en général, ça peut l’être pour les pays en ISO 3166 mais c’est assez rare).

Pour les régions, comme le dit Rasta il existe le code INSEE qui est numérique (1 ou deux chiffres) et qui permet de reconnaitre la région si on cherche des statistiques INSEE associées.
Il existe aussi la norme ISP 3166-2 qui a l’intérêt elle d’être valable pour tous les pays qui souhaitent l’utiliser. La nomenclature est basée sur le code ISO alpha2 du pays, soit FR pour la France et un suffixe pour préciser la subdivision. Par exemple, les 13 régions actuelles ont des suffixes à 3 lettres ce qui donne FR-BRE pour la Bretagne alors que le code de la Bretagne avant 2016 était FR-E. Il est donc même possible de conserver les deux nomenclatures.
C’est pareil pour l’Allemagne avec des régions comme DE-BY pour la Bavière…
Ce code unique existe aussi pour les départements et autres subdivisions comme les collectivités Outre-Mer, les départements étant aussi rattachés à une région.

Ca fait un moment que je voulais me pencher sur les plugins Géographie et Pays car, au moment pù j’ai commencé à revoir les codes de langue, j’ai initié un plugin nommé Isocode dont le but est de regrouper les codes ISO, IANA… dans des tables adaptées afin de fournir un service Web qui est presque jamais disponible sur les sites source.
Le principe du plugin est de charger des fichiers texte, excel, xml… suivant les cas voire de lire des pages web et de construire les tables associées qui fournissent toute l’information nécessaire.
J’avais dans l’idée d’installer ce plugin sur un site de la Galaxie et de servir les plugins Géographie ou Pays ou autres via une interface web.
Ca serait peut-être bien de voir comment merger tout ça.
Je n’ai aucun problème à revoir le plugin voire à le dissoudre ailleurs si besoin.

En tout cas, l’expérience m’a montré qu’il fallait créer des tables qui intègrent par objet l’ensemble des identifiants connus. Par exemple, il parait intéressant pour les pays et les subdivisions de conserver les identifiants ISO et propres au pays comme ceux de l’INSEE pour la France car ils peuvent être utilisés dans différents contextes même si la priorité doit être donnée au plus universel, cad l’ISO.
En outre, je ne sais pas comment est fait le plugin Géographie mais pour être multi-pays il vaudrait mieux ne pas avoir de tables pour chaque subdivision (région, département, collectivité…) mais une table subdivision avec un type voire une profondeur qui pourrait s’adapter en fonction du pays.

La complexité ensuite vient du chargement des tables.
Le plugin Isocode a quelques fonctions et mécanismes génériques pour des fichiers csv, xml, json et pour l’extraction de page web.
C’est peut-être une bonne base à reprendre.
A discuter.

Voilà pour les quelques idées du moment.

maieul · Octobre 13, 2019, 5:01

après les nouvelles régions datant de 2015, rien n'exclu de prendre des
id_regions_2015. Cela étant, je suis pas convaincu que garder 2 système
de région dans un même plugin est une bonne chose. La proposition de
Cédric me semble du coup la plus pertinent.

Reste à trouver le prefix correct pour le nouveau plugin.

Le samedi 12 octobre 2019 à 14:02 +0200, Cerdic a écrit :

Hello,

je me demandais aussi quel était le chemin de migration le plus propre
pour
ne pas casser les sites existants
permettre au nouveaux de se construire sur les nouvelles régions
permettre à ceux qui veulent de migrer, ce qui implique effectivement
une migration en base et du changement de code possiblement.
La proposition de touti à l’avantage de ne pas casser, mais on va se
retrouver avec des id_nouvelles_regions qu’on va trainer des années,
et à un moment ou à un autre il faudra renommer en « regions » car les
« nouvelles régions » dans 10 ans ça sera un peu balot. Et alors on
aura toujours/encore le soucis de migration, changement de code etc.

La proposition de maieul est pas mal, MAIS on risque d’avoir des
upgrades involontaires parce que SVP dira « hé y a une version 2 du
plugin geographies » et les gens cliqueront sur mise à jour sans
savoir que leur base de données devient tout à coup incohérente.

Donc je pense qu’il faut aller un tout petit peu plus loin en mettant
un nouveau prefixe sur la branche de la v2 pour éviter la proposition
de migration automatique (et une balise <procure> sur le nouveau
plugin pour qu’il dire qu’il procure bien les fonctions de
geographies).
Et comme maieul le propose, une fonction de migration réutilisable
pour permettre à ceux qui doivent migrer des tables en relation de le
faire facilement.

--
Cédric
Le 12 oct. 2019 à 12:12 +0200, toutati <toutati@free.fr>, a écrit :
> Hello,
>
> et pourquoi ne pas rajouter une table "nouvelles_regions" qui
> regroupe
> les départements idoines et qu'on peut appeler seulement si on le
> souhaite ?
>
> ++
>
> Le 11/10/2019 à 12:37, Maïeul Rouquette a écrit :
> > Holla,
> >
> > le plugin géographie fonctionne toujours avec les anciennes
> > régions.
> >
> > Est-ce qu'il ne faudrait pas passer aux nouvelles régions ?
> > Pour des installations neuves, cela ne devrait pas poser de
> > problème. En
> > revanche pour des installations plus ancienne, se pose la question
> > de la
> > migration :
> > - pour les tables du plugin proprement dit, pas de souci
> > - en revanche pour les tables qui utilisent les identifiants des
> > régions
> > comment faire ?. Je pense notamment aux champs extra éventuelle
> > (hypothèse relativement peu problable dans la mesure où il n'y a
> > pour le
> > moment pas de possibilité d'ajouter un champ extra de région via
> > l'interface graphique). Ma proposition : le plugin fournirait une
> > function de migration
> > geo_migrer_region_2015($table, $colonne) qui s'occuperait
> > automatiquement de migrer si on l'appelle.
> >
> > Dans une telle hypothèse, on poserait un sabot sur une branche 1,
> > et les
> > nouvelles régions seraient dans la branche 2.
> >
> > Avis bienvenus !
> >
> > Maïeul
> >
> >
> >
> > ----
> > spip-zone@rezo.net -
> > https://listes.rezo.net/mailman/listinfo/spip-zone

eric_tonton · Octobre 13, 2019, 6:22

Euh tu réponds à quoi et à qui ?

eric_tonton · Octobre 13, 2019, 7:15

Re,

Le dim. 13 oct. 2019 à 19:02, Maïeul Rouquette <maieul@maieul.net> a écrit :

après les nouvelles régions datant de 2015, rien n’exclu de prendre des
id_regions_2015. Cela étant, je suis pas convaincu que garder 2 système
de région dans un même plugin est une bonne chose. La proposition de
Cédric me semble du coup la plus pertinent.

Je me demande vraiment si on a besoin de faire ça.
On avait pas changé justement dans SVP pour ne pas proposer la mise à jour automatiquement si on avait un saut de X ?

++
Eric

b_b · Octobre 13, 2019, 7:20

Hop,

Le 13/10/2019 à 21:15, Eric Lupinacci a écrit :

Je me demande vraiment si on a besoin de faire ça.
On avait pas changé justement dans SVP pour ne pas proposer la mise à jour
automatiquement si on avait un saut de X ?

Non, et ça propose même la mise à jour si un plugin actif indique qu'il nécessite la branche 1.x maxi alors que la 2.x est dispo, ce qui n'est pas pratique du tout.

++
b_b

Franck · Octobre 13, 2019, 7:32

Ouaip, c'est dans les tickets https://core.spip.net/projects/svp/issues?set_filter=1&tracker_id=2

-----Message d'origine-----
De : Bruno Bergot <bruno@eliaz.fr>
Envoyé : dimanche 13 octobre 2019 21:20
À : Eric Lupinacci <eric@smellup.net>
Cc : spip-zone <spip-zone@rezo.net>
Objet : Re: [SPIP Zone] Plugins géographie : nouvelle région

Hop,

Le 13/10/2019 à 21:15, Eric Lupinacci a écrit :

Je me demande vraiment si on a besoin de faire ça.
On avait pas changé justement dans SVP pour ne pas proposer la mise à
jour automatiquement si on avait un saut de X ?

Non, et ça propose même la mise à jour si un plugin actif indique qu'il nécessite la branche 1.x maxi alors que la 2.x est dispo, ce qui n'est pas pratique du tout.

++
b_b
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

maieul · Octobre 13, 2019, 7:56

Je me demande vraiment si on a besoin de faire ça.
On avait pas changé justement dans SVP pour ne pas proposer la mise à
jour automatiquement si on avait un saut de X ?

++
Eric

pas encore, à ma connaissance (mais peut être que je me trompe)

maieul · Octobre 14, 2019, 7:35

Le 13/10/2019 à 11:34, Eric Lupinacci a écrit :

Hello,

Le dim. 13 oct. 2019 à 00:26, RastaPopoulos <rastapopoulos@spip.org <mailto:rastapopoulos@spip.org>> a écrit :

    Mais faudrait alors changer de préfixe à chaque fois qu'il y a des
    changements dans les tables ? Pour les régions là, il se trouve que
    c'est assez rare, mais en réalité pour les villes c'est… tous les ans
    quasiment. Tous les ans il y a des villes qui disparaissent et
    fusionnent avec d'autres, et des nouvelles qui apparaissent. Et le
    plugin n'est jamais vraiment à jour.

    À terme c'est la structure, l'architecture de comment c'est stocké qui
    me parait pas super pérenne (déjà au moins pour la France on devrait
    toujours faire appel à l'identifiant INSEE que ce soit pour région, dép,
    ville, et pas aux id SQL… mais après pour les autres pays je sais pas
    comment ça marche).

Absolument.
Pour toutes les nomenclatures, que ce soit pour les animaux, les pays, les langues... il est essentiel de n'utiliser que "id" unique fourni par la nomenclature qu'il soit un entier ou une chaine pour faire les liens avec les autres objets. Ainsi il est possible de recharger sans dommage les tables source de ces nomenclatures car en général si les id changent les id supprimés ne sont jamais réutilisés (en général, ça peut l'être pour les pays en ISO 3166 mais c'est assez rare).

Pour les régions, comme le dit Rasta il existe le code INSEE qui est numérique (1 ou deux chiffres) et qui permet de reconnaitre la région si on cherche des statistiques INSEE associées.
Il existe aussi la norme ISP 3166-2 qui a l'intérêt elle d'être valable pour tous les pays qui souhaitent l'utiliser. La nomenclature est basée sur le code ISO alpha2 du pays, soit FR pour la France et un suffixe pour préciser la subdivision. Par exemple, les 13 régions actuelles ont des suffixes à 3 lettres ce qui donne FR-BRE pour la Bretagne alors que le code de la Bretagne avant 2016 était FR-E. Il est donc même possible de conserver les deux nomenclatures.
C'est pareil pour l'Allemagne avec des régions comme DE-BY pour la Bavière...
Ce code unique existe aussi pour les départements et autres subdivisions comme les collectivités Outre-Mer, les départements étant aussi rattachés à une région.

Ca fait un moment que je voulais me pencher sur les plugins Géographie et Pays car, au moment pù j'ai commencé à revoir les codes de langue, j'ai initié un plugin nommé Isocode dont le but est de regrouper les codes ISO, IANA... dans des tables adaptées afin de fournir un service Web qui est presque jamais disponible sur les sites source.
Le principe du plugin est de charger des fichiers texte, excel, xml... suivant les cas voire de lire des pages web et de construire les tables associées qui fournissent toute l'information nécessaire.
J'avais dans l'idée d'installer ce plugin sur un site de la Galaxie et de servir les plugins Géographie ou Pays ou autres via une interface web.
Ca serait peut-être bien de voir comment merger tout ça.
Je n'ai aucun problème à revoir le plugin voire à le dissoudre ailleurs si besoin.

En tout cas, l'expérience m'a montré qu'il fallait créer des tables qui intègrent par objet l'ensemble des identifiants connus. Par exemple, il parait intéressant pour les pays et les subdivisions de conserver les identifiants ISO et propres au pays comme ceux de l'INSEE pour la France car ils peuvent être utilisés dans différents contextes même si la priorité doit être donnée au plus universel, cad l'ISO.
En outre, je ne sais pas comment est fait le plugin Géographie mais pour être multi-pays il vaudrait mieux ne pas avoir de tables pour chaque subdivision (région, département, collectivité...) mais une table subdivision avec un type voire une profondeur qui pourrait s'adapter en fonction du pays.

La complexité ensuite vient du chargement des tables.
Le plugin Isocode a quelques fonctions et mécanismes génériques pour des fichiers csv, xml, json et pour l'extraction de page web.
C'est peut-être une bonne base à reprendre.
A discuter.

Voilà pour les quelques idées du moment.

++
Eric

----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

Oui, clairement c'est plus pérenne.

maieul · Octobre 14, 2019, 7:45

Le 12/10/2019 à 16:37, toutati a écrit :

Héhé, je pense qu'on en a pour un moment à garder les "anciennes" régions, leboncoin est toujours découpé à l'ancienne et ce n'est pas comme de parler en euros ou en francs.

Si c'est une question de nomenclature, une table regions_groupees irait très bien, mais bon, autant se casser la tête si vous aimez :))

++

Le 12/10/2019 à 14:02, Cerdic a écrit :

Hello,

je me demandais aussi quel était le chemin de migration le plus propre pour

  * ne pas casser les sites existants
  * permettre au nouveaux de se construire sur les nouvelles régions
  * permettre à ceux qui veulent de migrer, ce qui implique
    effectivement une migration en base et du changement de code
    possiblement.

La proposition de touti à l’avantage de ne pas casser, mais on va se retrouver avec des id_nouvelles_regions qu’on va trainer des années, et à un moment ou à un autre il faudra renommer en « regions » car les « nouvelles régions » dans 10 ans ça sera un peu balot. Et alors on aura toujours/encore le soucis de migration, changement de code etc.

La proposition de maieul est pas mal, MAIS on risque d’avoir des upgrades involontaires parce que SVP dira « hé y a une version 2 du plugin geographies » et les gens cliqueront sur mise à jour sans savoir que leur base de données devient tout à coup incohérente.

Donc je pense qu’il faut aller un tout petit peu plus loin en mettant un nouveau prefixe sur la branche de la v2 pour éviter la proposition de migration automatique (et une balise <procure> sur le nouveau plugin pour qu’il dire qu’il procure bien les fonctions de geographies).
Et comme maieul le propose, une fonction de migration réutilisable pour permettre à ceux qui doivent migrer des tables en relation de le faire facilement.

--
Cédric
Le 12 oct. 2019 à 12:12 +0200, toutati <toutati@free.fr>, a écrit :

Hello,

et pourquoi ne pas rajouter une table "nouvelles_regions" qui regroupe
les départements idoines et qu'on peut appeler seulement si on le souhaite ?

++

Le 11/10/2019 à 12:37, Maïeul Rouquette a écrit :

Holla,

le plugin géographie fonctionne toujours avec les anciennes régions.

Est-ce qu'il ne faudrait pas passer aux nouvelles régions ?
Pour des installations neuves, cela ne devrait pas poser de problème. En
revanche pour des installations plus ancienne, se pose la question de la
migration :
- pour les tables du plugin proprement dit, pas de souci
- en revanche pour les tables qui utilisent les identifiants des régions
comment faire ?. Je pense notamment aux champs extra éventuelle
(hypothèse relativement peu problable dans la mesure où il n'y a pour le
moment pas de possibilité d'ajouter un champ extra de région via
l'interface graphique). Ma proposition : le plugin fournirait une
function de migration
geo_migrer_region_2015($table, $colonne) qui s'occuperait
automatiquement de migrer si on l'appelle.

Dans une telle hypothèse, on poserait un sabot sur une branche 1, et les
nouvelles régions seraient dans la branche 2.

Avis bienvenus !

Maïeul

----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

Bon,

j'ai commencé à faire quelque chose pour cela. Et c'est au moment de préparation la migration des anciens id de région vers les nouveaux que je me suis apercu d'un hic.

Les communes et départements sont créées régions par régions.

Par conséquent, leur ordre de création n'est pas le même avec les nouvelles communes. Et du coup leur id non plus.... Du coup faudrait aussi remapper toutes les communes (et tous les départements).

Pour se donner une idée : avec la version region 2016 installé brut, Perpignan c'est 31177, alors que ce même code correspond à Ligescourt dans la version actuelle.

Conclusion : la piste la plus pérenne, à long terme, me parait bien le système ISO.

Pour ma part je pense que je vais laisser en plan cette branche (qui en plus à fait planter IRC !)

Maïeul

eric_tonton · Octobre 15, 2019, 7:14

Hello,

et pourquoi ne pas rajouter une table « nouvelles_regions » qui regroupe
les départements idoines et qu’on peut appeler seulement si on le
souhaite ?

Dans une telle hypothèse, on poserait un sabot sur une branche 1, et les
nouvelles régions seraient dans la branche 2.

Avis bienvenus !

Suite à cette discussion, je me suis remis sur le développement du plugin Isocode.
A l’origine je l’avais développé pour travailler sur les étiquettes de langue et vérifier la correction ou pas de celles de SPIP.
Puis petit à petit j’en ai fait une sorte de concentrateur de ressources normatives difficilement accessibles sur le Net.

Aujourd’hui, outre les ressources linguistiques sur les éléments des codes de langue (y compris la table de tous les subtags IANA), le plugin possède aussi la liste des devises des pays et des ressources géographiques, à savoir :

// Table des indicatifs des pays ISO-3166 et autres informations : spip_iso3166countries
$table_countries = array(
   'code_alpha2'     => "char(2) DEFAULT '' NOT NULL",       // The two-letter identifier
   'code_alpha3'     => "char(3) DEFAULT '' NOT NULL",       // The three-letter identifier
   'code_num'        => "char(3) DEFAULT '' NOT NULL",       // Numeric identifier
   'label_en'        => "varchar(255) DEFAULT '' NOT NULL",  // English name
   'label_fr'        => "varchar(255) DEFAULT '' NOT NULL",  // french name
   'label'           => "text DEFAULT '' NOT NULL",          // Multiple langages label
   'capital'         => "varchar(255) DEFAULT '' NOT NULL",  // Capital name
   'area'            => "int DEFAULT 0 NOT NULL",            // Area in squared km
   'population'      => "int DEFAULT 0 NOT NULL",            // Inhabitants count
   'code_continent'  => "char(2) DEFAULT '' NOT NULL",       // Continent code alpha2
   'code_num_region' => "char(3) DEFAULT '' NOT NULL",       // Parent region numeric code (ISO 3166)
   'tld'             => "char(3) DEFAULT '' NOT NULL",       // Tld - Top-Level Domain
   'code_4217_3'     => "char(3) DEFAULT '' NOT NULL",       // Currency code ISO-4217
   'currency_en'     => "varchar(255) DEFAULT '' NOT NULL",  // Currency English name
   'phone_id'        => "varchar(16) DEFAULT '' NOT NULL",   // Phone id
   'maj'             => 'timestamp DEFAULT current_timestamp ON UPDATE current_timestamp'
);

gilcot · Octobre 15, 2019, 7:52

Le mar. 15 oct. 2019 21:15, Eric Lupinacci a écrit :

Suite à cette discussion, je me suis remis sur le développement du plugin Isocode.

C’est marrant qu’on en parle ; j’étais tombé dessus samedi et me suis demandé si ça remplaçait Pays puis ai vu que c’était surtout pour les codes de langues…

A l’origine je l’avais développé pour travailler sur les étiquettes de langue et vérifier la correction ou pas de celles de SPIP.
Puis petit à petit j’en ai fait une sorte de concentrateur de ressources normatives difficilement accessibles sur le Net.

Aujourd’hui, outre les ressources linguistiques sur les éléments des codes de langue (y compris la table de tous les subtags IANA), le plugin possède aussi la liste des devises des pays et des ressources géographiques,

Une initiative similaire à Wikipedia, sauf que l’encyclopédie libre fait de la présentation et qu’ici tu présentes les données brutes en tables SQL. Je trouve cela fort louable car effectivement, les données sont dispersées et pas toujours facile d’accès ni dans des formes facilement exploitables de prime abord. Je trouve cela louable car on peut/devrait avoir un point central pour favoriser les mises à jours aussi.

[…]
Cela n’empêche pas de toute façon de supprimer l’utilisation de l’id objet de chaque table dans les plugins Pays et Géographie pour assurer une pérennité quasi totale des utilisations.

Je te rejoins à 1000% sur le fait qu’on devrait utiliser les codes ISO et IANA qui ont le mérite d’avoir été pensé comme des clés primaires et qui en plus ne sont pas recyclés (on croise les doigts pour que cela dure), permettant donc historisation (pour ceux qui utilisent encore les anciens trucs pas de souci) et évolution (les nouveaux trucs peuvent cohabiter avec les anciens et sinon la migration est assez simple à mon goût.)

Concernant les id numériques, j’ai vu que Pays l’utilise pour bénéficier de la gestion d’objets automatique de SPIP et leur présence ne me dérange pas en soi. Par contre les autres plugins devraient se lier en utilisant les codes ISO (comme le fait justement Coordonnées)

Je vous laisse réfléchir à la proposition sachant que l’on peut aussi faire évoluer ce plugin si besoin.

++

Eric

gilcot · Octobre 15, 2019, 8:14

Le sam. 12 oct. 2019 16:37, toutati a écrit :

Héhé, je pense qu'on en a pour un moment à garder les "anciennes" régions,
leboncoin est toujours découpé à l'ancienne et ce n'est pas comme de parler
en euros ou en francs.

Et sauf tracasseries administratives, beaucoup comme moi raisonnent en
anciennes régions...

Si c'est une question de nomenclature, une table regions_groupees irait
très bien,

Plutôt une colonne qu'une table...

mais bon, autant se casser la tête si vous aimez :))

++
Le 12/10/2019 à 14:02, Cerdic a écrit :

[...]
La proposition de touti à l’avantage de ne pas casser, mais on va se
retrouver avec des id_nouvelles_regions qu’on va trainer des années, et à
un moment ou à un autre il faudra renommer en « regions » car les «
nouvelles régions » dans 10 ans ça sera un peu balot.

Ou il aura juste de nouvelles nouvelles regions...

Et alors on aura toujours/encore le soucis de migration, changement de
code etc.

La proposition de maieul est pas mal, MAIS on risque d’avoir des upgrades
involontaires parce que SVP dira « hé y a une version 2 du plugin
geographies » et les gens cliqueront sur mise à jour sans savoir que leur
base de données devient tout à coup incohérente.

Donc je pense qu’il faut aller un tout petit peu plus loin en mettant un
nouveau prefixe sur la branche de la v2 pour éviter la proposition de
migration automatique

Pour vraiment aller loin et faire proprement pour de bon, il faudra aussi

surtout utiliser les codes ISO et EINSEE comme préconisent _Eric_ et
RastaPopoulos

(et une balise <procure> sur le nouveau plugin pour qu’il dire qu’il

procure bien les fonctions de geographies).

Et comme maieul le propose, une fonction de migration réutilisable pour

permettre à ceux qui doivent migrer des tables en relation de le faire
facilement.

eric_tonton · Octobre 16, 2019, 7:22

Hello,

Le mar. 15 oct. 2019 à 21:14, Eric Lupinacci <eric@smellup.net> a écrit :

Suite à cette discussion, je me suis remis sur le développement du plugin Isocode.

A l’origine je l’avais développé pour travailler sur les étiquettes de langue et vérifier la correction ou pas de celles de SPIP.
Puis petit à petit j’en ai fait une sorte de concentrateur de ressources normatives difficilement accessibles sur le Net.

Aujourd’hui, outre les ressources linguistiques sur les éléments des codes de langue (y compris la table de tous les subtags IANA), le plugin possède aussi la liste des devises des pays et des ressources géographiques, à savoir :
// Table des indicatifs des pays ISO-3166 et autres informations : spip_iso3166countries
// Table des indicatifs des continents GeoIP : spip_geoipcontinents
```
// Table des indicatifs des régions du monde UN M49 (arborescence) : spip_m49regions

```

```
// Table des subdivisions géographiques des pays suivant la norme ISO 3166-2 : spip_iso3166subdivisions

```

```
L'idée n'est pas d'inclure ce plugin dans tous les sites SPIP mais plutôt de l'installer sur un site serveur de la Galaxie et de proposer une API REST.
```

J’ai continué à avancer sur le plugin ISOCODE (je crois que je vais le renommer car ce nom ressemble plus à un préfixe qu’à autre chose).
J’ai donc développé une API REST sur le modèle de celle de SVP Typologie.
La première collection « pays » est disponible au sein de l’API nommée « geographie » (format comme l’appelle la doc du plugin Serveur HTTP abstrait).
Il est possible d’utiliser deux filtres : le continent et la région, le continent étant désigné par son codet alpha2 provenant de GeoIP et la région par son codet numérique sur 3 chiffres (ISO 3166-1).

Les url ont donc la forme :

domaine/http.api/geographie/pays => tous les pays
domaine/http.api/geographie/pays&continent=EU => tous les pays du continent européen
domaine/http.api/geographie/pays&region=015 => tous les pays d’Afrique Septentrionale

Vous pouvez essayer cette interface sur mon site de demo (avec mesure!) en remplaçant le nom du domaine par demopot;smellup.net.

Cela peut permettre de charger / recharger sans problème le plugin Pays.
C’est une première étape.
Je vais finir ce PoC en créant une nouvelle branche expérimentale de Pays qui abandonnera l’id_pays comme identifiant dans les tables de liens.
On peut le conserver dans la table des pays pour continuer à bénéficier de l’API objet.
J’ai déjà fait ça sur Taxonomie avec les taxons qui ont à la fois un id_taxon et un identifiant universel et pérenne appelé TSN.

A vous lire.

++

Eric

cerdic · Octobre 28, 2019, 9:25

Hello,

à ce sujet on notera l’incongruité de la saisie Pays qui par défaut fonctionne en id_pays au lieu de fonctionner en code iso…

--
Cédric
Le 16 oct. 2019 à 21:22 +0200, Eric Lupinacci <eric@smellup.net>, a écrit :

Hello,

> Le mar. 15 oct. 2019 à 21:14, Eric Lupinacci <eric@smellup.net> a écrit :
> > Suite à cette discussion, je me suis remis sur le développement du plugin Isocode.
> > > A l'origine je l'avais développé pour travailler sur les étiquettes de langue et vérifier la correction ou pas de celles de SPIP.
> > > Puis petit à petit j'en ai fait une sorte de concentrateur de ressources normatives difficilement accessibles sur le Net.
> > >
> > > Aujourd'hui, outre les ressources linguistiques sur les éléments des codes de langue (y compris la table de tous les subtags IANA), le plugin possède aussi la liste des devises des pays et des ressources géographiques, à savoir :
> > > // Table des indicatifs des pays ISO-3166 et autres informations : spip_iso3166countries
> > > // Table des indicatifs des continents GeoIP : spip_geoipcontinents
> > > // Table des indicatifs des régions du monde UN M49 (arborescence) : spip_m49regions
> > > // Table des subdivisions géographiques des pays suivant la norme ISO 3166-2 : spip_iso3166subdivisions
> > > L'idée n'est pas d'inclure ce plugin dans tous les sites SPIP mais plutôt de l'installer sur un site serveur de la Galaxie et de proposer une API REST.
> J'ai continué à avancer sur le plugin ISOCODE (je crois que je vais le renommer car ce nom ressemble plus à un préfixe qu'à autre chose).
> J'ai donc développé une API REST sur le modèle de celle de SVP Typologie.
> La première collection "pays" est disponible au sein de l'API nommée "geographie" (format comme l'appelle la doc du plugin Serveur HTTP abstrait).
> Il est possible d'utiliser deux filtres : le continent et la région, le continent étant désigné par son codet alpha2 provenant de GeoIP et la région par son codet numérique sur 3 chiffres (ISO 3166-1).
>
> Les url ont donc la forme :
> - domaine/http.api/geographie/pays => tous les pays
> - domaine/http.api/geographie/pays&continent=EU => tous les pays du continent européen
> - domaine/http.api/geographie/pays&region=015 => tous les pays d'Afrique Septentrionale
>
> Vous pouvez essayer cette interface sur mon site de demo (avec mesure!) en remplaçant le nom du domaine par demopot;smellup.net.
>
> Cela peut permettre de charger / recharger sans problème le plugin Pays.
> C'est une première étape.
> Je vais finir ce PoC en créant une nouvelle branche expérimentale de Pays qui abandonnera l'id_pays comme identifiant dans les tables de liens.
> On peut le conserver dans la table des pays pour continuer à bénéficier de l'API objet.
> J'ai déjà fait ça sur Taxonomie avec les taxons qui ont à la fois un id_taxon et un identifiant universel et pérenne appelé TSN.
>
> A vous lire.
>
> ++
> Eric
>

eric_tonton · Octobre 28, 2019, 9:47

Hello,

Hello,

à ce sujet on notera l’incongruité de la saisie Pays qui par défaut fonctionne en id_pays au lieu de fonctionner en code iso…

Aujourd’hui mon plugin Isocode (que je vais surement renommer Nomenclatures quelque chose…) est prêt à fournir des informations normalisées à tout plugin géographique et linguistique.
A mon avis on devrait remplacer Géographie et Pays par deux autres plugins :

l’un pour les zones du monde pays compris, qui sont aujourd’hui normalisées : continents, zones géographiques UN M49 et les pays.
l’autre pour les subdivisions nationales qui utilisent à la fois des données normalisées ISO mais aussi des données normalisées en local.

Isocode servirait de concentrateur des données accessibles via API REST lors de l’initialisation ou d’une mise à jour.

On peut toujours conserver l’id pour les pays ou autres objets géographiques ce qui permet d’utiliser certaines API objet mais pour les liens il faut absolument utiliser un code ISO donné pour assurer la pérennité.
L’intérêt de créer ces deux plugins serait d’éviter les clashs avec l’existant et on pourrait fournir des scripts de migration activables manuellement.

Votre avis ?