sly a écrit :Je pensais aux deux qui existe déjà :
un poly peut tout faire c'est vrai. tiens une question, chez OSM, comment vous gerez le cas de Paris a la fois departement et ville ? 2 polys redondants ou 1 seul poly avec des analyses d'URL ?
C'est la meme chose ici, je verrai les choses comme pour paris, c'est un cas particulier,
ce n'est pas le cas qui a décidé à la découpe du territoire métropolitain. En toute logique,
pour éviter l'usine a gaz, ils ont du créer 2 polys ? en tout cas c'est ce que je ferai perso, et ainsi ne pas avoir de cas particulier.
Chez nous, le cas de la Reunion est comparable. Massif zone et departement a la fois, combien de poly ?
Pour les pyrenes ca fait bizarre de le traiter comme un massif, quand on voit que le Taillefer est un massif a part entiere ...
Je dirais qu'on est en plein dans le cas particulier, ou du moins la
demande marginale. Si elle etait pas si marginale que ça , c'est qu'on a merdé en faisant des sous-massifs. l'un ou l'autre.
Mais je voulais surtout ton avis sur la facon dons les 2 hiérarchies géo et administratives cohabitent.
Je rejoins un peu Claude, les 2 découpages ont été fait par des personnes differentes, d'un coté l'
Etat qui se fout de la montagne comme de la Commune de Paris, et d'un autre coté les
Montagnards qui se foutent des frontières. en gros.
Techniquement, je sais que ca se gere en GIS. mais
Conceptuellement, comment tu le vois ?
sly a écrit :
J'ai aussi en tête une fonctionnalité que je cherche à réaliser, mais ça sera pour plus tard, mais sans doute que ça peut aussi se grouper : faire en sorte qu'une recherche puisse donner un résultat sur carte en plus du listing classique
Avec WFS et OL, c'est les doigts dans le nez. c'est meme plus facile avec carte que sans. C'est le listing qui devient plus difficile . lol
sly a écrit :
Des fois on va soit en afficher trop, soit pas ceux qu'on veut
C'est vrai, ça peut etre aussi synonyme de merdooillage dans le schema ou dans les découpage.
sly a écrit :
Pour les bauges, on pourrait vouloir les points, ce qui est aujourd'hui, mais aussi, par exemple, les réserves naturelles qui y sont contenues.
Lis ce que j'ai écris hier. J'ai écrit exactement cela. (sauf que au lieu des bauges c'etait le queyras
c'est vrai que les posts sont longs...)
en ayant un écart de pondération faible entre les data Refuges et les data Reserve, c'est faisable avec un code 100% générique.
Je pense que ce n'est pas seulement avec de la flexibilité qu'on arrive a ce genre de résultat, mais aussi avec un schema bien réfléchi et bien lié.
(Tu m'aurais dis afficher les reserves sur une eventuelle carte du monde, j'aurais été con
)
C'est ce dont on discute depuis le debut, de definir le type d'affichage dans l'URL. de fusionner les pages et differencier l'URL.
La on est d'accord et Dominique aussi.
allez un petit retour à l'idéologie:
mais dans ce cas la , il y a 2 données qu'on gère pour rien:
- le type du polygone
- la hiérarchie des data (colonne ordre)
En exagérant, Tout le super boulot que tu a fait avec la BDDentre les tables, la reflexion qui y a conduit, pour avoir aujourd'hui un site qui roule bien, tout ca pour passer des liens entre clefs SQL en URL
351?type_polygones=4&points=non
C'est la que les opinions divergent, moi je baserai tout le code sur ces 2 données là justement... type et hiérarchie
Et en effet, pour moi et en faisant rapide, si notre offre colle pas a la demande => tant pis ... (
ou une poignée de checkboxes pour corriger le tir en accessoires)
Ce qui est important, c'est que ca corresponde
presque toujours a la demande.
exemple Sur une carte de france de Google map, on voit pas les departementales, les concepteurs ont fait le choix que non.
je comprends que certains voudraient que ce soit possible, il y a des cas très particulier ou ce serait utile.
mais non. il y a peut etre moyen de trafiquer l'URL, j'ai jamais essayé,
mais le cas général a primé sur le cas particulier, sans que l'utilisateur en soit particulièrement traumatisé.
Ce que je veux dire, c'est que si on lie les type de données les uns aux autres, on les lies toutes entre elles, points et polys, on les pondère toutes, et il suffit d'en
tirer 1 pour avoir sans rien faire ses voisins grace au miracle du SQL, qui seront forcément pertinents, puisqu'ils sont voisins. que ce soit des poly ou des points, ce sera pertinent. c'est un peu le debut de ce qui est codé dans
Ordre des polys et des points, et
c'est cool.
Au résultat, on arriverait surement a la meme chose puisque je suis
daccord avec toi de conserver une possibilité de demandes exceptionnelles.
mais on le prends pas par le meme bout.
Une bonne nouvelle: de la flexibilité, WFS ça en est farçi (et bizarrement c'est ce qui m'embete en ce moment
)
Je parie 10 kopecks qu'on a perdu Claude !
