[migration:reporté]fusion pages massifs et nav

[yip]

Désolé, pour les zones et les massifsnivo1, j'ai toujours pas tout compris

Donc

La contrainte c'est que si on veut lister de manière automatique ce que doit contenir le menu "massif" il faut créer autant de zones qu'il y a de secteur lointain couvert par wri (réunion, andes, etc.)

pas un problème je m'en occupe ! il y en a moins d'une dizaine .

Si j'ai tout compris, on garde qu'un seul type,
Et c'est donc le même type qui va servir:
-la page d'accueil (avec un $config[zonedefaut])
-une grosse page nav avec tous les massifs de la zone
-le menu Massifs (plutot "Regions" du coup)
-les listes de liens "Et Encore"
-l'appartenance des points
-Au juste dessus on aura rien sauf peut-etre "pays" ?
-Au juste dessous on aura "Massifs" voire departements ?

C'est bien ça ?
(yip croise les doigts )

On peut donc avoir une zone "alpes" (un rectangle) en plus d'un massif niveau 1 : alpes. (le polygone plus complet)

Snif je te suis plus, la pour le coup, l'interet je le vois plus.
pourquoi ne pas avoir un seul gros poly complet a la definition correcte ?
Si ca rame de trop, on avait envisagé une autre solution que dédoubler les types pour les polys.

Il suffit de centraliser dans une fonction ou un pdo->prepare() qui n'utilise qu'une seule requête avec une condition "$conditions->avec_geom=true;" en option qui activera la récupération de la géométrie

Bah tu me fais marcher, on laisse tomber ce truc, vu comme ca merdoie en plus ... faire et defaire c'est toujours travailler on remplacera en factorisant le PHP

[sly]

pas un problème je m'en occupe ! il y en a moins d'une dizaine .

Ok alors, on fait comme ça.

Pour le reste, tout juste, quelques commentaires.

-le menu Massifs (plutot "Regions" du coup)

Très bonne réflexion, ce menu qui se nomme "massif" n'a depuis bien longtemps plus aucun sens : "Corse, réunion" -> pas un massif "Alpes orientales, du nord, etc." -> idem.
"Régions" ça fait un peu penser aux régions françaises, "zone" ça fait trop général... heu... j'ai pas d'idée. Secteurs ? "zones de couvertures" ? "territoires" ? "truc bidule" ?

-Au juste dessus on aura rien sauf peut-etre "pays" ?
-Au juste dessous on aura "Massifs" voire departements ?

Pourquoi pas, mais alors dans un autre menu, histoire d'avoir 3 recherches transversales :
- la recherche pas caractéristiques des refuges (nom, place, poële)
- la recherche par "zones culturo-géologique" -> alpes, réunion, alpes du nord,
- la recherche par "frontières administratives" -> France/Italie/suisse + par régions ou départements (qu'on peut pour l'instant reporter à plus tard)

On peut donc avoir une zone "alpes" (un rectangle) en plus d'un massif niveau 1 : alpes. (le polygone plus complet)

Snif :| je te suis plus, la pour le coup, l'interet je le vois plus.
pourquoi ne pas avoir un seul gros poly complet a la definition correcte ?
Si ca rame de trop, on avait envisagé une autre solution que dédoubler les types pour les polys.

Ce que tu as en tête c'est : on vire "massif niveau 1" et on ne garde plus que des zones ?
Je n'arrive pas à trouver où ça va merder, mais je le sens. J'ai la sensation, mais je n'ai pas d'exemple, que ces deux "type" n'ont pas le même rôle qu'on veut leur faire jouer. "Alpes" et "Alpes du Nord" n'ont pas la même nature, et pourtant on va les mettre tout pareil au même endroit et on ne pourra plus les différencier.

Au pire, y'a pas mort de quoi que ce soit, on pourra toujours changer, go pour ça : on déplace tous les massifs niveau 1 dans "zone" et on vire le type "massif niveau 1"

