[SPIP Zone] Géographie

Question conne : si j'ai besoin de données géographiques, je dois installer le plugin Géographie, ou le plugin SPIP-Geo ?

Ils utilisent en plus presque les mêmes tables, sauf que dans l'un c'est spip_geo_communes et l'autre spip_geo_villes.

Apparemment le plugin Géographie est beaucoup plus complet, à part qu'il n'a pas les continents, contrairement à SPIP-Geo.

Bref.
Pourtant il me semble que Cédric et Quentin faisaient partis des gens qui collaboraient plutôt que de créer des doublons. :smiley:

Ya quand même pas tant de différences que ça pour empêcher la fusion non ?

--
RastaPopoulos

Question conne : si j’ai besoin de données géographiques, je dois installer le plugin Géographie, ou le plugin SPIP-Geo ?

Ils utilisent en plus presque les mêmes tables, sauf que dans l’un c’est spip_geo_communes et l’autre spip_geo_villes.

Apparemment le plugin Géographie est beaucoup plus complet, à part qu’il n’a pas les continents, contrairement à SPIP-Geo.

Bref.
Pourtant il me semble que Cédric et Quentin faisaient partis des gens qui collaboraient plutôt que de créer des doublons. :smiley:

Parles en à cerdic du pourquoi et du comment…

Bref je ne veux pas troller sur le sujet …

Q.

Le 18/08/2009 17:12, Quentin Drouet a écrit :

Parles en à cerdic du pourquoi et du comment...

Bref je ne veux pas troller sur le sujet ...

Ben moi je trolles jamais, c'est pas mon genre.
C'était une vrai question.

J'ai juste lu les deux plugins, et j'ai vu tellement peu de différences que je n'ai pas compris pourquoi ce n'était pas fusionné depuis longtemps...

--
RastaPopoulos

Le 18 août 09 à 17:12, Quentin Drouet a écrit :

Question conne : si j'ai besoin de données géographiques, je dois installer le plugin Géographie, ou le plugin SPIP-Geo ?

Ils utilisent en plus presque les mêmes tables, sauf que dans l'un c'est spip_geo_communes et l'autre spip_geo_villes.

Apparemment le plugin Géographie est beaucoup plus complet, à part qu'il n'a pas les continents, contrairement à SPIP-Geo.

Bref.
Pourtant il me semble que Cédric et Quentin faisaient partis des gens qui collaboraient plutôt que de créer des doublons. :smiley:

Parles en à cerdic du pourquoi et du comment...

Bref je ne veux pas troller sur le sujet ...

oué sur ce coup là c'est moi (ou presque :p) qui ait merdé.
J'avais repris tout le bordel de inscription2 (je crois), pour en faire un plugin propre sans voir que kent1 avait déjà fait pareil (mais sans mettre à jour inscription2 :p).
Comme entre temps j'avais développé une appli sur la base du mien, j'ai pas fusionné immédiatement, puis après j'ai oublié

Ma culpa donc
Cédric

Hello,

Moi j’avais compris à l’époque avec Cedric qu’il fallait utiliser Géographie maintenant. je me rappelle on en avait parlé par rapport à Rainette pour choisir les villes.

Donc je suggèrerais de partir de là

++
Eric

Le 18 août 2009 17:15, RastaPopoulos <vincent@ldd.fr> a écrit :

Le 18/08/2009 17:12, Quentin Drouet a écrit :

Parles en à cerdic du pourquoi et du comment…

Bref je ne veux pas troller sur le sujet …

Ben moi je trolles jamais, c’est pas mon genre.
C’était une vrai question.

J’ai juste lu les deux plugins, et j’ai vu tellement peu de différences que je n’ai pas compris pourquoi ce n’était pas fusionné depuis longtemps…


RastaPopoulos


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

cedric.morin@yterium.com a écrit :

Le 18 août 09 à 17:12, Quentin Drouet a écrit :

Question conne : si j'ai besoin de données géographiques, je dois installer le plugin Géographie, ou le plugin SPIP-Geo ?

Ils utilisent en plus presque les mêmes tables, sauf que dans l'un c'est spip_geo_communes et l'autre spip_geo_villes.

Apparemment le plugin Géographie est beaucoup plus complet, à part qu'il n'a pas les continents, contrairement à SPIP-Geo.

