[migration:résolu] nom colonne qui contient la géométrie

Message par **sly** » 16 févr. 2013, 18:27

pour yip :
J'ai vu que tu avais opté pour "gis" comme nom dans mysql, mais je ne trouve pas ça super explicite.

Je propose plutôt d'utiliser le nom "geometrie".

A priori on devrait donc, comme tu l'as fais, en avoir au total 3 :
- une pour la table points_gps qui sera de type POINT (il s'agit des coordonnées des points de la table points, déporté dans une autre table car il peut exister des points partageant la même position)
- une pour la table polygones de type MULTIPOLYGON (supportant les trous, multiples enveloppes disjointes)
- une pour la table osm_poi pour les points qui peuvent nous intéresser en provenance d'osm*

* Note pour cette dernière, je pense refaire ma procédure d'import complètement, ça ne vaut donc peut-être (et même sûrement) pas le coup de s'occuper de la migration de fonctions_osm.php et exportations_osm.php Du moins pas tant qu'on est pas passé directement à PG, ce qui devrait nous éviter une étape de migration

yip · Message par **yip** » 17 févr. 2013, 00:52

faut un truc court, trop galere a comprendre sinon, on a deja plein de terme a rallonge dont certains sont au pluriels d'autres au singulier, parfois avec raison, parfois non.
il y a meme 3 conjuguaisons differentes incohérentes dans le meme nom de variable

Au depart je l'avais fait moi aussi pour aider a la comprehension, et bien c'est ce qui m'embrouille le plus maintenant. Contre productif.
ca rends certaines fonctions dures à lire, effet inverse a celui souhaité.
geometrie ca me va. meme si je prefererai un truc plus court comme "geo"
... WHERE ST_Within( points_gps.geo , polygones.geo ) ... ca se comprends mieux que GIS c'est sur
et on reste sur le meme nom pour les 3 tables ? pour simplifier .
points_gps.geom polygones.geom osm_poi.geom
(par exemple pas de "points_gps.geometrie_points_gps" ou je deviens dingue)

sly a écrit : - une pour la table polygones de type MULTIPOLYGON (supportant les trous, multiples enveloppes disjointes)

un POLYGON supporte deja les trous (inner/outer rings)
c'est pour ca qu'il y a la double parenthese

Code : Tout sélectionner

POLYGON&#40; &#40;.....&#41;,&#40;.....&#41;,&#40;.....&#41; &#41;   poly, ring-internes, ring-externe &#40;ou l'inverse je sais plus&#41;

lors de mes essaie de MySQL GIS,j'ai fait exprès de modifier certains polygones pour leur boucher les trous. MySQL/GIS n'aurait pas su travailler avec de toute facon, mais PG si.
Lors des exports, si les objets sont simples, ca devrait bien rouler

* Note pour cette dernière, je pense refaire ma procédure d'import complètement

Ce serait vraiment cool. tu as vu les scripts "osm2pg" tout faits ?

Message par **sly** » 17 févr. 2013, 11:29

yip a écrit :faut un truc court, trop galere a comprendre sinon, on a deja plein de terme a rallonge dont certains sont au pluriels d'autres au singulier, parfois avec raison, parfois non.
il y a meme 3 conjuguaisons differentes incohérentes dans le meme nom de variable :cry:
Au depart je l'avais fait moi aussi pour aider a la comprehension, et bien c'est ce qui m'embrouille le plus maintenant. Contre productif.
ca rends certaines fonctions dures à lire, effet inverse a celui souhaité.

Le débat sur les "codings style" peut s'avérer long et chaque développeur aura son style, je ne sais pas si nous arriverons à mettre tout le monde d'accord ;-)
Ce style étant d'ailleurs sans doute lié à l'éditeur qui est utilisé.
Les variables, les noms de champs bdd et nom de fonctions "longs", comme j'ai très souvent fait sur wri sont liées à ma perception. Historiquement, tu avais plutôt choisi des noms courts et j'avais opté pour tout transformer car je préfère qu'un nom soit le plus explicite par lui même afin de réduire le nombre de commentaires. Mais si ton éditeur de code t'oblige à retaper intégralement à la main le nom de la variable, bien sûr, c'est contre-productif, le mien me propose une complétion automatique, c'est pour ça que grace à ce gain de temps, j'en profite pour devenir explicite, exemple :