Il suffit de centraliser dans une fonction ou un pdo->prepare() qui n'utilise qu'une seule requête avec une condition "$conditions->avec_geom=true;" en option qui activera la récupération de la géométrie

Bah tu me fais marcher, on laisse tomber ce truc, vu comme ca merdoie en plus ... faire et defaire c'est toujours travailler ;) on remplacera en factorisant le PHP ;)

En fait, je te charrie un peu mais pour une raison utile : je ne suis toujours pas convaincu d'avoir fait le bon choix et j'aimerais pouvoir tester les deux et qu'on s'en rendent compte à l'usage. Sauf que ce petit plaisir intellectuel de type : "Mmm j'aimerais bien savoir" peut nous coûter du temps au final ou au contraire nous en faire gagner. Mais je ne sais justement pas !

[yip]

"Alpes" et "Alpes du Nord"

c'est le seul cas que je vois.
c'est en pensant a ca que je disais '-Juste audessus il n'y aura que pays, en dessous massif.'
Alpes ca fait un intermediaire de trop. On en a pas d'autre. pas de pyrenees-ouest/est, cordillier nor/sud.

On peut le virer. et de ne garder que "alpesdu nord" et "alpes centrales" au meme niveau que "pyrenees" "massifcentral" ....

Ca ferait perdre la carte integrale des Alpes.

Une alternative est de le descendre au rang des massnivo1, ou le monter dans les pays.
Ca fait bizarre dans la cohérence et peut mettre la zone(!) en ayant des polys de meme niveau qui se chevauchent pour plus tard.
mais garder un type_polygon juste pour lui ...

Quant a garder une table, vaut mieux garder massifnivo1, elle est plus complète que "zone" ou il y a 3 polys qui se courrent après et redondent.

Bah je me prends la tete sur des broutilles en ce moment ...

[Claude Mauguier]

Pour les petits ensembles, c'est simple (Jura, Vosges, Réunion, Corse) et on n'a qu'une subdivision dans laquelle nagent les pictogrammes ; pour les "monstres" (Alpes, Pyrénées), je ne vois pas la nécessité d'intercaler un niveau "du nord", "de l"ouest", etc. entre le principal (par ex. Alpes) et les zones "massif" (Mt Blanc, Grisons,...). Ou alors, j'ai rien compris

[sly]

Quant a garder une table, vaut mieux garder massifnivo1, elle est plus complète que "zone" ou il y a 3 polys qui se courrent après et redondent.

Ok pas de problème.

Je m'en occupe, je fais le ménage, et je renomme le champs et change les ids

[yip]

Je m'en occupe, je fais le ménage, et je renomme le champs et change les ids

Ca marche nickel !

En l'absence d'"Alpes Nord" , on se codera donc en dur la page d'accueil, puisqu'elle ne correspond plus a aucune zone. Mais c'est plus clair comme ça.

J'ai refait un petit test OpenLayers où on voit la hiérarchie des massifs:
http://yip.refuges.info/nav3/ (code OL plus concis et propre)

ya des soucis, comme l'affichage lié au zoom et non pas a la densité des points (autrement plus compliqué), ca foire pour les zones exceptionnelles (andes/jura)

A ce propos , on pourrait découper le Jura en 2 ou 3 morceaux ?
J'ai découpé les vosges vite fait, ca colle ?

Autre souci, la gestion des polys intermediaires, il va falloir un bool "uniquement a la demande" sur les types de polygones.
Là c'est les cartes suisses qui viennent se mettrent au milieu. Bientot toutes les subdivisons administratives (si on les mets) feront pareil. va falloir un truc genre 'n'est pas affiché par defaut"

[sly]

A ce propos , on pourrait découper le Jura en 2 ou 3 morceaux ?

Tu parles de la zone, ou du massif ? Sinon oui, on peut toujours découper, mais il ne faut pas découper dans le but de nous arranger le code qui est bancal ;-)
Le code soit s'adapter au mieux, mais si on veut diviser le massif du jura car il y a une réalité locale qui pourrait lui donner plusieurs nom, évidement oui.

