yip a écrit :
- soit on projette de mettre en avant cette "feature" a l'avenir, et on peut par exemple fusionner avec osm_poi
(...)
euh, sans surprise, je suis du coté de la simplification de code maintenant qu'il n'y a plus les polygones dedans ... mais ca peut fermer des fonctionnalités futures
Il y a 3 ans, tout était dans points, quand j'ai opté pour refaire une bonne partie du code, j'ai choisi de normaliser à donf la base de donnée pour justement prévoir que l'on puisse utiliser cette fonctionnalité et donc mettre les infos de position : altitude/coodonnées/accès dans une table séparé des points pour pouvoir gérer un jour que la partie hiver d'un refuge gardé puisse avoir son propre nombre de place sans être obligé de créer "à la main" une fiche dans la fiche.
Cette fonctionnalité existe toujours et peut s'activer, on a d'ailleurs amélioré la présentation sur carte de ces cas donc je suis pour de la laisser. Un des objectif d'avenir et de se lancer dans une campagne de dédoublement des fiches point eau/refuge gardé/partie non gardée afin, par exemple, que lorsque l'on souhaite afficher ou chercher ou exporter les "hébergements non gardés" on puisse les avoir sans être obligé de se dire qu'il faut aussi chercher/cocher les gardés car ils peuvent avoir une partie non gardée.
Ce qui manque peut-être par contre, c'est de bien soigner cette fonctionnalité et la mettre en avant.
exemple :
http://www.refuges.info/point/2235/caba ... mbe-hiver/
Pour passer de cette fiche, à celle du refuge gardé, on va soit dans "point à proximité : 0km" soit "sur la vignette de carte" mais c'est encore imparfait, une mise en avant avec un lien style :
"Ce refuge dispose également d'une partie gardée l'été du x au y visible ici"
pourrait aider. Ou d'autres idées.
==Pour la fusion avec osm_pois : ==
je ne sais pas trop quel est l'avenir de cette table et de son contenu. Mélanger avec nos points, je ne suis pas chaud vu que c'est assez différent, et la méthode de mise à jour n'est pas la même.
J'ai tenté un import osm avec une méthode différente pour donenr osm_points, table dé-normalisées, mais créé par un outil tout fait : osm2pgsql (donc maxi gain de code car déjà fait). Pour l'instant, j'hésite encore entre : garder ma procédure et passer osm_pois en mode gis ou laisser tomber osm_pois, osm_tags et osm_poi_tags pour ne garder que le format osm_points.
A voir à l'usage, la procédure avec osm2pgsql est très longue, avec une table redondante et il faut s'adapter aux "tags" osm, mais ça tient en 2 lignes de commandes.
Ma procédure que j'avais codée est mieux intégrée à notre site, c'est aussi très long, mais ça sélectionne mieux les zones qui nous concerne (pas d'import des campings japonais !) et on a plus de flexibilité.
Entre les 2, mon coeur balance, je vais donc tester et voir ce qui sera le plus adapté.