Code : Tout sélectionner

presentation_infos_point_court&#40;$point&#41;

C'est sûr, c'est long, mais si j'écris juste "pres" le nom de la fonction sera proposé, c'est donc rapide pour moi, et en voyant son nom, je sais rapidement de quoi il s'agit : présenter donc hml, les infos d'un point, en version courte ;-)

J'aurais pû la nommer pipc($point) mais v'la la galère pour se souvenir !

En ce qui concerne la logique de "conjugaison" des champs, variable, fonctions, je n'ai pas encore tout migré depuis ce qui était avant, c'est long et fastidieux, c'est pour ça, plus des erreurs possibles, que l'on trouve des incohérences.
L'idée que j'ai suivi est celle-ci (mais pas toujours appliquée):
infos_point() -> renvoi les informations d'un seul point
infos_points() -> de plusieurs points
$point -> un pseudo-objet (sans méthode en fait) contenant un seul point
$points-> un pseudo-objet contenant plusieurs objets $point

Pour les tables sql :
Les champs d'une table seront les champs de l'objet qui seront les champs des formulaires web (tout rendre homogène afin de manipuler, de manière code->tables et tables->code de manière automatique)

Une table "points" sera au plurielle car elle en contient plusieurs, elle aura un id_point au singulier, car c'est l'id, d'un seul point, de la table points.

geometrie ca me va. meme si je prefererai un truc plus court comme "geo"
... WHERE ST_Within( points_gps.geo , polygones.geo ) ... ca se comprends mieux que GIS c'est sur
et on reste sur le meme nom pour les 3 tables ? pour simplifier .
points_gps.geom polygones.geom osm_poi.geom
(par exemple pas de "points_gps.geometrie_points_gps" ou je deviens dingue)

Si vraiment on veut gagner des lettres (tu ne dois pas avoir de complétion toi ;-) ) va pour "geom"

La question d'expliciter, en SQL, les champs (l'exemple du id_point au lieu de id partout) c'est de permettre des requêtes en appelant les champs de manière non absolu :
plutôt que :
select points.id,points_gps.id from points,points_gps where points.id=points_gps.id and geometrie && geometrie_points.geometrie;
on aurait :
select id_point,id_points_gps from points,points_gps where id_points=id_points_gps and geometrie_points_gps && geometrie_points;

Comme ça, à première vue, à part 2 caractères de plus, ça revient plus ou moins au même, mais lorsque l'on récupère ça avec php, ça devient une autre histoire, sur ces 2 requêtes, si j'opte pour :
$point=mysql_fetch_object(execute($query));

Alors $point->id est indéterminé (de quelle table s'agit-t-il ?) pour la requête 1
alors que dans 2, j'obtiens $point->id_point et $point->id_point_gps

Si j'ai loupé quelque chose, je veux bien changer de méthode, mais je crois que c'est pour ça que j'ai opté pour des champs tous explicites.

sly a écrit : - une pour la table polygones de type MULTIPOLYGON (supportant les trous, multiples enveloppes disjointes)
un POLYGON supporte deja les trous (inner/outer rings)

Yes, mais on peut aussi avoir des vrais multipolygon (deux enveloppes, comme par exemple la corse qui est aussi la france), donc autant choisir MULTIPOLYGON qui marchera de manière identique que ça soit un polygone simple ou un vrai multi

* Note pour cette dernière, je pense refaire ma procédure d'import complètement

Ce serait vraiment cool. tu as vu les scripts "osm2pg" tout faits ?
[/quote]
Il n'y aura de toute façon pas de scripts "osm2wri" tout faits, on sera toujours obligé d'adapter un peu à notre sauce pour faire un savant mélange des polygones que l'on peut récupérer d'osm et ceux qu'on doit gérer en interne (massifs alpins et vallées pyrénéennes).
Mais je connais des outils pour nous mâcher une bonne partie du travail.
Mes travaux sont ici :
https://github.com/sletuffe/www.refuges ... nstreetmap
Les tables sont déjà dispo sous le nom osm_polygones et osm_points

yip · Message par **yip** » 18 févr. 2013, 00:08

Pour prolonger le debat idéologique

Banco pour les nom longs.

sly a écrit : La question d'expliciter, en SQL, les champs (l'exemple du id_point au lieu de id partout) c'est de permettre des requêtes en appelant les champs de manière non absolu :
plutôt que :
select points.id,points_gps.id from points,points_gps where points.id=points_gps.id and geometrie && geometrie_points.geometrie;
on aurait :
select id_point,id_points_gps from points,points_gps where id_points=id_points_gps and geometrie_points_gps && geometrie_points;

