Localisation dans les unités administratives

[Claude Mauguier]

Sur cette page :
http://www.refuges.info/point/1927/gite ... t-Aigoual/
J'observe ceci, sur la succession des ensembles>sous ensembles :
....Gard>Cévennes.... ce qui est une absurdité, les "Cévennes" étant un concept ethno-géographique qui contient une partie de plusieurs départements (Gard, Ardèche, Hérault); donc le Gard, unité administrative dont on n'a que faire, ne peut en aucun cas contenir les Cévennes !
Bis repetita : les départements, on n'en a rien à f....., pas plus que les régions, provinces, etc. Sinon pourquoi ne figure-t-on pas "Vallée d'Aoste" ou "Valais" pour les refuges "Alpes Pennines" ???
A ce titre, écrire: Italie>Alpes est tout aussi inexact, puisqu'en revanche les Alpes contiennent pour tout ou partie Italie, France, Suisse, Autriche, Allemagne, Liechtenstein, Slovénie et je laisse Monaco de côté, les refuges n'y étant accessibles qu'aux émirs pétroliers et autres mafieux russes ou non.
POURQUOI tient-on absolument à exprimer des unités administratives
Bourdieu avait raison : les gens ont l'Etat dans la tête et ne peuvent pas penser en dehors de ses schémas.
France, Italie, Suisse, à la limite on s'en balance tout autant : où est la montagne dans tout ça ?
A croire que plus c'est usine à gaz, plus vous prenez votre pied.
Si on va sur une fiche de cabane, à quoi servira de figurer l'appartenance administrative (en dehors de réserves, qui se foutent des départements et même des massifs) ?
Je finis même par me demander si le fait de vouloir préciser que le Mont Blanc est dans les Alpes n'est pas une manière indirecte de se payer la tête des gens par excès de sollicitude. Si tu n'es pas foutu d'aller chercher un massif donné sur une carte d'Europe, mieux vaudrait que tu bifurques vite vite de la montagne vers le bridge, le badminton ou la philatélie.
FAITES SIMPLE ET LOGIQUE
Vous ne bossez pas pour le ministère de l'intérieur : sinon ça devient comme disait Nicolas...non ?

[yip]

Tout a fait d'accord avec Claude.

Avec la nuance supplémentaire de garder quand même un peu de granularité pour définir que le massif de la Silvretta est dans les Alpes par exemple car tout le monde ne connais pas tous les massifs (que ce soit les Alpes slovènes ou suisse c'est pas la peine et ça intéresse moins)
Tu pointes aussi le doigt sur la contradiction qu'il y a entre découpage géographique et administratif (Italie ->Alpes), C'est la difficulté de mélanger plusieurs découpage différents.

Ce serait bien si on restait concentrés sur les entités géographiques.
En gros, uniquement les éléments qui peuvent avoir un intérêt pour l'utilisateur, et qui sont chainés (le Mt Blanc est dans les Alpes, il n'y a pas de litige comme Italie->Alpes), en incluant aussi les réserves (bonne idée), voire les cartes topo par exception.
Il y a d'autres bons SIG pour les infos généralistes, enfin je crois

... on est spécialisés sur la montagne ...

[Claude Mauguier]

Je crois qu'il faut se limiter aux ensembles 1 > sous ensembles d'ordre 2 > sous ensembles d'ordre n > etc. en évitant les intersections d'ensembles. Le "hic" résidant chez les parcs et réserves déjà arbitrairement disséminés pour ne pas leur surajouter les départements / provinces / Länder, des trucs remontant aux baillages et sénéchaussées du Moyen Âge.
Mais après tout, avons nous vocation à devenir les accessoires, les subordonnés, les propagandistes zélés de telle ou telle disposition administrative, quand bien même aurait-elle pour but la préservations des grenouilles velues ou des ânes à six pattes ? Du train où vont les choses, on va bientôt chercher à définir aussi les réserves de chasse, de pêche, les microbiotopes protégés, les sites ethno-archéologiques délimités par les art. 6,8,12 bis et 47 quinquiès de l'ordonnance 1157/csy/B12 du 24.02.1956...
Il y a sur le terrain assez de panneaux, affiches, barrières, rappels à la responsabilité de chacun : si tu vas en Vanoise, à moins d'y être parachuté (sly se déplace surtout en parachute, notons-le ), tu sauras vite quelles sont les contraintes attachées aux lieux.
Et si tu prends une prune pour infraction, c'est tant pis (mieux, dirais-je) pour ta pomme. Un simple rappel serait suffisant dans le "mode d'emploi" (que vraisemblablement 5% au plus des utilisateurs lisent vraiment) à propos de toutes ces choses
Sinon avez-vous pensé à mettre le Code Pénal en format pdf comme annexe au "mode d'emploi" du site ? C'est indirectement à ça qu'on en arrive.
Il ne faut pas confondre civisme et complaisance béate à n'importe quelle contrainte, aussi angéliques que soient ses intentions.
Maintenant, si les manips de codes démultipliées vous font frémir d'aise, je suggère d'aller demander à GdF, département "production", un sponsoring en faveur de WRI,