Bref.
Pourtant il me semble que Cédric et Quentin faisaient partis des gens qui collaboraient plutôt que de créer des doublons. :smiley:

Parles en à cerdic du pourquoi et du comment...

Bref je ne veux pas troller sur le sujet ...

oué sur ce coup là c'est moi (ou presque :p) qui ait merdé.
J'avais repris tout le bordel de inscription2 (je crois), pour en faire un plugin propre sans voir que kent1 avait déjà fait pareil (mais sans mettre à jour inscription2 :p).
Comme entre temps j'avais développé une appli sur la base du mien, j'ai pas fusionné immédiatement, puis après j'ai oublié

tiens ben j'en rajoute une couche : moi j'ai fait un plugin geoinsee (un plugin pour F&T qui permet de selectionner pays/region/departement/commune + EPCI et pays avec des listes synchronisées) en essayant d'avoir un maximum d'infos et en prenant le code geoinsee en identifiant (ce qui posait des pb car c'est une chaine, pas un nombre)

Est-ce qu'on ne pourrait pas avoir faire un plugin qui ne contienne que les tables et leurs données (avec les selecteurs peut etre) totalement indépendant de ce qu'on en fait ?

Je suis resté dans mon coin pour pas en remettre une couche sur la zone (j'avais quand meme posé la question ici si je me souviens bien, mais cette histoire de clé primaire etait bloquante), mais maintenant que les clés de type chaine posent moins de problemes (d'après ce que j'ai vu en spip2), c'est peut etre pas une mauvaise idée de s'appuyer sur le code geoInsee.
Ca a le gros avantage de pouvoir choisir indifféremment un département, une communauté de commune ou une commune et d'avoir toujours des coordonnées en face (celles de la commune "chef lieu") en ajoutant simplement un champ "geoInsee" aux objets qu'on veut localiser
L'autre avantage à mon sens, c'est que ces données sont récupérables sur leur site et donc plus simple à maintenir (car en fait, meme si ca bouge peu, ca bouge...)

Bref, si c'est envisageable d'utiliser le code geoInsee comme clé, je suis partant et j'ai deja pas mal de matière, meme si je n'ai intégré pour le moment les ECPI et pays que sur un departement (58).

@++

PS : l'autre truc qui m'a retenu de commiter, c'est que le fichier des communes fait plus de 2Mo...

2009/8/18 Stephane <stephane@rezo.net>

cedric.morin@yterium.com a écrit :

oué sur ce coup là c’est moi (ou presque :p) qui ait merdé.
J’avais repris tout le bordel de inscription2 (je crois), pour en faire un plugin propre sans voir que kent1 avait déjà fait pareil (mais sans mettre à jour inscription2 :p).

Avant cela inscription2 nécessitait avant tout une réécriture presque complète … :stuck_out_tongue:

Comme entre temps j’avais développé une appli sur la base du mien, j’ai pas fusionné immédiatement, puis après j’ai oublié

Je suis resté dans mon coin pour pas en remettre une couche sur la zone (j’avais quand meme posé la question ici si je me souviens bien, mais cette histoire de clé primaire etait bloquante), mais maintenant que les clés de type chaine posent moins de problemes (d’après ce que j’ai vu en spip2), c’est peut etre pas une mauvaise idée de s’appuyer sur le code geoInsee.
Ca a le gros avantage de pouvoir choisir indifféremment un département, une communauté de commune ou une commune et d’avoir toujours des coordonnées en face (celles de la commune « chef lieu ») en ajoutant simplement un champ « geoInsee » aux objets qu’on veut localiser
L’autre avantage à mon sens, c’est que ces données sont récupérables sur leur site et donc plus simple à maintenir (car en fait, meme si ca bouge peu, ca bouge…)

Oui mais ca reste franco français… après si vous faites des sites uniquement français c’est intéressant … mais si vous faites un peu plus de bornes il y a des normes que l’on s’est efforcé d’utiliser dans spip_geo

Bref, si c’est envisageable d’utiliser le code geoInsee comme clé, je suis partant et j’ai deja pas mal de matière, meme si je n’ai intégré pour le moment les ECPI et pays que sur un departement (58).

Tu bosses sur la Nièvre? cool tu es où?

@++

PS : l’autre truc qui m’a retenu de commiter, c’est que le fichier des communes fait plus de 2Mo…

C’était une contrainte que j’ai du prendre en compte puisque fil m’a gentiment fait remarquer à l’époque (à bon escient) que ce n’était pas le rôle de la zone pour cela…

Spip-geo avait vocation à l’époque à faire bien plus … qui était en cours … que l’arrivée de geographie a un peu atténué et donc enterré par la suite …

++

Quentin

Quentin Drouet a écrit :

2009/8/18 Stephane <stephane@rezo.net <mailto:stephane@rezo.net>>

    cedric.morin@yterium.com <mailto:cedric.morin@yterium.com> a écrit :

        oué sur ce coup là c'est moi (ou presque :p) qui ait merdé.
        J'avais repris tout le bordel de inscription2 (je crois), pour
        en faire un plugin propre sans voir que kent1 avait déjà fait
        pareil (mais sans mettre à jour inscription2 :p).

Avant cela inscription2 nécessitait avant tout une réécriture presque complète ... :stuck_out_tongue:

        Comme entre temps j'avais développé une appli sur la base du
        mien, j'ai pas fusionné immédiatement, puis après j'ai oublié

    Je suis resté dans mon coin pour pas en remettre une couche sur la
    zone (j'avais quand meme posé la question ici si je me souviens
    bien, mais cette histoire de clé primaire etait bloquante), mais
    maintenant que les clés de type chaine posent moins de problemes
    (d'après ce que j'ai vu en spip2), c'est peut etre pas une
    mauvaise idée de s'appuyer sur le code geoInsee.
    Ca a le gros avantage de pouvoir choisir indifféremment un
    département, une communauté de commune ou une commune et d'avoir
    toujours des coordonnées en face (celles de la commune "chef
    lieu") en ajoutant simplement un champ "geoInsee" aux objets qu'on
    veut localiser
    L'autre avantage à mon sens, c'est que ces données sont
    récupérables sur leur site et donc plus simple à maintenir (car en
    fait, meme si ca bouge peu, ca bouge...)

Oui mais ca reste franco français... après si vous faites des sites uniquement français c'est intéressant ... mais si vous faites un peu plus de bornes il y a des normes que l'on s'est efforcé d'utiliser dans spip_geo

tu parles des codes iso ?
je n'ai rien vu qui permette de faire l'equivalent etat/region/departement/commune au niveau mondial (normal, chacun a une organisation differente...)
Moi mon besoin, c'etait (et ca reste) d'avoir des selecteurs qui proposent chaque fois le niveau inferieur correspondant (les region du pays, les departements de la region...) en Ajax.
ceci dit, c'est juste une question de nombre de niveaux pour le faire marcher sur d'autres pays.
le principe, c'est juste d'avoir un "parent" et un "chef lieu"

Mais c'est quand meme bien un truc franco-francais qu'il me faut puisque je manipule aussi les EPCI (communautés de communes) et les pays (voynet) qui ne sont pas des sous ensembles des departements (certains sont à cheval...)
J'ai aussi une demande la pour gerer des "bassins d'emploi" et une autre pour des "zone d'influence".
bref, c'est peut etre un truc plus générique qu'il faudrait faire ?
je pense qu'un truc du genre continent => pays => territoire => commune serait générique, il faut juste prevoir que des territoires puissent etre des sous-ensembles d'autres territoires avec un id_parent.
Mais j'ai du mal à voir comment garder toute l'info que j'ai aujourd'hui et qui me permet de localiser des objets aussi bien sur des communes que sur des "territoires".

    Bref, si c'est envisageable d'utiliser le code geoInsee comme clé,
    je suis partant et j'ai deja pas mal de matière, meme si je n'ai
    intégré pour le moment les ECPI et pays que sur un departement (58).

Tu bosses sur la Nièvre? cool tu es où?

à Montpellier... mais j'ai un client la bas.

    @++

    PS : l'autre truc qui m'a retenu de commiter, c'est que le fichier
    des communes fait plus de 2Mo...

C'était une contrainte que j'ai du prendre en compte puisque _fil_ m'a gentiment fait remarquer à l'époque (à bon escient) que ce n'était pas le rôle de la zone pour cela...

c'est clair que ca ne necessite pas de suivi de version.
Mais bon, pour resoudre les problemes de charset à l'insertion (selon la config du SPIP), j'ai finalement mis des insertq pour chaque ville, alors toutes les communes à ce format, c'est surement plus de 10Mo
Et puis on a rarement besoin de toute la france, donc je pensais plutot faire un systeme qui installe les données au niveau commune/EPCI/Pays à la demande

Spip-geo avait vocation à l'époque à faire bien plus ... qui était en cours ... que l'arrivée de geographie a un peu atténué et donc enterré par la suite ...

quand j'avais regardé, je n'avais vu que continents/pays, du coup, j'ai fait au plus proche de geographie pour pouvoir echanger les données des communes.
Mais si tu connais une classification internationale, je suis preneur !

@++

RastaPopoulos a écrit :

Ya quand même pas tant de différences que ça pour empêcher la fusion non ?

"gogogo" !
("vavava")
JL

El Tuesday 18 August 2009 13:10:38 Stephane va escriure:

je n'ai rien vu qui permette de faire l'equivalent
etat/region/departement/commune au niveau mondial (normal, chacun a
une organisation differente...)
Moi mon besoin, c'etait (et ca reste) d'avoir des selecteurs qui
proposent chaque fois le niveau inferieur correspondant (les region
du pays, les departements de la region...) en Ajax.
ceci dit, c'est juste une question de nombre de niveaux pour le faire
marcher sur d'autres pays.
le principe, c'est juste d'avoir un "parent" et un "chef lieu"

Mais c'est quand meme bien un truc franco-francais qu'il me faut
puisque je manipule aussi les EPCI (communautés de communes) et les
pays (voynet) qui ne sont pas des sous ensembles des departements
(certains sont à cheval...)

C'est peut-être possible d'avoir dans une table les différentes divisions
existantes, avec une table de jointure pour les associer aux pays qui
les utilisent. Par exemple : département, région, pays, continent,
commune, état d'un pays (par exemple pas en france mais au mexique et
aux état-unis si), canton, pays-comme-le-voynet, etc.
Pour compléter ça, on pourrait avoir une jointure entre un type de
division et le type de division qui le compose. Par exemple une région
est faite de départements, et un pays-comme-le-voynet est fait de je
sais pas quoi, disons de communes. Ça permet d'éviter d'avoir une
hiérarchie de subdivisions unique. C'est un concept assez flexible pour
être adaptable dans tous les pays qui me viennent en tête (mais je me
réveille à peine). Ah, et la notion de ville principale d'une division,
qu'elle s'appelle capitale, chef-lieu, etc., mais voilà l'idée.

J'ai aussi une demande la pour gerer des "bassins d'emploi" et une
autre pour des "zone d'influence".

Je connais pas... Est-ce que ça peut être défini comme une nouvelle
division contenant certaines divisions d'un autre type ? (genre qu'une
zone d'influence soit une liste de villes).

bref, c'est peut etre un truc plus générique qu'il faudrait faire ?
je pense qu'un truc du genre continent => pays => territoire =>
commune serait générique, il faut juste prevoir que des territoires
puissent etre des sous-ensembles d'autres territoires avec un
id_parent.

Ah tiens c'est peut-être ça que tu voulais dire... (pardon je me
réveille), avec territoire = division.

Mais j'ai du mal à voir comment garder toute l'info que
j'ai aujourd'hui et qui me permet de localiser des objets aussi bien
sur des communes que sur des "territoires".

Si on associe un objet à un id de territoire, c'est générique, non ?
(dans ma tête une commune est un type de territoire au même titre qu'un
pays ou un département, elle n'est juste composée d'aucune subdivision)

J'espère que c'est clair ce que je raconte...

En tout cas je sais pas si c'est le lieu ici pour réfléchir à un modèle
générique pour uniformiser tout ça dans SPIP, mais je veux bien en être.

/me va prendre un café.

davux a écrit :

Ah tiens c'est peut-être ça que tu voulais dire... (pardon je me réveille), avec territoire = division.
  
oui c'est ca, sauf que je pensais garder continent, pays et commune et n'utiliser cette table unique que pour les intermediaires entre pas et commune
mais ca oblige effectivement à passer en relation n-n ce qui change carrement la donne au niveau de la manipulation des données.

Mais j'ai du mal à voir comment garder toute l'info que
j'ai aujourd'hui et qui me permet de localiser des objets aussi bien
sur des communes que sur des "territoires".
    
Si on associe un objet à un id de territoire, c'est générique, non ?
  
les id au sens autoincrement dans la base, c'est ce que je voulais eviter, mais il faut pour ca un identifiant (d'ou le code geoInsee pour moi)