Comme ça, à première vue, à part 2 caractères de plus, ça revient plus ou moins au même, mais lorsque l'on récupère ça avec php, ça devient une autre histoire, sur ces 2

ca va a l'encontre de ma thèse (que j'abandonne) mais
expliciter les champs permets aussi le NATURAL JOIN (j'en ai mis remplacé plein dans le code) ca revient à

Code : Tout sélectionner

SELECT id_point,id_points_gps
 FROM points NATURAL JOIN points_gps
 WHEREgeometrie_points_gps && geometrie_points;

il est possible uniquement parce qu'on a ce genre nommage. mais etait jamais utilisé ? je rassure tout de suite, c'est SQL ANSI

et le code SQL en majuscule ? c'est mieux ou pas ?

sly a écrit :
yip a écrit : un POLYGON supporte deja les trous (inner/outer rings)
Yes, mais on peut aussi avoir des vrais multipolygon (deux enveloppes, comme par exemple la corse qui est aussi la france)

Nous, on va les gerer ?
si on va trop la dedans, la carte de france inclut les antilles et les kerguelen, et a l'affichage j'imagines pas le mega cas particulier a gerer quand il va calculer la BBOX du Polygon...
chez OSM comment ils font , ils s'arretent au premier poly en fonction du besoin ?

Message par **sly** » 18 févr. 2013, 00:49

ca va a l'encontre de ma thèse (que j'abandonne) mais
expliciter les champs permets aussi le NATURAL JOIN (j'en ai mis remplacé plein dans le code) ca revient à
Code : Tout sélectionner
SELECT id_point,id_points_gps
 FROM points NATURAL JOIN points_gps
 WHEREgeometrie_points_gps && geometrie_points;
il est possible uniquement parce qu'on a ce genre nommage. mais etait jamais utilisé ? je rassure tout de suite, c'est SQL ANSI

N'était jamais utilisé ? Alors je pense que tu ne connais pas ce que j'ai utilisé en permanence dans mon code : les IMPLICIT JOIN ;-)
Les "JOIN" sont la base des sgbdR (R= relationnel) donc, bien sûr, j'en ai utilisé en masse !

Ce qu'on appel les "jointures implicites" se sont des jointures, comme celles en INNER JOIN mais qu'on déclenchent par une condition, ta requête, par exemple, devient :

Code : Tout sélectionner

 SELECT id_point,id_points_gps
 FROM points,points_gps
 WHERE geometrie_points_gps && geometrie_points;

ce qui revient exactement au même, tant au niveau du résultat, que du planificateur de requête de PG

Le JOIN (ici une jointure particulière car spatiale) est implicitement donné par ton where, sur les deux tables indiquées après le from.

Une forme relationnelle de la jointure implicite est celle-ci :

Code : Tout sélectionner

 SELECT count&#40;*&#41;
 FROM points,commentaires
 WHERE commentaires.id_point=points.id_point 
 AND points.id_point=7

et le code SQL en majuscule ? c'est mieux ou pas ?

Aucun avis technique, je peux juste dire que ma touche "caps lock" est trop à gauche ;-) Mais j'admets que ça aide à la lisibilité, bien que mettre des sauts de lignes rendent la chose encore plus lisible (Il semblerait qu'avant je mettais en majuscules, mais franchement, je ferais l'effort de faire l'un ou l'autre si on est d'accord pour un format, ça ne me changera pas la vie)

