Il y a un effet de bord quand on passe du POI (noeud) au surfacique (batiment). Sur le rendu OSM standard cela fait très souvent disparaitre le nom et l"icone (même si le bâtiment a tous les tags nécessaires en plus du building=*).
J'ai vu le cas de deux bâtiments mitoyens, l'un avec un seul service, tagué en surfacique sur le batiment, l'autre non tagué sur son batiment similaire car il y avait deux POIs dessus; résultat: disparition du nom dur le premier batiment (à tous les niveaux de zoom, même quand il y a largement la place), mais les deux noeuds sur le bâtiment voisins affichés avec leur nom et leur icône. Mais si on passe au rendu OSM.fr, on constate exactement l"inverse ! Bref les choix faits dans l'OSMcarto d'OSM.org et ceux faits dans le rendu OMSfr sont incompatibles: on ne peut pas taguer pour les deux, donc on tague forcément pour un. Mais étant donné les mauvaises performances (serveur trop limité en ressources) de la carto OSMfr, beaucoup font le choix de garder la solution qui marche avec le rendu OSM.org. Et là on ne parle que des rendus en tuiles bitmap. Les rendus vectoriels (y compris les exports pour appareils navigateurs GPS) s'en sortent mieux, même si au final c'est pas aussi joli car le rendu vectoriel est limité par la capacité des navigateurs web actuels notamment sur mobiles, et ils fontrent beaucoup plus de choses (mais il serait temps d'étendre cela et songer à déprécier à l'avenir les tuiles bitmaps, qui sont difficilement navigables/orientables et leur mise à jour est lente et très coûteuse (d'où de sérieux problèmes de "scalability" pour pouvoir offrir des carte à plein de monde, sauf en hébergeant ce service chez Mapbox). Même Wikimedia a du mal à générer et servir correctement les tuiles qu'il fabrique pour ses wikis: nombre de cartes affichent trop de tuiles grises qui mettent un temps fou à s'afficher ou parfois ne s'affichent jamais, même sans aller bien loin au niveau des zooms avant. Les rendus vectoriels fonctionnent bien aujourd'hui (en témoigne les rendus pour navigateurs GPS embarqués, ou les jeux comme Microsoft Flight Simulator car même s'ils filtrent les éléments à afficher ils ajoutent pas mal de choses pour enrichir le visuel, mais on peut voir aussi un rendu vectoriel fonctionnel et pas aussi "filtrant" chez Mapbox aussi sans subir les choix éditoriaux du concepteur du jeu poru ce qu'ils décident de rendre visibles; si les jeux utilisent maintenant OSM, c'est parce que c'est une carte riche en diversité et que cela sert de base plus naturelle que les cartes générées par des algos artificiels qui ont le défaut de reproduire trop souvent les mêmes patterns un peu partout, OSM a l'avantage de la diversité et de l'unicité, même si on peut ensuite enrichir avec des données générées ou en utilisant des extraits cartographiques à certains endroits comme base de modification et "combiner" des zones sans reproduire les patterns, le jeu gagne beaucoup en intérêt car il y a plus de choses à découvrir et l'expérience se renouvelle constamment, ce qui évite l'ennui, les tactiques toutes faites connues des joueurs plus expérimentés, et plus d'équité entre joueurs). Le dim. 30 août 2020 à 09:47, Christian Quest <cqu...@openstreetmap.fr> a écrit : > Le 30/08/2020 à 08:29, Arnaud Champollion a écrit : > > Le 29/08/2020 à 20:13, osm.sanspourr...@spamgourmet.com a écrit : > >> Donc les rendus affichant les fontaines n'ont pas la place d'afficher le > >> nom (en fait à un certain niveau de zoom en ne centrant pas ce serait > >> possible). Les autres si. > > > > Ou alors il faudrait que le rendu décale le nom là où c'est possible. > > Dans le cas présent, au zoom 19 et peut-être 18, un humain saurait le > > décaler au sud de la fontaine, quitte à manger sur les chemins. > > > > J'imagine que c'est autre chose de traduire ça en algorithme pour un > > rendu. > > > > Sinon, est-ce qu'ajouter un short_name=Jardin J. d’Albret (en > > abréviant le prénom) peut permettre aux rendus qui l'utilisent de le > > substituer en cas de manque de place ? > > > Aux zooms élevé, 'est bien à cause de la fontaine située quasiment au > centroid du jardin que le nom ne trouve pas sa place. > > Pour le zoom 17, il pourrait tenir, mais le nom du parking est sûrement > placé avant (les amenity=* placés en priorité). > > Décaler les objets est possible, il y a un mécanisme dans mapnik qui le > permet, mais cela a des effets de bord... au bord des tuiles. Le > décalage pouvant se faire sur une tuile à cause d'un objet déjà placé, > mais pas sur la voisine, l'objet étant trop loin pour être pris en > compte comme déjà placé. > > C'est TRES compliqué de générer de façon purement algorithmique un rendu > auto-adaptatif. mapnik a des mécanismes limités à ce niveau. > (https://carto.com/developers/styling/cartocss/#text-placements-string). > > Dans le chantier toujours en cours sur la feuille de style, j'utilise de > plus en plus la taille des objets pour décider d'afficher leur nom et > ajuster la taille du texte. Postgresql calcule ainsi approximativement > la surface en pixels de l'objet pour faciliter la prise en compte par la > feuille de style. Cela permet aussi de simplifier la feuille de style > car je faisais cela avant avec des tests en fonction du niveau de zoom > et de la taille 'brute' des polygones. > > > Pour répondre à deuzeffe... oui osmfr-cartoss est un fork de > openstreetmap-carto, mais un fork qui date de 2012 et qui largement > divergé depuis. > > Les fontaines ne sont pas rendues sur les autres styles, ou alors à des > zoom plus élevés ou avec des priorités différentes. > > > Plus globalement, devrait-on prioriser le mapping des POI en surfacique, > qu'on peut ordonner par surface contrairement à ceux ponctuels pour > lesquels il est difficile de déterminer leur importante relative sur une > carte ? Je pense que oui. Cela permettrait ici d'avoir le nom du jardin > en zoom 17 avant celui du parking, mais en zoom 18 et suivant, l’icône > de la fontaine viendrait reprendre sa place (les icônes sont placées > avant les noms car elles prennent moins de place). > > Bien souvent dans mes contributions, je remet des POI en surfacique > alors qu'ils ne sont que ponctuels, la première étape consistant souvent > à migrer un tag sur un bâtiment entier, mais la seconde, quand on le > peut, consiste à délimiter plus largement l'emprise de tel ou tel POI. > Cas typique: les écoles ! > > -- > Christian Quest - OpenStreetMap France > > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