(dans ma tête une commune est un type de territoire au même titre qu'un pays ou un département, elle n'est juste composée d'aucune subdivision)

J'espère que c'est clair ce que je raconte...
  
oui, on parle bien de la meme chose, mais ca pose en fait plus de probleme que ca en leve...
je me demande si ca ne serait pas plus simple de parametrer l'organisation par pays (en gros à dire quelle(s) table(s) intermediaire(s) exploiter en fonction du parent selectionné)

En tout cas je sais pas si c'est le lieu ici pour réfléchir à un modèle générique pour uniformiser tout ça dans SPIP, mais je veux bien en être.
  
le probleme c'est qu'on veut souvent faire 2 choses totalement differentes : géolocaliser et catégoriser
par exemple, dans mon utilisation, je veux faire remonter les objet attachés à une communauté de commune quand je selectionne filtre sur une commune, mais d'un autre coté, je vais utiliser les coordonnées du chef lieu (donc une commune) pour afficher.

Bref, le "générique", j'y crois moyennement sur la structure des données.
Par contre, avoir une couche de parametrage definissant la structure à utiliser pour chaque pays, ca me parait plus jouable, ou peut etre une convention de nommage permettant au systeme de trouver ses petits ?

/me va prendre un café.
  
ben moi je vais me coucher...
@++

Vous connaissez http://www.openstreetmap.org/ ?
Y a pas moyen de s’interfacer avec ou de récupérer quelque chose par là ?


damazone

damazone a écrit :

Vous connaissez http://www.openstreetmap.org/ ?

oui, une belle alternative à google, mais qui a encore besoin de pas mal de bras...

Y a pas moyen de s'interfacer avec ou de récupérer quelque chose par là ?

heu, non,la on parle de selecteurs (listbox) pour choisir son pays, puis sa region, puis son departement puis sa commune.
une fois selectionné, on a effectivement des coordonnées permettant de positionner sur une carte, mais c'est tout.

@++

Bonjour,

Le 19 août 09 à 00:36, davux a écrit :

El Tuesday 18 August 2009 13:10:38 Stephane va escriure:

je n'ai rien vu qui permette de faire l'equivalent
etat/region/departement/commune au niveau mondial (normal, chacun a
une organisation differente...)
Moi mon besoin, c'etait (et ca reste) d'avoir des selecteurs qui
proposent chaque fois le niveau inferieur correspondant (les region
du pays, les departements de la region...) en Ajax.
ceci dit, c'est juste une question de nombre de niveaux pour le faire
marcher sur d'autres pays.
le principe, c'est juste d'avoir un "parent" et un "chef lieu"

Mais c'est quand meme bien un truc franco-francais qu'il me faut
puisque je manipule aussi les EPCI (communautés de communes) et les
pays (voynet) qui ne sont pas des sous ensembles des departements
(certains sont à cheval...)

C'est peut-être possible d'avoir dans une table les différentes divisions
existantes, avec une table de jointure pour les associer aux pays qui
les utilisent. Par exemple : département, région, pays, continent,
commune, état d'un pays (par exemple pas en france mais au mexique et
aux état-unis si), canton, pays-comme-le-voynet, etc.
Pour compléter ça, on pourrait avoir une jointure entre un type de
division et le type de division qui le compose. Par exemple une région
est faite de départements, et un pays-comme-le-voynet est fait de je
sais pas quoi, disons de communes. Ça permet d'éviter d'avoir une
hiérarchie de subdivisions unique. C'est un concept assez flexible pour
être adaptable dans tous les pays qui me viennent en tête (mais je me
réveille à peine). Ah, et la notion de ville principale d'une division,
qu'elle s'appelle capitale, chef-lieu, etc., mais voilà l'idée.

