Le 15 février 2012 11:28, Ab_fab <[email protected]> a écrit : > > > Le 15 février 2012 08:05, Philippe Verdy <[email protected]> a écrit : > >> >> C'est à chaque moteur de rendu de définir le nombre de couches >> indépendantes de tuiles qu'il va générer, et dans quelle couche il va >> placer les éléments qu'il trouve. >> > C'est le genre de choix pour lequel je considère que l'humain possède un > discernement plus efficace que la machine. > >> >> > - Où placer les textes ? Sur la même tuile que les surfaces ? Sur une >> > tuile à part, avec tous les textes ? Sur une tuile à part, dédiée càd ne >> > contenant que les textes d'un layer donné ? >> >> Je penche plutôt pour la séparation complète (dans un même moteur de >> rendu) des libellés, notamment pour permettre de choisir dans quelle >> langue les afficher, ou même choisir de ne pas les afficher tout en >> affichant le reste. > > > Déjà fait ! > http://toolserver.org/~osm/locale/__all.html > > Autre exemple réussi, mais là avec des fonds et des calques > : http://francetopo.fr/ > > C'est pas mal, mais en regardant de près il y a des télescopages possibles > entre le texte et les éléments de la carte. Ils restent limités quand le > rendu de toutes ces couches est fait par la même machine. > >> >> > - Comment assurer que deux textes ne vont pas se superposer si les >> > calculs des tuiles deviennent indépendants ? A moins que le rendu ne prenne >> > en compte toutes les données affichables (càd le maximum de tuiles >> > superposées)... >> >> Là encore, si les tuiles sont servies par des moteurs dont le >> développement est séparé, il est impossible de s'assurer que ces >> textes ne se superposeront pas. >> >> Cependant, comme ces tuiles seront servies dans des couches séparées, >> on peut encore disposer d'une interface permettant de sélectionner >> laquelle de ces couches afficher. > > > francetopo.fr est le meilleur exemple. > >> >> >> > Cependant, si on trouve des réponses pratiques à toutes ces questions, >> > les moteurs de rendu OSM auraient grand intérêt à mettre en place ce >> > principe :) >> >> Je le pense aussi, car cela simplifierait énormément l'utilisation des >> cartes et le travail de modification ou création de données (vers >> quelquechose de bien plus utilisable que le "bordel" qu'on voit dans >> JOSM ou Potlatch, où tout se mélange et où il est difficile d'oublier >> des choses à créer ou corriger), > > > Si tu veux filtrer / atténuer / occulter des éléments de la base osm > "perturbateurs" pour ta contribution, il existe un super outil de filtrage > pour JOSM. > Côté rendu, JOSM fonctionne avec une feuille de style au format mapcss. Rien > ne t'empêche de l'ajuster pour que l'affichage colle mieux à ton "profil de > contribution" > >> >> tout en assurant une bien meilleure >> cohérence des données stockées dans la base (en permettant à chaque >> couche modifiable dans l'interface de restreindre le jeu de tags et de >> valeurs utilisables ou acceptables). > > > Le mode de stockage des données dans la base principale OSM suit une logique > qui parait bordélique, mais qui vise surtout à arriver à un haut niveau de > "robustesse". > > Restreindre le jeu de tags et de valeurs ? > Et pourquoi pas demander un diplôme pour avoir le droit de contribuer à > Wikipedia ?
Justement je n'ai pas dit ça. Tu commence à comprendre à l'envers... Je n'ai pas dit de restreindre ces valeurs, mais justement pouvoir taguer avec des valeurs dont on sait qu'elles sont reconnues correctement et supportées (en cas d'évolution des recommandations), en évitant des tas d'erreurs communes commises dans un éditeur qui permet de saisir absolument n'importe quoi n'importe quand, presque sans rien signaler du tout (ou si peu, et souvent après coup sur d'autres outils). Quand je vois le nombre de tags très ambigus (ou redondants sans raison) dans la base dont on ne sait pas trop comment les interpréter, même quand on est humain, un peu de cohérence de nuit pas. Et ce sera plus facile à assurer si une couche est développée pour afficher des classes d'objets plus uniformes dans leur définition, puisque chacune peut offrir des raccourcis utiles à cette couche d'informations qui accélère le travail de contribution en évitant aussi d'autres problèmes: sur cette couche spécialisée des tas d'actions de modifications peuvent être semi-automatisées pour taguer correctement sans erreur, et cette couche spécialisée peut aussi offrir un accès facile à des tags plus précis que ce que chacun croit connaître. _______________________________________________ Talk-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-fr