yip a écrit : Nous, on va les gerer ?
si on va trop la dedans, la carte de france inclut les antilles et les kerguelen, et a l'affichage j'imagines pas le mega cas particulier a gerer quand il va calculer la BBOX du Polygon...
chez OSM comment ils font , ils s'arretent au premier poly en fonction du besoin ?

Je pense qu'on ne va pas s'en soucier pour l'importation. La procédure d'import osm que j'utilise s'occupe de tout. Pour les calculs d'appartenances, postGIS fera aussi tout pour nous. Par contre, pour les exports vers OL, là, je suis moins sûr, mais je suppose fortement que le support WKB de OL devrait faire ça les doigts dans le nez.

yip · Message par **yip** » 18 févr. 2013, 22:33

Merci pour le SQL, je connaissais pas les implicit !

sly a écrit : Je pense qu'on ne va pas s'en soucier pour l'importation. La procédure d'import osm que j'utilise s'occupe de tout. Pour les calculs d'appartenances, postGIS fera aussi tout pour nous.

J'en doute pas, les polygons seront exacts et les calculs justes, mais ils vont bosser, mettons, avec la MBR, des fois, pour l'affichage en particulier
et la MBR de la france, légalement, c'est le monde entier...
a moins de considérer que st pierre et miquelon n'est pas la france.
Ca a quelques conséquence avec Openlayer, les autoextend et autolimit bbox qu'il serait dommage de ne pas utiliser
Enfin suffit de le savoir.

sly a écrit : Par contre, pour les exports vers OL, là, je suis moins sûr, mais je suppose fortement que le support WKB de OL devrait faire ça les doigts dans le nez.

En effet , les doigts dans le nez
Le (E)WKB c'est pas la panacée, pas assez d'infos véhiculées.si on bosse en WKB, j'ai peur qu'on doivent encore se faire des couches d'interfacage.

Ce que vous avez montés en GML/SLD c'est vachement mieux !

Les exports vers OL c'est de la bombe de balle en WFS (donc en GML dessous), c'est vraiment fait pour et encore plus simple que ce que je pensais.
Le protocole permet des fonctionnalités nickel, en particulier les Filter, qui exploités correctement, simpliefierait du code de partout.
OpenLayers travaille en WFS avec une grande facilité.
En plus Dominique est un expert OL !
WFS est fait pour supporter les requetes tordues qu'on peut avoir. je suis complétement emballé

Message par **sly** » 19 févr. 2013, 09:53

la partie OL, je ne maitrise pas du tout, j'avançe coté serveur, il y a tellement d'options possibles que je ne m'inquiète pas trop. Tant qu'on a les géométries proprement dans postgis je ne suis pas inquièt.

Message par **Dominique** » 19 févr. 2013, 15:04

yip a écrit :
sly a écrit : Par contre, pour les exports vers OL, là, je suis moins sûr, mais je suppose fortement que le support WKB de OL devrait faire ça les doigts dans le nez.
En effet , les doigts dans le nez
Le (E)WKB c'est pas la panacée, pas assez d'infos véhiculées.si on bosse en WKB, j'ai peur qu'on doivent encore se faire des couches d'interfacage.

Ce que vous avez montés en GML/SLD c'est vachement mieux !

Les exports vers OL c'est de la bombe de balle en WFS (donc en GML dessous), c'est vraiment fait pour et encore plus simple que ce que je pensais.
Le protocole permet des fonctionnalités nickel, en particulier les Filter, qui exploités correctement, simpliefierait du code de partout.
OpenLayers travaille en WFS avec une grande facilité.
En plus Dominique est un expert OL !
WFS est fait pour supporter les requetes tordues qu'on peut avoir. je suis complétement emballé

On peut faire beaucoup de choses avec OL,
mais ce serait sympa si on gardait GML/SLD (emballé ou pas dans un WFS)
la séparation donnée / style est assez sympa (et trés puissante)

yip · Message par **yip** » 21 févr. 2013, 22:42