J'ai découpé les vosges vite fait, ca colle ?

Je ne connais pas les vosges, je ne me prononce pas...

Autre souci, la gestion des polys intermediaires, il va falloir un bool "uniquement a la demande" sur les types de polygones.
Là c'est les cartes suisses qui viennent se mettrent au milieu. Bientot toutes les subdivisons administratives (si on les mets) feront pareil. va falloir un truc genre 'n'est pas affiché par defaut"

Tiens tiens ;-) Y'a pas quelqu'un qui me disait "on va vampiriser l'intérêt des type_polygone ?" en rajoutant des tags dans la table des polygones ?
Mon avis reste la version simple pour l'instant : Seuls les massifs sont a afficher par défaut, tout le reste n'est que sur activation manuelle ou par un paramètre forcé dans l'url.

La vue : http://yip.refuges.info/nav3/ (vue monde) n'a selon moi pas besoin d'être actuellement, et les contours des zones n'ont pas besoin d'être affichés, les zones n'ont pour l'instant d'utilité que pour choisir le point de vue, seuls les massifs, cliquables sont utiles à afficher par défaut.

La vue "monde" étant en fait pris en charge par le menu "massif" que j'ai renommé en "zones couvertes" qui peut, dans une phase 1 être explicitement décrit dans le code du menu, un jour peut-être automatiquement généré.

Bref, ça sent un peu le coupage de cheveux en 4, dans mon idée, le choix du "quoi afficher par défaut ?" se fait ainsi :
Url d'accès : http://yip.refuges.info/nav/45/x/y/z
-> si 45 est une zone (type 11) => on ne charge que les polygone de type 1 (les "massifs")
-> si 45 n'est pas une zone => on charge les points et on affiche le contour de 45

Si Url d'accès : http://yip.refuges.info/nav/ (qui ne devrait pas arriver)
-> on prend une zone de notre choix. Alpes ?

Edit : Notez que j'ai re-ranger sur le forum les messages en rapport avec les polygones, le choix zone/massif et les questions de leur affichage

[sly]

Note que j'ai aussi progresser sur ma fonction d'import polygones d'openstreetmap, c'est bien plus tordu que je l'imaginais (je peine avec nos zones à n'importer que ceux qui nous intéresse et en évitant les doublons) mais ça fini par marcher.

J'ai importé une palanquée de ~220 réserves naturelles et autres parc nationaux sur les secteurs qui nous intéressent (hors cordillère) ce qui devrait te permettre d'avoir du grain à moudre pour tes tests.

Je vais ensuite m'attaquer à la section "limites administratives" ce qui devrait te donner une nouvelle palanquée de trucs et bidule afin de voir si ton système ne fait pas exploser tous les navigateurs du coin

[sly]

Voilà qui est fait pour les sélections des zones administratives (départements/régions/pays)

Ce qui donne ça en coté localisation de points : http://sly.refuges.info/point/3965/site ... ncroyable/

Comme vous pouvez voir, suite aux discussions de l'incohérence qui résulte à comparer des choux et des processeurs, j'ai opté (à voir si on garde) pour une "méta-catégorie" des types de polygones.

J'étais au passage en train de regarder la "tambouille" de dominique concernant le choix de fond de carte par défaut pour la vignette (que j'ai cassé suite à mes manips) et je vois que le choix était fait sur la base du pays auquel le point appartient pour déterminer si on utilise MRI, cycle map, google, suisstopo, etc.

