[reflexion] Choix de l'Organisme fournisseur de carte

Message par **sly** » 07 mars 2013, 17:11

Claude Mauguier a écrit :
sly a écrit :et 30 autres aspects de la montagne que je pourrais citer...
Ah ? Des noms, des noms, des noms :!:

Vraiment ? On en a pour la nuit si je te liste tout ce que j'ai affiché sur cette carte.
Réduisons alors à "ce que je crois être ajouté par rapport à OCM" ;-)

Sinon, sous couvert de lecture de l'anglais, on trouve ici :
http://wiki.openstreetmap.org/wiki/Hiking/openhikingmap
et là :
http://wiki.openstreetmap.org/wiki/Talk ... nhikingmap

Une bonne palanquée d'éléments qui serons affichés, s'ils sont dans la base OSM bien évidement, sur MRI

Pèle mél qui n'y sont peut-être pas sur OCM :
- 'altitude des points de vue, sommet, source, fontaines, refuges, panneaux, micro village
- 4 niveaux d'utilisabilité en voiture des routes forestières, 2 niveaux de visibilité du chemin sur le terrain, 3 niveaux de difficulté du chemin selon la classification suisse
- réserves naturelles de 4 niveaux variés
- courbes de niveaux d'un modèle de terrain de meilleure qualité dans les alpes
- surfaces glaciers, marais, éboulis, roches dures, alpages, forêts arbustives en mutation
- et d'autres encore que je dois oublier ;-) Mais si je compte bien, je viens d'en lister 31 ;-p

Message par **Dominique** » 07 mars 2013, 17:25

Heu. bon. Si ça risque de compromettre les Pyrénées, je vais jouer mon peureux ariègeois

yip · Message par **yip** » 07 mars 2013, 18:29

si IGN est dispo sur la zone : IGN
si IGN pas dispo mais MRI dispo : MRI
si MRI pas dispo : OCM

Ca me va aussi. et on peut s'affranchir des pays car cet algo ne depends plus d'eux.
Faut voir comment faire rentrer les cartes Swisstopo dans cet algo.

des Zones il y en a toujours eu depuis des lustres. seulement, au debut, c'etait des BBOX en dur mais c'est exactement pareil sur le plan du concept (une bbox est une zone carrée qui a toujours contenu des massifs)

Sly je suis daccord en grande partie avec ce que tu dis, et j'étais même dans l'erreur en étant contre les premières extensions à l'époque. Finalement, heureusement que ca a été étendu, on a atteinds une pertinence , à laquelle je croyais pas, sur la plupart des secteurs.
(Pour les andes, malgré que je sois le contributeur principal des refuges des Andes (en fait 2 sur 3

) . je reste pour leur suppression. On sera jamais pertinents sur cette région.)

Maintenant qu'on est bien externalisé, ils faut qu'on soit bien organisés, il est là le problème.
Le schema SGBDR n'etait pas prévu pour , et il a du mal a suivre.

- le menu de recherche par massifs est (était) imbittable et énorme
- le menu d'exportation pareil

On pourrait regrouper les massifs par zones. oui j'ai commencé pour la recherche. Je ferai l'exportation. C'est sur ces trucs là qu'on voit l'importance du schema d'organisation des données. sinon c'est dur.

- les liens vers zones ont commencées à remplir le plan de travail

La pas grand chose a faire a part tailler dans le lard (Andes) ou repenser les secteurs.
Supprimer des zones, en fusionner (comme Jura etVosges, déja codé, mais pas eu de retour la dessus)

- la modération voyait des messages arriver concernant les vosges
- la page des nouvelles est devenu saturée de trucs qui ne les intéressent pas

Encore l'Organisation des données. On peut trier les nouvelles par zones, spécialiser les modos par zones, ca ne représente pas tant de code que ca (pour les nouvelles du moins) si les données dessous sont bien hiérarchisées. sinon, impossible et le fouillis deviens inévitable.

Oui, toutes mes goutte peuvent être asséchées, mais on ne le fait pas, et wri s'étends aux andes alors que les gouttes ne sont pas sèches.

lol, C'est pas comme si depuis 1 mois , je ne relancais pas quasi systématiquement dans chaque discussion l'idée de mieux organiser les données avec souvent une virulence non légitime d'ailleurs
On va assécher les gouttes !

Message par **Dominique** » 07 mars 2013, 19:04