Dominique a écrit : On peut faire beaucoup de choses avec OL,
mais ce serait sympa si on gardait GML/SLD (emballé ou pas dans un WFS)
la séparation donnée / style est assez sympa (et trés puissante)

Ca change pas grand chose de ce coté là: le WFS fait transiter du GML, puis a coté OL se charge sa feuille SLD, je suppose que ca revient au meme ? Tu as déja créé une feuille SLD qui a l'air de s'appliquer a peu près pareil au WFS ....

La version d'OL maison, tu l'a modifié pour la gestion améliorée du SLD notamment ?

J'ai fait quelques essais avec OL et WFS, en insistant sur les notions de filtres (spatial) en OL/WFS, c'est interessant, mais faut maitriser le javascript dediou !

http://yip.refuges.info/nav2/(idpolygone)
(C'est sur la release officielle d'OL, mais juste pour tester, pas intégré au git vu que ca va surement changer)
L'objectif que je visais etait de se libérer des taches de protocoles (comme ecrire du GML a la mano)
Ca a l'air bien rapide, malgré le code objet JS fait avec mes pieds.
il y a un peu de doc dans GIS.

Il faudra que tu nous présentes OpenLayers un jour Dominique

Message par **sly** » 22 févr. 2013, 00:30

yip a écrit : http://yip.refuges.info/nav2/(idpolygone)

Chouet, ça à l'air pas mal du tout ton truc !
Doit y avoir encore quelques choix de réglage sur comment ça doit se comporter par défaut au niveau des cases à gauche, mais le principe me semble pas mal.

yip a écrit : (...)pas intégré au git vu que ca va surement changer