Je peux re-coder ça (proprement ;-) ) afin d'éviter de parser les > d'une chaine de caractère vu que j'ai maintenant des fonctions pour déterminer facilement dans quel pays se trouve le point mais je me demande si on ne peut pas remonter d'un cran, et plutôt que de se baser sur le pays, se baser sur la zone de couverture carte (qu'on a pas encore en base)

Certes, IGN ne couvre que la france, suissetopo que la suisse, etc. mais pour MRI (encore que c'est la seule exception) ne couvre pas uniquement un pays, mais un rectangle arbitraire.

Question à deux balles : est-ce que je me prend trop la tête ? et ré-utilisons les pays ? ou faire une méthode adaptable (si un champs d'un polygone quelconque indique un fond de carte dispo : le prendre. Ou est-ce qu'on remet du google maps par défaut pour partout et on arrête de se prendre la tête ?*


* : nan je déconne

[yip]

Tu peux expliquer la meta-categorie de polys ? je suis perdu

On peut pas lier la map-source au types polys, le type massif n'a pas la meme carte en suisse qu'en france.

On peut la lier au poly lui meme. mais c'est lourdingue et redondant. chaque massif sa source => 40 massifs francais auront la meme source.

On peut la lier au poly de Pays comme l'a fait Dom, mais dans ce cas, il faut bien dire que les pays ne sont pas des polys comme les autres (bool, tout ça ...) pour qu'il ne soit pas affichés à tout va et serve uniquement a ce genre de chose.
Je dirais que le plus propre c'est comme Dominique l'a fait, avec les pays...

Tiens tiens Y'a pas quelqu'un qui me disait "on va vampiriser l'intérêt des type_polygone ?" en rajoutant des tags dans la table des polygones ?
Mon avis reste la version simple pour l'instant : Seuls les massifs sont a afficher par défaut, tout le reste n'est que sur activation manuelle ou par un paramètre forcé dans l'url.

... ce qui revient a dire que les massifs ne sont pas des polys comme les autres...
Ou sera donc la differenciation ? je la propose en bool, tu la proposes en code PHP/URL, mais elle est là
Je sais pas ou tu as lu que je voulais rajouter des tags dans la table polygone, c'est de type_poly dont il s'agit depuis le depart
L'"activation manuelle", ca veut dire aussi "inactif par defaut", autrement dit différencier les types de polys les uns des autres.

Je m'incline, on va continuer a l'analyser en URL cette difference, ça roule.

Faudrait voir comment on fait nav ? WFS ou pas ?

[sly]

Tu peux expliquer la meta-categorie de polys ? je suis perdu

voir table polygone_type :
j'ai ajouté un champs qui dit : ce type de polygone est-il administratif ou "culturo-montagnard"

Je dirais que le plus propre c'est comme Dominique l'a fait, avec les pays...

et à la main pour MRI, ça se tient. Ou est-ce qu'on stoque l'info quel pays => quelle carte utiliser ? (actuellement dans config.php je crois)

... ce qui revient a dire que les massifs ne sont pas des polys comme les autres...
Ou sera donc la differenciation ? je la propose en bool, tu la proposes en code PHP/URL, mais elle est là ;)

Tout à fait, actuellement, c'est stocké dans le config.php :
$config['id_massif']=1;
(vu qu'un seul type de polygone est concerné, mais ça peut se mettre dans un champs de la table : par_defaut=1)

Mon idée "en URL" c'est que si besoin on peut changer le par défaut, rien de plus.

Je sais pas ou tu as lu que je voulais rajouter des tags dans la table polygone, c'est de type_poly dont il s'agit depuis le depart ;)

Je me suis trompé en te répondant, j'avais bien compris que tu ne proposais pas de remplir tous les massifs d'un champ à 1 ;-)

La confusion peut venir qu'avant, j'avais en effet parlé d'un champ dans la table des polygones, car certains polygones pouvaient être des massif niveau 1 et des zones en même temps. Mais c'était l'embrouille, tu m'as convaincu ;-)
On verra à l'avenir si on veut différencier nos zones qui sont "arbitraires" de nos zones qui sont "réélles" style europe VS alpes, mais c'est pas pour aujourd'hui.

Je m'incline, on va continuer a l'analyser en URL cette difference, ça roule.
Faudrait voir comment on fait nav ? WFS ou pas ?

Notre discussion d'aujourd'hui et un résumé ont été envoyé à dominique pour l'avis de l'expert ;-)