[sly]

J'observe ceci, sur la succession des ensembles>sous ensembles

Si ce n'est que le signe ">" qui gêne, on peut très bien le remplacer par un "+".
On peut aussi créer deux chaines de localisation "montagne" et "administrative" comme je le proposais dans un autre message. Il ne s'agit là que d'une représentation visuelle, ça peut se changer.

Bis repetita : les départements, on n'en a rien à f....., pas plus que les régions, provinces, etc.

Toi peut-être, moi j'y vois des intérêts à une localisation croisée permettant plusieurs choses :
- Que je me fasse plaisir car s'amuser avec des polygones, c'est fun
- Permettre à un non local de mieux savoir de quel endroit il s'agit car il connait mieux ses départements français que les vallées des Pyrénées
- la majorité des humains travaillant avec des notions administratives, cela nous permettra, par exemple, si un fond d'image satellite n'a été subventionné que par la Savoie sur la Savoie de pouvoir afficher les meilleurs photos, cartes, pour une zone donnée.

Alors que l'inconvénient est quasi nulle : "juste une ligne indiquant France > Savoie > Commune de Jarsy", il suffi de ne pas la lire !

Sinon pourquoi ne figure-t-on pas "Vallée d'Aoste" ou "Valais" pour les refuges "Alpes Pennines" ???

C'est en cours.

[sly]

Il y a sur le terrain assez de panneaux, affiches, barrières, rappels à la responsabilité de chacun : si tu vas en Vanoise, à moins d'y être parachuté (sly se déplace surtout en parachute, notons-le :laughing: ), tu sauras vite quelles sont les contraintes attachées aux lieux.

Il y a aussi sur le terrain des panneaux qui indiquent la direction et le temps de parcours avant d'arriver au refuge, il y a souvent sur le terrain des cartes qui présentent l'endroit. Pour autant, refuges.info reste utile pour préparer sa rando. Et ben tout pareil, refuges.info a pour utilité d'informer avant d'être verbalisé sur le terrain.

Et si ce que tu dis est assez vrai pour la vanoise, c'est tout de suite beaucoup moins le cas pour la réserve biologique dirigée du haut chéran, et ça me ferait chier d'apprendre, le matin, pour le prix de 150 euros, que je n'avais en réalité pas le droit de planter ma tente à 50m du refuge de bonverdant

[Claude Mauguier]

- Que je me fasse plaisir car s'amuser avec des polygones, c'est fun

Je ne vais pas te disputer ton plaisir, hein...? Sinon tu ne serais pas là mais dans une boulangerie, une fonderie, ou autre chose...

- Permettre à un non local de mieux savoir de quel endroit il s'agit car il connait mieux ses départements français que les vallées des Pyrénées

Mouaif, je me permets un grooooos doute : j'ai été "non local" en Ariège et autour, au début, mais je n'ai jamais eu recours aux subdivisions administratives pour quelque raison que ce soit. J'ai toujours travaillé "physique", vois-tu.

- la majorité des humains travaillant avec des notions administratives

Hélas, j'espère au moins que tu mesures ce qu'il y a là de désastreux, et je ne plaisante pas. Avoir dans la tête des abaques administratifs (c'est d'ailleurs une idée en passe d'être tout à fait fausse : interroge donc le premier quidam sur la localisation et les caractéristiques d'un département lambda, tu risques de rigoler un bon coup) à la place d'une connaissance de la réalité physique des choses - une vallée est une réalité, un département non, c'est une projection arbitraire due à l'histoire et à l'organisation subséquente du pouvoir - constitue, à mon humble avis le début de la fin...
Je vais en Ubaye, pas dans les AdHP, dans le Biros, pas en Ariège, dans l'Ortler, pas en Italie...
Mais bon, le Chef akhbar ! c'est toi qui te tapes le taf. Viel Glück

[yip]

... constitue, à mon humble avis le début de la fin...

le début du conformisme, qui prends alors le pas sur la perception réelle