Sachant que c'est un test, ça se comprend, mais je crois que tu as dû corriger d'autres trucs dans ta version car, par exemple : le menu de recherche se rempli bien avec les massifs mais pas sur ma version (et j'aimerais debuger un peu la recherche pour voir si ça se passe bien).

(si tu n'as fais que ajouter des dossiers ou fichiers, normalement un "git pull ; git merge ; git push" devrait faire l'affaire pour ne valider tes changements que aux fichiers existants sans rajouter ceux que que tu veux garder de coté)

il y a un peu de doc dans GIS.

Heu, aïe, j'ai déplacé aujourd'hui le dossier GIS dans /ressources pour mieux le ranger. (ressources ces les documents, les méthodes, les procédures, les docs, les données annexes liées à refuges.info)

yip · Message par **yip** » 22 févr. 2013, 09:29

sly a écrit : Chouet, ça à l'air pas mal du tout ton truc !
Doit y avoir encore quelques choix de réglage sur comment ça doit se comporter par défaut au niveau des cases à gauche, mais le principe me semble pas mal.

Merci ! ça merdouille pas mal pourtant.
Le comportement par defaut, tu sais comment je le vois, par une espèce de pondération des type....
D'ailleurs j'ai modifié les valeurs des colonne "ordre" des tables points_type et poly_type. ça ne change rien à l'ordre de tri, mais on peut se servir des écarts entre valeurs pour le comportement par defaut (pas fait encore).

Concernant le principe, c'est que du Javascript ... J'ai la plus grande admiration pour Dominique

sly a écrit : Sachant que c'est un test, ça se comprend, mais je crois que tu as dû corriger d'autres trucs dans ta version car, par exemple : le menu de recherche se rempli bien avec les massifs mais pas sur ma version (et j'aimerais debuger un peu la recherche pour voir si ça se passe bien).

euh, j'ai oublié, c'est indépendant ..c'etait du temps de MySQL .. de toute facon ca aurait du etre remonté par git ...j'ai pas créé de fichier pour ça.
a un moment, meme les resultats marchaient, mais il y a eu une embrouille de git qui m'a effacé plein de modifs et j'ai peut etre pas tout récupéré.

Message par **sly** » 22 févr. 2013, 11:49

yip a écrit : Merci ! ça merdouille pas mal pourtant.
Le comportement par defaut, tu sais comment je le vois, par une espèce de pondération des type....

J'avais compris l'idée. Il faut juste trouver le moyen de ne pas trop en afficher(si je vais sur "europe" afficher tous les polygones jusqu'au commune, ça va pas forcément le faire. Peut-être une version "light" pour commencer ou on afficherait que les massifs quoi qu'il arrive (les massifs de type belledonne)
et ultérieurement, on tentera des trucs plus sioux.
En gros, retrouver dans une phase 1 le comportement qu'on avait avant :
http://www.refuges.info/massifs.php

D'ailleurs j'ai modifié les valeurs des colonne "ordre" des tables points_type et poly_type. ça ne change rien à l'ordre de tri, mais on peut se servir des écarts entre valeurs pour le comportement par defaut (pas fait encore).

Oulla, mesurer l'écart c'est un truc que je sens pas trop, déjà que cette histoire d'ordre, je n'ai jamais été fan (j'avais fais comme ça faute de mieux) mais si en plus l'écart commence à avoir un sens, je sais pas trop comment ça va se gérer si on veut étendre le principe !

Autre option dont je ne mesure pas la difficulté : on passe d'abord une marche = migrer à PG avec les fonctionnalités d'aujourd'hui et on garde l'évolution de la fusion massif/nav pour juste après.

euh, j'ai oublié, c'est indépendant ..c'etait du temps de MySQL .. de toute facon ca aurait du etre remonté par git ...j'ai pas créé de fichier pour ça.
a un moment, meme les resultats marchaient, mais il y a eu une embrouille de git qui m'a effacé plein de modifs et j'ai peut etre pas tout récupéré.

En tout cas, visiblement tu as mis la correction sur github hier soir, je me suis re-synchronisé et hop !
La recherche par massif marche direct sans rien faire dans ma version.
Super ! La recherche de bugs continue...

yip · Message par **yip** » 22 févr. 2013, 14:47

Le truc de test OL c'est du bazar, mais je préfère pas m'avancer avant de savoir si ça a un avenir et comment va être gérée la hiérarchie entre géométries (et d'avoir l'avis de Dominique !)
Actuellement, on a pas de probleme car on a 0 niveaux de zoom vectoriels par carte(le type d'objet affiché est figé en dur).
Le 2e niveau de zoom, on se le fabrique en changeant complètement de page.

sly a écrit :J'avais compris l'idée. Il faut juste trouver le moyen de ne pas trop en afficher(si je vais sur "europe" afficher tous les polygones jusqu'au commune, ça va pas forcément le faire.

faut donc lier les géométries entre elles, d'une facon ou d'une autre

sly a écrit : Oulla, mesurer l'écart c'est un truc que je sens pas trop, déjà que cette histoire d'ordre, je n'ai jamais été fan (j'avais fais comme ça faute de mieux) mais si en plus l'écart commence à avoir un sens, je sais pas trop comment ça va se gérer si on veut étendre le principe !

Ca facilite grandement si on etends le principe.
Mettons, Les couches de poly sont éspacées de 100 a peu près.
Mettons, tu affiches tout ce qui est ton poly actuel avec un ecart <= 100.
Ca te prends donc directement la ( ou les )couche du dessous.
et c'est valable a tous les niveaux, des points aux pays.
Pour rajouter un type de poly, tu l'intercale avec l'ordre souhaité et il s'affichera quand on veut.

Il va de toute façon falloir qu'on reflechisse a un moyen de lier les affichages.

Une autre solution serait de se faire un tableau dans un coin, avec pour chaque poly, les geometries(points et polys) a afficher en face par defaut.
ca a l'avantage de pouvoir faire des trous dans la hiérarchie.
Ou alors rajouter un champs dans la table type_poly avec une liste de types a afficher par defaut ce qui est pareil.

Une version plus propre serait de définir un range de zoomlevels a chaque type_de_geometrie, et laisser OpenLayers se démerder ensuite.
ça me parait pas mal aussi. peut etre le plus "standard".

sly a écrit : Autre option dont je ne mesure pas la difficulté : on passe d'abord une marche = migrer à PG avec les fonctionnalités d'aujourd'hui et on garde l'évolution de la fusion massif/nav pour juste après.

Ca fait porter un peu de code en double mais bon tu as raison c'est le plus raisonnable.

Message par **sly** » 22 févr. 2013, 15:24

yip a écrit :Le truc de test OL c'est du bazar, mais je préfère pas m'avancer avant de savoir si ça a un avenir et comment va être gérée la hiérarchie entre géométries (et d'avoir l'avis de Dominique !)

Je crois qu'il faut revenir à la question initiale qui est "mais pour quoi faire des hiérarchies ?"
L'idée en démo sur ton nav2 me semble pas mal : des cases à cocher : celui qui veut voir les réserves, il cliquera, celui qui veut voir les départements il cliquera. Donc pourquoi hiérarchiser ?
- Pour le choix de l'affichage "par défaut" ? : je propose une version simple : on affiche juste les massifs lorsque l'on accès par /nav2/4 (quand 4 est de type "zone"), affichage des points seulement le reste du temps (en clair, comme on est déjà, avec les cases à cocher pour celui qui veut voir autre chose)
- Pour afficher "Localisation: France > Alpes > Haute Savoie > Bauges" sur les fiches des points... bon, là ok, un ordre semble nécessaire. Encore que, peut-être qu'on peut juste ordonner par l'aire. Après tout, il n'y a pas de logique à dire que Haute savoie est avant ou après bauges si ce n'est l'histoire de taille.
- Pour faire évoluer la recherche ? qu'on puisse d'abord demander à l'internaute "Quelle zone" ensuite "quel massif". Un ordre simple comme il existe suffit aussi.

Actuellement, on a pas de probleme car on a 0 niveaux de zoom vectoriels par carte(le type d'objet affiché est figé en dur).
Le 2e niveau de zoom, on se le fabrique en changeant complètement de page.

En effet, et ça me semble suffisant pour l'instant, peut-être qu'on peut continuer comme ça (je reviens en arrière sur mon idée d'afficher ce qu'on veut comme on veut de manière automatique) : Ton système de case à cocher me semble très bien pour ce besoin, on ne peut pas vraiment prétendre savoir ce que l'internaute voudra afficher. Donc notre seule règle devient :
- Si zone alors on affiche les massifs par défaut et on ne coche pas les cases des points (je lance un autre message pour se questionner sur le sens que wri donne aux "massifs")
- Si n'importe quoi d'autre, on ne coche aucun polygones et on affiche tous les points

En clair, comme cela existe déjà, mais avec la même interface commune qui permet ensuite à l'internaute de faire ses choix.

Une version plus propre serait de définir un range de zoomlevels a chaque type_de_geometrie, et laisser OpenLayers se démerder ensuite.
ça me parait pas mal aussi. peut etre le plus "standard".

Pour se prémunir contre un usage "n'importe quoi" genre : le mec il dézoom pour voir la terre et il coche tout les polygones, le système lui répond : "bien trop de truc à afficher, merci de zoomer" (en se basant arbitrairement sur par exemple : 50 polygones et 150 points max)

yip · Message par **yip** » 22 févr. 2013, 16:13

sly a écrit : Pour se prémunir contre un usage "n'importe quoi" genre : le mec il dézoom pour voir la terre et il coche tout les polygones, le système lui répond : "bien trop de truc à afficher, merci de zoomer" (en se basant arbitrairement sur par exemple : 50 polygones et 150 points max)

Presque, il pourrait meme pas envoyer sa requete.
avec OL la case "Refuge" se griserait au dela d'un certain éloignement.
Comme la case "Pays" se griserait quand on navigue sur les massifs.
C'est clair pour l'utilisateur qui va comprendre tout de suite en voyant des trucs se griser au fur qu'il dezoome.
OL a les outils pour permettre de coder ces trucs, on peut aussi faire un stade intermediaire, ou la case est décochée d'office, mais pas grisée. Où il peut encore envoyer des requêtes inhabituelles mais pas complètement aberrantes.

Ca pourrait le faire comme ça ? le tri-state coché/décoché/grisé en fonction du zoom ?

On peut en effet cumuler une limitation par zoomlevel, avec une limitation par nombre d'elements, il me semble que le protocole gère ça .