J'ai aussi une demande la pour gerer des "bassins d'emploi" et une
autre pour des "zone d'influence".

Je connais pas... Est-ce que ça peut être défini comme une nouvelle
division contenant certaines divisions d'un autre type ? (genre qu'une
zone d'influence soit une liste de villes).

bref, c'est peut etre un truc plus générique qu'il faudrait faire ?
je pense qu'un truc du genre continent => pays => territoire =>
commune serait générique, il faut juste prevoir que des territoires
puissent etre des sous-ensembles d'autres territoires avec un
id_parent.

Ah tiens c'est peut-être ça que tu voulais dire... (pardon je me
réveille), avec territoire = division.

Mais j'ai du mal à voir comment garder toute l'info que
j'ai aujourd'hui et qui me permet de localiser des objets aussi bien
sur des communes que sur des "territoires".

Si on associe un objet à un id de territoire, c'est générique, non ?
(dans ma tête une commune est un type de territoire au même titre qu'un
pays ou un département, elle n'est juste composée d'aucune subdivision)

il y a aussi deux choses :

-- les intercommunalités et interrégionales transfrontières (COPIT Lille Tournai Kortrijk et leurs intercommunales), les trois frontières (avec Mulhouse), Thiérache (parties du Nord, de l'Aisne, du Hainaut et des Ardennes : deux pays, trois régions, trois départements, une province, tous incomplets)

-- les divisions communales : sections de communes aux droits différents (la loi tente de les évacuer petit à petit) en France ; Communes et entités en Belgique (grande fusion intercommunale en 1975 mais elles ont chacune leur numéro équivalent Insee) ; paroisses en Angleterre... bref, le plein d'exotisme administratif

-- sans compter les modifications communales (fusion et division de communes) mais qui n'intéressent que les historiens pour reconstituer des territoires (Atlas historiques) d'avant les codes Insee.

Bref, il n'y a pas vraiment d'unité commune de base si n'on ne prends déjà que l'Europe. Même pas l'État ! puisque la Suisse, c'est 26 États (en gros, et c'est pas fini de bouger). La seul tendance commune, c'est le regroupement mais des regroupements à façon qui ont tendance à ce chevaucher.

Cette discussion me fait penser à celles sur mettre un article dans plusieurs rubriques (un plugin propose un compromis) et sur les autorisations par groupes.

Claude

J'espère que c'est clair ce que je raconte...

En tout cas je sais pas si c'est le lieu ici pour réfléchir à un modèle
générique pour uniformiser tout ça dans SPIP, mais je veux bien en être.

/me va prendre un café.

Salut!

Je suis travaillant sur une web avec spip pour formation online ouvert, libre et participative et dans principes de connaissance libre (http://www.auladigitaldecgt.net). Mais, pour l'homologation de quelq'unes activitées il serait necessaire le suivi des élèves :frowning:

J'ai installé le bigbrother, merci, et l'activité du jour, merci, mais je vois qu'ils ne me sont utiles pas pour cela, sauf partialement.

Je crois que avec la balisse #SESSION et une table ou champ nouveau qui recuille le id_auteur connecté, les temps de conexion et les lieux accedus il sera possible ce suivement totalment (comme déjà on faite avec un trous de les statistiques de spip pour les visiteurs mais ajoutant le id_auteur connecté)

Il y a quelq'un personne travaillant dans cette chemin? Il y a quelq'un outil déjà prêt pour ce suivi?

Merci.

cedric.morin@yterium.com wrote:

Le 18 août 09 à 17:12, Quentin Drouet a écrit :

Comme entre temps j'avais développé une appli sur la base du mien, j'ai pas fusionné immédiatement, puis après j'ai oublié

Je me permets de te rapeller que tu as codé spip-bonux alors, des fois que tu l'oublies aussi :stuck_out_tongue:

BoOz

Le 19 août 09 à 13:43, BoOz a écrit :

cedric.morin@yterium.com wrote:

Le 18 août 09 à 17:12, Quentin Drouet a écrit :

Comme entre temps j'avais développé une appli sur la base du mien, j'ai pas fusionné immédiatement, puis après j'ai oublié

Je me permets de te rapeller que tu as codé spip-bonux alors, des fois que tu l'oublies aussi :stuck_out_tongue:

Ah mais y a pas de problème avec Bonux :
- il ne fait pas doublon avec autre chose
- l'intégration des boucles POUR et CONDITION dans le core n'est pas à l'ordre du jour

Donc tout va bien

Cédric

- l'intégration des boucles POUR et CONDITION dans le core n'est pas à
l'ordre du jour

Dommage car on en a vraiment besoin

-- Fil