On fait quoi alors ? de l'administratif sans l'afficher ?
Si on l'affiche, ça pose quelques soucis , il y a donc les departements et les districts suisses sur le meme niveau:



les departements francais sur la gauche, les districts a droite.
Vu la complexité du bazar suisse, ca tape la limite et ca plante (zone blanches) (je pense que c'est la limite virtuelle du million d'arretes qui est atteinte dans ce cas).

Ce genre de question quoi..
Quelque soit la carto utilisée, avoir 2 genre de polys aux résolutions radicalement différentes dans le même type, ca va pas être évident à gerer.
Sly, je me doute que tu as fait un gros boulot d'import OSM, alors garder que les pays (pour le fournisseur de carte) ça le ferait pas ?
Est-ce qu'on degrade les districts suisses au niveau des communes francaises, qui ont des surfaces comparables,
et on monte les cantons au niveau des departements (qui ont des surfaces comparables)?

[sly]

On fait quoi alors ? de l'administratif sans l'afficher ?

A mon avis c'est le mieux en effet. Ou tout du moins, ne jamais en afficher plus que 1.
Un truc genre ça : http://sly.refuges.info/nav/2193/departement/Savoie/ est déjà plus acceptable.



Joli plat de nouille !

Sly, je me doute que tu as fait un gros boulot d'import OSM, alors garder que les pays (pour le fournisseur de carte) ça le ferait pas ?
Est-ce qu'on degrade les districts suisses au niveau des communes francaises, qui ont des surfaces comparables,
et on monte les cantons au niveau des departements (qui ont des surfaces comparables)?

Quand un programmeur en arrive à souhaiter retirer des données ou les transfigurer, c'est souvent qu'il n'a pas bien prévu son code, pas bien prévu son modèle en base ou mal choisi sa stratégie ;-)

Y'a qu'a changer d'optique et ne pas les afficher ni les proposer à l'affichage. C'est sans doute pas bien utile, on ne les gardera que pour la géolocalisation.

On peut quand même noter qu'avec d'autres outils, ça reste possible malgré tout :
http://layers.openstreetmap.fr/?zoom=9& ... TFFFFFFFFF

Mais ok, nous on en a pas besoin sur une carte.

[Claude Mauguier]

Y'a qu'a changer d'optique et ne pas les afficher ni les proposer à l'affichage. C'est sans doute pas bien utile, on ne les gardera que pour la géolocalisation.
....................
Mais ok, nous on en a pas besoin sur une carte.

L'exemple cartographique donné (c'est à la limite du lisible, on ne voit plus qu'un embrouillamini de limites) descend bien en dessous du canton, jusqu'au district, càd en gros nos cantons bien de chez nous avec notables, banquet annuel de la FDSEA, réunions mensuelles des pompiers, etc... du train où vont les choses, pourquoi ne pas viser les communes, que dis-je, les parcelles cadastrales (ce qui, entre nous soit dit, permettrait de séparer terrain communal et terrain privé... où se trouvent certains abris recensés sur WRI ) ; ce n'est plus du polygone, mais de la cristallographie sub nanométrique.
"On n'en a pas besoin" : c'est tout à fait juste, je ne voulais rien dire d'autre.
CQFD.

[yip]

Ah oui, ils y arrivent mieux chez OSM ! en fait ils font tout en TMS.
ce ne sont pas des polygones qu'ils affichent. ce sont des PNG.
donc ils ont pas des millions d'arretes a gerer.
pas un seul polygone chez OSM en fait.
c'est malin, comme ça la quantité de data est toujours la même. quelquesoit la complexité de la vue, il doit construire un TMS au vol.
par contre, exit la possibilité d'un clic ou d'un highlight. Niet.
a moins de le traiter en WMS GetFeature ? (si le TMS peut repondre au WMS GetFeature)

Quand un programmeur en arrive à souhaiter retirer des données ou les transfigurer, c'est souvent qu'il n'a pas bien prévu son code, pas bien prévu son modèle en base ou mal choisi sa stratégie

Bah, je savais pas que departement francais = district suisse,
c'est un peu comparer des courgettes et des tomates , et le choix d'OSM est forcément arbitraire.
On peut se baser sur un nombre d'habitant comparable, une surface comparable, l'importance politique comparable ...
je suppose qu'OSM a retenu le critère du "rang dans le pouvoir politique" ou un truc du genre. car c'est clairement pas le nombre d'habitant ni la surface qui ont été retenus.

Y'a qu'a changer d'optique et ne pas les afficher ni les proposer à l'affichage

