Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
En fait c'est peu clair - wiki francais article place et article hamlet moins de 100 habitant - wiki anglais article place paragraphe hamlet some 100 inhabitants - wiki anglais article hamlet typically with less than 100-200 inhabitants, although this may vary by country Le souci c'est que some hundred peut etre compris comme quelques centaines, contrairement a about hundred ou aprroximatively hundred. Le 21 août 2013 20:33, Pieren pier...@gmail.com a écrit : 2013/8/21 Tetsuo Shima tets...@gmail.com: Pas mal d'agglomération sont taggé village - plus de 1000h - alors quel devrai etre hamlet - quelques centaine d'habitant - au sens du wiki notamment. Non. hamlet si 100 habitants, pas 1000. C'était 1000 dans le wiki anglais par le passé mais 100 depuis toujours dans le wiki français. Et ça a changé aussi dans le wiki anglais depuis pas mal de temps maintenant. Pieren ___ 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
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Ouille... ça pique les yeux ! La faute aux ronds-points... J'ai rectifié le tir en revoyant complètement la façon de faire (une fois de plus). Finie la fusion des tronçons, maintenant je limite les cartouches en me basant sur la longueur de ceux-ci. C'est pas idéal (ça en retire beaucoup il où ils sont fortement segmentés) mais ça semble donner de bons résultats. Toulouse: http://tile.openstreetmap.fr/?zoom=12lat=43.63783lon=1.39339layers=B00FFF Le 20 août 2013 21:24, Lord Awikatchikaen lord.awikatchik...@gmail.com a écrit : Sur toulouse, ca a l'effet inverse, il y a plus de cartouches qu'avant (exemple de la D1 et D2 en haut a gauche) et on ne voit plus les autoroutes A621 et A624. Le mar. 20 août 2013 19:44:55 CEST, Christian Quest a écrit : J'ai retravaillé le placement des noms de ville et des cartouches de références de route. Pour l'instant c'est visible sur le zoom 12 du layer osmfr-lowzoom-test à comparer avec osmfr et osm-defaut. Exemple (dans le même coin Evrux/Dreux): http://tile.openstreetmap.fr/?**zoom=12lat=49.04611lon=1.** 01288layers=B00FFFhttp://tile.openstreetmap.fr/?zoom=12lat=49.04611lon=1.01288layers=B00FFF Vous verrez que j'ai aussi fait apparaitre les tertiary à partir du zoom 12 (qui est en cours de recalcul sur l'hexagone, ça sera terminé vers 20h30). Un peu de cuisine: - les morceaux de routes portant le même type et ref sont regroupés pour éviter trop de répétition des cartouches - les cartouches sont placés par priorité de type de route (motorway trunk primary secondary) puis par longueur de tronçon (regroupé donc) décroissante. Les plus curieux peuvent voir les commit sur github. Je lancerai un recalcul des zooms 9 à 11 dans la soirée... ça sera donc à jour demain matin pour le monde entier. -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/**server2013/http://donate.osm.org/server2013/ __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Christian, Comment fais tu pour trier les villages ayant le tag population rempli et ceux ne l'ayant pas? Tu privilégie ceux qui l'ont? et jusqu'a qu'elle seuil bas de population continues tu a trier? jusqu’à 0? La derniere mouture est bien mieux mais je vois encore quelques bizarrerie sur les petite agglomération, notament entre village et hamlet et ceux ayant des population ou pas, certain étant tres proche les uns des autres, parfois les village sans population semble prendre le pas sur le village d’à coté avec un tag population même si celle ci est assez réduite - genre 800h -. Le 21 août 2013 13:27, Christian Quest cqu...@openstreetmap.fr a écrit : Ouille... ça pique les yeux ! La faute aux ronds-points... J'ai rectifié le tir en revoyant complètement la façon de faire (une fois de plus). Finie la fusion des tronçons, maintenant je limite les cartouches en me basant sur la longueur de ceux-ci. C'est pas idéal (ça en retire beaucoup il où ils sont fortement segmentés) mais ça semble donner de bons résultats. Toulouse: http://tile.openstreetmap.fr/?zoom=12lat=43.63783lon=1.39339layers=B00FFF Le 20 août 2013 21:24, Lord Awikatchikaen lord.awikatchik...@gmail.coma écrit : Sur toulouse, ca a l'effet inverse, il y a plus de cartouches qu'avant (exemple de la D1 et D2 en haut a gauche) et on ne voit plus les autoroutes A621 et A624. Le mar. 20 août 2013 19:44:55 CEST, Christian Quest a écrit : J'ai retravaillé le placement des noms de ville et des cartouches de références de route. Pour l'instant c'est visible sur le zoom 12 du layer osmfr-lowzoom-test à comparer avec osmfr et osm-defaut. Exemple (dans le même coin Evrux/Dreux): http://tile.openstreetmap.fr/?**zoom=12lat=49.04611lon=1.** 01288layers=B00FFFhttp://tile.openstreetmap.fr/?zoom=12lat=49.04611lon=1.01288layers=B00FFF Vous verrez que j'ai aussi fait apparaitre les tertiary à partir du zoom 12 (qui est en cours de recalcul sur l'hexagone, ça sera terminé vers 20h30). Un peu de cuisine: - les morceaux de routes portant le même type et ref sont regroupés pour éviter trop de répétition des cartouches - les cartouches sont placés par priorité de type de route (motorway trunk primary secondary) puis par longueur de tronçon (regroupé donc) décroissante. Les plus curieux peuvent voir les commit sur github. Je lancerai un recalcul des zooms 9 à 11 dans la soirée... ça sera donc à jour demain matin pour le monde entier. -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/**server2013/http://donate.osm.org/server2013/ __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ 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
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
C'est trié par population décroissante, jusqu'à 0... par contre si c'est non renseigné (null) est-ce que ça ne sortirai pas en premier ? Pas impossible, et ça expliquerai ce désordre. J'ai encore fait une modif il n'y a pas 1h... et le zoom 12 est en recalcul. On va bientôt pouvoir démarrer le concours sur les coupures en bord de metatile ;) Petite nouveauté: une icône pour les bases aériennes... Je pense pouvoir bientôt basculer cette dernière version sur le rendu osmfr normal. Le 21 août 2013 17:38, Tetsuo Shima tets...@gmail.com a écrit : Christian, Comment fais tu pour trier les villages ayant le tag population rempli et ceux ne l'ayant pas? Tu privilégie ceux qui l'ont? et jusqu'a qu'elle seuil bas de population continues tu a trier? jusqu’à 0? La derniere mouture est bien mieux mais je vois encore quelques bizarrerie sur les petite agglomération, notament entre village et hamlet et ceux ayant des population ou pas, certain étant tres proche les uns des autres, parfois les village sans population semble prendre le pas sur le village d’à coté avec un tag population même si celle ci est assez réduite - genre 800h -. Le 21 août 2013 13:27, Christian Quest cqu...@openstreetmap.fr a écrit : Ouille... ça pique les yeux ! La faute aux ronds-points... J'ai rectifié le tir en revoyant complètement la façon de faire (une fois de plus). Finie la fusion des tronçons, maintenant je limite les cartouches en me basant sur la longueur de ceux-ci. C'est pas idéal (ça en retire beaucoup il où ils sont fortement segmentés) mais ça semble donner de bons résultats. Toulouse: http://tile.openstreetmap.fr/?zoom=12lat=43.63783lon=1.39339layers=B00FFF Le 20 août 2013 21:24, Lord Awikatchikaen lord.awikatchik...@gmail.coma écrit : Sur toulouse, ca a l'effet inverse, il y a plus de cartouches qu'avant (exemple de la D1 et D2 en haut a gauche) et on ne voit plus les autoroutes A621 et A624. Le mar. 20 août 2013 19:44:55 CEST, Christian Quest a écrit : J'ai retravaillé le placement des noms de ville et des cartouches de références de route. Pour l'instant c'est visible sur le zoom 12 du layer osmfr-lowzoom-test à comparer avec osmfr et osm-defaut. Exemple (dans le même coin Evrux/Dreux): http://tile.openstreetmap.fr/?**zoom=12lat=49.04611lon=1.** 01288layers=B00FFFhttp://tile.openstreetmap.fr/?zoom=12lat=49.04611lon=1.01288layers=B00FFF Vous verrez que j'ai aussi fait apparaitre les tertiary à partir du zoom 12 (qui est en cours de recalcul sur l'hexagone, ça sera terminé vers 20h30). Un peu de cuisine: - les morceaux de routes portant le même type et ref sont regroupés pour éviter trop de répétition des cartouches - les cartouches sont placés par priorité de type de route (motorway trunk primary secondary) puis par longueur de tronçon (regroupé donc) décroissante. Les plus curieux peuvent voir les commit sur github. Je lancerai un recalcul des zooms 9 à 11 dans la soirée... ça sera donc à jour demain matin pour le monde entier. -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/**server2013/http://donate.osm.org/server2013/ __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ 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 -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Je demandais ca parce que j'ai du mal a savoir si les bizarrerie que je trouve sont lié a un défaut dans les donnée, ou au rendu lui meme. En fouillant je trouve pas mal de défaut dans les données des petite ville et village, notamment la hiérarchisation village/hamlet qui semble très flou. Pas mal d'agglomération sont taggé village - plus de 1000h - alors quel devrai etre hamlet - quelques centaine d'habitant - au sens du wiki notamment. Le 21 août 2013 18:59, Christian Quest cqu...@openstreetmap.fr a écrit : C'est trié par population décroissante, jusqu'à 0... par contre si c'est non renseigné (null) est-ce que ça ne sortirai pas en premier ? Pas impossible, et ça expliquerai ce désordre. J'ai encore fait une modif il n'y a pas 1h... et le zoom 12 est en recalcul. On va bientôt pouvoir démarrer le concours sur les coupures en bord de metatile ;) Petite nouveauté: une icône pour les bases aériennes... Je pense pouvoir bientôt basculer cette dernière version sur le rendu osmfr normal. Le 21 août 2013 17:38, Tetsuo Shima tets...@gmail.com a écrit : Christian, Comment fais tu pour trier les villages ayant le tag population rempli et ceux ne l'ayant pas? Tu privilégie ceux qui l'ont? et jusqu'a qu'elle seuil bas de population continues tu a trier? jusqu’à 0? La derniere mouture est bien mieux mais je vois encore quelques bizarrerie sur les petite agglomération, notament entre village et hamlet et ceux ayant des population ou pas, certain étant tres proche les uns des autres, parfois les village sans population semble prendre le pas sur le village d’à coté avec un tag population même si celle ci est assez réduite - genre 800h -. Le 21 août 2013 13:27, Christian Quest cqu...@openstreetmap.fr a écrit : Ouille... ça pique les yeux ! La faute aux ronds-points... J'ai rectifié le tir en revoyant complètement la façon de faire (une fois de plus). Finie la fusion des tronçons, maintenant je limite les cartouches en me basant sur la longueur de ceux-ci. C'est pas idéal (ça en retire beaucoup il où ils sont fortement segmentés) mais ça semble donner de bons résultats. Toulouse: http://tile.openstreetmap.fr/?zoom=12lat=43.63783lon=1.39339layers=B00FFF Le 20 août 2013 21:24, Lord Awikatchikaen lord.awikatchik...@gmail.coma écrit : Sur toulouse, ca a l'effet inverse, il y a plus de cartouches qu'avant (exemple de la D1 et D2 en haut a gauche) et on ne voit plus les autoroutes A621 et A624. Le mar. 20 août 2013 19:44:55 CEST, Christian Quest a écrit : J'ai retravaillé le placement des noms de ville et des cartouches de références de route. Pour l'instant c'est visible sur le zoom 12 du layer osmfr-lowzoom-test à comparer avec osmfr et osm-defaut. Exemple (dans le même coin Evrux/Dreux): http://tile.openstreetmap.fr/?**zoom=12lat=49.04611lon=1.** 01288layers=B00FFFhttp://tile.openstreetmap.fr/?zoom=12lat=49.04611lon=1.01288layers=B00FFF Vous verrez que j'ai aussi fait apparaitre les tertiary à partir du zoom 12 (qui est en cours de recalcul sur l'hexagone, ça sera terminé vers 20h30). Un peu de cuisine: - les morceaux de routes portant le même type et ref sont regroupés pour éviter trop de répétition des cartouches - les cartouches sont placés par priorité de type de route (motorway trunk primary secondary) puis par longueur de tronçon (regroupé donc) décroissante. Les plus curieux peuvent voir les commit sur github. Je lancerai un recalcul des zooms 9 à 11 dans la soirée... ça sera donc à jour demain matin pour le monde entier. -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/**server2013/http://donate.osm.org/server2013/ __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ 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 -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ 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
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
2013/8/21 Tetsuo Shima tets...@gmail.com: Pas mal d'agglomération sont taggé village - plus de 1000h - alors quel devrai etre hamlet - quelques centaine d'habitant - au sens du wiki notamment. Non. hamlet si 100 habitants, pas 1000. C'était 1000 dans le wiki anglais par le passé mais 100 depuis toujours dans le wiki français. Et ça a changé aussi dans le wiki anglais depuis pas mal de temps maintenant. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Le 21/08/2013 19:12, Tetsuo Shima a écrit : Je demandais ca parce que j'ai du mal a savoir si les bizarrerie que je trouve sont lié a un défaut dans les donnée, ou au rendu lui meme. En fouillant je trouve pas mal de défaut dans les données des petite ville et village, notamment la hiérarchisation village/hamlet qui semble très flou. Pas mal d'agglomération sont taggé village - plus de 1000h - alors quel devrai etre hamlet - quelques centaine d'habitant - au sens du wiki notamment. Je met systématiquement village au minimum pour toutes les communes quelques soit le nombre d'habitants. J'estime qu'un village de 50 habitants a plus d'importance sur une carte qu'un immeuble de 50 appartements ! Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Même chose, je pense qu'on a beaucoup trop de hamlet notamment en milieu rural car me^me si c'est une petite commune, on doit pouvoir repérer son centre par rapport à tous ses hameaux. Et pour les gros hameaux d'une commune, qui sont d'anciens villages couvrant toute une série de petits hameaux environnants, je pense que la classification avec suburb est utile (même si ce n'est pas à proprement parler en zone urbaine, c'est quasiment un quartier à l'échelle de la commune, qui inclut le gros bourg et ses petits hameaux et fermes isolées tout autour). Ce cas se trouve facilement mais cela évite de les classer en village avec pour conséquence de faire apparaitre sur la carte seulement ne nom de ce bourg et pas celui de la commune sur son bourg le plus important. La carte devrait aussi malgré tout distinguer les place=village qui ont une population indiquée (pour la commune entière), des autres place=village qui n'ont pas de population indiquée (ni de numéro de référence INSEE, sauf peut-être historique pour les anciennes communes) elle n'est pas mesurée directement et car ce ne sont pas des unités urbaines au plan statistique. Les documentation des tags sont indicatives et il faut parfois les adapter, surtout quand on a des données parcellaires, afin de pouvoir ensuite gérer des priorités d'affichage avec des règles raisonnables. Mais si les tags place=* sont pris de façon trop stricte, la seule façon de gérer les priorités sera d'indiquer des chiffres de population fictifs (juste grossièrement estimés, en indiquant en note qu'il ne s'agit que d'une estimation grossière). C'est parfois utile lorsque le découpage administratif est trop éloigné de la réalité urbaine actuelle. Mais plus qu'une note pour ce cas il faudrait peut-être un tag particulier population:fictive=yes pour ne pas perturber les utilisations sur des rendus de cartes ou fichiers statistiques. Le 21 août 2013 20:41, Christophe Merlet red...@redfoxcenter.org a écrit : Le 21/08/2013 19:12, Tetsuo Shima a écrit : Je demandais ca parce que j'ai du mal a savoir si les bizarrerie que je trouve sont lié a un défaut dans les donnée, ou au rendu lui meme. En fouillant je trouve pas mal de défaut dans les données des petite ville et village, notamment la hiérarchisation village/hamlet qui semble très flou. Pas mal d'agglomération sont taggé village - plus de 1000h - alors quel devrai etre hamlet - quelques centaine d'habitant - au sens du wiki notamment. Je met systématiquement village au minimum pour toutes les communes quelques soit le nombre d'habitants. J'estime qu'un village de 50 habitants a plus d'importance sur une carte qu'un immeuble de 50 appartements ! Librement, -- Christophe Merlet (RedFox) __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Le 21 août 2013 21:02, Philippe Verdy verd...@wanadoo.fr a écrit : Mais plus qu'une note pour ce cas il faudrait peut-être un tag particulier population:fictive=yes pour ne pas perturber les utilisations sur des rendus de cartes ou fichiers statistiques. population:estimated=nnn serait préférable (ou un truc du genre). Si un rendu veut utiliser ce tag il le pourra, et il ne gênera pas ceux qui feraient des statistiques avec population=* -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Le 21 août 2013 21:34, Christian Quest cqu...@openstreetmap.fr a écrit : Le 21 août 2013 21:02, Philippe Verdy verd...@wanadoo.fr a écrit : Mais plus qu'une note pour ce cas il faudrait peut-être un tag particulier population:fictive=yes pour ne pas perturber les utilisations sur des rendus de cartes ou fichiers statistiques. population:estimated=nnn serait préférable (ou un truc du genre). Si un rendu veut utiliser ce tag il le pourra, et il ne gênera pas ceux qui feraient des statistiques avec population=* Pourquoi pas... De toute façon c'est mieux et plus objectif que les actuels place=* qui sont assez mal fichus pour classer ce qu'on veut afficher sur une carte quand les critères sont impossibles à établir clairement de façon unique partout, et souvent trafiqués de façon incohérente. A mon avis tous les place=city/town/village/suburb/hmalet/locality sont condamnés à être traités de la même façon et on a besoin de critères à la fois plus précis et plus souples non fondés sur des seuils arbitraires. Une population précise ou estimée sera toujours mieux, surtout quand on sait que mêmes les populations statistiques officielles sont aussi estimées avec une marge d'erreur (et devraient toutes être datées car les statistiques ne sont pas mises à jour partout en même temps, avec peut-être à terme aussi le codage d'un taux de croissance annuel de population pour permettre d'affiner les populations données à des dates très différentes). En plus dans certains pays il n'y a pas de population donnée pour chaque niveau adminsitratif mais sur un échelon supérieur ou seulement à une échelle des unités urbaines (indépendamment du découpage administratif qui n'évolue pas en même temps). Rien que la notion de ville est difficile à établir (demandez-vous ce que désigne Paris, Londres, ou Moscou si on retenait les critères de classification des villes d'un autre pays que le leur, les échelles ne sont pas comparables entre elles au plan administratif comme au plan du découpage urbain statistique national...) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
J'ai retravaillé le placement des noms de ville et des cartouches de références de route. Pour l'instant c'est visible sur le zoom 12 du layer osmfr-lowzoom-test à comparer avec osmfr et osm-defaut. Exemple (dans le même coin Evrux/Dreux): http://tile.openstreetmap.fr/?zoom=12lat=49.04611lon=1.01288layers=B00FFF Vous verrez que j'ai aussi fait apparaitre les tertiary à partir du zoom 12 (qui est en cours de recalcul sur l'hexagone, ça sera terminé vers 20h30). Un peu de cuisine: - les morceaux de routes portant le même type et ref sont regroupés pour éviter trop de répétition des cartouches - les cartouches sont placés par priorité de type de route (motorway trunk primary secondary) puis par longueur de tronçon (regroupé donc) décroissante. Les plus curieux peuvent voir les commit sur github. Je lancerai un recalcul des zooms 9 à 11 dans la soirée... ça sera donc à jour demain matin pour le monde entier. -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Sur toulouse, ca a l'effet inverse, il y a plus de cartouches qu'avant (exemple de la D1 et D2 en haut a gauche) et on ne voit plus les autoroutes A621 et A624. Le mar. 20 août 2013 19:44:55 CEST, Christian Quest a écrit : J'ai retravaillé le placement des noms de ville et des cartouches de références de route. Pour l'instant c'est visible sur le zoom 12 du layer osmfr-lowzoom-test à comparer avec osmfr et osm-defaut. Exemple (dans le même coin Evrux/Dreux): http://tile.openstreetmap.fr/?zoom=12lat=49.04611lon=1.01288layers=B00FFF Vous verrez que j'ai aussi fait apparaitre les tertiary à partir du zoom 12 (qui est en cours de recalcul sur l'hexagone, ça sera terminé vers 20h30). Un peu de cuisine: - les morceaux de routes portant le même type et ref sont regroupés pour éviter trop de répétition des cartouches - les cartouches sont placés par priorité de type de route (motorway trunk primary secondary) puis par longueur de tronçon (regroupé donc) décroissante. Les plus curieux peuvent voir les commit sur github. Je lancerai un recalcul des zooms 9 à 11 dans la soirée... ça sera donc à jour demain matin pour le monde entier. -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ 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
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Un peu de progrès sur le front des libellés de villes/villages... Je procède désormais en 2 passes, l'un pour positionner en priorité les libellés des principales villes, puis on ajoute les autres éléments comme les ref des routes, puis une deuxième passe de remplissage pour combler les espaces vides. J'ai aussi légèrement augmenté la taille du texte pour plus de lisibilité. Résultat: - osmfr avant: http://cl.ly/image/2m1t0c3r1Y2B - osmfr après: http://cl.ly/image/3p3K3n0Y410H - osm.org: http://cl.ly/image/2E1h3p2X302l Y'a pas photo ! Le zoom 11 a été recalculé sur l'hexagone. Autre changement... les aéroports/aérodromes, où j'ai ajouté un prétraitement pour supprimer le Aéroport|Aérodrome de|du|d'|de la dans le nom. J'ai voulu faire de même sur les gares, mais du coup la Gare de Lyon devennait Lyon :( ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
On 19/08/2013 12:03, Christian Quest wrote: Résultat: - osmfr avant: http://cl.ly/image/2m1t0c3r1Y2B - osmfr après: http://cl.ly/image/3p3K3n0Y410H Connaissant le Pays d'Ouche et la vallée de l'Avre illustrés dans cet extrait, je témoigne que les toponymes sélectionnés par le rendu sont maintenant beaucoup plus conformes à ce à que je m'attend à y voir. Beau travail, merci ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Nettement mieux, quasi parfait dans l'ensemble. Heureusement pour ma passion de la critique surtout pas constructive encore, toujours et partout, j'ai trouvé ce qui me semble être des maladresses dans le cas de nom de ville assez long, dont la situation urbaine est décentrée par rapport à la situation géographique, et bousculé par un autre nom proche (fallait trouver). Exemple Annecy / Annecy le vieux : http://tile.openstreetmap.fr/?zoom=11lat=45.91166lon=6.11371layers=B00FFF Le nom Annecy le vieux déborde largement sur la surface géographique d'Annecy ; on le voit nettement au zoom 12 http://tile.openstreetmap.fr/?zoom=12lat=45.91333lon=6.1271layers=B00FFFoù les limites communales sont tracées et où le phénomène persiste. Il me semble que ça iinduit une erreur de placement intuitive auprès du lectorat. (tout ça pour dire que le rendu est fautif). ... mais enfin, j'ai parcouru toute la France, et c'est malheureusement le seul cas que je puisse rouspéter :-((( Merci. Le 19 août 2013 12:03, Christian Quest cqu...@openstreetmap.fr a écrit : Un peu de progrès sur le front des libellés de villes/villages... Je procède désormais en 2 passes, l'un pour positionner en priorité les libellés des principales villes, puis on ajoute les autres éléments comme les ref des routes, puis une deuxième passe de remplissage pour combler les espaces vides. J'ai aussi légèrement augmenté la taille du texte pour plus de lisibilité. Résultat: - osmfr avant: http://cl.ly/image/2m1t0c3r1Y2B - osmfr après: http://cl.ly/image/3p3K3n0Y410H - osm.org: http://cl.ly/image/2E1h3p2X302l Y'a pas photo ! Le zoom 11 a été recalculé sur l'hexagone. Autre changement... les aéroports/aérodromes, où j'ai ajouté un prétraitement pour supprimer le Aéroport|Aérodrome de|du|d'|de la dans le nom. J'ai voulu faire de même sur les gares, mais du coup la Gare de Lyon devennait Lyon :( ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Les dérives de rue : La municipalité de Saint-Étienne applaudit le théâtre emporté par le venthttp://drivrsdu.fr/la-municipalite-de-saint-etienne-applaudit-le-theatre-emporte-par-le-vent/ http://drivrsdu.fr/profession-emotion/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Pour les aéroports, l'Euroairport Basel-Mulhouse-Freibourg apparaît et disparait au gré des zooms. J'image que c'est du à la longueur du nom. Pas moyen de découper ? http://tile.openstreetmap.fr/?zoom=13lat=47.59468lon=7.53298layers=B00FFF http://tile.openstreetmap.fr/?zoom=12lat=47.60463lon=7.55049layers=B00FFF http://tile.openstreetmap.fr/?zoom=11lat=47.58125lon=7.58551layers=B00FFF http://tile.openstreetmap.fr/?zoom=10lat=47.57199lon=7.64731layers=B00FFF Sinon, j'aurai une requête concernant les passages à niveau : serait-il possible, vers le zoom 16, d'indiquer le n° (je le mets en ref, mais je suppose que d'autres le mette en name) précédé éventuellement d'une mention PN. Un couleur rouge (assez foncé) serait top et pour le symbole et pour le libellé. D'avance merci au nom du club des yakafaucon. -Message d'origine- De : Christian Quest [mailto:cqu...@openstreetmap.fr] Envoyé : lundi 19 août 2013 12:04 À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles... Un peu de progrès sur le front des libellés de villes/villages... Je procède désormais en 2 passes, l'un pour positionner en priorité les libellés des principales villes, puis on ajoute les autres éléments comme les ref des routes, puis une deuxième passe de remplissage pour combler les espaces vides. J'ai aussi légèrement augmenté la taille du texte pour plus de lisibilité. Résultat: - osmfr avant: http://cl.ly/image/2m1t0c3r1Y2B - osmfr après: http://cl.ly/image/3p3K3n0Y410H - osm.org: http://cl.ly/image/2E1h3p2X302l Y'a pas photo ! Le zoom 11 a été recalculé sur l'hexagone. Autre changement... les aéroports/aérodromes, où j'ai ajouté un prétraitement pour supprimer le Aéroport|Aérodrome de|du|d'|de la dans le nom. J'ai voulu faire de même sur les gares, mais du coup la Gare de Lyon devennait Lyon :( ___ 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
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Annecy et Annecy-le-Vieux sont deux communes différentes... c'est donc tout à fait normal ! Annecy: http://nominatim.openstreetmap.org/search.php?q=annecyviewbox=5.92%2C45.98%2C6.34%2C45.82polygon=1 Annecy-le-Vieux: http://nominatim.openstreetmap.org/search.php?q=annecy-le-vieuxviewbox=5.92%2C45.98%2C6.34%2C45.82polygon=1 Le 19 août 2013 13:45, Ista Pouss ista...@gmail.com a écrit : Nettement mieux, quasi parfait dans l'ensemble. Heureusement pour ma passion de la critique surtout pas constructive encore, toujours et partout, j'ai trouvé ce qui me semble être des maladresses dans le cas de nom de ville assez long, dont la situation urbaine est décentrée par rapport à la situation géographique, et bousculé par un autre nom proche (fallait trouver). Exemple Annecy / Annecy le vieux : http://tile.openstreetmap.fr/?zoom=11lat=45.91166lon=6.11371layers=B00FFF Le nom Annecy le vieux déborde largement sur la surface géographique d'Annecy ; on le voit nettement au zoom 12 http://tile.openstreetmap.fr/?zoom=12lat=45.91333lon=6.1271layers=B00FFFoù les limites communales sont tracées et où le phénomène persiste. Il me semble que ça iinduit une erreur de placement intuitive auprès du lectorat. (tout ça pour dire que le rendu est fautif). ... mais enfin, j'ai parcouru toute la France, et c'est malheureusement le seul cas que je puisse rouspéter :-((( Merci. Le 19 août 2013 12:03, Christian Quest cqu...@openstreetmap.fr a écrit : Un peu de progrès sur le front des libellés de villes/villages... Je procède désormais en 2 passes, l'un pour positionner en priorité les libellés des principales villes, puis on ajoute les autres éléments comme les ref des routes, puis une deuxième passe de remplissage pour combler les espaces vides. J'ai aussi légèrement augmenté la taille du texte pour plus de lisibilité. Résultat: - osmfr avant: http://cl.ly/image/2m1t0c3r1Y2B - osmfr après: http://cl.ly/image/3p3K3n0Y410H - osm.org: http://cl.ly/image/2E1h3p2X302l Y'a pas photo ! Le zoom 11 a été recalculé sur l'hexagone. Autre changement... les aéroports/aérodromes, où j'ai ajouté un prétraitement pour supprimer le Aéroport|Aérodrome de|du|d'|de la dans le nom. J'ai voulu faire de même sur les gares, mais du coup la Gare de Lyon devennait Lyon :( ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Les dérives de rue : La municipalité de Saint-Étienne applaudit le théâtre emporté par le venthttp://drivrsdu.fr/la-municipalite-de-saint-etienne-applaudit-le-theatre-emporte-par-le-vent/ http://drivrsdu.fr/profession-emotion/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Le lundi 19 août 2013 12:03:45 Christian Quest a écrit : Résultat: - osmfr avant: http://cl.ly/image/2m1t0c3r1Y2B - osmfr après: http://cl.ly/image/3p3K3n0Y410H - osm.org: http://cl.ly/image/2E1h3p2X302l Y'a pas photo ! Excellent ! Une toute petite remarque sur La Bourboule, elle apparaît bien au zoom 10 et 12, mais pas 11 (peut-être à cause de la ref D129 ?). http://tile.openstreetmap.fr/?zoom=11lat=45.59279lon=2.70596layers=B00FFF On voit pourtant bien Murat-le-Quaire, le village juste au-dessus, très sympatique, mais moins peuplé. Au passage, le bleu des lacs est un peu pâle, ce qui fait passer inaperçu les lacs des alentours. D'ailleurs, je suggère d'afficher les noms des lacs d'une certaine superficie avant le zoom 14, car ça peut être des bons repères géographiques. Dans ma région (chaîne des Puys), mais aussi ailleurs, puisque le nom du Lac léman et autres grands lacs des alpes pourraient aussi être sympa :-) Merci encore Christian et bravo. -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Hello ! Au zoom 6, en Vendée, olonne sur Mer apparait, mais pas la roche sur yon qui est pourtant beaucoup plus peuplée. Un problème de place ? Plus bizarre, pourquoi c'est olonne sur mer qui apparait en lieu et place de Les sables d'olonnes, située juste à coté et un peu plus peuplée ? Au zoom 7, ça redevient normal. Stf ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
zoom 10... le nom ne devrait pas être rendu, il est (encore) visible car la tuile n'a pas encore été recalculée. zoom 11... il est bien là zoom 12 et 13... et suivants, à vérifier sur les tuiles osmfr-lowzoom-test car les modifs de style ne sont pour l'instant pas reportées sur les tuiles osmfr en prod. Par contre là l'icône indique un simple aérodrome et pas un aéroport, et ça vient du aerodrome=continental que je ne connais pas seuls 'international' et 'airport' étaient pris en compte... je modifie pour les prochains rendus. Pensez aussi à vider votre cache... j'utilise par défaut Chrome mais j'ai configuré Firefox avec le cache désactivé pour tout mes tests, ça m'évite de m'énerver à cause d'une tuile pas fraîche ;) Le 19 août 2013 14:04, HELFER Denis denis.hel...@rff.fr a écrit : Pour les aéroports, l'Euroairport Basel-Mulhouse-Freibourg apparaît et disparait au gré des zooms. J'image que c'est du à la longueur du nom. Pas moyen de découper ? http://tile.openstreetmap.fr/?zoom=13lat=47.59468lon=7.53298layers=B00FFF http://tile.openstreetmap.fr/?zoom=12lat=47.60463lon=7.55049layers=B00FFF http://tile.openstreetmap.fr/?zoom=11lat=47.58125lon=7.58551layers=B00FFF http://tile.openstreetmap.fr/?zoom=10lat=47.57199lon=7.64731layers=B00FFF Sinon, j'aurai une requête concernant les passages à niveau : serait-il possible, vers le zoom 16, d'indiquer le n° (je le mets en ref, mais je suppose que d'autres le mette en name) précédé éventuellement d'une mention PN. Un couleur rouge (assez foncé) serait top et pour le symbole et pour le libellé. D'avance merci au nom du club des yakafaucon. -Message d'origine- De : Christian Quest [mailto:cqu...@openstreetmap.fr] Envoyé : lundi 19 août 2013 12:04 À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles... Un peu de progrès sur le front des libellés de villes/villages... Je procède désormais en 2 passes, l'un pour positionner en priorité les libellés des principales villes, puis on ajoute les autres éléments comme les ref des routes, puis une deuxième passe de remplissage pour combler les espaces vides. J'ai aussi légèrement augmenté la taille du texte pour plus de lisibilité. Résultat: - osmfr avant: http://cl.ly/image/2m1t0c3r1Y2B - osmfr après: http://cl.ly/image/3p3K3n0Y410H - osm.org: http://cl.ly/image/2E1h3p2X302l Y'a pas photo ! Le zoom 11 a été recalculé sur l'hexagone. Autre changement... les aéroports/aérodromes, où j'ai ajouté un prétraitement pour supprimer le Aéroport|Aérodrome de|du|d'|de la dans le nom. J'ai voulu faire de même sur les gares, mais du coup la Gare de Lyon devennait Lyon :( ___ 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 -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
2013/8/19 HELFER Denis denis.hel...@rff.fr: Sinon, j'aurai une requête concernant les passages à niveau : serait-il possible, vers le zoom 16, d'indiquer le n° (je le mets en ref, mais je suppose que d'autres le mette en name) précédé éventuellement d'une mention PN. Un couleur rouge (assez foncé) serait top et pour le symbole et pour le libellé. Oups. Il y a des numéros aux passages à niveau ? Où est-ce qu'on peut les voir ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Le 19 août 2013 14:16, Christian Quest cqu...@openstreetmap.fr a écrit : Annecy et Annecy-le-Vieux sont deux communes différentes... c'est donc tout à fait normal ! Comment ça tout à fait normal ?? Je le sais que c'est 2 communes différentes (d'importance similaire), d'où le fait qu'il me semblait qu'il était _A_normal que le nom de l'une déborde nettement sur la situation géographique de l'autre. On voit le phénomène sur ton lien : Annecy: http://nominatim.openstreetmap.org/search.php?q=annecyviewbox=5.92%2C45.98%2C6.34%2C45.82polygon=1 Si c'était moi, j'aurais placé le nom Annecy le vieux nettement plus à droite, au milieu de la commune, sans qu'il occupe rien du tout de l'espace d'annecy puisqu'il y a largement la place. Cordialement. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Ici par exemple : http://cartelie.application.equipement.gouv.fr/cartelie/voir.do?carte=SIG_BDPNservice=CETE_NCcontext=molsheim5743045780994961453 A savoir : tout PN du Réseau Ferré National fait l'objet d'un arrêté préfectoral. Exemple : http://www.bas-rhin.pref.gouv.fr/medias/fichiers/Recueil_no_24_du_15_decembre_2008.pdf p.2159 et suivantes Les n° sont visibles sur le terrain comme ici le PN 31 à Dettwiller : http://goo.gl/maps/8N4bw (panonceau bleu) -Message d'origine- De : Pieren [mailto:pier...@gmail.com] Envoyé : lundi 19 août 2013 14:53 À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles... 2013/8/19 HELFER Denis denis.hel...@rff.fr: Sinon, j'aurai une requête concernant les passages à niveau : serait-il possible, vers le zoom 16, d'indiquer le n° (je le mets en ref, mais je suppose que d'autres le mette en name) précédé éventuellement d'une mention PN. Un couleur rouge (assez foncé) serait top et pour le symbole et pour le libellé. Oups. Il y a des numéros aux passages à niveau ? Où est-ce qu'on peut les voir ? Pieren ___ 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
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Oups, je n'avais pas compris... Effectivement quand le nom est un peu long et le nœud place=* un peu trop proche de la limite de commune, ça peut déborder. Est-ce vraiment un problème ? Je ne pense pas, ça reste quand même clair et il suffit éventuellement de décaler le nœud place un peu plus à l'est dans le cas présent ce qui ne sera pas incohérent. Le 19 août 2013 15:12, Ista Pouss ista...@gmail.com a écrit : Le 19 août 2013 14:16, Christian Quest cqu...@openstreetmap.fr a écrit : Annecy et Annecy-le-Vieux sont deux communes différentes... c'est donc tout à fait normal ! Comment ça tout à fait normal ?? Je le sais que c'est 2 communes différentes (d'importance similaire), d'où le fait qu'il me semblait qu'il était _A_normal que le nom de l'une déborde nettement sur la situation géographique de l'autre. On voit le phénomène sur ton lien : Annecy: http://nominatim.openstreetmap.org/search.php?q=annecyviewbox=5.92%2C45.98%2C6.34%2C45.82polygon=1 Si c'était moi, j'aurais placé le nom Annecy le vieux nettement plus à droite, au milieu de la commune, sans qu'il occupe rien du tout de l'espace d'annecy puisqu'il y a largement la place. Cordialement. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Le 19/08/2013 15:12, Ista Pouss a écrit : Le 19 août 2013 14:16, Christian Quest cqu...@openstreetmap.fr mailto:cqu...@openstreetmap.fr a écrit : Annecy et Annecy-le-Vieux sont deux communes différentes... c'est donc tout à fait normal ! Comment ça tout à fait normal ?? Je le sais que c'est 2 communes différentes (d'importance similaire), d'où le fait qu'il me semblait qu'il était _A_normal que le nom de l'une déborde nettement sur la situation géographique de l'autre. On voit le phénomène sur ton lien : Annecy: http://nominatim.openstreetmap.org/search.php?q=annecyviewbox=5.92%2C45.98%2C6.34%2C45.82polygon=1 Si c'était moi, Just do it j'aurais placé le nom Annecy le vieux nettement plus à droite, au milieu de la commune, sans qu'il occupe rien du tout de l'espace d'annecy puisqu'il y a largement la place. Le nom s'affiche là où est le noeud. C'est tout. Le rendu français n'est pas fait à la main dans photoshop ! Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Bonjour Le 19/08/2013 15:16, HELFER Denis a écrit : Les n° sont visibles sur le terrain comme ici le PN 31 à Dettwiller :http://goo.gl/maps/8N4bw (panonceau bleu) Hum, cela ressemble plutôt à un point kilométrique. Ce serait donc plutôt le PK 31 plutôt que le PN 31. Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Bien sûr que le PN ont des numéros. Les journaux locaux y font souvent référence : http://www.ladepeche.fr/article/2013/05/06/1620378-saint-germier-les-premieres-etudes-au-passage-a-niveau.html http://www.lot.fr/cg_suite.php?newsid=1147 Et pas seulement en France : http://rixke.tassignon.be/spip.php?article1349 Art. Le 19 août 2013 14:53, Pieren pier...@gmail.com a écrit : 2013/8/19 HELFER Denis denis.hel...@rff.fr: Sinon, j'aurai une requête concernant les passages à niveau : serait-il possible, vers le zoom 16, d'indiquer le n° (je le mets en ref, mais je suppose que d'autres le mette en name) précédé éventuellement d'une mention PN. Un couleur rouge (assez foncé) serait top et pour le symbole et pour le libellé. Oups. Il y a des numéros aux passages à niveau ? Où est-ce qu'on peut les voir ? Pieren ___ 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
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Bonjour Le 19/08/2013 17:16, David Crochet a écrit : Bonjour Hum, cela ressemble plutôt à un point kilométrique. Ce serait donc plutôt le PK 31 plutôt que le PN 31. Erreur de ma part, les PK, c'est écriture rouge sur fond blanc. Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Encore quelques bizarrerie dans les zone peu peuplé. La commune de Murat 2000h - la plus grosse commune et de loin a 30 ou 40km a la ronde - n'apparait pas alors que les deux communes voisines - Chastel sur Murat et Bredons - de 100h apparaissent http://tile.openstreetmap.fr/?zoom=11lat=45.10553lon=2.88165layers=B00FFFSemble t il masqué par l'étiquette de la route D926? Meme chose a Riom-Es-Montagne - 3000h - la plus grosse ville a 100km a la ronde. http://tile.openstreetmap.fr/?zoom=11lat=45.28429lon=2.64823layers=B00FFFElle n'apparait qu'a partir du zoom 13, le reste du temps caché par l'étiquette de la route D3 visiblement. Ne serait il pas plus judicieux de forcer l'affichage des chef lieu de canton et d'arrondissement pour compléter le tri par population qui est naturellement très relatif en fonction de la densité de la région envisagée. Néanmoins on note une réelle et globale amélioration de l'affichage de commune dans ce nouveau rendu ;) Les imperfections affectant essentiellement les zone très peu peuplés. Le zoom 9 a été modifié? par que j'y trouve aussi des drôles de de bizarrerie. Le 19 août 2013 17:20, David Crochet david.croc...@online.fr a écrit : Bonjour Le 19/08/2013 17:16, David Crochet a écrit : Bonjour Hum, cela ressemble plutôt à un point kilométrique. Ce serait donc plutôt le PK 31 plutôt que le PN 31. Erreur de ma part, les PK, c'est écriture rouge sur fond blanc. Cordialement -- David Crochet __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Même chose avec les îles d'Oléron et de Ré qui prennent le pas sur La Rochelle. Sans doute à cause du placement du libellé un peu long Poitou-Charentes concernant le niveau 6 (qui pourrait avantageusement pourtant être écrit sur 2 lignes au lieu d'une seule et éviter de masquer trop de choses à l'ouest). Mais pour le niveau 7, toujours pas La Rochelle alors qu'on a les deux îles. La question ici c'est : est-ce mieux de voir l'île de Ré ou la Rochelle ? Pourtant à partir du niveau 9 (où la Rochelle est visible), les noms d'îles disparaissent et on voit une commune masi pas la plus peuplée (on voit La Couarde-sur-Mer mais pas Le Bois-Plage-en-Ré ou Sainte--Marie-en-Ré. Il semble que le nom des îles (affiché en caractères italiques) prenne la priorité sur les noms des communes (qui devraient rester affichés en caractères droits, pour ne pas les confondre avec les bourgs et quartiers qui devraient rester en italique et d'un gris plus clair) si elles ont une taille suffisante (il se trouve que justement ces deux îles sont plus grandes en surface que la commune de la Rochelle seule) indépendamment de leur population (puisqu'elles n'ont pas de population renseignée, chacune de ces 2 îles étant coupées en plusieurs communes). *** Un réglage à faire donc entre îles d'une certaine taille, et communes importantes. *** Sinon au Nord de Rennes (Bretagne), on voit dès le zoom 10 le tout petit bourg de Maison-Blanche, mais pas le nom de la commune qui le contient, Saint-Grégoire, pas plus que l'on voit Cesson-Sévigné non plus (limitrophe de Rennes à l'Est) alors que c'est une des communes les plus peuplées d'Ille-et-Vilaine (bien plus que Saint-Jacques-de-la-Lande elle aussi limitrophe de Rennes mais dont la plus grande partie est occupée par des marais et par l'aéroport, avec sa partie la plus peuplée en fait située dans la rocade comme un quartier interne de Rennes. Je ne comprend pas d'ailleurs pourquoi Maison-Blanche (qui se limite à une cinquantaine de maisons autour d'un petit bout d'une avenue, 2 petites rues résidentielles attenantes et de très courtes impasses) n'est pas en gris clair comme les noms des quartiers de Rennes, alors que c'est bien ici un nom de quartier à Saint-Grégoire. Au niveau 11, toujours pas Saint-Grégoire mais Maison-Blanche. On dirait que c'est le placement du cartouche de la D 29 (qui apparait à ce niveau) qui empêche de placer le nom de la commune. Là il semble donc que c'est le placement des cartouches qui ne profite pas de la grande liberté pour le placer : dans la passe où le rendu place les cartouches de routes, aucune commune hors des city n'est encore placé ou dans la liste à traiter. et le moteur se contente de déterminer une position arbitraire pour le cartouche (parfois plusieurs fois comme on le voit ensuite au niveau 12 qui choisit **deux** autres emplacements mais pas le même à l'intersection de la D 137) et il ne revient jamais dessus. Ce cartouche semble occuper une place rectangulaire plus grande que nécessaire pour placer ensuite les toponymes suivants, et aussi le critère de distance/densité entre les toponymes (noms de communes, villages non communaux, îles...) devrait être moins strict concernant la distance entre un cartouche déjà placé et un toponyme déjà placé. car il n'y a pas de risque de confusion : il n'est pas du tout nécessaire de retenir une marge autour des cartouches pour placer un nouveau toponyme, alors que c'est utile d'ajouter cette marge autour des autres toponymes. *** Un réglage à faire donc sur les marges à conserver autour des cartouches de routes (la marge est à considérer entre deux cartouches mais doit être réduite à pratiquement zéro après les avoir placés, pour que cela n'empêche pas le placement des autres toponymes importants non traités en première passe). *** Au zoom 14, d'ailleurs le petit bourg de Maison-Blanche est (comme aussi la commune de Saint-Grégoire) affiché plus petit que les quartiers de Rennes (comme Saint-Laurent). Le zoom 14 est correct pour Maison-Blanche, mais Saint-Grégoire (abrégé St-Grégoire) visible me semble encore trop petit (alors que cette commune est du même ordre de population et de surface que Betton très visible, plus même que Cesson-Sévigné pourtant plus peuplé encore). Même le petit bourg de La Vizeule (à l'ouest de Saint-Grégoire sur la D137, un peu à l'écart au sud-est de la commune de Montgermont) est plus visible que Saint-Grégoire (mais on voit le petit bourg de la Maison-Blanche à Saint-Grégoire bien avant celui de La Vizeule à Montgermont, alors qu'en surface habitée La Vizeule est plus grande, mais moins dense, que Maison-Blanche). Globalement on voit les limites du système des tags pour place=*, et il nous faudrait autre chose intermédiaire entre place=village (gardé pour la commune) et place=hamlet, pour qualifier les bourgs ruraux à l'écart dans une commune (et pas sûr que place=suburb soit adapté quand on l'utilise pour les quartiers administratifs de grandes villes) et qui
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
bonjour, Que de difficults pour "rendre" une carte partir de donnes non unifies... - Au zoom 9 ne faudrait-il pas rendre plus visibles les limites des dpartements dans un violet leger? (elles sont prsentes mais quasi invisible) - pour nommer les dpartements, une technique de violet gras semi-transparent en trs grosse typo qui pourrait tre plac en fond et recouvrable par la toponymie des villes serait peut tre lisible ? serait-ce valable aussi pour les autres pays ? - zoom 8 :un brin de prsence supplmentaire pour les villes d'envergures rgionales serait-peut tre mieux, en restant dans une taille en dessous de celle des rgions (voire augmenter celle des rgions?) - quoi la confiture ? ;) djo_man Le 17/08/2013 20:06, Christian Quest a crit: J'ai modifi la requte pour les noms de capitales, en effet, le schma de tag est peu clair et il y a plein de variations: - is_capital=country - capital=yes + admin_level=2 - capital=2 La requte gre maintenant les 3 possibilits, et j'en ai profite pour complter les quelques capitales pour lesquelles il manquait des infos. Les zoom jusqu' 7 ont t recalculs, c'est nettement mieux. J'ai aussi mis les libells un tout petit peu plus gros. Autre changement majeur: un patch mapnik pour grer diffremment les limites entre metatile. L'effet est qu'il y a beaucoup moins de textes et cartouches coups. Il m'en reste encore sur une requte trs spciale pour les noms de rues. Ds que celle-ci sera corrige et les tuiles recalcules, je lancerai un concours o il y aura un pot de confiture (maison) gagner si vous trouvez un texte coup ;) ___ 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
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Le 18 août 2013 14:34, djo_man djo_...@laposte.net a écrit : bonjour, Que de difficultés pour rendre une carte à partir de données non unifiées... - Au zoom 9 ne faudrait-il pas rendre plus visibles les limites des départements dans un violet leger? (elles sont présentes mais quasi invisible) Oui, ça mérite d'être un peu plus visible. - pour nommer les départements, une technique de violet gras semi-transparent en très grosse typo qui pourrait être placé en fond et recouvrable par la toponymie des villes serait peut être lisible ? serait-ce valable aussi pour les autres pays ? Pas évident que ça puisse convenir avec les algos de base. En effet, si on met un texte en très gros et en placement libre (c'est à dire sur lequel on peut placer d'autres choses, textes et icônes), ça risque de se superposer dans les pays où les départements sont très petits... il faudrait donc en plus avoir un garde fou sur la superficie du département. Pas simple, mais pas impossible. - zoom 8 :un brin de présence supplémentaire pour les villes d'envergures régionales serait-peut être mieux, en restant dans une taille en dessous de celle des régions (voire augmenter celle des régions?) Là aussi, c'est pas simple sauf si on veut optimiser le résultat sur la France quitte à avoir quelque chose de moins lisible ailleurs. Regarde les pays voisins... notre tissus de 36000 communes fait qu'on a beaucoup de village et peu de town. - à quoi la confiture ? ;) Au choix: fraises, groseilles, framboise, rhubarbe-banane, abricots, toutes faites maison et siglées OpenStreetMap ;) -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Le 17 août 2013 20:06, Christian Quest cqu...@openstreetmap.fr a écrit : Autre changement majeur: un patch à mapnik pour gérer différemment les limites entre metatile. L'effet est qu'il y a beaucoup moins de textes et cartouches coupés. Il m'en reste encore sur une requête très spéciale pour les noms de rues. Dès que celle-ci sera corrigée et les tuiles recalculées, je lancerai un concours où il y aura un pot de confiture (maison) à gagner si vous trouvez un texte coupé ;) Ca progresse bien sur les frontières de metatiles... quasiment plus de défauts à par un que j'ai identifié mais pas encore corrigé ;) Le concours n'est pas ouvert, mais vous pouvez vous entrainer sur http://tile.openstreetmap.fr/?layers=B00FFF (layer osmfr-lowzoom-test, c'est lui qui me sert de test). Il faut être un peu patient car les tuiles ne pas précalculées (sauf zoom 1 à 11 qui sont communs avec osmfr), mais cela permet de voir plus facilement où se trouvent les limites des metatile lorsqu'on se déplace et donc ça aide au repérage des défauts. -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Le 18 août 2013 16:13, Christian Quest cqu...@openstreetmap.fr a écrit : Au choix: fraises, groseilles, framboise, rhubarbe-banane, abricots, toutes faites maison et siglées OpenStreetMap ;) Question goût, que dire de rhubarbe-banane ? Avec de la rhubarbe fraiche OK, mais pas avec les bananes importées, même bio. Association étrange de gout et texture entre l'acidité et l'amertume de la rhubarbe (qu'on apprécie aussi pour sa texture filandreuse), et la douceur sucrée mais sa texture très pâteuse. Pour moi une bonne confiture ne mélange pas les fruits pour que chacun soit cuit de façon optimale sans perdre ses goûts spécifiques et sa texture. Banane et rhubarbe ne peuvent pas cuire aussi longtemps l'un que l'autre (on doit monter davantage en température pour la rhubarbe pour lui faire perdre aussi plus d'eau, alors que si on fait ça à la banane, on la brûle... Et la rhubarbe pas assez cuite est franchement pas terrible en confiture. Les deux fruits ne demandent pas non plus la même quantité de sucre. Si on veut un mélange de fruit, on le fait après cuisson au moment de servir, c'est bien meilleur. Si on ajoute des épices (poivre, cannelle...), c'est seulement après cuisson dans les fruits encore chauds (mais pas trop sinon on dégrade les arômes de l'épice qui donnent laors mauvais goût). Moi je fais mes propres compotes de pomme, et j'y met du poivre (que je trouve bien meilleur et moins lourd que la cannelle utilisée juste dans la pâtisserie bon marché avec des pommes de mauvaise qualité) et des zestes de citron (le jus de citron c'est dès le début de cuisson pour éviter l'oxydation) ; variantes épicées possibles aussi avec l'anis étoilé (moulu et entier) ou la cardamome. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Le 18/08/2013 20:55, Philippe Verdy a écrit : Le 18 août 2013 16:13, Christian Quest cqu...@openstreetmap.fr mailto:cqu...@openstreetmap.fr a écrit : Au choix: fraises, groseilles, framboise, rhubarbe-banane, abricots, toutes faites maison et siglées OpenStreetMap ;) Question goût, que dire de rhubarbe-banane ? [...] variantes épicées possibles aussi avec l'anis étoilé (moulu et entier) ou la cardamome. Je suis déçu que ton message soit si court sur un sujet que tu n'avais jamais étalé (comme la confiture) sur la liste... Après tout le sujet est vaste, et tu aurais pu continuer à disserter sur l’intérêt d'utiliser une bassine en cuivre pour la cuisson, de rajouter ou non de la pectine, le type de sucre à utiliser (glucose, fructose ou saccharose). Comment stériliser et conserver les pots pendant des années... J'ai confiance en toi, je sais que tu es capable de développer le sujet... Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
C'est surtout en voyant le mélange banane-rhubarbe proposé. C'est peut-être à ton goût mais je doute fortement de l'intérêt de la recette, sauf si c'est pour faire une compote pour bébés (pas besoin de longue cuisson). Ceci dit ce n'est pas moi qui ai lancé le sujet. Mais puisqu'on en était à proposer ses recettes de confitures... la confiture est faite pour être étalée. Le 18 août 2013 23:13, Christophe Merlet red...@redfoxcenter.org a écrit : Le 18/08/2013 20:55, Philippe Verdy a écrit : Le 18 août 2013 16:13, Christian Quest cqu...@openstreetmap.fr mailto:cquest@openstreetmap.**fr cqu...@openstreetmap.fr a écrit : Au choix: fraises, groseilles, framboise, rhubarbe-banane, abricots, toutes faites maison et siglées OpenStreetMap ;) Question goût, que dire de rhubarbe-banane ? [...] variantes épicées possibles aussi avec l'anis étoilé (moulu et entier) ou la cardamome. Je suis déçu que ton message soit si court sur un sujet que tu n'avais jamais étalé (comme la confiture) sur la liste... Après tout le sujet est vaste, et tu aurais pu continuer à disserter sur l’intérêt d'utiliser une bassine en cuivre pour la cuisson, de rajouter ou non de la pectine, le type de sucre à utiliser (glucose, fructose ou saccharose). Comment stériliser et conserver les pots pendant des années... J'ai confiance en toi, je sais que tu es capable de développer le sujet... Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
J'ai modifié la requête pour les noms de capitales, en effet, le schéma de tag est peu clair et il y a plein de variations: - is_capital=country - capital=yes + admin_level=2 - capital=2 La requête gère maintenant les 3 possibilités, et j'en ai profite pour compléter les quelques capitales pour lesquelles il manquait des infos. Les zoom jusqu'à 7 ont été recalculés, c'est nettement mieux. J'ai aussi mis les libellés un tout petit peu plus gros. Autre changement majeur: un patch à mapnik pour gérer différemment les limites entre metatile. L'effet est qu'il y a beaucoup moins de textes et cartouches coupés. Il m'en reste encore sur une requête très spéciale pour les noms de rues. Dès que celle-ci sera corrigée et les tuiles recalculées, je lancerai un concours où il y aura un pot de confiture (maison) à gagner si vous trouvez un texte coupé ;) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
J'ai intégré les nouveaux zoom 1 à 11 au rendu FR... Quelques explications ici: http://openstreetmap.fr/blogs/cquest/rendu-fr-premiers-zooms Pour leur recalcul, explications là: http://wiki.openstreetmap.org/wiki/FR:Servers/tile.openstreetmap.fr et là http://openstreetmap.fr/blogs/cquest/osm-fr-faibles-zooms ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
bonjour Je n'ai pas encore particip aux remarques sur ce rendu TOP FR Voici les miennes : zoom 3 - la disparition des frontires est interessante mais dans ce cas il faudrait sans doute renforcer la visibilit des noms des continents zoom 4 - quelle est cette capitale qui prend lieu et place de la cte du cap Sizun ? il s'agit de cette limite administrative en fait : http://www.openstreetmap.org/browse/way/232710933 - il manque un paquet de points noirs capitales ? zoom 5 - la Sardaigne et la Sicile affichent leurs ctes - il manque un paquet de noms de capitales ? zoom 6 - rien dire personnellement, top zoom 7 - si les dpartements devaient tre cits ce serait pas sur ce niveau de zoom ? mais cela ferait du monde, je sais... Rien dire de plus Sauf peut tre revenir sur une vieille discution sur la couleur trs peut visible (zoom 8-9-10) des trunks vertes ? (je pense toujours aprs rflexion qu'une dclinaison de violet serait la bonne couleur) Merci toi Christian pour tes efforts de nous doter d'une carte vraiment exploitable djo_man Le 16/08/2013 08:43, Christian Quest a crit: J'ai intgr les nouveaux zoom 1 11 au rendu FR... Quelques explications ici: http://openstreetmap.fr/blogs/cquest/rendu-fr-premiers-zooms Pour leur recalcul, explications l: http://wiki.openstreetmap.org/wiki/FR:Servers/tile.openstreetmap.fr et l http://openstreetmap.fr/blogs/cquest/osm-fr-faibles-zooms ___ 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
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Le 16 août 2013 14:51, djo_man djo_...@laposte.net a écrit : zoom 4 - quelle est cette capitale qui prend lieu et place de la côte du cap Sizun ? il s'agit de cette limite administrative en fait : http://www.openstreetmap.org/browse/way/232710933 Cela démontre la nuisibilité des tags boundary=administrative et admin_level=* sur les chemins de frontières de limites administratives côtières. On ne devrait les mettre que su les ways partagés par des relations administratives de même niveaux des deux côtés du chemin. Et même si la ligne de côte et la frontière ne partagent pas exactement le même tracé (car ces chemins ne sont pas encore fusionnés. Ou seulement sur des chmins de frontières maritimes (uniquement ceux qui ont maritime=yes, pour les limites des eaux territoriales ou ZEE) On a le problème du côté de la Méditerranée près de Fréjus. Dans les deux cas, cette frontière taguée en admin_level=2 n'a pas de sens car ce n'est pas une frontière internationale (contrairement à la frontière des 12 miles), ni même une frontière communale car ce n'est pas la ligne de base (qu' en fait on ne connait pas précisément), ni la frontière de département (pour la même raison), ni celle de la région (la région maritime, de compétence du préfet de région mais pas de la collectivité région (qui utilise la ligne de base), s'étend jusqu'à la frontière territoriale de 12 miles). En raison de l'ambiguïté de compétence entre celle exclusive de l'Etat (via ses préfets) et celle des collectivités locales (sur la ligne de base mal définie) il vaut mieux ne rien mettre du tout en France sur les chemins de frontières côtières, dont le tracé reste indicatif dans la relation pour seulement suivre d'assez près les lignes côtières, avec trop souvent une ambiguité concernant les plages et les limites des hauteurs de marées ou du seul retenu pour leur amplitude qui varie sans cesse dans l'année et qui évolue avec le temps, notamment aussi car d'une part nos côtes ont de moins en moins de sable, qu'on extrait massivement, et d'autre part par l'érosion marine, ainsi que dans les baies par l'ensablement naturel, freiné par les extractions qui vont aussi impliquer un apport moins important sur les autres côtes soumises à l'érosion). Bref, ne garder boundary=administrative et admin_level=* que sur les frontières terrestres (ou celles au milieu des fleuves mais pas non plus celles fermant l'embouchure d'un fleuve). Et poursuivre le travail de fusion des chemins limitant les relations administratives le long des côtes (natural=coastline suffit à lui seul). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Le 16 août 2013 14:51, djo_man djo_...@laposte.net a écrit : bonjour Je n'ai pas encore participé aux remarques sur ce rendu TOP FR Voici les miennes : zoom 3 - la disparition des frontières est interessante mais dans ce cas il faudrait sans doute renforcer la visibilité des noms des continents zoom 4 - quelle est cette capitale qui prend lieu et place de la côte du cap Sizun ? il s'agit de cette limite administrative en fait : http://www.openstreetmap.org/browse/way/232710933 C'est un bug que j'ai ailleurs aussi. J'ai une idée pour éliminer ces frontières... vérifier qu'elles appartiennent à 2 relations de même admin_level. Je voulais m'appuyer sur la présence de natural=coastline, mais ce n'est pas suffisant vu cet exemple. - il manque un paquet de points noirs capitales ? Bien possible, c'est le tag is_capital=country qui est utilisé sur un nœud place=city/town zoom 5 - la Sardaigne et la Sicile affichent leurs côtes - il manque un paquet de noms de capitales ? Même requête... c'est bien ça met en évidence un manque de cohérence dans les data ;) Il y a des noms de capitale que j'ai corrigé/traduit grâce à de niveau de zoom du rendu. zoom 6 - rien à dire personnellement, top :) zoom 7 - si les départements devaient être cités ce serait pas sur ce niveau de zoom ? mais cela ferait du monde, je sais... Et oui, trop de monde... j'ai essayé et il faut voir aussi par rapport à d'autres pays, par exemple l'Allemagne où les admin_level=6 sont beaucoup plus petits et nombreux (et je ne parle pas du Luxembourg, mais là il n'y aurait pas la place de mettre un seul nom). J'ai essayé de trouver un équilibre qui tienne à peu près la route entre ces situations très différentes. Eventuellement, il faudrait que je me base non pas sur l'admin_level mais sur la superficie du découpage en question... à tester ;) Rien à dire de plus Sauf peut être revenir sur une vieille discution sur la couleur très peut visible (zoom 8-9-10) des trunks vertes ? (je pense toujours après réflexion qu'une déclinaison de violet serait la bonne couleur) Trop pâle ? J'avais modifie les trunk pour avoir un peu plus de contraste avec les landuse verts... Merci à toi Christian pour tes efforts de nous doter d'une carte vraiment exploitable De rien ! -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
C'est le tag population=* sur le nœud place=* dont je me sert et uniquement ça. Eventuellement je pourrais remonter vers le population=* de la relation de la commune quand elle existe (on n'est pas à 100% même si on se rapproche). Oui, il en manque sur les petites communes, mais ce sont celles qui sont le moins prioritaires à mettre sur la carte. Oui, ce n'est pas forcément à jour, mais les ordres de grandeur pour les tris ne sont pas bouleversés pour autant. Le rendu dépend forcément de la cohérence des données ici comme partout ! Le 18 juillet 2013 07:33, Tetsuo Shima tets...@gmail.com a écrit : Avant que je pose des questions bêtes... dis moi Christian, la population des nodes place tu la prends directement dans le geofla? ou bien tu prends celle qu'il y a dans la base OSM? Parce que ce tag ne semble pas souvent rempli pour les petites communes dans OSM, et accessoirement elle n'est pas forcément homogène - obsolescence des donnée, divers source etc. - 2013/7/17 Christian Quest cqu...@openstreetmap.fr: Les zoom 3 à 7 sont en cours de régénération après avoir supprimé quelques pays parasites... http://www.openstreetmap.org/browse/changeset/16990256 ___ 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 -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Le 18 juillet 2013 09:36, Christian Quest cqu...@openstreetmap.fr a écrit : Le rendu dépend forcément de la cohérence des données ici comme partout ! Oui je comprends bien, mais il n'y a pas un bot qui maintient cela? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Le 17/07/2013 14:34, Philippe Verdy a écrit : Le 17 juillet 2013 09:01, Christian Quest cqu...@openstreetmap.fr mailto:cqu...@openstreetmap.fr a écrit : J'ai retravaillé le zoom 10... - j'ai amélioré le tracé des limites de pays Avec maintenant des trous dans les frontières par endroit (ici le niveau 11: http://tile.openstreetmap.fr/?zoom=11lat=50.87114lon=24.01423layers=B0FFF et tous les niveaux 10 et moins). Apparemment si le chemin ne contient pas explicitement un admin_level tu ne vas pas le chercher dans les relations dont il est membre. La correction est plus rapide que la remarque ! C'est fait ! Anomalie identique entre Mexique et USA au nord-Est de Monterrey: http://tile.openstreetmap.fr/?zoom=9lat=26.39221lon=-98.92668layers=B0FFF Certes on peut corriger en mettant les admin_level manquants ou corrects dans les chemins. Mais c'est le genre de truc secondaire dans les données, une redondance dont le moteur de rendu devrait pouvoir se passer, par une préparation en amont des données de frontières et reclacul des admin_level corrects. Aussi aux faibles niveaux de zoom les frontières autour des déserts (en jaune d'or) sont trop visibles (exemple entre Tunisie et Lybie) et ne devraient même pas être visibles du tout. On ne voit que ça, mieux que les frontières internationales alors que ces déserts ont des contours flous et ne sont pas des frontières. Encore quelques effets de pâtés dans la méthode de simplification des contours (exemple: au sud-est du Liechtenstein) qui produit des traits plus gras que nécessaire par endroit par accumulation excessive de points arrondis Sinon bravo pour avoir enlevé leur couloir noire incongrue qui était beaucoup trop contrastée (et trop gras en plus, ce qui masquait trop de chose). Il reste à unifier les styles de polices pour que villes et régions ne mélangent pas caractères italiques et droits sans règle établie (qui varie en plus selon le zoom). a mon avis toutes les villes devraient avoir des caratèes droits (n'utiliser les italiques qu'au delà du niveau 8 ou pour les noms de pays et régions (en caractères plus grands mais moins contrastés, plus gras aussi mais plus transparents). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Marc Sibert mailto:m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Le 18 juillet 2013 19:32, Marc Sibert m...@sibert.fr a écrit : Le 17/07/2013 14:34, Philippe Verdy a écrit : Le 17 juillet 2013 09:01, Christian Quest cqu...@openstreetmap.fr a écrit : J'ai retravaillé le zoom 10... - j'ai amélioré le tracé des limites de pays Avec maintenant des trous dans les frontières par endroit (ici le niveau 11: http://tile.openstreetmap.fr/?zoom=11lat=50.87114lon=24.01423layers=B0FFF et tous les niveaux 10 et moins). Apparemment si le chemin ne contient pas explicitement un admin_level tu ne vas pas le chercher dans les relations dont il est membre. La correction est plus rapide que la remarque ! C'est fait ! Hu... ça bogue, c'est pire qu'avant (oui j'ai forcé le refresh de la même zone au niveau 11) !!! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
J'ai retravaillé le zoom 10... - le placement des place=village est moins prioritaire, du coup ils ne bouffent pas tout l'espace et les références des autoroutes, sont de retour, ainsi que d'autre libellés - j'ai amélioré le tracé des limites de pays A comparer avec le rendu OSM actuel et le rendu OSM-FR non modifié. OSM-FR-lowzoom: http://tile.openstreetmap.fr/?zoom=10lat=50.69812lon=2.95486layers=B0FFF OSM-FR: http://tile.openstreetmap.fr/?zoom=10lat=50.69812lon=2.95486layers=B0FFF OSM défaut: http://tile.openstreetmap.fr/?zoom=10lat=50.69812lon=2.95486layers=00B000FFF -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Le 17/07/2013 09:01, Christian Quest a écrit : J'ai retravaillé le zoom 10... - le placement des place=village est moins prioritaire, du coup ils ne bouffent pas tout l'espace et les références des autoroutes, sont de retour, ainsi que d'autre libellés - j'ai amélioré le tracé des limites de pays A comparer avec le rendu OSM actuel et le rendu OSM-FR non modifié. OSM-FR-lowzoom: http://tile.openstreetmap.fr/?zoom=10lat=50.69812lon=2.95486layers=B0FFF OSM-FR: http://tile.openstreetmap.fr/?zoom=10lat=50.69812lon=2.95486layers=B0FFF OSM défaut: http://tile.openstreetmap.fr/?zoom=10lat=50.69812lon=2.95486layers=00B000FFF Excellent ce rendu ! Et de mieux en mieux ! Merci pour ce travail de fourmi zélée ! -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Le 17/07/2013 09:01, Christian Quest a écrit : J'ai retravaillé le zoom 10... Après les éloges... Quelques suggestions : Pour les abréviations : Machin-sur-Truc : Machin/Truc [1] Style : [2] Entre le zoom 13 et 14, le nom de la ville passe de droit à italique... [3] Nom de la commune présent deux fois [3] Étrange ces pylônes sans ligne... [1] http://tile.openstreetmap.fr/?zoom=10lat=47.97226lon=4.59508layers=B0FFF [2] http://tile.openstreetmap.fr/?zoom=14lat=50.07397lon=3.34131layers=B0FFF http://tile.openstreetmap.fr/?zoom=13lat=50.07397lon=3.34131layers=B0FFF [3] http://tile.openstreetmap.fr/?zoom=16lat=50.08438lon=3.36949layers=B0FFF -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Bonjour, Excellent ce rendu ! Et de mieux en mieux ! Merci pour ce travail de fourmi zélée ! +1 Sinon j'ai essayé de mettre à jour certaines limites de Pays en Amérique du Sud ; est ce que le rendu à été réactualisé? (pour voir si les changements sont correct!) (changement sur l'admin_level=2 et sur les frontières maritime) http://tile.openstreetmap.fr/?zoom=8lat=7.14355lon=-59.68305layers=B0FFF http://tile.openstreetmap.fr/?zoom=4lat=-9.86698lon=-82.79004layers=B0FFF Merci, Simon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Quelques suggestions : Pour les abréviations : A propos des abréviations, je suis dubitatif face à l'abréviation de Rocade : Roc. C'est la première fois que je vois cette abréviation et je ne la trouve pas naturelle. Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Le 17 juillet 2013 09:01, Christian Quest cqu...@openstreetmap.fr a écrit : J'ai retravaillé le zoom 10... - j'ai amélioré le tracé des limites de pays Avec maintenant des trous dans les frontières par endroit (ici le niveau 11: http://tile.openstreetmap.fr/?zoom=11lat=50.87114lon=24.01423layers=B0FFF et tous les niveaux 10 et moins). Apparemment si le chemin ne contient pas explicitement un admin_level tu ne vas pas le chercher dans les relations dont il est membre. Anomalie identique entre Mexique et USA au nord-Est de Monterrey: http://tile.openstreetmap.fr/?zoom=9lat=26.39221lon=-98.92668layers=B0FFF Certes on peut corriger en mettant les admin_level manquants ou corrects dans les chemins. Mais c'est le genre de truc secondaire dans les données, une redondance dont le moteur de rendu devrait pouvoir se passer, par une préparation en amont des données de frontières et reclacul des admin_level corrects. Aussi aux faibles niveaux de zoom les frontières autour des déserts (en jaune d'or) sont trop visibles (exemple entre Tunisie et Lybie) et ne devraient même pas être visibles du tout. On ne voit que ça, mieux que les frontières internationales alors que ces déserts ont des contours flous et ne sont pas des frontières. Encore quelques effets de pâtés dans la méthode de simplification des contours (exemple: au sud-est du Liechtenstein) qui produit des traits plus gras que nécessaire par endroit par accumulation excessive de points arrondis Sinon bravo pour avoir enlevé leur couloir noire incongrue qui était beaucoup trop contrastée (et trop gras en plus, ce qui masquait trop de chose). Il reste à unifier les styles de polices pour que villes et régions ne mélangent pas caractères italiques et droits sans règle établie (qui varie en plus selon le zoom). a mon avis toutes les villes devraient avoir des caratèes droits (n'utiliser les italiques qu'au delà du niveau 8 ou pour les noms de pays et régions (en caractères plus grands mais moins contrastés, plus gras aussi mais plus transparents). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Am 17.07.2013 09:01, schrieb Christian Quest: J'ai retravaillé le zoom 10... - le placement des place=village est moins prioritaire, du coup ils ne bouffent pas tout l'espace et les références des autoroutes, sont de retour, ainsi que d'autre libellés Merci pour cette amélioration qui fait que mon village (moins de 2000h) est affiché en zoom 10 ;) place=village couvre un éventail trop large pour servir de seul critère de sélection. Il faudrait saisir l'attribut population=* de façon systématique pour pouvoir parametriser le rendu en fonction du nombre d'habitants. Existe-t-il une source de données libre pour cette information? Rainer ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Le rendu lowzoom en test ne se recalcule pas tout seul lorsqu'il y a des changements. Je vais refaire une passe sur les premiers zooms pour qu'ils prennent en compte les dernières données. Le 17 juillet 2013 12:25, Simon Miniou simon.min...@gmail.com a écrit : Bonjour, Excellent ce rendu ! Et de mieux en mieux ! Merci pour ce travail de fourmi zélée ! +1 Sinon j'ai essayé de mettre à jour certaines limites de Pays en Amérique du Sud ; est ce que le rendu à été réactualisé? (pour voir si les changements sont correct!) (changement sur l'admin_level=2 et sur les frontières maritime) http://tile.openstreetmap.fr/?zoom=8lat=7.14355lon=-59.68305layers=B0FFF http://tile.openstreetmap.fr/?zoom=4lat=-9.86698lon=-82.79004layers=B0FFF Merci, Simon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Le 17 juillet 2013 12:11, Vincent Pottier vpott...@gmail.com a écrit : Le 17/07/2013 09:01, Christian Quest a écrit : J'ai retravaillé le zoom 10... Après les éloges... Quelques suggestions : Pour les abréviations : Machin-sur-Truc : Machin/Truc [1] http://tile.openstreetmap.fr/?zoom=10lat=47.97226lon=4.59508layers=B0FFF l'abréviation normale c'est Machin s/ Truc, mais ça me semble moche et surtout on ne gagne pas tant que ça rue la longueur, donc les sur, je ne les remplace pas pour ne gagner un petit caractère. C'est comme pour Rue - R. je trouve qu'on perd en lisibilité sans gagner vraiment en longueur. Style : [2] Entre le zoom 13 et 14, le nom de la ville passe de droit à italique... http://tile.openstreetmap.fr/?zoom=14lat=50.07397lon=3.34131layers=B0FFF J'en suis au zoom 10... un à la fois ;) L'idée de l'italique est d'indiquer que c'est un nom qui n'indique pas précisément un lieu. Donc en premiers niveaux de zoom le même nom indique assez précisément un lieu et à partir d'un certain niveau il devient plutôt arbitraire et a pu être en plus déplacé par un algo. [3] Nom de la commune présent deux fois Pour le nom en double... c'est déjà un progrès sur: http://tile.openstreetmap.fr/?zoom=16lat=50.08508lon=3.3726layers=00B000FFF Le nom a été remis sur le landuse=residential... en plus du nœud place et de la relation de la commune. Étrange ces pylônes sans ligne... Oui, un bug... lié au masquage des lignes enterrées (location=underground) que j'ai ajouté dernièrement et qui masque un peu trop ! -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Le 17 juillet 2013 15:10, rainerU ra...@sfr.fr a écrit : Am 17.07.2013 09:01, schrieb Christian Quest: J'ai retravaillé le zoom 10... - le placement des place=village est moins prioritaire, du coup ils ne bouffent pas tout l'espace et les références des autoroutes, sont de retour, ainsi que d'autre libellés Merci pour cette amélioration qui fait que mon village (moins de 2000h) est affiché en zoom 10 ;) place=village couvre un éventail trop large pour servir de seul critère de sélection. Il faudrait saisir l'attribut population=* de façon systématique pour pouvoir parametriser le rendu en fonction du nombre d'habitants. Existe-t-il une source de données libre pour cette information? En France il y a l'INSEE et ces infos sont remises dans le GEOFLA de l'IGN. Tout ça est assez libre pour OSM. J'utilise population=* pour placer pas population décroissante les noms de place=city/town/village -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Le 17 juillet 2013 14:34, Philippe Verdy verd...@wanadoo.fr a écrit : Le 17 juillet 2013 09:01, Christian Quest cqu...@openstreetmap.fr a écrit : J'ai retravaillé le zoom 10... - j'ai amélioré le tracé des limites de pays Avec maintenant des trous dans les frontières par endroit (ici le niveau 11: http://tile.openstreetmap.fr/?zoom=11lat=50.87114lon=24.01423layers=B0FFF et tous les niveaux 10 et moins). Apparemment si le chemin ne contient pas explicitement un admin_level tu ne vas pas le chercher dans les relations dont il est membre. Exact, c'est un truc à améliorer soit dans les données (ça ne fera pas de mal), soit aussi de mon côté. L'idée est que pour tracer proprement une frontière, il ne faut la tracer qu'une fois et pas deux, sinon les pointillées se superposent. Donc si on part des relations on a des polygones et ceux-ci sont dessinés deux fois - c'est moche. Si on part des way, on ne les dessine qu'une fois, mais il faut retrouver dans quelle relation avec le plus petit admin_level ils sont et ça le schéma osm2pgsql n'aide pas trop, mais c'est pas impossible non plus, juste pas encore fait dans mes requêtes. Anomalie identique entre Mexique et USA au nord-Est de Monterrey: http://tile.openstreetmap.fr/?zoom=9lat=26.39221lon=-98.92668layers=B0FFF Et tu en trouvera plein d'autre... c'est d'ailleurs pour ça que c'est encore en test en pas basculé sur le rendu OSM-FR. Certes on peut corriger en mettant les admin_level manquants ou corrects dans les chemins. Mais c'est le genre de truc secondaire dans les données, une redondance dont le moteur de rendu devrait pouvoir se passer, par une préparation en amont des données de frontières et reclacul des admin_level corrects. Bien d'accord quoiqu'un peu de redondance permet de vérifier la cohérence des données... ça ne me choquerai d'ailleurs pas qu'un bot fasse la mise en cohérence des admin_level sur les way avec un boundary=* ça simplifie tellement la réutilisation des données ! Aussi aux faibles niveaux de zoom les frontières autour des déserts (en jaune d'or) sont trop visibles (exemple entre Tunisie et Lybie) et ne devraient même pas être visibles du tout. On ne voit que ça, mieux que les frontières internationales alors que ces déserts ont des contours flous et ne sont pas des frontières. C'est un artifact indésirable de la réduction du gros PNG. A revoir... Encore quelques effets de pâtés dans la méthode de simplification des contours (exemple: au sud-est du Liechtenstein) qui produit des traits plus gras que nécessaire par endroit par accumulation excessive de points arrondis Plus de permalien pour être sûr de parler de la même chose ? Sinon bravo pour avoir enlevé leur couloir noire incongrue qui était beaucoup trop contrastée (et trop gras en plus, ce qui masquait trop de chose). Il reste à unifier les styles de polices pour que villes et régions ne mélangent pas caractères italiques et droits sans règle établie (qui varie en plus selon le zoom). a mon avis toutes les villes devraient avoir des caratèes droits (n'utiliser les italiques qu'au delà du niveau 8 ou pour les noms de pays et régions (en caractères plus grands mais moins contrastés, plus gras aussi mais plus transparents). Il est normal et souhaitable de faire évoluer la feuille de style pour chaque zoom y compris sur les textes. Exemple: dans les premiers niveaux de zoom, la mise en gras permet de repérer la capitale d'un pays. A partir d'un certain niveau de zoom, cela n'apporte plus une info pertinente pour se repérer dans la carte. Ce qui manque par contre c'est une légende (pour chaque zoom). -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
+1. En plus je ne suis même pas convaincu de l'utilité d'abréger le mot Rocade. Si une abréviation était utilisée, cela devrait plutôt être Rsupde/sup pour que cela ne ressemble pas à un autre mot; même sans les exposants pour les lettres finales cela donne Rde (comme la route est abrégée Rsupte/sup et non Rou.). Les rocades sont des voies très longues en comparaison des autres rues ou routes. Le nom doit bien pouvoir s'afficher quelque part en entier (et tant pis s'il manque sur les bretelles d'accès). si le zoom est trop faible pour que le mot soit visible, autant ne pas le mettre du tout sinon on risque de supprimer l'affichage du nom de la ville qu'elle contourne (et la mention Rocade Nord de toute façon n'apporte rien à faible niveau de zoom où le nord est bien identifiable), ou de masquer l'étiquette du numéro de référence. Attention encore à certaines abréviations qui ne savent pas utiliser le point abréviatif correctement: - on DOIT mettre un point après une abréviation d'un mot dont on n'a gardé QUE une ou plusieurs lettres initiales (ce point vient toujours à la fin de l'abréviation du mot). - on ne DOIT PAS mettre de point après une ou plusieurs lettres médiales ou finales (qui devraient être en exposant) si l'abréviation a supprimé des lettres entre elles et l'initiale du mot (donc pour boulevard on abrège Bsupd/sup ou Bd, voire Bsupvd/sup ou Bvd en insérant une médiale, mais PAS Bd. ni Bvd. !) - mais il est préférable de supprimer le point abréviatif dans les sigles (suite de mots qui sont tous abrégés mais ou certains termes sont même carrément supprimés et non abrégés comme les articles et conjonctions de coordination), et on supprimes les espaces entre les lettres du sigle. - Si le sigle se prononce plus souvent comme un mot et non lettre à lettre (acronyme) il garde des capitales seulement sur la première lettre (Unesco et Onu et non UNESCO et ONU -- mais SNCF, RATP ou LCL et non Sncf, Ratp ou Lcl car ce ne sont pas des acronymes). On devrait donc écrire Caf et non CAF. Quelques suggestions d'abréviations encore possibles: - Créd. pour Crédit (noms de banques) mais parfois certaines banques ont des sigles pour certaines caisses (exemple CRCAM). - Bibl. pour Bibliothèque (s'il y a une précision dans d'autres mots avant ou après) - Nat. pour National(e), Dép. pour Départemental(e), Rég. pour Régionale (pas pour les routes abrégées dans l'étiquette du numéro de référence) - Csuptre/sup ou Ctre pour Centre Quelques fautes communes dans les abréviations de nombres ordinaux: - 1ère erroné, on écrit 1supre/sup ou 1re - 2nde erroné, on écrit 2supde/sup ou 2de (certains ne sont pas d'accord); attention toute fois on n'emploie second(e) que s'il n'y a pas de troisième, le second étant aussi le dernier... - 12ème erroné, on écrit 12supe/sup ou 12e (sans accent) - on n'accorde au féminin ou pluriel les abréviations affichant les lettres finales (sauf pour l'ordinal en -ième abrégé supe/sup invariable) Le 17 juillet 2013 13:23, Eric Sibert courr...@eric.sibert.fr a écrit : Quelques suggestions : Pour les abréviations : A propos des abréviations, je suis dubitatif face à l'abréviation de Rocade : Roc. C'est la première fois que je vois cette abréviation et je ne la trouve pas naturelle. Eric __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Le 17 juillet 2013 18:48, Christian Quest cqu...@openstreetmap.fr a écrit : Il reste à unifier les styles de polices pour que villes et régions ne mélangent pas caractères italiques et droits sans règle établie (qui varie en plus selon le zoom). a mon avis toutes les villes devraient avoir des caratèes droits (n'utiliser les italiques qu'au delà du niveau 8 ou pour les noms de pays et régions (en caractères plus grands mais moins contrastés, plus gras aussi mais plus transparents). Il est normal et souhaitable de faire évoluer la feuille de style pour chaque zoom y compris sur les textes. Peut-être mais quand on commence à avoir des libellés dans un niveau de zoom donné pour des noms de villes, ou de départements ou de régions, les styles mutuels se confondent et se mélangent, les libellés deviennent incohérents entre eux. Si en plus on ajoute des sous-communes (comme des quartiers ou lieux-dits), qu'est-ce qui les différencie entre eux? Je veux ben qu'on veuille donner plus d'importance à une grosse ville ou une capitale, mais pas en jouant sur le style droit/italique qui en grande partie sert à indiquer en grand les régions ou départments et plus petits (aux zooms plus avancés où ils apparaissent) les lieux dits et sous-communes. L'importance donné à un libellé doit plutôt jouer sur la taille de police (préférable même aux caractères gras qui ne devraient servir QUE pour quelques capitales administratives, quel que soit leur importance en population. LA couleur est aussi une information: les noms de villes et lieux-dits étant en noir non transparent, les objets beaucoup plus grands auront des tailles de police plus grandes mais on peut aussi jouer pour eux sur l'interlettrage, et utiliser une couleur grise plus claire (pour éviter de trop les mettre en évidence), la graisse permettant de garder leur lisibilité, et la semiransparence permettant de garder visible des détails de l'arrière-plan que cacherait trop la mise en gras (ne pas oublier que la lisibilité est aussi maintenue par le halo plus clair qu'on met autour, la semi-transparence n'est pas un problème quel que soit les couleurs en arrière-plan, puisque c'et le halo clair qui contraste déjà avec les caractères). - Sinon le bot de mise à jour des admin_level peut se faire aussi en amont avant le rendu Mapnik, même sur ta base locale hors OSM. LE prétraitement toutefois demanderait d'importer les relations frontières différemment : repérer les segments communs de frontière pour ne les tracer qu'une fois et associer alors le min(admin_level) des relations importées à ces traits Attention à certains pièges concernant des frontières qui ne sont pas du tout administratives, mais politiques: cantons, et circonscriptions) car elles ne sont pas toujours alignées sur des frontières administratives et n'ont pas d'admin_level défini non plus, et pourtant elles sont aussi des séparations entre deux zones de même type avec un segment partagé tracé lui aussi deux fois, mais qu'on ne trace pas du tout si le segment est partagé comme frontière administrative (qui prend la priorité). Un autre problème est qu'actuellement les frontières sont importées comme des polygones fermés, sinon comme des ways ouverts (anomalies de frontières brisées dans OSM). et qu'ensuite ce sont les polygones qui sont simplifiés indépendamment des uns des autres : des segments au départ communs ne le sont plus en passant à l'étape simplification car la simplification ne retient pas les mêmes noeuds (elle part pour chaque polygone d'une noued aribtraire, et parcours les chemins dans un sens ou dans un autre, là où la simplification devrait toujours partir du noeud d'un point trple (extrémité d'un segment partagé), qui doit être gardé, et yojours parcourir les segments dans le même sens (quel que soit le polygone qui l'utilise, alors que les polygones importés sont systématiquement dans le sens trigonométrique, donc les segments sont parcourus en sens opposé par la simplification propre à chaque niveau de zoom). Bref ce n'est pas qu'une question de ce qui est dans la base OSM mais de ce qui est importé dans la base locale de rendu: les frontières à dessiner ne devraient pas être importées comme des polygones mais comme des chemins, avec une direction imposée indépendante des (multi)polygones qui les référencent. On peut facilement imposer un sens arbitraire répondant au problème en comparant les coordonnées des deux extrémités, et imposant une direction d'abord nord-sud, sinon ouest-est pour les rares segments exactement horizontaux, et sinon pour les chemins fermés restants (pas de direction déterminable)il suffit de les garder dans le sens antihoraire et imposer que le premier-et dernier point à garder soit celui le plus au nord (sinon le plus à l'ouest). Alors seulement la simplification des tracés donnera un résultat cohérent et peut se faire dans le système de coordonnées du rendu mesuré en pixels. Et là on peut éliminer les effets indésirables
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Les zoom 3 à 7 sont en cours de régénération après avoir supprimé quelques pays parasites... http://www.openstreetmap.org/browse/changeset/16990256 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Je ne suis toujours pas convaincu par l'utilité des pointillés pour les frontières maritimes, qu'on confond facilement avec les routes maritimes. Un trait continu marchera aussi bien. C'est pour les frontières terrestre que le pointillé est davantage justifié, pour ne pas confondre avec un cours d'eau ou une route. Exemple ici pour les Antilles, les pointillés (pour les eaux territoriales à 12 nm) sont difficiles à suivre: http://tile.openstreetmap.fr/?zoom=6lat=13.83449lon=-61.02613layers=B0FFF Les pointillés sont éventuellement pour les limites de ZEE (souvent non fermées, juste des lignes entre deux entités mais pas les autres) Bizarrement on a par endroit des lignes continues (mais trop épaisses et trop contrastées, ici pour Pago Pago et Alofi) : http://tile.openstreetmap.fr/?zoom=7lat=-16.7819lon=-173.11187layers=B0FFF et plus à l'ouest d'étranges lignes verticales sur l'antiméridien coupant les Fidji): http://tile.openstreetmap.fr/?zoom=7lat=-16.7819lon=-173.11187layers=B0FFF Le 17 juillet 2013 12:25, Simon Miniou simon.min...@gmail.com a écrit : Bonjour, Excellent ce rendu ! Et de mieux en mieux ! Merci pour ce travail de fourmi zélée ! +1 Sinon j'ai essayé de mettre à jour certaines limites de Pays en Amérique du Sud ; est ce que le rendu à été réactualisé? (pour voir si les changements sont correct!) (changement sur l'admin_level=2 et sur les frontières maritime) http://tile.openstreetmap.fr/?zoom=8lat=7.14355lon=-59.68305layers=B0FFF http://tile.openstreetmap.fr/?zoom=4lat=-9.86698lon=-82.79004layers=B0FFF Merci, Simon ___ 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
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Avant que je pose des questions bêtes... dis moi Christian, la population des nodes place tu la prends directement dans le geofla? ou bien tu prends celle qu'il y a dans la base OSM? Parce que ce tag ne semble pas souvent rempli pour les petites communes dans OSM, et accessoirement elle n'est pas forcément homogène - obsolescence des donnée, divers source etc. - 2013/7/17 Christian Quest cqu...@openstreetmap.fr: Les zoom 3 à 7 sont en cours de régénération après avoir supprimé quelques pays parasites... http://www.openstreetmap.org/browse/changeset/16990256 ___ 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
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Rendu peu lisible sur les Antilles : Zoom 7 : La Dominique ressemble à un pâté (avec ses frontières administratives ?) Zoom 6 et 5 : mélange entre noms de villes, d'îles… on ne sait pas trop quoi et quoi Zoom 3 et 4 : afficher plutôt les Antilles que le noms de chaque île Quelque soit le niveau de zoom, on voit Basse-Terre mais jamais Guadeloupe !!?? Zoom 12 : les limites administratives sur les lignes de côtes, c'est moche :-( D'ailleurs c'est bizarre de ne pas en trouver une autour de l'île comme pour Montserrat ? -- Yves___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Euh... la côte c'est bien là où la terre (beige clair) se termine et ou la mer (bleu clair) commence ? lol tu peux remplacer côte par Frontière maritime (pointillé bleu), ( je devais pas être très réveillé) Pour être très précis, ce sont les nœuds place=* qui sont utilisés et les tags qu'ils ont. Trop compliqué d'exploiter les relations à ce niveau sans rétraitement. sans utiliser les relations c'est peut être possible sous osmose ou autre de faire la jointure entre tous les nœuds place qui ont une référence Insee et la population correspondante? (on ciblerai plus facilement ceux ou la population n'est pas renseigné ou que sur la relation) tu parle des frontières coupées ? oui c'est ça ; j'ai essayé de remettre sur le Paraguay, Pérou et Bolivie le tag admin_level=2 et boundary=adminsitrative sur tous les chemins de leur relation. Simon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
J'ai fait un petit résumé sous forme de post de blog... http://openstreetmap.fr/blogs/cquest/osm-fr-faibles-zooms Ce n'est que le premier épisode ;) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Bonjour, Il y a aussi l'effet contraire, c'est à dire dans des régions très peuplés comme l'Allemagne et où il y a beaucoup de place=town, en zoom 7 l'espace entre les place=city semble être rempli au max avec des place=town choisis de façon arbitraire. Un classement par nombre d'habitants et une distance minimale pourrai là-aussi améliorer le rendu. Rainer ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Tient des bases de cubistes ?! :-DJ'ai regardé dans les données mais je ne vois pas de carré ?--YvesPrèsd'AnkaraEt deTikrit___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Le 8 juillet 2013 02:09, Jérôme Amagat jerome.ama...@gmail.com a écrit : Autre chose, j'ai regarder le site sur un ipad. Lorsque l'on utilise l'ipad en position paysage pas de problème mais en portrait c'est écrit tellement petit que se n'est pas toujours lisible. Lorsque l'on passe de l'un à l'autre, sur la largeur tout reste identique et comme en paysage c'est moins large il diminue tout. Cela ne me parait pas être un bogue d'OSM ou de rendu mais du navigateur de l'iPad et de la façon dont tu l'as réglé pour réduire les images et les faire tenir dans la largeur d'écran. Normalement le framework javascript devrait détecter le changement de largeur d'écran quand tu tourne ta tablette, et ajuster le nombre de tuiles visibles.Si cela ne se passe pas, c'est que ton navigateur iPad continue à prétendre qu'il a un écran en mode portrait. Le bogue est a signaler aux concepteurs du framework javascript. car le moteur de rendu ne peut pas savoir que les bitmaps qu'il génère vont subir une réduction de taille à l'affichage, ces bitmaps étant supposées s'afficher clairement à leur résolution native. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Vérifie si les lacs sont correctement fermés et ne laissent pas non plus de segments parasites inutilisés ou en double. Car en zoomant plus l'affichage est correct. En général ce sont des anomalies de géométrie qui causent ça, avec une fermeture de polygone générée arbitrairement sur une bounding box. Le 8 juillet 2013 08:49, Yves Pratter yves.prat...@laposte.net a écrit : Tient des bases de cubistes ?! :-D J'ai regardé dans les données mais je ne vois pas de carré ? -- Yves Près d'Ankarahttp://tile.openstreetmap.fr/?zoom=9lat=39.17679lon=32.90303layers=B0FFF [image: 24.png]http://tile.openstreetmap.fr/?zoom=9lat=39.17679lon=32.90303layers=B0FFF Et de Tikrithttp://tile.openstreetmap.fr/?zoom=9lat=34.1466lon=42.7701layers=B0FFF [image: 25.png]http://tile.openstreetmap.fr/?zoom=9lat=34.1466lon=42.7701layers=B0FFF ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr 25.png24.png___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Le 8 juil. 2013 à 09:01, Philippe Verdy verd...@wanadoo.fr a écrit : Vérifie si les lacs sont correctement fermés Oui cf. zoom plus importants et ne laissent pas non plus de segments parasites inutilisés ou en double. Pour info, tu fais comment pour vérifier ça ? -- Yves ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Le 8 juillet 2013 02:09, Jérôme Amagat jerome.ama...@gmail.com a écrit : Allez, je participe aux remarques sur le rendu: Je trouve que l'on ne voit pas vraiment la différence entre admin_level=2 et 3 exemple la Slovénie: http://tile.openstreetmap.fr/?zoom=7lat=45.79052lon=14.44125layers=B0FFF Dans le cas de la Slovénie, les tracés des admin_level=2 et 3 ont le même rendu et c'est une anomalie spécifique (au minimum la frontière niveau 3 devrait être plus fine qu'une frontière internationale, ou moins constrastée avec plus de transparence). Il n'y a pas que la Slovénie, c'est partout pareil, même en France entre zoom 6 et 7: on ne voit pas plus de nom de régions, ou de départements ou de villes ou de rivières, ce qu'on remarque c'est seulement le rendu ou pas des landuse, et pas non plus davantage de frontières administratives (des départements par exemple). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
On ne peut pas le vérifier en regardant seulement le rendu. La seule façon c'est d'abord de corriger les anomalies de géométrie détectées par des outils comme Osmose, ou sinon de charger la zone dans un éditeur. Un truc qui arrive parfois aussi c'est une pseudo-fermeture avec des segments supposés jointifs mais dont les noeuds sont différents mais superposés au même endroit, ça provoque des anomalies aussi qu'on corrige en les fusionnant. Le 8 juillet 2013 09:13, Yves Pratter yves.prat...@laposte.net a écrit : Le 8 juil. 2013 à 09:01, Philippe Verdy verd...@wanadoo.fr a écrit : Vérifie si les lacs sont correctement fermés Oui cf. zoom plus importants et ne laissent pas non plus de segments parasites inutilisés ou en double. Pour info, tu fais comment pour vérifier ça ? -- Yves ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Arg. C'est un effet non désiré de text-min-distance que j'utilise pour contrôler la densité des noms. Chaque nom brûle son emplacement ET toute la distance indiquée... du coup on ne peut plus rien mettre en plus, y compris les ref de routes :( text-min-distance n'est donc pas adéquate, mais il n'y a rien d'autre de dispo. Il va falloir régler ça à un autre niveau, ça sent le prétraitement avec un calcul de la distance la plus courte vers le village ayant plus d'habitants... ce qui risque d'être chaud en SQL ;) Le 8 juillet 2013 01:19, Simon Miniou simon.min...@gmail.com a écrit : Bonsoir, Sur cette zone, le nom des villes prend le dessus sur les n° des routes : http://tile.openstreetmap.fr/?zoom=11lat=48.73928lon=4.56117layers=B0FFF Simon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Je viens de regarder il n'y a rien dans la base OSM elle-même. Ces lacs étant dans des régions avec peu de données, c'est facile à voir. Mais il y pu y en avoir dans le passé et dans ce cas ce n'est pas dans la base OSM mais c'est resté en parasite dans la base pgsql utilisée par le moteur de rendu, ou alors ils viennent d'un import raté. Les autres moteurs de rendu n'affichent pas ces carrés. Pour info j'ai essayé de forcer la mise à jour du lac turc (un seul chemin fermé) en permutant l'ordre des noeuds (découpe en deux segments puis refusion, cela ne semble pas avoir d'effet visible. Ce qui me laisse penser qu'il y a un autre objet parasite dans la base pgsql que ce lac, visible aux niveaux de zoom 2 à 9 (même chose pour le carré en Irak). Tout de même dans les deux cas il s'agit de lacs fermés par un seul chemin, coupé en 4 par une limite de métatuiles au niveau 9 mais pas au niveau 8. Ces lacs sont coupés en 4 morceaux aussi au niveau 10 (et plus) mais on n'a pas ce problème de carré visible. Cela me parait étonnant et ne semble pas lié au découpage des métatuiles. Le 8 juillet 2013 09:16, Philippe Verdy verd...@wanadoo.fr a écrit : On ne peut pas le vérifier en regardant seulement le rendu. La seule façon c'est d'abord de corriger les anomalies de géométrie détectées par des outils comme Osmose, ou sinon de charger la zone dans un éditeur. Un truc qui arrive parfois aussi c'est une pseudo-fermeture avec des segments supposés jointifs mais dont les noeuds sont différents mais superposés au même endroit, ça provoque des anomalies aussi qu'on corrige en les fusionnant. Le 8 juillet 2013 09:13, Yves Pratter yves.prat...@laposte.net a écrit : Le 8 juil. 2013 à 09:01, Philippe Verdy verd...@wanadoo.fr a écrit : Vérifie si les lacs sont correctement fermés Oui cf. zoom plus importants et ne laissent pas non plus de segments parasites inutilisés ou en double. Pour info, tu fais comment pour vérifier ça ? -- Yves ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Le 7 juillet 2013 23:19, Ista Pouss ista...@gmail.com a écrit : Autre remarque super constructive : au zoom 10 http://tile.openstreetmap.fr/?zoom=10lat=46.41239lon=-1.15803layers=B0FFF est-il judicieux de faire apparaître les micro-aérodromes (Aérodrome de La Tranche sur mer) ? Leur nom est illisibles mais bouffe une place phénoménale sur la carte et il y a une personne sur 100.000 qui s'en préoccupe. C'est quoi le tag pour reconnaitre un micro-aérodrome d'un aérodrome ? Il faut avoir des infos pour pouvoir faire des choix... et là, c'est plutôt maigre. J'ai déjà complété les aéroports internationaux avec des tags supplémentaires pour les distinguer. Le 8 juillet 2013 02:09, Jérôme Amagat jerome.ama...@gmail.com a écrit : Allez, je participe aux remarques sur le rendu: Je trouve que l'on ne voit pas vraiment la différence entre admin_level=2 et 3 exemple la Slovénie: http://tile.openstreetmap.fr/?zoom=7lat=45.79052lon=14.44125layers=B0FFF Oui, le tracé des limites admins est à affiner. J'ai déjà séparé admin_level 2 et 3: http://tile.openstreetmap.fr/?zoom=7lat=45.79052lon=14.44125layers=B0FFF A Lyon, le parc de la tête d'or : http://tile.openstreetmap.fr/?zoom=13lat=45.77548lon=4.85858layers=B0FFF On voit le nom de petites îles à l’intérieur du parc mais pour avoir le nom du parc il faut beaucoup zoomer. Arghhh... trop d'îles maintenant ;) Noté. Regarder la rivière l'Yzeron ici : http://tile.openstreetmap.fr/?zoom=15lat=45.74017lon=4.72872layers=B0FFF 4 fois d’affiler le nom se trouve sous un pont et est donc moins lisible. Les nom des rivières se retrouve souvent sous des ponts alors qu'il y a de la place a coté. Un coup de pas de bol ça... c'est pas pire qu'avant (rendu OSM). Je peux les remonter sur un layer supérieur pour éviter les collisions... Autre chose, j'ai regarder le site sur un ipad. Lorsque l'on utilise l'ipad en position paysage pas de problème mais en portrait c'est écrit tellement petit que se n'est pas toujours lisible. Lorsque l'on passe de l'un à l'autre, sur la largeur tout reste identique et comme en paysage c'est moins large il diminue tout. Le site ne sert qu'à visualiser rapidement les tuiles. Il n'est pas destiné à être utilisé tel que et ne comporte pas les balises pour que l'ipad adapte sa résolution correctement. C'est une install basique d'openlayers... pas forcément le mieux adapté à un usage tactile. Le 8 juillet 2013 07:11, Philippe Verdy verd...@wanadoo.fr a écrit : Au fait pourquoi Rennes est en italique? Par soucis de cohérence: - les noms de communes devraient tous être en caractères droits et noirs (oui on peut jouer sur leur taille et leur graisse pour les plus grosses), - les italiques (petits et gris) resteraient pour les quartiers, - ou (larges et gras, avec un interlettrage étendu, et sans doute en caractères gris et semi-transparents) pour les départements ou régions Je met en italique les noms dès qu'ils correspondent plus ou moins à une grande zone et donc que le nom d'indique plus de façon précise un lieu. Et pourquoi Pacé (ouest de Rennes) est microscopique ? plus petit que son quartier Les Ponts-de-Pacé (gris italique), et pas plus gros que ses lieux-dits (qui devraient être tout petits, et italiques (noirs ou gris?) Pacé: 5500 habitants donc village Oui, les tailles de texte sont à harmoniser elles aussi voire prendre en compte population=* pour avoir un intermédiaire entre les villages et les petites villes, par exemple une limite à 1000 habitants. Le 8 juillet 2013 08:49, Yves Pratter yves.prat...@laposte.net a écrit : Tient des bases de cubistes ?! :-D J'ai regardé dans les données mais je ne vois pas de carré ? Aucune idée d'où proviennent ces carrés bleu, moi aussi j'ai chargé les données de la zone sans rien trouver... mystère. Peut être effective 2 bugs dans la base SQL... -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Le 8 juillet 2013 10:24, Christian Quest cqu...@openstreetmap.fr a écrit : C'est quoi le tag pour reconnaitre un micro-aérodrome d'un aérodrome ? Il faut avoir des infos pour pouvoir faire des choix... et là, c'est plutôt maigre. J'ai déjà complété les aéroports internationaux avec des tags supplémentaires pour les distinguer. En absence de tag permettant de découvrir un aérodrome approprié au niveau de zoom, il me semble qu'il vaut mieux en réserver le rendu aux zooms les plus gros : comme il y a moins d'aérodromes importants ça sera plus facile de mettre les tags correspondants. J'ai fait mon id avec ça pour ceux de la région parisienne http://www.diaam.com:8080/idalacarte/ids/aerodrome On voit que c'est un peu le bord... bazar dans la base ; il y aurait closest_town, ou passengers qui pourrait aider au zoom, mais aucun des aéroports principaux ne comporte toutes ces valeurs :-( Et en plus passengers n'est même pas cité dans le wiki http://wiki.openstreetmap.org/wiki/Tag:aeroway=aerodrome?uselang=fr -((. En gros, ma proposition abouti à supprimer tous les aéroports dans la situation actuelle :-((( ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Bonjour, A propos des pistes des aérodromes, est-ce que le rendu pourrait tenir compte du tag surface pour changer sa couleur ? Avec cette couleur bitume, les pistes en herbes deviennent très visibles sur le rendu, alors que ce n'est pas le cas en réalité : http://tile.openstreetmap.fr/?zoom=16lat=46.93305lon=-1.32407layers=B0FFF J'imagine qu'on pourrait faire la même demande pour tous les objets comprenant un attribut surface, mais que ça risque de devenir compliqué à gérer. Stéphane Le lundi 8 juillet 2013 11:26:07, Ista Pouss a écrit : Le 8 juillet 2013 10:24, Christian Quest cqu...@openstreetmap.fr mailto:cqu...@openstreetmap.fr a écrit : C'est quoi le tag pour reconnaitre un micro-aérodrome d'un aérodrome ? Il faut avoir des infos pour pouvoir faire des choix... et là, c'est plutôt maigre. J'ai déjà complété les aéroports internationaux avec des tags supplémentaires pour les distinguer. En absence de tag permettant de découvrir un aérodrome approprié au niveau de zoom, il me semble qu'il vaut mieux en réserver le rendu aux zooms les plus gros : comme il y a moins d'aérodromes importants ça sera plus facile de mettre les tags correspondants. J'ai fait mon id avec ça pour ceux de la région parisienne http://www.diaam.com:8080/idalacarte/ids/aerodrome On voit que c'est un peu le bord... bazar dans la base ; il y aurait closest_town, ou passengers qui pourrait aider au zoom, mais aucun des aéroports principaux ne comporte toutes ces valeurs :-( Et en plus passengers n'est même pas cité dans le wiki http://wiki.openstreetmap.org/wiki/Tag:aeroway=aerodrome?uselang=fr -((. En gros, ma proposition abouti à supprimer tous les aéroports dans la situation actuelle :-((( ___ 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
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Le 08/07/2013 12:10, Stéphane Péneau a écrit : Bonjour, A propos des pistes des aérodromes, est-ce que le rendu pourrait tenir compte du tag surface pour changer sa couleur ? Avec cette couleur bitume, les pistes en herbes deviennent très visibles sur le rendu, alors que ce n'est pas le cas en réalité : http://tile.openstreetmap.fr/?zoom=16lat=46.93305lon=-1.32407layers=B0FFF J'imagine qu'on pourrait faire la même demande pour tous les objets comprenant un attribut surface, mais que ça risque de devenir compliqué à gérer. Stéphane C'est un peu délicat. Une carte, ce n'est pas une peinture. Si on met en vert tout ce qui est en herbe, en gris tout ce qui est en goudron... on risque d'avoir plus une peinture, pas satisfaisante, qu'une carte. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Le lundi 8 juillet 2013 12:40:21, Vincent Pottier a écrit : Le 08/07/2013 12:10, Stéphane Péneau a écrit : Bonjour, A propos des pistes des aérodromes, est-ce que le rendu pourrait tenir compte du tag surface pour changer sa couleur ? Avec cette couleur bitume, les pistes en herbes deviennent très visibles sur le rendu, alors que ce n'est pas le cas en réalité : http://tile.openstreetmap.fr/?zoom=16lat=46.93305lon=-1.32407layers=B0FFF J'imagine qu'on pourrait faire la même demande pour tous les objets comprenant un attribut surface, mais que ça risque de devenir compliqué à gérer. Stéphane C'est un peu délicat. Une carte, ce n'est pas une peinture. Si on met en vert tout ce qui est en herbe, en gris tout ce qui est en goudron... on risque d'avoir plus une peinture, pas satisfaisante, qu'une carte. Ca se tient... openstreetart ? :-) Stf ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
2013/7/8 Ista Pouss ista...@gmail.com: En gros, ma proposition abouti à supprimer tous les aéroports dans la situation actuelle :-((( Tu veux dire, les supprimer du rendu, pas de la base de données, bien sûr ! La seule chose que je trouve dans le wiki pour distinguer les gros aéroports des petits est cette proposition (l'utiliser pour les aéroports a été suggéré en 2010 sur la liste tagging): http://wiki.openstreetmap.org/wiki/Proposed_Features/Importance importance=internation/national/regional/etc... Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
On 07/08/2013 02:17 PM, Pieren wrote: La seule chose que je trouve dans le wiki pour distinguer les gros aéroports des petits est cette proposition (l'utiliser pour les aéroports a été suggéré en 2010 sur la liste tagging): http://wiki.openstreetmap.org/wiki/Proposed_Features/Importance importance=internation/national/regional/etc... Sur le style HOT, j'utilise la présence du tag iata (présence du tag iata = aéroport, sinon aérodrome): https://github.com/hotosm/HDM-CartoCSS/blob/master/hdm.mml#L899 Mais je sais pas si c'est assez pour ce que vous cherchez à faire. Yohan ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
2013/7/8 Yohan Boniface yohanbonif...@free.fr: Sur le style HOT, j'utilise la présence du tag iata (présence du tag iata = aéroport, sinon aérodrome): Le code iata s'intéresse à tous les aéroports ayant une activité commerciale. Elle n'est qu'un indicateur partiel de son importance. Par exemple, l'aéroport de Lannion possède un code iata alors que ça n'est qu'un aéroport régional. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Le 8 juillet 2013 10:24, Christian Quest cqu...@openstreetmap.fr a écrit : Le 7 juillet 2013 23:19, Ista Pouss ista...@gmail.com a écrit : Autre remarque super constructive : au zoom 10 http://tile.openstreetmap.fr/?zoom=10lat=46.41239lon=-1.15803layers=B0FFF est-il judicieux de faire apparaître les micro-aérodromes (Aérodrome de La Tranche sur mer) ? Leur nom est illisibles mais bouffe une place phénoménale sur la carte et il y a une personne sur 100.000 qui s'en préoccupe. C'est quoi le tag pour reconnaitre un micro-aérodrome d'un aérodrome ? Il faut avoir des infos pour pouvoir faire des choix... et là, c'est plutôt maigre. J'ai déjà complété les aéroports internationaux avec des tags supplémentaires pour les distinguer. Déjà les aérodromes qui ont un code AOCI sont plus important que les autres. Même s'ils ne servent pas habituellement au transport aérien commercial civil international, ils sont appelés à pouvoir servir à cet effet (ne serait-ce qu'en cas d'urgence, même avec des services limités sur place et une capacité faible en nombre de vols supportables). Ce n'est pas le cas des petits aéroclubs ou des altiplans qui n'ont qu'une piste gazonnée seulement dégagée d'obstacles et à peu près plat sur l'essentiel de leur longueur. Ni des aérodromes privés (exploités pa exemple pour faire une liaison entre le continent et une île, souvent d'ailleurs par hélicoptère plus que par petit avion). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Le 7 juillet 2013 23:19, Ista Pouss ista...@gmail.com a écrit : Autre remarque super constructive : au zoom 10 http://tile.openstreetmap.fr/?zoom=10lat=46.41239lon=-1.15803layers=B0FFF est-il judicieux de faire apparaître les micro-aérodromes (Aérodrome de La Tranche sur mer) ? C'est vrai que Aérodrome de La Tranche-sur-Mer (orthographe corrigée) mentionne ici surtout la localisation et le terme générique; ce libellé n'apporte rien de plus que la seule icône, sauf pour indiquer (indirectement) que c'est un aérodrome civil du réseau de transport public. Le nom est surtout utile pour les aéroports situés très souvent hors du territoire de la ville qu'ils desservent (ex. Paris-Orly, Paris CDG, qui ne sont pas à Paris, et maintenant aussi Paris-Beauvais vendu sous ce nom par les compagnies aériennes low-cost, qui parfois l'abrège juste Paris en tant que destination des billets dans leurs comparateurs d'offres et catalogues, bien que l'aéroport ne soit pas inclus dans l'entité Aéroports de Paris, mais qui pourtant entre dans le secteur parisien pour le contrôle aérien). Mais on pourrait même se passer dans ce cas de Aérodrôme de , comme on ne met pas non plus Gare de , Port de . ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Le code IATA est plus discriminant. Quasiment tous les aérodromes, même ceux qui sont à circulation restreinte (non ouvert à la circulation aérienne publique), même ceux en herbe, même les privés (ex-LFJM de Gérard Bourgoin à Chailley) ont un code OACI. Mais évidement, le code IATA ne permettra pas de distinguer Roissy de Lannion. Art. Le 8 juillet 2013 15:12, Philippe Verdy verd...@wanadoo.fr a écrit : Le 8 juillet 2013 10:24, Christian Quest cqu...@openstreetmap.fr a écrit : Le 7 juillet 2013 23:19, Ista Pouss ista...@gmail.com a écrit : Autre remarque super constructive : au zoom 10 http://tile.openstreetmap.fr/?zoom=10lat=46.41239lon=-1.15803layers=B0FFF est-il judicieux de faire apparaître les micro-aérodromes (Aérodrome de La Tranche sur mer) ? Leur nom est illisibles mais bouffe une place phénoménale sur la carte et il y a une personne sur 100.000 qui s'en préoccupe. C'est quoi le tag pour reconnaitre un micro-aérodrome d'un aérodrome ? Il faut avoir des infos pour pouvoir faire des choix... et là, c'est plutôt maigre. J'ai déjà complété les aéroports internationaux avec des tags supplémentaires pour les distinguer. Déjà les aérodromes qui ont un code AOCI sont plus important que les autres. Même s'ils ne servent pas habituellement au transport aérien commercial civil international, ils sont appelés à pouvoir servir à cet effet (ne serait-ce qu'en cas d'urgence, même avec des services limités sur place et une capacité faible en nombre de vols supportables). Ce n'est pas le cas des petits aéroclubs ou des altiplans qui n'ont qu'une piste gazonnée seulement dégagée d'obstacles et à peu près plat sur l'essentiel de leur longueur. Ni des aérodromes privés (exploités pa exemple pour faire une liaison entre le continent et une île, souvent d'ailleurs par hélicoptère plus que par petit avion). ___ 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
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Celui de Lannion n'est pas si petit que ça... Si on le compare à celui de Dinard (qui a pourtant bel et bien un trafic commercial international régulier). L'activité militaire et pour la Sécurité civile ou le secours en mer doit y être pour quelque chose (ce qu'on n'a pas à Dinard), et il y a un trafic pour le fret postal urgent. Il n'est même pas envisagé de fermer celui de Lannion à cause de l'activité militaire et de sécurité et la surveillance du trafic maritime civil, même si c'est par hélico Commentaires: - les heures de vol par hélico coûtent trop cher en temps de restriction budgétaire, on revient de plus en plus aux petits avions bimoteurs, même s'ils sont moins maniables, avec l'appui en mer par bateau, et la surveillance par satellite est aussi de plus en plus utilisée, très économique, grâce aussi aux équipements radio et satellite rendus obligatoires sur les navires, même de plaisance. - la France dispose d'une très forte densité d'aéroclubs, parmi la plus élevée au monde surtout en terme de formation et en nombre de formateurs, même si le nombre de propriétaires est réduit, car les avions se louent facilement à ces aéroclubs. La formation de pilote non commercial y est aussi parmi les moins chères, accessible à de nombreux pilotes même mineurs (on dit parfois que cela coûte le même prix que la consommation de cigarettes pour quelques heures de vol par mois, c'est évidemment un choix à faire dans un budget personnel, certes impossible si on n'a que des minimas sociaux et pas de patrimoine ni de parents pour aider, pour certains c'est aussi soit pouvoir voler, soit avoir une voiture et l'assurer). - En revanche devenir pilote commercial coûte très cher en France en comparaison d'autres pays (car on demande un nombre d'heures de vol très élevé pour les licences, et le carburant est cher en France, même si les aéroclubs économisent beaucoup par leur compétences et le partage de moyens pour l'acquisition et l'entretien des appareils et par le bénévolat des formateurs), mais il faut en passer par là pour avoir les agréments obligatoires demandés par les aéroports commerciaux ou sortir des couloirs aériens réservés aux petits aéronefs, sinon on vole tout seul ou dans son aéroclub, mais le vol en solo permet vite d'utiliser les petits aéroports qui ont des espaces réservées aux aéroclubs et la navigation privée... Certains vont donc se former et faire leurs heures de vol dans des pays qui ont du pétrole pas trop cher (Moyen-Orient, Russie... et même aux USA ou au Venezuela, aussi à nouveau en Tunisie et en Egypte), même s'ils doivent ensuite valider leurs acquis au retour en France (mais les emplois de pilotes commerciaux sont plutôt au Moyen-Orient et en Asie aujourd'hui). Le 8 juillet 2013 15:30, Art Penteur art.pent...@gmail.com a écrit : Le code IATA est plus discriminant. Quasiment tous les aérodromes, même ceux qui sont à circulation restreinte (non ouvert à la circulation aérienne publique), même ceux en herbe, même les privés (ex-LFJM de Gérard Bourgoin à Chailley) ont un code OACI. Mais évidement, le code IATA ne permettra pas de distinguer Roissy de Lannion. Art. Le 8 juillet 2013 15:12, Philippe Verdy verd...@wanadoo.fr a écrit : Le 8 juillet 2013 10:24, Christian Quest cqu...@openstreetmap.fr a écrit : Le 7 juillet 2013 23:19, Ista Pouss ista...@gmail.com a écrit : Autre remarque super constructive : au zoom 10 http://tile.openstreetmap.fr/?zoom=10lat=46.41239lon=-1.15803layers=B0FFF est-il judicieux de faire apparaître les micro-aérodromes (Aérodrome de La Tranche sur mer) ? Leur nom est illisibles mais bouffe une place phénoménale sur la carte et il y a une personne sur 100.000 qui s'en préoccupe. C'est quoi le tag pour reconnaitre un micro-aérodrome d'un aérodrome ? Il faut avoir des infos pour pouvoir faire des choix... et là, c'est plutôt maigre. J'ai déjà complété les aéroports internationaux avec des tags supplémentaires pour les distinguer. Déjà les aérodromes qui ont un code AOCI sont plus important que les autres. Même s'ils ne servent pas habituellement au transport aérien commercial civil international, ils sont appelés à pouvoir servir à cet effet (ne serait-ce qu'en cas d'urgence, même avec des services limités sur place et une capacité faible en nombre de vols supportables). Ce n'est pas le cas des petits aéroclubs ou des altiplans qui n'ont qu'une piste gazonnée seulement dégagée d'obstacles et à peu près plat sur l'essentiel de leur longueur. Ni des aérodromes privés (exploités pa exemple pour faire une liaison entre le continent et une île, souvent d'ailleurs par hélicoptère plus que par petit avion). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Le 08/07/2013 15:30, Art Penteur a écrit : Le code IATA est plus discriminant. Quasiment tous les aérodromes, même ceux qui sont à circulation restreinte (non ouvert à la circulation aérienne publique), même ceux en herbe, même les privés (ex-LFJM de Gérard Bourgoin à Chailley) ont un code OACI. Mais évidement, le code IATA ne permettra pas de distinguer Roissy de Lannion. Le tag IFR permet de distinguer entre les petits aérodromes genre : http://www.openstreetmap.org/browse/way/32350925 IFR=no http://www.openstreetmap.org/browse/way/32862447 IFR=yes Si l'aérodrome est taggé en chemin, le contenu est un indicateur d'importance. 4 pistes en dur à Rooissy, aérogares, taxiway.. et surface du polygone. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Bonjour, Sympa le zoom 4 ! (*beaucoup plus clair*) ; Par contre le rendu est bizarre en Amérique du Sud (ça provient peut être des données) : http://tile.openstreetmap.fr/?zoom=4lat=-26.66783lon=-63.79904layers=B0FFFhttp://tile.openstreetmap.fr/?zoom=4lat=-26.66783lon=-63.79904layers=B0FFF Sinon pour le zoom 3, on pourrait aussi mettre le nom des continents (avec la limite) : http://tile.openstreetmap.fr/?zoom=3lat=51.71291lon=-8.21921layers=B0FFF Simon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
A mon avis tracer les côtes est superflu et alourdit les choses (si elles ne sont pas simplifiées à la résolution d'affichage, ça fait des pâtés tout le long des côtes). Ne pas tracer les limites administratives côtières aux niveau de zoom faible sera plus clair (les côtes sont trop découpées, les îles deviennent illisibles. De plus la couleur noire est trop contrastée, je préfère nettement des frontières gris moyen (qui s'accordent bien avec la délimitation terre-mer sans surcharger), surtout à ces niveaux où la terre n'est pas remplie de landuse/natural et reste en blanc: trop de contraste nuit à la lisibilité du reste. Cela empêche par exemple d'avoir un rendu clair de couches de POIs superposées (par exemple des bulles pour une recherche, ou une frontière épaisse correspondant à un objet sélectionné dans la recherche, qui devrait avoir un rendu lisible, comme sur les cartes de Wikipédia où l'objet sélectionné doit apparaître avec un polygone rouge plus contrasté que le fond de carte). Enfin pourquoi des tirets sur les frontières maritimes ? un filet bleu suffit largement et est plus discret (là je préfère le rendu Mapnik du site .org standard). C'est plus facile d'identifier les contours des tirets des routes maritimes (qui elles sont indicatives et en fait très floues et simplifiées). Le 8 juillet 2013 17:53, Simon Miniou simon.min...@gmail.com a écrit : Bonjour, Sympa le zoom 4 ! (*beaucoup plus clair*) ; Par contre le rendu est bizarre en Amérique du Sud (ça provient peut être des données) : http://tile.openstreetmap.fr/?zoom=4lat=-26.66783lon=-63.79904layers=B0FFFhttp://tile.openstreetmap.fr/?zoom=4lat=-26.66783lon=-63.79904layers=B0FFF Sinon pour le zoom 3, on pourrait aussi mettre le nom des continents (avec la limite) : http://tile.openstreetmap.fr/?zoom=3lat=51.71291lon=-8.21921layers=B0FFF Simon ___ 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
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Au sujet des pâtés sur les frontières, cela concerne aussi les frontières terrestres. Une simplification des polygones avec une distance **minimale** entre les sommets successifs de 1,42 pixels (et non pas 1,0 pixel exactement, à cause des angles rendus en diagonale à 45 degrés ou 135 degrés causés et immédiatement voisin d'un angle à 0° ou 90°, par les arrondis de la résolution finale, même s'il utilise des pixels semi transparents, ceci s'ajustant en fonction du nombre de niveaux de semi-transparence retenu qui s'appuie sur des demis ou quarts de pixels) devrait conserver leur précision visible sans trop alourdir la graisse visible du tracé. Les pâtés sont trop nombreux sur la frontière franco-belge, Maroc-Algérie, Belgigue-Pays-Bas, Suisse-Autriche, Slovénie-Croatie... On en a aussi sur les îles italiennes (mais là le problème est simple : ce sont des lignes de côtes, ne pas tracer les frontières sera préférable, on a déjà un contraste terre-mer entre le bleu et les couleurs claires de la terre, tracer le trait cache plus de détails qu'il n'en apporte. Les frontières administratives des régions grecques sont en mer, le tracé est plus simple et ne fait pas de pâtés visibles, la graisse visible est bonne, lisible et assez discrète pour ne pas surcharger (mais ces régions grecques pourraient malgré tout avoir une couleur moins contrastée encore: la frontière territoriale pointillée bleue devant suffire si on la trace en continu peu épais, avec les mêmes simplifications à la limite de 1,42 pixels minimum entre les sommets). Idéalement la simplification devrait détecter les cas où l'angle arrondi à un sommet est de 90 degrés ou plus serré : il faudrait garder ce sommet, quitte à supprimer les voisins trop proches (à moins de 1,42 pixels), en commençant par ça avant de simplifier les autres sommets par un parcours linéaire des sommets qui restent (donc deux boucles à faire, le première calculant les positions arrondies et les angles, non conservés dans la liste, étant plus longue que la seconde qui n'utilise que les distances ; plutôt que la distance on peut aussi utiliser le carré de la distance, ce qui évite une racine carrée à calculer : le carré de la distance doit être supérieur à 2, sinon on élimine un sommet). D'une façon générale il faudrait le faire pour tous les tracés linéaires (le rendu des tracés surfaciques ne souffre pas de ce problème). Le 8 juillet 2013 18:05, Philippe Verdy verd...@wanadoo.fr a écrit : A mon avis tracer les côtes est superflu et alourdit les choses (si elles ne sont pas simplifiées à la résolution d'affichage, ça fait des pâtés tout le long des côtes). Ne pas tracer les limites administratives côtières aux niveau de zoom faible sera plus clair (les côtes sont trop découpées, les îles deviennent illisibles. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Par rapport aux autres grandes villes, Stockholm n'apparait pas à plusieurs niveaux de zoom : http://tile.openstreetmap.fr/?zoom=5lat=57.26277lon=18.82682layers=B0FFF Perso, je trouve que voir les côtes apporte bien quelque chose à la carte, ces limites existent et sont peu voir jamais représentées. --- Pour l'affichage des villes, si j'ai bien compris, la population est recherché sur les admin_centre ; ne serait-il pas possible de les compléter automatiquement avec les chiffres du dernier recensement ? Simon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
On peut mettre en contraste léger les côtes (à l'extérieur par effet d'ombrage, uniquement dans la zone mer), mais sans indiquer que c'est une frontière: il suffit que les frontières terrestre s'y connectent. Les frontières maritimes (au milieu de l'eau ne gagnent rien à être pointillées : c'est très fouillis en comparaison quand on a des lignes maritimes. L'exemple de la Baltique est parlant, et ce n'est pas cohérent quand on regarde la Grèce. Ne rien mettre autour, comme en France où on a supprimé les tags boundary=administrative inutiles, suffit très bien et ce n'est pas parce qu'une ligne de côte a ce tag qu'on doit le dessiner. Ce n'est que si la ligne de côte et a frontière s'écarte qu'on peut tracer la frontière (Elle devrait être taguée comme maritime=yes sans avoir à faire de calcul de géométrie, et dans ce cas elles sera tracée en ligne continu, juste d'un bleu visible plus sombre que la mer en couleur pleine, ce qui permet de confondre le trait avec l'ombrage semi transparent de mise en relief côté mer fait le long des côtes, si on en met un, et de résoudre les cas où le tracé administratif suit de très près la ligne de côte avec un tracé pas exactement superposé). L'ombrage des lignes de côte suffit à représenter la notion de ligne de base. Il n'est donc pas nécessaire d'ajouter autre chose, on n'a plus que des frontières terrestres en pointillés gris moyen (pas trop envahissant) et des frontières réellement en mer en bleu assombri qui vient se fondre dans le relief de la ligne de côte. La mise en relief des côtes pourrait être supprimé aussi le long des plages (natural=beach) ou tracé dans une couleur fondant le bleu de la mer et la couleur donnée à la plage (le jaune à moins qu'on tienne compte de la surface) cela peut être fait uniquement lors du tracé des plages et autres landuse, sachant que les frontières seront tracées par dessus de toute façon en gris foncé semi transparent si terrestre, bleu foncé semi-transparent si maritime. Mais plus de noir du tout pour ces frontières, c'est trop fort, ça pollue la lisibilité des icônes et libellés posées ensuite qu'on a ensuite tendance à trop renforcer en contraste aussi, et qui eux-mêmes cachent alors la lisibilité de l'arrière-plan. Gardont le noir uniquement pour les petits libellés (les plus gros libellés devraient ne pas être noirs mais gris foncés avec un halo blanc pour les villes, gris clair et plus grands et gras avec un halo clair et moins épais pour les régions et départements. Enfin je le répète, garder une homogénétité des styles de polices : ne pas alterner caractères droits et titaliques pour les noms de villes. réserver les italiques pour les quartiers et lieux-dits, ou pour les pays, régions ou départements. Pour les faibles niveaux de zoom où on n'a aucune nom de ville, les noms de pays devraient être lisibles et droits (même s'ils sont abrégés). Et ensuite par dessus ça on n'a plsu de problème à représenter les réserves et parcs naturels marins. Le 8 juillet 2013 19:15, Simon Miniou simon.min...@gmail.com a écrit : Par rapport aux autres grandes villes, Stockholm n'apparait pas à plusieurs niveaux de zoom : http://tile.openstreetmap.fr/?zoom=5lat=57.26277lon=18.82682layers=B0FFF Perso, je trouve que voir les côtes apporte bien quelque chose à la carte, ces limites existent et sont peu voir jamais représentées. --- Pour l'affichage des villes, si j'ai bien compris, la population est recherché sur les admin_centre ; ne serait-il pas possible de les compléter automatiquement avec les chiffres du dernier recensement ? Simon ___ 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
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
En amerique du sud il y a des trous dans les frontieres Les frontieres ne s'affiche pas si il n'y a pas le tag admin_level= sur le chemin meme si il y est dans la relation. probleme pour les pays et aussi plus bas. ici admin_level=4 : http://tile.openstreetmap.fr/?zoom=9lat=-2.21041lon=-46.51516layers=B0FFF Le 8 juillet 2013 17:53, Simon Miniou simon.min...@gmail.com a écrit : Bonjour, Sympa le zoom 4 ! (*beaucoup plus clair*) ; Par contre le rendu est bizarre en Amérique du Sud (ça provient peut être des données) : http://tile.openstreetmap.fr/?zoom=4lat=-26.66783lon=-63.79904layers=B0FFFhttp://tile.openstreetmap.fr/?zoom=4lat=-26.66783lon=-63.79904layers=B0FFF Sinon pour le zoom 3, on pourrait aussi mettre le nom des continents (avec la limite) : http://tile.openstreetmap.fr/?zoom=3lat=51.71291lon=-8.21921layers=B0FFF Simon ___ 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
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Le 8 juillet 2013 19:15, Simon Miniou simon.min...@gmail.com a écrit : Par rapport aux autres grandes villes, Stockholm n'apparait pas à plusieurs niveaux de zoom : http://tile.openstreetmap.fr/?zoom=5lat=57.26277lon=18.82682layers=B0FFF Perso, je trouve que voir les côtes apporte bien quelque chose à la carte, ces limites existent et sont peu voir jamais représentées. Euh... la côte c'est bien là où la terre (beige clair) se termine et ou la mer (bleu clair) commence ? On ne la voit pas assez la limite ? --- Pour l'affichage des villes, si j'ai bien compris, la population est recherché sur les admin_centre ; ne serait-il pas possible de les compléter automatiquement avec les chiffres du dernier recensement ? Pour être très précis, ce sont les nœuds place=* qui sont utilisés et les tags qu'ils ont. Trop compliqué d'exploiter les relations à ce niveau sans rétraitement. -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Le 8 juillet 2013 17:53, Simon Miniou simon.min...@gmail.com a écrit : Bonjour, Sympa le zoom 4 ! (beaucoup plus clair) ; Par contre le rendu est bizarre en Amérique du Sud (ça provient peut être des données) : http://tile.openstreetmap.fr/?zoom=4lat=-26.66783lon=-63.79904layers=B0FFF tu parle des frontières coupées ? C'est que je n'utilise pas les relations, mais directement les ways. Ca pose problème là où l'admin_level maximal n'a pas été renseigné... au moins, ça le met bien en évidence ;) Sinon pour le zoom 3, on pourrait aussi mettre le nom des continents (avec la limite) : http://tile.openstreetmap.fr/?zoom=3lat=51.71291lon=-8.21921layers=B0FFF place=continent ? je vais rajouter ça... je ne savais pas que ça existait, j'ai pas trop eu l'occasion de mapper ce tags ! -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Zoom 3 : les noms des capitales en Europe viennent polluer la carte (Geneva, Vienna…) je vois Kabul, mais pas Afghanistan tient, les noms sont en anglais (j'ai essayé du /dirty). L'algorithm d'affichage des noms serait différent suivant le niveau de zoom ? il n'existe pas dans cette base une procédure stockée ? Tu pourrais en créer une name() que tu appels partout ? Zoom 4 : La Suisse, la Pologne, l'Ukraine, la Lituanie, l'Espagne, la Turquie et j'en passe sont polluées par les codes des régions (champ ref ?). Pas les autres pays qui n'ont pas la chance d'en avoir :-D Île de Wright apparait, Minorque, Pélage, Saint-Pierre et Miquelon, mais pas le reste : est-ce utile de les afficher à ce niveau de zoom ? Zoom 5 : Pas de Paris, ni de Berne… aucune capitale il me semble. En Suisse, on voit à peine le nom du pays qui est pollué par les noms de régions (ici les cantons) Tu peux utilisé ref ici mais il me semble que c'est encore trop tôt d'afficher les régions ?? En Serbie, Bosnie Herzégovine, Roumanie… les limites de régions apparaissent sans libellé alors que pour la Pologne on a les libellés mais pas les contours. Zoom 6 : Les noms des grandes villes apparaissent mais rendent difficiles la lecture du nom des régions. Peut-être afficher un point mais sans libellé ? Pour la Suisse, utiliser les ref plutôt que les noms de cantons. L'algo pourrait-être : affiche ref, puis nom. ça marcherait pour la France et la Suisse, mais pour le reste du monde. Tu parlais de pré-traitements : c'est peut-être la solution ? : Pour chaque pays et chaque niveau de zoom, tu détermines à l'avance le champ que le rendu doit utiliser ? En Grèce, on a des villes avec point et libellé, d'autres juste avec un point (bizarre et peu lisible) Zoom 7 : Suisse : les noms de cantons semblent disproportionnés et certains manque encore Luxembourg : il ressemble à un poumon ou une truffe au choix :-D France : c'est lisible :-) En conclusion, pas facile de faire des cartes ;-) -- Yves PS: bon courage___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Le 07/07/2013 08:38, Yves Pratter a écrit : [...] Bravo au codeur et au beta-testeur ! -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Le 7 juillet 2013 00:13, Philippe Verdy verd...@wanadoo.fr a écrit : Le 6 juillet 2013 20:29, Christian Quest cqu...@openstreetmap.fr a écrit : La solution: placer les noms des rues courtes (plus difficile à placer donc) en premier... Problème : une fois qu'on a placé toutes les petites rues traversales d'une avenue, on n'a plus de place pour le nom de l'avenue coupé trop souvent. Cela veut dire plutôt pouvoir placer les nom de l'avenue en ardant l'info sur ses noeuds de début et sa fin sur le chemin, puis tenter de placer les rues plus courtes (en commençant par les plus longues; seulement s'il reste de la place pour couper davantage le nom du plus long segment de rue. Chaque fois qu'on découpe une avenue plus longue rue en deux parties, on s'assure de garder au moins un nom sur le premier et le dernier segment de l'avenue. Une fois que toutes les rues sont découpées par celles plus courtes qui les traverse, on rebalaye la liste des segments composant une rue pour voir ceux qui assez éloignés entre eux, peuvent reproduire le nom davantage: on repère ceux des segments intermédiaires qui sont assez longs (on élimine les autres segments intermédiaires, et on répartit ces noms autant de fois que nécessaire pour éviter de trop grands écarts entre eux. Tout ça ne peut pas se faire dans le SQL, et nécessiterait un code plutôt du coté du client SQL du moteur de rendu. Donc quelque chose comme un plugin gérant des règles supplémentaires de placement, que les options actuelles de Mapnik ne peuvent pas gérer avec une requête SQL unique avec une priorité unique et un simple tri ORDER BY fait en SQL, même augmenté des fonctions d'extension GIS. Ce genre de traitement ne rentre pas dans le langage compris par les extension GIS. Cela demanderait à Mapnik de supporter des listes d'objets personnalisées modifiables par code. Sans doute avec un langage de script, intégré par un plugin hôte de VM de type Python, Lua, PHP, Javascript (voire Java si on y intègre la compilation de classes à la demande), et muni des bindings nécessaires pour accéder à l'API de Mapnik, ou permettant à Mapnik d'exposer ses objets au plugin hôte du langage de script Toutes les listes d'objets manipulées par un tel plugin seraient modifiables tant qu'elles sont dans le même layer de Mapnik, et éventuellement le script exécuté par le plugin pourrait faire aussi d'autres requêtes SQL complémentaires (pour éviter à la sélections initiale de faire trop de traitements pour récupérer des données dont l'utilité ne sera déterminée qu'à l'exécution du script selon ses propres règles. Quand le script se termine, il reste des listes d'objets, auquel le script a attribué des noms symboliques de classes, qu'on peut ensuite styler avec le langage de style existant de Mapnik (un langage que le script peut aussi contrôler en générant ses feuilles de style). Le script se termine, la liste d'objet peut être conservée pour les layers suivants si le script le demande. Le script pourrait aussi utiliser son propre stockage SQL dans des tables complémentaires si cela facilite les requêtes SQL des layers suivants. Chaque layer Mapnik en fait ne serait pas obligé de tracer les objets immédiatement sélectionnés, ils peuvent être gardés par le script propre au layer qui peut les garder dans un état encore modifiable. Et il doit encore être possible d'ajouter des layers Mapnik sans sélection SQL depuis les données géographiques mais depuis les données complémentaires insérées lors du travail des scripts dans la base SQL sur des tables de travail. On n'est plus limité du tout alors par la division arbitraire en listes de priorités basées sur l'ordre des layers, qui n'est plus qu'un ordre d'exécution des requêtes de sélections de données, et plus un ordre d'affichage imposé. Yaka Logiquement, le nom doit être répété à intervalle régulier, ça se règle aussi, comme pour les noms des rues / routes qu'on répète, en tenant compte aussi de la taille d'un écran qui sert à consulter la carte, car c'est ça qui dicte la fréquence à laquelle il faut répéter les noms. Mapnik est conçu pour générer un rendu à une échelle bien définie. La tailel de l'écran importe peu car ici on travaille dans le système de coordonnées du rendu et non plus dans le système géographique. On a donc des mesures en pixels (ou pixels logiques) y compris pour les tailles de polices utilisées, les épaisseurs de traits, les tailles d'icônes. etc. Mpanik devrait s'occuper déjà de changer la projection initiale (en longitude, latitude WGS84) dans la projection 2D du rendu (voire 3D si on lui doit convertir des tags comme ele=* spécifiés à prirori en mètres et non dans l'unité du système de coordonnées de la tuile de rendu) Mapnik fonctionne déjà comme ça. On raisonne en pixels et pas en coordonnées qui en général ne sont même plus stockées en WGS84 mais reprojetées par osm2pgsql en Google Mercator, justement pour simplifier le
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
J'ai remis de l'ordre... en fait il restait des couches de données non OSM utilisées historiquement pour les premiers niveaux de zoom et aussi pour des besoins de perf. J'ai rajouté des index qui font que j'ai pu virer ces couches être en 100% OSM et gagner en rapidité (moins de 2mn pour générer un zoom 4 à 6 mondial). zoom4: frontières des pays et noms de pays uniquement + un petit point pour signaler la capitale zoom5: les capitales apparaissent, les limites de régions et leurs noms, les grosses iles et archipels zoom6: les villes font leur apparition... le nom de pays disparait, on a un peu plus d'iles zoom7: encore plus de villes et d'iles... Le 7 juillet 2013 08:38, Yves Pratter yves.prat...@laposte.net a écrit : Zoom 3 : les noms des capitales en Europe viennent polluer la carte (Geneva, Vienna…) je vois Kabul, mais pas Afghanistan tient, les noms sont en anglais (j'ai essayé du /dirty). L'algorithm d'affichage des noms serait différent suivant le niveau de zoom ? il n'existe pas dans cette base une procédure stockée ? Tu pourrais en créer une name() que tu appels partout ? Zoom 4 : La Suisse, la Pologne, l'Ukraine, la Lituanie, l'Espagne, la Turquie et j'en passe sont polluées par les codes des régions (champ ref ?). Pas les autres pays qui n'ont pas la chance d'en avoir :-D Île de Wright apparait, Minorque, Pélage, Saint-Pierre et Miquelon, mais pas le reste : est-ce utile de les afficher à ce niveau de zoom ? Zoom 5 : Pas de Paris, ni de Berne… aucune capitale il me semble. En Suisse, on voit à peine le nom du pays qui est pollué par les noms de régions (ici les cantons) Tu peux utilisé ref ici mais il me semble que c'est encore trop tôt d'afficher les régions ?? En Serbie, Bosnie Herzégovine, Roumanie… les limites de régions apparaissent sans libellé alors que pour la Pologne on a les libellés mais pas les contours. Zoom 6 : Les noms des grandes villes apparaissent mais rendent difficiles la lecture du nom des régions. Peut-être afficher un point mais sans libellé ? Pour la Suisse, utiliser les ref plutôt que les noms de cantons. L'algo pourrait-être : affiche ref, puis nom. ça marcherait pour la France et la Suisse, mais pour le reste du monde. Tu parlais de pré-traitements : c'est peut-être la solution ? : Pour chaque pays et chaque niveau de zoom, tu détermines à l'avance le champ que le rendu doit utiliser ? En Grèce, on a des villes avec point et libellé, d'autres juste avec un point (bizarre et peu lisible) Zoom 7 : Suisse : les noms de cantons semblent disproportionnés et certains manque encore Luxembourg : il ressemble à un poumon ou une truffe au choix :-D France : c'est lisible :-) En conclusion, pas facile de faire des cartes ;-) -- Yves PS: bon courage ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Dernier ajout... une tentative de comblage de déserts... Il y a des endroits avec très peu de ville (town) et donc il faut énormément zoomer pour commencer à voir des toponymes. Actuelle sur le rendu OSM les village ne sont visibles qu'au zoom 12 ! Afin de combler ces trous (très prononcés sur des zones peu peuplées), j'ai remonté le rendu des village à partir du zoom 6, mais, en les triant par population décroissance et en imposant au moins 50 pixels de libre. Ceci limite largement la densité et conserve une carte lisible. J'ai un doute sur le choix des villages ainsi rendus, par exemple, un village que je connais bien avec plus de 2000 habitants n'est pas visible alors que le voisin avec 800 habitants a pris la place. Si vous tombez sur d'autres exemples de choix incohérent merci de passer un permalien et une petite explication... Les zoom 6 à 8 sont à jour, le reste est en cours de rendu. Un exemple: Avant: http://tile.openstreetmap.fr/?zoom=6lat=23.647lon=46.6634layers=B0FFF Après: http://tile.openstreetmap.fr/?zoom=6lat=23.647lon=46.6634layers=B0FFF (c'est efficace aussi en France pour des coins nettement moins désertiques) Le 7 juillet 2013 14:39, Christian Quest cqu...@openstreetmap.fr a écrit : J'ai remis de l'ordre... en fait il restait des couches de données non OSM utilisées historiquement pour les premiers niveaux de zoom et aussi pour des besoins de perf. J'ai rajouté des index qui font que j'ai pu virer ces couches être en 100% OSM et gagner en rapidité (moins de 2mn pour générer un zoom 4 à 6 mondial). zoom4: frontières des pays et noms de pays uniquement + un petit point pour signaler la capitale zoom5: les capitales apparaissent, les limites de régions et leurs noms, les grosses iles et archipels zoom6: les villes font leur apparition... le nom de pays disparait, on a un peu plus d'iles zoom7: encore plus de villes et d'iles... Le 7 juillet 2013 08:38, Yves Pratter yves.prat...@laposte.net a écrit : Zoom 3 : les noms des capitales en Europe viennent polluer la carte (Geneva, Vienna…) je vois Kabul, mais pas Afghanistan tient, les noms sont en anglais (j'ai essayé du /dirty). L'algorithm d'affichage des noms serait différent suivant le niveau de zoom ? il n'existe pas dans cette base une procédure stockée ? Tu pourrais en créer une name() que tu appels partout ? Zoom 4 : La Suisse, la Pologne, l'Ukraine, la Lituanie, l'Espagne, la Turquie et j'en passe sont polluées par les codes des régions (champ ref ?). Pas les autres pays qui n'ont pas la chance d'en avoir :-D Île de Wright apparait, Minorque, Pélage, Saint-Pierre et Miquelon, mais pas le reste : est-ce utile de les afficher à ce niveau de zoom ? Zoom 5 : Pas de Paris, ni de Berne… aucune capitale il me semble. En Suisse, on voit à peine le nom du pays qui est pollué par les noms de régions (ici les cantons) Tu peux utilisé ref ici mais il me semble que c'est encore trop tôt d'afficher les régions ?? En Serbie, Bosnie Herzégovine, Roumanie… les limites de régions apparaissent sans libellé alors que pour la Pologne on a les libellés mais pas les contours. Zoom 6 : Les noms des grandes villes apparaissent mais rendent difficiles la lecture du nom des régions. Peut-être afficher un point mais sans libellé ? Pour la Suisse, utiliser les ref plutôt que les noms de cantons. L'algo pourrait-être : affiche ref, puis nom. ça marcherait pour la France et la Suisse, mais pour le reste du monde. Tu parlais de pré-traitements : c'est peut-être la solution ? : Pour chaque pays et chaque niveau de zoom, tu détermines à l'avance le champ que le rendu doit utiliser ? En Grèce, on a des villes avec point et libellé, d'autres juste avec un point (bizarre et peu lisible) Zoom 7 : Suisse : les noms de cantons semblent disproportionnés et certains manque encore Luxembourg : il ressemble à un poumon ou une truffe au choix :-D France : c'est lisible :-) En conclusion, pas facile de faire des cartes ;-) -- Yves PS: bon courage ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...
Le 7 juillet 2013 22:47, Christian Quest cqu...@openstreetmap.fr a écrit : Si vous tombez sur d'autres exemples de choix incohérent merci de passer un permalien et une petite explication... En Vendée à http://tile.openstreetmap.fr/?zoom=9lat=46.37024lon=-1.34067layers=B0FFFapparait au zoom 9 un obscur trou paumé dit Les Conches dans une zone avec plein de patelins largement plus importants autour. (La Tranche sur mer, par ex). Il disparait (heureusement) au zoom 11 http://tile.openstreetmap.fr/?zoom=11lat=46.36479lon=-1.43543layers=B0FFFpour réapparaitre (bien) au 12 http://tile.openstreetmap.fr/?zoom=12lat=46.3893lon=-1.45157layers=B0FFF Autre remarque super constructive : au zoom 10 http://tile.openstreetmap.fr/?zoom=10lat=46.41239lon=-1.15803layers=B0FFFest-il judicieux de faire apparaître les micro-aérodromes (Aérodrome de La Tranche sur mer) ? Leur nom est illisibles mais bouffe une place phénoménale sur la carte et il y a une personne sur 100.000 qui s'en préoccupe. Cordialement. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
