Tu admettras que ton "il suffit de..." était de trop. Toi qui as les mains dans le cambouis et le nez dans le guidon pour avoir ces feuilles dans le détail toujours sur les yeux parce que tu écris les règles d'un moteur de rendu que tu mets en oeuvre tu ne peux pas demander le même niveau d'implication à n'importe qui sur le thème "il suffit de" alors qu'il n'a pas en charge ce travail et n'en a même pas les moyens matériels de faire une telle mise en oeuvre.
Et ce n'est pas non plus parce que c'est disponible quelque part en ligne que cela facilite les choses : on se retrouve à gérer toutes sortes de liens externes pour différents projets, avec pour chacun des milliers de ligne de code qu'on ne peut pas fouiller dans le détail. Bref si on dit quelque chose, ce ne doit être pris que comme des pistes, ou des constatations sur ce qu'on voit, ou ne voit pas. Il ne faut pas mal le prendre, et ça doit plutôt t'aider dans ta tâche, même si en fin de compte la piste est mauvaise pour un cas précis (ce qui n'exclue pas que cette piste peut aussi expliquer toutes sortes d'autres anomalies générales qui seront à fouiller une par une de toute façon). Je n'ai fait que citer une cause courante d'objets qui apparaissent et où on a du mal parfois à les retrouver dans la base. Une d'elle est la duplication involontaire de données dans JOSM (CTRL+D au lieu de CTRL+ALT+D) et qui n'est pas toujours signalée par les outils d'analyse et vérification de cohérence avant la soumission des données. Souvent l'effet est visible masi pas toujours quand cele donne des objets orphelins ou insuffisamment tagués mais pas erronés en soit sur la simple base de leur tags. Des erreurs dans la base il y en a beaucoup pour plein de raisons, et souvent involontaires ou par manque d'ergonomie de l'éditeur utilisé ou une mauvaise compréhension, ou un oubli, ou une bête faute de frappe ou un clic de trop par accident, des erreurs que tout le monde peut faire et fera à un moment ou un autre. [Notes] Ces erreurs évidemment (y compris l'oubli de vérification) engendrent des anomalies de rendu parfois très sérieuses et très visibles, comme cela s'est produit pour la limite côtière ouest de la Bretagne, corrigée après plusieurs mois dans les rendus d'OSM France, puis plus récemment dans ceux d'OSM, mais toujours pas dans le rendu Mapnik du Toolserver intégré dans Wikipédia. L'erreur de rendu de la pointe ouest de la Bretagne, toujours très visible sur le rendu pour Wikipédia -- malgré une correction qui rend cela moins visible par l'incorporation dans les données de la base des "baies" en tant que polygones couvrant une partie de la mer tout en évitant de couvrir les îles, mais qui est toujours visible sur la terre émergée -- risque de ne pas être corrigée avant l'an prochain quand les applications actuelles du Toolserver de Wikimedia DE, désormais en fin de vie et en maintenance minimale, auront migré sur les serveurs Wikimedia Labs en préparation à la WMF mais pas encore opérationnels ; ceux qui maintiennent les applications actuelles du Toolserver ont une autre priorité pendant les quelques mois qui restent pour effectuer et réussir leur migration tout en respectant les nouvelles politiques en terme de licence, droits d'usage, sécurisation des comptes, gestion des quotas de ressources, tests de montée en charge, etc. On voit bien que le point le plus compliqué, le plus coûteux et le plus bloquant reste celui de la maintenance. Dans le cas de Mapnik, il n'y a pas encore de processus opérationnel pour la maintenance efficace des fichiers de lignes de côtes, qui sont une base annexe séparée, pas maintenue en même temps que les autres données OSM alors qu'elles en sont des données dérivées. La maintenance de ces fichiers est toujours coûteuse et inefficace et quand elle se fait elle oublie la phase de vérification avant publication vers les autres moteurs de rendus qui eux aussi prennent beaucoup de temps à en tenir compte. Et si ces erreurs ne sont pas corrigées c'est qu'elles sont aussi insuffisamment signalées. Le signalement d'anomalies (même difficiles à résoudreà est un élément important du projet, pas une tare de la part de ceux qui les font mais n'ont pas les moyens de les corriger eux-mêmes. Bref, il suffit de... n'a pas sa place, c'est du langage "yakafaucon" : si tu sembles ne retenir que le "faucon" contre ceux qui te signalent des choses, en revanche tu réponds par un "yaka"... Alors qu'on n'a jamais voulu dire que la solution était simple, mais que le problème peut être non seulement signalé, mais étudié et pris en compte d'un point de vue plus général. Car souvent plusieurs problèmes sont liés et ont des causes communes, pas toujours dans le code d'ailleurs et pas spécifiquement sur le seul problème signalé. Si on ne traite pas cela de façon plus générale, on se contentera d'appliquer un peu partout des "rustines" qui rendront plus tard la maintenance encore plus difficile (collage de rustines sur d'autres rustines jusqu'à la modification du pédalier puis des réparation du vélo tout entier) là où on aurait pu mettre en place une procédure menant à remplacer le pneu tout entier contre un pneu résistant aux crevaisons, ou faciliter le remplacement des pneus par d'autres déjà prêts ou à balayer préalablement les routes et apprendre aux cyclistes comment rester sur la route en évitant les bas-côtés. [/Notes] Le 21 avril 2013 16:18, Christian Quest <cqu...@openstreetmap.fr> a écrit : > Le 21 avril 2013 15:03, Philippe Verdy <verd...@wanadoo.fr> a écrit : > >> Et je sais pourquoi je ne le voyais pas, me^me en vérifiant: le label >> n'apparait qu'à un seul niveau de zoom et il m'a fallu raffraichir le tuile >> pour le voir, en vidant d'abord le cache de mon navigateur. Le label >> n'apparait pas quand on zoom plus avant. >> Alors je veux bien qu'il y ait un ou deux bogues mais il va falloir se >> demander pourquoi cela affecte ce niveau de zoom précisément, et pas plus >> avant car la position géographique calculée (avant projection dans les >> coordonnées en pixels de la tuile) est normalement la même. >> >> > > Ce qui rentre en ligne de compte pour que cela affecte ou non un niveau de > zoom donné : > > - la taille des metatuiles (8x8 tuiles, soit 2048x2048 pixels): est-ce que > l'objet intersecte ou pas cette metatuile, donc aux zooms supérieurs à 15 > le polygone n'intersecte plus la bbox de la metatuile et donc le label > n'est plus là. > > - la feuille de style et ses règles de rendu.. et là il suffit d'aller lui > rendre visite sur > https://trac.openstreetmap.org/browser/subversion/applications/rendering/mapnik/osm.xml > > > Que trouve-t-on ligne 4036 ? "and (waterway is null or waterway != > 'riverbank')" un test spécifique sur riverbank... pour éviter de dessiner > un label pour les riverbank, mais ce test ne tient pas compte des > natural=water + water=river qui sont un équivalent récent de > waterway=riverbank (voir le wiki: > http://wiki.openstreetmap.org/wiki/Tag:waterway%3Driverbank "new > tagging"). > > C'est l'origine de l'apparition du label en zoom 14 sur le layer > "area-text"... qui en plus dépend de la taille du polygone et du niveau de > zoom (voir lignes 212-227)... sans oublier l'ordre de placement des textes > car si la place est déjà prise, le label n'est pas rendu. Voilà pourqu'oi > il n'apparait pas à tout plus de niveaux de zoom. > > Ensuite zoom 15... là c'est le layer "text avec sa règle de rendu en bleu, > taille 10 qui est ligne 350... et qui s'appuie sur la requête postgis qui > est en ligne 4019 qui cherche entre autre des natural is not null... > > zoom 16 et suivant on est hors de la metatuile... > > > C'est bon, assez détaillé comme explication du fonctionnement de la > feuille de style XML ? C'est vrai que c'est pas super facile à comprendre. > > Il y a bien un problème avec la feuille de style OSM qui ne prend pas bien > en compte les natural=water + water=river, mais uniquement les > waterway=riverbank... qu'il est donc préférable de laisser en "doublon" > (mais ça n'éliminera qu'un des deux labels indésirables, celui du zoom 14). > > > Ca c'est pour le bug de la feuille de style OSM (et OSM-FR jusqu'à ce que > j'en corrige une partie, je vais faire la deuxième maintenant). > > Le deuxième bug, je n'ai pas réussit à le cerner... c'est dans Mapnik que > ça se passe et que le centroid calculé par mapnik pour le multipolygone > retourné par postgis est complètement farfelu et que du coup ce label > apparait très loin du multipolygone dont il est issu. > > > >> Aussi un niveau de zoom arrière, on voit le label mais dans une style >> différent, qui n'est plus celui d'une rivière ou d'un fleuve mais celui >> d'un lieu-dit. C'est ce qui me convint encore qu'il y a une autre anomalie >> dans les tags ou dans leur traitement, que tu n'as pas vu. >> >> > C'est le layer "area-text" ligne 214 + 4036 pour le zoom 14. Je l'ai bien > vu, merci. > > > >> Celle sur les natural=water+water=* au lieu de natural=riverbank n'a rien >> à voir puisque les deux sont déjà rendus de façon identifique (au moins aux >> niveaux de zoom élevés). L'anomalie semble spécifique de ces 2 niveaux de >> zoom qui ont des styles appliqués différents et des méthodes de rendu >> différentes pour les libellés. >> >> > Rien compris. > > > >> De toute façon c'est sur le rendu des libellés (leur sélection, leur >> positionnement optimal, leur dimensionnement, les styles de polices ou >> d'interlettrage, leur graisse et leur transparence pour ceux apparaissant >> en très gros, voire aussi le placement non nécessairement horizontal mais >> sur des diagonales ou courbes) qu'OSM, dans ses rendus Mapnik ou autres, >> doit faire encore beaucoup de progrès pour approcher un peu ce que savent >> faire à la perfection Michelin ou l'IGN ou les instituts cartographiques >> nationaux qui affinent les cartes patiemment à la main depuis des >> décennies, ou même (moins bien mais toujours mieux qu'OSM) Google Map et >> Bing Map. Souvent aussi MapQuest (et maintenant aussi uMap) fait mieux >> qu'OSM avec son rendu Mapnik sur ce point, à partir pourtant des mêmes >> données de base OSM. >> >> > Oh ? uMap a sont propre rendu maintenant ? Tu as un lien pour qu'on puisse > le voir ? > > Tout ce travail c'est la "généralisation cartographique"... comment > partant d'une masse de données détaillées sélectionner les objets les plus > utiles et faire le choix graphique approprié pour une carte dense en info > mais lisible... > > > >> Michelin vient aussi de démontrer aussi qu'il savait le faire avec des >> données OSM; bref la compétence et le savoir-faire carto**graphique**, issu >> de longues traditions et du travail réalisé par des humains (qu'on peut >> qualifier d'artistes tellement les cartes obtenues sont "belles" tout en >> restant précises à leur échelle) et pas seulement par des heuristiques >> programmées encore balbutiantes, n'est pas du tout la même que la >> compétence et le savoir-faire en terme de collecte, de codification, de >> classement, de vérification et de mise à jour des données ; elle ne dépend >> pas non plus du soin apporté par ceux qui passent du temps à patiemment >> travailler le contenu de la base de données avec les outils d'édition ; >> comme dans OSM on dit qu'on ne "tague pas pour le rendu", la tâche restant >> à faire derrière est immense. >> >> > > La grosse différence vient de la méthode 100% automatique pour le rendu > sortant de mapnik et donc de la complexité des règles de généralisation et > les cartes qui sont retravaillées à la main avant impression où là on peut > s'écarter quand c'est nécessaire des règles, comme déplacer certains > éléments. > > > >> Un progrès significatif a été fait pour les libellés le long des >> frontières en les plaçant du bon côté et non par dessus. Mais pas pour les >> libellés des noeuds. Et pas plus dans la sélection des libellés à garder >> contre d'autres à masquer (notamment les noms de villes, villages et >> lieux-dits). L'essai en cours pour les libellés des noms de rue demande à >> être affiné, c'est parfois trop ambigu. >> >> > Je suis preneur de permaliens... des trucs concrets quoi ;) > > Voilà, sujet terminé pour moi, je viens de passer 1h à étayer cette > réponse par les vérifications de la feuille de style OSM. > > -- > Christian Quest - OpenStreetMap France > Synthèse du Week-end "SOTM-FR" à Lyon : > http://openstreetmap.fr/s<http://openstreetmap.fr/sotmfr2013>ynthese-sotmfr > > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