Si un jour on fait un nav a plus de zero niveaux de zoom, comment on fait pour les exclure ?

edit: vraiment interessant cette histoire de generation de TMS pour afficher n'importe quoi sans avoir peur des limites. je suis curieux du code, et surtout de la gestion du click et du "hover".

[sly]

Ah oui, ils y arrivent mieux chez OSM !

Chez OSM, c'est bibi qui s'en occupe ;-)

en fait ils font tout en TMS.
ce ne sont pas des polygones qu'ils affichent. ce sont des PNG.

Instant philosophiquo-technique : qu'est-ce que "afficher un polygone" ? Quelles que soient les méandres retenues sous le capot, ton oeil ne visualise in fine que des tas de pixels, que leur couleurs et leur position soient décidées par OL (coté client) ou par mapnik (coté serveur) quoi qu'on décide, à un moment il faut de toute façon passer des données vectorielles stockées à des pixels pour qu'on puisse les voir sur l'écran.

Le choix fait coté openstreetmap.fr c'est de générer ces images à partir du vecto du coté du serveur et pouvoir mettre le résultat en cache (ou pas), coté wri, le choix a été fait de transmettre les données vecto et de laisser la tambouille navigateur/JS/OL s'occuper de créer les images à la volée.
La question étant en partie de savoir si on bouffe le CPU du client, ou du serveur.

donc ils ont pas des millions d'arretes a gerer.
pas un seul polygone chez OSM en fait.

Bien sûr que si, la donnée à la base est de toute façon vectorielle ! Mais une grande quantité à été déporté chez le serveur pour réduire le boulot du client. Ce qui n'empêche en rien que le serveur peut en chier autrement plus...

c'est malin, comme ça la quantité de data est toujours la même.

à la taille du png près, oui.

quelle que soit la complexité de la vue, il doit construire un TMS au vol.
par contre, exit la possibilité d'un clic ou d'un highlight. Niet.
a moins de le traiter en WMS GetFeature ? (si le TMS peut repondre au WMS GetFeature)