On doit avoir quelque part les bornes de validité des cartes (voir le layerswitcher qui se grise quand on sort des limites)
On devrait donc pouvoir donner des priorités par zone:
- si le point est dans les bornes IGN => IGN
- si le point est dans les bornes Swiss => Swiss
- si MRI => MRI
- sinon ? GG / OCM / ... ?

Autre remarque de

il veut que quand il a choisi un fournisseur de carte, on n'en change pas à chaque changement de page (sauf s'il est hors zone de cette carte)
Donc => cookie
Au fait, toutes ces infos sont dans le java OL... faut que je voie ce que je peux faire

Message par **sly** » 07 mars 2013, 19:08

Dominique a écrit :Heu. bon. Si ça risque de compromettre les Pyrénées, je vais jouer mon peureux ariègeois :calimero: :ours:

Pas de risque, c'est loin qu'il en soit question ;-)

Mon souhait été juste d'amener la réflexion et tâter le ressenti de chacun et éventuellement amener à freiner l'arrivé de nouvelles zones tant que nous n'avons pas évoluer sur la ségmentation

Message par **sly** » 07 mars 2013, 19:17

yip a écrit : Faut voir comment faire rentrer les cartes Swisstopo dans cet algo.

Il nous faudrait un polygone de couverture des cartes je pense, l'algo suivra de lui même.

Pour les andes, malgré que je sois le contributeur principal des refuges des Andes (en fait 2 sur 3 ;) ) . je reste pour leur suppression. On sera jamais pertinents sur cette région.

Andes = zone peu couverte = peu de problèmes + déjà du boulot de fait -> pas de raison de s'en défaire.
Mais qu'elles restent ou partent, je vote blanc.
Et puis, qui sait, il ne faut jamais dire jamais ;-) "Meilleure pertinence francophone sur les andes ? pas impossible"

L'idée des zones mieux segmentée semble faire son bout de chemin, si on arrive à un bon niveau, nous n'aurons plus de raison de type "changement d'habitude" à craindre, et l'extension pourra reprendre

- les liens vers zones ont commencées à remplir le plan de travail
La pas grand chose a faire a part tailler dans le lard (Andes) ou repenser les secteurs.
Supprimer des zones, en fusionner (comme Jura etVosges, déja codé, mais pas eu de retour la dessus)

Idée : $_SESSION['id_zone_préférée']

lol, C'est pas comme si depuis 1 mois , je ne relancais pas quasi systématiquement dans chaque discussion l'idée de mieux organiser les données ;) avec souvent une virulence non légitime d'ailleurs ;)
On va assécher les gouttes ! :calimero:

Tout à fait, depuis 1 mois, et avec ce nouvel outil qu'est GIS, on se rapproche de plus en plus et ça devrait être de plus en plus faisable. La mise en base de nos zones est un pas important vers cet objectif

Message par **Dominique** » 07 mars 2013, 19:32

sly a écrit :Il nous faudrait un polygone de couverture des cartes je pense, l'algo suivra de lui même.

T'as la tête en forme de polygone

J'ai les BORNES des carte (quelque part dans OL)

yip · Message par **yip** » 07 mars 2013, 22:14

T'as la tête en forme de polygone Wink
J'ai les BORNES des carte (quelque part dans OL)

Il nous faudrait un polygone de couverture des cartes je pense, l'algo suivra de lui même.

le polygone de couverture a toute les chance d'etre le meme que le pays

IGN s'arrete au bornes de la france (+ST_Buffer de 20km disons) et Swisstopo pareil

Mais c'est vrai que c'est prise de tete, des BBOX d'approximation peuvent suffire et tant pis pour les effets bananes

Message par **sly** » 07 mars 2013, 23:33

yip a écrit : le polygone de couverture a toute les chance d'etre le meme que le pays ;)
IGN s'arrete au bornes de la france (+ST_Buffer de 20km disons) et Swisstopo pareil

Mais c'est vrai que c'est prise de tete, des BBOX d'approximation peuvent suffire et tant pis pour les effets bananes ;)

J'aime bien l'idée d'un st_buffer approximatif et un petit st_simplify derrière, en plus, ça se fait super simplement avec une requête SQL.

ça permet d'avoir une type de polygone "disponibilité carte" et l'id de la carte dans le $config par exemple et on évite ainsi de faire une soupe "pays" ou "bbox" ou autre.