Aujourd'hui, la feuille de style qu'on utilise pour présenter nos points fournis en gml sur la carte est hautement basique et ne contient en gros que :
<sld:ElseFilter /> --> pour tout le reste
<sld:OnlineResource xlink:href="http://www.refuges.info/images/icones/${type}.png" /> --> affiche une icone qui nous a déjà été indiquée
En clair, coté code, on trifouille un "type" bidon qui ne correspond déjà plus à rien et qui en fait devrait s'appeler "icone". Notre GML n'est donc pas un transfert de donnée pur mais un truc déjà orienté "trifouille de l'affichage". Ce qui le rend impropre à une consommation externe autre que juste "pour les yeux" et notre carte ne peut que difficilement évoluer vers une solution plus fine ou on changerait l'icone quand il y a un moyen de chauffage, on afficherait l'altitude des sommets ou je ne sais quel pop-up fun avec des infos "éclairs"
En outre, les icones apparaissent aussi sur le menu de sélection OL (qui a été généré coté serveur) qui correspondent à un id dans la base et donc nous empêche pour l'instant d'avoir deux coches comme : "abri sommaire" et "cabane non gardée"
L'export kml, qui lui aussi fait usage de nos icones, dispose, pour une 3ème fois consécutive de la logique "quelle icone pour quel point"
Je me pose donc la question de la centralisation propre de "quelles icones = quels champs en base", un endroit pour dire :
(place=0 ou manque_mur=1) -> icone abri sommaire et nom court "abri sommaire"
gardé=non and (poêle = oui ou chemine=oui) and bois=oui -> icone cabane avec feu et rondins de bois et nom court "Cabane chauffée avec bois proche"
etc. vous avez compris
J'ai plusieurs pistes de recherches :
- Mettre ça dans le SLD écrit à la main et exporter un gml du style :
Code : Tout sélectionner
<gml:featureMember>
<point_wri>
<nom>Habert de la dame ( Cabane de l'Alpettaz )</nom>
<$champ_en_base>$valeur</$champ_en_base> --> Pour tous !
<url>http://sly.refuges.info/point/295/cabane-non-gardee/Chartreuse/Habert-de-la-dame-Cabane-de-l-Alpettaz-/</url>
...
-> dominique va être content car son boulot coté OL va devenir bien plus simple ;-)
inconvénients :
-> je dois me taper un parseur de sld pour générer le kml et le choix des icones (et éventuellement gpx et extension "sym") à afficher dans le menu de sélection. + A l'avenir pour l'utiliser dans le getcapabilities de l'éventuel WFS pour qu'il puisse donner un nom court et une icone (éventuelle) à la couche disponible
- Mettre ça dans un style "fait main" simplifié (ou carrément un truc CSS ou autre truc existant)
avantages :
-> l'écrire est plus simple, le lire aussi pour la partie kml/icone+nom à cocher
inconvénients :
-> Cette fois, je n'écris plus un parseur de SLD mais un écriveur de SLD qui part de notre truc simple et en génère un SLD tel qu'on aurait pû l'écrire à la main (templates toutefois toujours les bienvenus !)
Dans les deux solutions, on gagne évidement que notre gml à générer devient sémantique et non "orienté style" ça peut ainsi nous servir pour exporter notre base et que je sors cette horreur que j'ai faite dans la base.
Voilà, j'hésite, des avis ou autres propositions ?
ps: l'idée que j'ai en tête fait suite à ce débat : http://www.refuges.info/forum/viewtopic.php?t=5005
où je ne suis pas satisfait intégralement de la proposition de dominique mais par contre je valide toujours l'idée de changer les choses.
Notez que je ne parle ici que de "présentation" (en clair, icone et nom court) qui rejoins le débat sur les clefs à récupérer que des gens veulent voir sur la carte, et l'interminable débat qui ne peut toujours pas répondre à "c'est quoi un gite d'étape ou un refuge gardé" et "c'est quoi un abri sommaire et une cabane"
En substance, je maintiens mon idée de séparer la manière de stocker en base, et les icones que l'on choisi de représenter, bref, éviter le : "un type de point = une icone"
Pour la partie du débat cité concernant le souhait pour dominique d'avoir une interface de saisie banalisée, idée à laquelle j'adhère mais pour laquelle je ne suis pas d'accord avec sa proposition. Pourra faire l'objet de choix techniques, je pense, assez indépendants.