Exact et re exact. Exit le clic sur carte, car la donnée vectorielle coté client n'est pas disponible, et à moins de faire de la reconnaissance d'image, ça oblige peu ou prou à revenir à la question du WFS, on économise juste la partie affichage dans OL (ce qui n'est pas toujours inutile) mais ça oblige à transférer tout deux fois, donc cette solution est médiocre.

Bah, je savais pas que departement francais = district suisse,
c'est un peu comparer des courgettes et des tomates ;) , et le choix d'OSM est forcément arbitraire.

C'est tout à fait exact. De même que si nous choisissons de monter ou descendre un niveau en suisse ou en italie ou je ne sais où, ça restera un autre choix arbitraire, ni mieux ni moins bien dans l'absolu. C'est pourquoi si nous avions voulu les afficher quand même, il aurait fallu choisir un autre critère qui nous semble pertinent, que par exemple tu aurais certainement choisi "par surface" (avec ou sans combinaison de leur niveau respectifs dans un pays donné)

je suppose qu'OSM a retenu le critère du "rang dans le pouvoir politique" ou un truc du genre.

re-re-re exact, avec une base commune de départ qui est : tous les pays, au sens reconnu par je ne sais plus quel organisme, au même niveau.

Y'a qu'a changer d'optique et ne pas les afficher ni les proposer à l'affichage

Si un jour on fait un nav a plus de zero niveaux de zoom, comment on fait pour les exclure ?

Je n'ai pas compris ? c'est quoi un "nav à plus de zero niveaux de zoom" ?

[yip]

Bravo bibi !
Merci pour les explications du TMS , je me doutais bien que le PostGis chez OSM stockait de la geometrie et pas des PNG
C'est interessant comme facon de faire. je me demande l'ampleur du code ... peut etre tres abordable ?

Pour le clic c'est possible, le WMS Getfeature n'a pas besoin de vectoriel pour marcher, s'il fallait envoyer du vecteur en //, ca perdrait tout le benefice du TMS bien sur ...
le GetFeature est fait pour ce cas: il envoie au serveur les coordonnees d'un clic, et de nouveau, c'est au serveur de l'analyser car seul le serveur peut savoir si c'est un endroit interessant ou pas.
c'est dans la norme WMS, mais en TMS, aucune idée.

Pour le MouseOver par contre, ça parait infaisable en pur TMS ..

---

le nav a plus de zero niveaux de zoom, c'est un futur navigateur qui devra gerer, a un moment ou un autre, quoi afficher par defaut à quelle echelle.
par exemple, sur le screenshot, il n'affiche pas les 5000 cabanes de la zone. c'est donc qu'il y a forcement eu un parametre quelque part.
Sur ce test, j'ai lié arbitrairement l'affichage au niveau de zoom.

Avec l'integration de l'administratif, le zoom n'est plus un critère suffisant.
Il faudra lui dire, d'une facon ou d'une autre, de sauter l'affichage des departements (et autres). je pensais a un champs dans la table type mais tu n'es pas chaud alors il y a aussi la solution PHP de $config[poly_administratifs] = [ 3, 5, 7, 15 ] et surement encore d'autres.
ca depends pas de WFS (placé ! ) ou de XML-maison, ca depends si on veut faire un nav dynamique en profondeur ou pas.

[sly]

C'est interessant comme facon de faire. je me demande l'ampleur du code ... peut etre tres abordable ?

Du code que j'ai dû taper moi ? ça devrait te plaire ;-) :
- 0 lignes de code, pas un seul if !
- ~100 lignes de description du style en xml qui contient les requêtes, le choix de la couleur et police
- ~100 lignes de config pour dire à tout plein d'outils de marcher comme il faut

Et des heures et des heures à configurer tous les softs entre eux pour qu'il dédaignent enfin fonctionner main dans la main.
Forces en présence :
- linux / apache / postgresql / postgis 1.5 pour fournir le "socle"
- osm2pgsql pour importer les données osm dans pg
- mod_tile un module pour que apache puisse gérer le cache des tuiles et traiter les demandes TMS
- renderd un daemon pour traiter la queue de rendu, les priorité, lancer le rendu des tuiles, choisir les feuilles de styles
- libmapnilk une librarire pour faire le rendu des images en fonction du style demandé par renderd

Pour le clic c'est possible, le WMS Getfeature n'a pas besoin de vectoriel pour marcher, s'il fallait envoyer du vecteur en //, ca perdrait tout le benefice du TMS bien sur ...
le GetFeature est fait pour ce cas: il envoie au serveur les coordonnees d'un clic, et de nouveau, c'est au serveur de l'analyser car seul le serveur peut savoir si c'est un endroit interessant ou pas.
c'est dans la norme WMS, mais en TMS, aucune idée.

Mais c'est super malin ça ! il suffit de transmettre un couple de coordonnée x et y, et le serveur répond ce que ça donne, pas cons les mecs ! Et ben tu vois, j'ignorais complètement que ça existait.

Pour le MouseOver par contre, ça parait infaisable en pur TMS ..

Ni en quoi que ce soit d'autre qui n'aurais pas préalablement transmis les infos en vectoriel. Mais ça reste minimal comme problème après tout, et finalement, bigre, c'est pas si con que ça cette idée... ouais par contre, ça remet tout en cause sur nos choix techniques, oulla là, gros mal de tête en perspective.
Mais on économiserais vachement coté client puisque c'est le serveur qui décide de tout. Bon ça fait quand même des cases mais ça réduit terriblement les données transférées
client : x+y + cases -> serveur
serveur url ou aller, pop-up à afficher -> client

[sly]

le nav a plus de zero niveaux de zoom, c'est un futur navigateur qui devra gerer, a un moment ou un autre, quoi afficher par defaut à quelle echelle.
par exemple, sur le screenshot, il n'affiche pas les 5000 cabanes de la zone. c'est donc qu'il y a forcement eu un parametre quelque part.

J'ai loupé le screenshot avec les cabanes ?

Mais sion, si le serveur ne lui en a donné que 120, ben il n'affiche que ça et zou non ?

Il faudra lui dire, d'une facon ou d'une autre, de sauter l'affichage des departements (et autres). je pensais a un champs dans la table type mais tu n'es pas chaud

Mais si, pourquoi je serais pas chaud ? en plus, c'est déjà fait !
where polygone_type.categorie_polygone_type!='administrative'

ca depends si on veut faire un nav dynamique en profondeur ou pas.

Je pense en fait que j'ai fais fausse route et que j'ai un peu trop rêver la dernière fois que je te l'ai proposé : espérer afficher un ensemble de polygone monstrueux en quantité monstrueuse et tout simplement pas viable. J'espérais, mais ton test, et les données que j'ai rentrée montre que ce n'est pas jouable en mode vectoriel coté OL.
Je m'a gouré, le mieux à mon avis, c'est de laisser tomber l'idée d'afficher quoi que ça soit d'autre que :
- les massifs
- les zones
en plus de 1 polygone.
Donc exit les coches pour départements, pays, réserves et tout le tintouin.