Bonjour En cartographiant le réseau de bus de ma ville, j'avais pris la
décision de représenter les arrêts de bus, pour la partie platform,
par un nœud avec en plus de l'attribut public_transport=platform
les différents attributs décrivant l'équipement de l'arrêt: shelter=yes/no,
bench=yes/no, bin=yes/no etc. Au fil du temps, d'autres contributeurs ont ajouté séparément
certains de ces équipements, par exemple sur un nœud (ou way) amenity=shelter
+ shelter_type=public_transport ou amenity=waste_basket. On gagne certes en précision et détail, mais je doute que les
principales applications orientées transport soient alors capable
d'indiquer de façon complète l'équipement de l'arrêt. J'aimerais connaitre votre avis sur la question pour décider de la meilleure méthode à appliquer. Merci._______________________________________________ Talk-fr mailing list [hidden email] https://lists.openstreetmap.org/listinfo/talk-fr |
Le 07-01-2021 18:46, blef a écrit :
amenity=shelter/waste_basket alors qu'il y a déjà shelter=yes ou bin=yes sur l'arrêt, c'est un doublon ! Qui n'a donc aucun intérêt. Mais en général, je contacte d'abord l'utilisateur pour lui exposer ce que j'ai l'intention de faire afin de garder une cohérence / maintenabilité. Ceci afin d'éviter une guerre de modifs. Si c'est un fanatique des poubelles sur les nœuds, je laisse tomber, il y a mieux à faire pour améliorer la qualité OSM. :-) _______________________________________________ Talk-fr mailing list [hidden email] https://lists.openstreetmap.org/listinfo/talk-fr |
C'est vrai inutile de le traiter de tête de nœud ^^.
Le 07/01/2021 à 21:22, Georges Dutreix via Talk-fr - [hidden email] a écrit : > > Si c'est un fanatique des poubelles sur les nœuds, je laisse tomber, > il y a mieux à faire pour améliorer la qualité OSM. :-) > _______________________________________________ Talk-fr mailing list [hidden email] https://lists.openstreetmap.org/listinfo/talk-fr |
In reply to this post by blef
Une stop area peut être très vaste, son but est lié au schéma de transport pour les interactions; cela n'a rien à voir avec les abris, bancs ou poubelles qui sont autour : mettre ces attributs qui conernent un objet individuel et pas automatiquement les autres dans la relation "stop_area" n'a pas grand sens. La relation stop_area a des membres bien précis pour indiquer leur rôle. La facilité qu'on a de pouvoir ajouter "shelter/bench/bin=yes/no" sur un autre objet est une simplication de cet objet qui évite juste de créer un autre objet au **même endroit** cet endroit n'est **pas** la stop_area" entière Bref je pense qu'on ne doit pas déplacer les attributs des membres de la relation "stop_area" (qui ne sont membres que pour leur rôle particulier dans le schéma de transport et les interconnexion, indépendamment de leur équipement annexe qui ne participe pas à ce rôle) vers cette relation qui n'est pas un "multipolygon" (ou une frontière "boundary": variante qui existe juste parce qu'elle a quelques rôles supplémentaires mais qui là aussi décrit la géométrie d'une surface entière). Un tel déplacement n'est pas prévu et ne fait que compliquer: une stop_area peut très bien avoir un banc dans un des arrêts et pas un autre, une poubelle dans un et pas un autre, la stop_area peut aussi avoir des neuds d'emplacements d'arrêt sur la voie où ces équipements ne sont **pas** présents (sur la voir même, certainement pas à ces endroits). Ces petits équiepements doivent rester au niveau le plus géolocalisé localement, la "stop_area" étant trop grande. Il vaut mieux s'en tenir au schéma de transport tel qu'il est défini (par ses rôles) et éviter une telle extension sémantique qui n'a pas grand sens. Le jeu. 7 janv. 2021 à 18:47, blef <[hidden email]> a écrit :
_______________________________________________ Talk-fr mailing list [hidden email] https://lists.openstreetmap.org/listinfo/talk-fr |
In reply to this post by Bibi
C'est de la sagesse. Le contributeur qui veut absolument ajouter son nœud dans l'arrêt, il ne faut pas tenter d'intervenir. Le 07-01-2021 21:58, [hidden email] a écrit :
_______________________________________________ Talk-fr mailing list [hidden email] https://lists.openstreetmap.org/listinfo/talk-fr |
In reply to this post by Philippe Verdy
Philippe, il me semble que Bernard voulait uniquement dire "faire disparaître" *shelter=yes/no* des platform et que les objets poubelle devraient être ajoutés à la relation stop area. Logiquement il a raison. Encore que une poubelle est elle intrinsèquement partie de la relation ? Non, vous pouvez déposer un papier sans valider un ticket ;-). Perd-t-on de le l'information ? Nom, par proximité géographique on peut retrouver les poubelles. Je ne vois pas trop l'intérêt de positionner les poubelles sauf que : - ça peut permettre à un aveugle de l'utiliser (mais s'il a un papier à jeter il le fera plus efficacement à la maison). Au fait bonne année Sébastien, tu peux nous dire si ça te semble utile. - ça peut permettre d'ajouter une référence afin de faciliter la déclaration de dégradations à la maire par exemple. Ceci dit pour moi savoir qu'il y a une poubelle à un arrêt c'est du luxe. Si je dois aller prendre le bus je vais peut-être ne pas choisir l'arrêt le plus proche pour avoir un abri, par contre ne pas descendre à un arrêt parce qu'il n'y pas de poubelle... Là éventuellement c'est la distance de la poubelle la plus proche qui m'intéresse. Bernard, tu peux dire que le poubelle n'était pas à décrire car déjà dans shelter=yes. Et s'il le contributeur incite, tu lui demande de mettre à jour la plateforme et supprimant *shelter=yes*. Oui il est probable que quelqu'un ne voyant pas la poubelle l'ajoutera. Il me semble qu'on a plus intéressant à faire que de se prendre le chou avec. Donc un message et expliquant pourquoi il ne faut pas faire comme il le fait doit suffire : tu lui donnes les 2 possibilités. Jean-Yvon _______________________________________________ Talk-fr mailing list [hidden email] https://lists.openstreetmap.org/listinfo/talk-fr |
Le jeu. 7 janv. 2021 à 22:34, <[hidden email]> a écrit :
J'avais parfaitement compris et j'ai été clair, je parlais bien de ça, et à mon avis ce n'est PAS à faire car cela ne fait pas partie des rôles pour lesquels les arrêts (les objets "stop" uniquement) sont membres de cette relation. Logiquement il n'ont rien à faire dans la relation car ils ne sont PAS localisés dans *toute* la relation (où il peut encore manquer des membres, dont les "stop_position",), pas plus que et les différentes lignes ("route" ou "route_master") qui s'y connectent (même si ces "route_*" ne sont pas membres directement). Et dans le cadre des relations "route/route_master" justement, elles référencent les lignes et arrêts, pas directement les relations "stop_area" qui font les interconnexions d'un réseau: ce sont aux objets "stop" membres des "route" qu'on s'attend à trouver les infos liées sur les abris ou équipements... qui du coup vont disparaitre des schémas de lignes (plus d'indication par exemple sur l'accessibilité d'une station, ou un point d'information/guichet voyageur, ou un abri: un outil qui voudrait les afficher sous forme de notes ou d'icones sera perdu, il lui faudra rechercher pour chaque arrêt s'il fait partie d'une relation "stop_area", et s'il le fait il risque de trouver des infos fausses sur cette arrêt qui n'a pas cet équipement. Rien que les poubelles, on ne les met sur un arrêt que pour éviter un second noeud proche alors que ces poubelles sont dans (ou collées à) un abri (souvent en fait les poubelles sont plutôt à côté pas loin on aurait pu les mettre sur un noeud séparé. De même une "stop_area" a vocation a contenir un membre surfacique pour par exemple un batiment (comme une gare), un parking, des quais, des couloirs (ou tapis roulants, escalators, ascenceurs...) d'interconnexion. Chaque arrêt individuel peut avoir d'autres éléments (télésurveillance par exemple, barrières de contrôle d'accès, bornes d'achats de titres) qu'on ne trouve pas dans tous les autres membres de la relation "stop_area". Il faut s'en tenir au "rôle" donné à chaque membre inclus dans la relation membre_area: une poubelle ou un abri n'est pas un "stop" et n'a pas ce rôle et ne fait pas partie des autres membres "stop position". Et s'il y a un membre pour la gare ou un parking (tagués comme des surfaces normales en "way fermé" ou relation "multipolygon"), on ne saura plus localiser ces petits équipements qui ne sont que là où l'indique indivisuellement chaque "stop". C'est une question de logique et cela bloquera encore plus les modifications des "stop_area" s'il faut aller les inspecter un par un pour voir s'il n'y a pas "trop" de membres dedans auxquels ces attributs ne s'appliquent **pas**. _______________________________________________ Talk-fr mailing list [hidden email] https://lists.openstreetmap.org/listinfo/talk-fr |
In reply to this post by Bibi
Le 07/01/2021 à 22:33, [hidden email] a écrit :
> Je ne vois pas trop l'intérêt de positionner les poubelles sauf que : > - ça peut permettre à un aveugle de l'utiliser (mais s'il a un papier à > jeter il le fera plus efficacement à la maison). Moi je m'en sers en micro-mapping pour faire de l'orientation avec de jeunes élèves. Comme on travaille sur des zones peu étendues (souvent moins de 300 mètres) on utilise beaucoup de détails pour se repérer. Et tout est bon à prendre : poubelles, arbres, souches, blocs de béton, lampadaires ... du moment qu'il y a un attribut OSM pour ça et que l'objet existe sur le terrain. Arnaud _______________________________________________ Talk-fr mailing list [hidden email] https://lists.openstreetmap.org/listinfo/talk-fr |
In reply to this post by Bibi
Les relations... sont souvent de fausses solutions ;)
bench=yes ou bin=yes, indique qu'il y a un banc ou une poubelle à cet arrêt, mais ça n'indique pas l'emplacement exact de ces objets, juste, qu'il y a ce type d'équipements, c'est un premier niveau de description. une géométrie avec amenity=bench ou amenity=waste_wasket indique où se trouvent ces équipements, et je ne pense pas que ça fasse doublon avec les tags précédents, c'est un second niveau de description Mettre ça dans une relation... bof bof bof... surtout une stop_area avec plein de platform, etc... Si on veut savoir si il y a une poubelle ou un banc à un arrêt, on devrait le faire sur bench=yes et bin=yes et c'est bien plus simple que de se farcir des relations. Si on veut savoir quels sont les bancs/poubelles à proximité d'un arrêt, on le fait par la géométrie Savoir que tel banc fait partie de l'arrêt est délicat, sauf pour un abribus ou il n'y a pas d'ambiguité. Sur un arrêt "poteau" il y a parfois un banc à proximité, je ne sais pas si c'est la RATP ou la Ville qui l'a installé, etc, etc... Le 07/01/2021 à 22:33, [hidden email] a écrit : > > Philippe, il me semble que Bernard voulait uniquement dire "faire > disparaître" *shelter=yes/no* des platform et que les objets poubelle > devraient être ajoutés à la relation stop area. > Logiquement il a raison. > Encore que une poubelle est elle intrinsèquement partie de la relation ? > Non, vous pouvez déposer un papier sans valider un ticket ;-). > Perd-t-on de le l'information ? Nom, par proximité géographique on peut > retrouver les poubelles. > > Je ne vois pas trop l'intérêt de positionner les poubelles sauf que : > - ça peut permettre à un aveugle de l'utiliser (mais s'il a un papier à > jeter il le fera plus efficacement à la maison). Au fait bonne année > Sébastien, tu peux nous dire si ça te semble utile. > - ça peut permettre d'ajouter une référence afin de faciliter la > déclaration de dégradations à la maire par exemple. > > Ceci dit pour moi savoir qu'il y a une poubelle à un arrêt c'est du > luxe. Si je dois aller prendre le bus je vais peut-être ne pas choisir > l'arrêt le plus proche pour avoir un abri, par contre ne pas descendre à > un arrêt parce qu'il n'y pas de poubelle... Là éventuellement c'est la > distance de la poubelle la plus proche qui m'intéresse. > > Bernard, tu peux dire que le poubelle n'était pas à décrire car déjà > dans shelter=yes. Et s'il le contributeur incite, tu lui demande de > mettre à jour la plateforme et supprimant *shelter=yes*. > > Oui il est probable que quelqu'un ne voyant pas la poubelle l'ajoutera. > > Il me semble qu'on a plus intéressant à faire que de se prendre le chou > avec. > > Donc un message et expliquant pourquoi il ne faut pas faire comme il le > fait doit suffire : tu lui donnes les 2 possibilités. > > Jean-Yvon > > > > _______________________________________________ > Talk-fr mailing list > [hidden email] > https://lists.openstreetmap.org/listinfo/talk-fr > Christian Quest - OpenStreetMap France _______________________________________________ Talk-fr mailing list [hidden email] https://lists.openstreetmap.org/listinfo/talk-fr
Christian Quest - cquest@openstreetmap.fr
|
mettre tout dans un stop_area conduit à avoir une relation avec des
milliers de membres pour la gare du nord à Paris, sans que la plus-value saute aux yeux (les relations ne sont pas des collections). surtout que la limite est sans fin : cet arrêt à un vendeur de café, un magasin de journaux, un parking, une entreprise de bureau partagé à l'étage, ... bench=yes <> amenity=bench ne représente pour moi pas la même chose : le premier est une caractéristique de l’arrêt (cet arrêt à un banc), le deuxième est l'objet "banc" si on veux éviter les bouclons de stats entre "je compte une première fois les arrêts dotés d'un banc" et "les bancs", certains utilisent bench=separate (sur le modèle de sidewalk=separate), cela indique que l'arrêt à un banc et qu'il a été renseigné lui aussi par un objet cela a aussi l'avantage de pouvoir monter en qualité (celui qui veux ajouter des bancs n'a qu'à prendre les bench=yes et sait renseigner ceux qui sont traité) idem pour bin=separate shelter=separate dans tous les cas, je n'effacerais ni bench=yes ni amenity=bench, cela n'apporte rien d'autres que de faire du yoyo entre ajout/suppression puisque les 2 sont juste _______________________________________________ Talk-fr mailing list [hidden email] https://lists.openstreetmap.org/listinfo/talk-fr |
In reply to this post by cquest
Le 08/01/2021 à 09:46, Christian Quest a écrit :
> Les relations... sont souvent de fausses solutions ;) > > bench=yes ou bin=yes, indique qu'il y a un banc ou une poubelle à cet > arrêt, mais ça n'indique pas l'emplacement exact de ces objets, juste, > qu'il y a ce type d'équipements, c'est un premier niveau de description. > > une géométrie avec amenity=bench ou amenity=waste_wasket indique où se > trouvent ces équipements, et je ne pense pas que ça fasse doublon avec > les tags précédents, c'est un second niveau de description > > Mettre ça dans une relation... bof bof bof... surtout une stop_area > avec plein de platform, etc... > > Si on veut savoir si il y a une poubelle ou un banc à un arrêt, on > devrait le faire sur bench=yes et bin=yes et c'est bien plus simple > que de se farcir des relations. > > Si on veut savoir quels sont les bancs/poubelles à proximité d'un > arrêt, on le fait par la géométrie > > Savoir que tel banc fait partie de l'arrêt est délicat, sauf pour un > abribus ou il n'y a pas d'ambiguité. Sur un arrêt "poteau" il y a > parfois un banc à proximité, je ne sais pas si c'est la RATP ou la > Ville qui l'a installé, etc, etc... Bon j'ai pas besoin d'écrire une réponse, ça correspond exactement à mon point de vue, merci Christian :) _______________________________________________ Talk-fr mailing list [hidden email] https://lists.openstreetmap.org/listinfo/talk-fr |
In reply to this post by Marc_marc
Le 08/01/2021 à 10:49, Marc_marc a écrit : > mettre tout dans un stop_area conduit à avoir une relation avec des > milliers de membres pour la gare du nord à Paris, sans que la plus-value > saute aux yeux (les relations ne sont pas des collections). > surtout que la limite est sans fin : cet arrêt à un vendeur de café, > un magasin de journaux, un parking, une entreprise de bureau partagé > à l'étage, ... Pareil, je ne vois pas l'utilité > bench=yes <> amenity=bench ne représente pour moi pas la même chose : > le premier est une caractéristique de l’arrêt (cet arrêt à un banc), le > deuxième est l'objet "banc" > > si on veux éviter les bouclons de stats entre "je compte une première > fois les arrêts dotés d'un banc" et "les bancs", certains utilisent > bench=separate (sur le modèle de sidewalk=separate), cela indique > que l'arrêt à un banc et qu'il a été renseigné lui aussi par un objet > cela a aussi l'avantage de pouvoir monter en qualité (celui qui veux > ajouter des bancs n'a qu'à prendre les bench=yes et sait renseigner > ceux qui sont traité) > idem pour bin=separate shelter=separate > > dans tous les cas, je n'effacerais ni bench=yes ni amenity=bench, > cela n'apporte rien d'autres que de faire du yoyo entre > ajout/suppression puisque les 2 sont juste Je ne connaissais pas "*=separate" et je vais l'adopter. Jusqu'à présent, je pensais que c'était la même chose et je ne touchais pas ce qu'avait fait un autre contributeur (même si c'était différent de ce que j'aurais fait) pour ne pas intervenir sur le nombre, maintenant s'il y a les deux déclarations j'utiliserais cet attribut qui ne fausse pas les stats si pour avoir le nombre de bancs on additionne les deux. leni _______________________________________________ Talk-fr mailing list [hidden email] https://lists.openstreetmap.org/listinfo/talk-fr |
In reply to this post by blef
Bonjour,
Merci pour vos avis.
Si je résume:
Si vous avez d'autres idées...
Le 07/01/2021 à 18:46, blef a écrit :
_______________________________________________ Talk-fr mailing list [hidden email] https://lists.openstreetmap.org/listinfo/talk-fr |
Hello, N'ayant pas grand chose à ajouter, je n'ai pour l'instant pas pris part à la discussion. Il me semble en effet que la cohabitation entre tags sur l'arrêt ou objets à proximité va perdurer. Côté exploitants (autorités organisatrices des transports, transporteurs ...) qui sont les clients de l'entreprise Jungle Bus, il est évident que seuls les tags présents sur les arrêts eux-mêmes sont pris en compte. C'est la raison pour laquelle c'est la modélisation favorisée lorsque nous menons des projets de cartographie. mettre tout dans un stop_area conduit à avoir une relation avec des Je suis un peu responsable de cette situation en ayant pris la décision de créer une relation par gare en Ile-de-France. Je suis conscient que ce n'est pas l'idéal et que cela amène de la complexification difficile à gérer et à maintenir. Néanmoins la SNCF et plusieurs entreprises sous-traitantes utilisent dans les faits ces relations pour identifier les objets relevant de leur périmètre d'action. Je vous demanderais donc de ne pas les supprimer.
Je confirme. FBI : Fausse Bonne Idée. Le ven. 8 janv. 2021 à 15:08, blef <[hidden email]> a écrit :
-- _______________________________________________ Talk-fr mailing list [hidden email] https://lists.openstreetmap.org/listinfo/talk-fr |
bonsoir
je reprends ou déterre un vieux sujet à propos de grèves « permanentes » dans le lit de la Loire (au moins etre saumur et les Pts-de-Cé. A l’époque j’avais posé le fait que des grèves permanentes, bin il n’y en a point. Pour vérifier ce que je connais d’expérience je me suis amusé à cartographier les grèves telles qu’elles apparaissent sur les ortho libres disponibles, IGN (https://remonterletemps.ign.fr/telecharger?x=-0.319893&y=47.348157&z=12&layer=GEOGRAPHICALGRIDSYSTEMS.MAPS.SCAN-EXPRESS.STANDARD&demat=DEMAT.PVA$GEOPORTAIL:DEMAT;PHOTOS&missionId=missions.4971264) et Siel (http://www.centre-val-de-loire.developpement-durable.gouv.fr/les-donnees-du-siel-r557.html). La précision n’est pas tjs terrible, mais je pense que je suis à moins de 15m d’erreur. L’idée était de voir si malgrès tout il était possible de déterminer des invariants. Ce en dehors des éléments qui à force de baisse du niveau à débit constantse sont pérennisés, il s’agit de quelques ilôts ou zones de dépots alluvionnaires végétalisés et des" bras morts », mais ce ne sont pas des grèves. Une autre raison de vouloir vérifier ça c’est qu’actuelement des soit disants grèves permanentes sont déssinées, d’après l’ortho ign, l’année n de l’ortho ça marche, l’année n+1 ça se gate et l’année n+3 c’est n’importe quoi. Ou alors c’est juste pour faire joli… faut remarquer qu’il me semble que sur la Bd_Topo, hydro, récente normalement, ce sont les grèves de 2002 qui y figurent… Pour ce qui concerne les grèves je n’ai pas réussi à déterminer par superposition des couches, des zones « traçables » de grèves « permanentes », d’autant que les dates de prise de vue sont parfois très rapprochées et que les variation à 1 ou 2 ans sont peux importantes. Mais si quelqu’un veut bien jeter un coup d’œel au cas où ces infos seraient exploitable dans OSM… J’ai mis ça en ligne sur uMap : https://umap.openstreetmap.fr/fr/map/loire-saumur-pts-de-ce-greves-1949-2016_546078#11/47.3342/-0.1967 le résultat est intéressant même si peu lisible sur uMap (si quelqu’un veut les shp et le pjt qGis suffit de demander, de même si quelqu’un veut connaitre le process d'amateur utilisé). _______________________________________________ Talk-fr mailing list [hidden email] https://lists.openstreetmap.org/listinfo/talk-fr |
In reply to this post by blef
Le 08/01/2021 à 15:08, blef a écrit :
> Bonjour, > > Merci pour vos avis. > > Si je résume: > > * Inclure les shelter, bench, bin séparés dans la relation > *stop_area*? Personne n'y semble favorable, moi non plus. > Dommage que le wiki/FR:Tag:public_transport=platform > <https://wiki.openstreetmap.org/wiki/FR:Tag:public%20transport=platform?uselang=fr> > ou wiki/FR:Key:public_transport > <https://wiki.openstreetmap.org/wiki/FR:Key:public_transport> > préconise de le faire: /Le lieu d'attente est normalement associé > aux autres éléments de l'arrêt > (//stop_position//,////bancs//,////abris//, ...) à l'aide d'une > relation de type////public_transport=//stop_area/ > > * Garder les deux indications: shelter=yes sur l'arrêt (platform) et > amenity=shelter sur un node ou way séparé? > Ça ne semble choquer personne, même si je n'ai pas l'impression > qu'il y ait consensus sur le fait que ce soit un doublon, ou pas. > Le wiki (encore lui) recommande: /shelter=yes indique si un abri > est présent (s'il n'est pas déjà tagué avec amenity=shelter) > /L'idée d'utiliser la valeur separate me plait bien. Ça donnerait, > si j'ai bien compris: shelter=separate au lieu de shelter=yes sur > l'arrêt (platform), l'objet lui même étant représenté à son > emplacement avec amenity=shelter. > Dommage encore que cette solution ne soit pas documentée, et sans > doute pas prise en compte par les appli genre Osmand et autres. > Ce n'est pas un doublon: - bench=yes indique juste que l'arrêt est équipé d'un banc (il y en a même peut être plusieurs) - amenity=bench cartographie ce(s) banc(s) en tant que tel(s), c'est un niveau d'info en plus, pas en double > * Autre remarque, même si on est sensé ne pas s'en préoccuper, sur > le rendu standard la présence d'un amenity=shelter près d'un arrêt > masque ce dernier à certains facteur de zoom. > > Donc, pour l'instant, je ne touche à rien. Personnellement, je suis > attaché aux attributs shelter/bench=yes/no sur l'arrêt (platform), > parce que c'est reconnu par les applis que je connais, et parce que ça > me permet une certaine homogénéité dans le tagging de tous les arrêts > du réseau. > -- Christian Quest - OpenStreetMap France _______________________________________________ Talk-fr mailing list [hidden email] https://lists.openstreetmap.org/listinfo/talk-fr
Christian Quest - cquest@openstreetmap.fr
|
In reply to this post by overflorian
Le 08.01.21 à 16:04, Florian LAINEZ a écrit :
> la SNCF et plusieurs entreprises sous-traitantes utilisent dans les > faits ces relations pour identifier les objets relevant de leur > périmètre d'action. Je vous demanderais donc de ne pas les supprimer. je cherchais justement le message d'il y a environ 2 ans ou la sncf allait changer son usage "collection" de ces relations. p'tre qu'il serrait temps hein :) _______________________________________________ Talk-fr mailing list [hidden email] https://lists.openstreetmap.org/listinfo/talk-fr |
In reply to this post by blef
Le 08.01.21 à 15:08, blef a écrit :
> sur le rendu standard la présence d'un amenity=shelter près d'un arrêt > masque ce dernier à certains facteur de zoom. un exemple ? cela mériterait probablement un ticket pour améliorer le rendu _______________________________________________ Talk-fr mailing list [hidden email] https://lists.openstreetmap.org/listinfo/talk-fr |
Le 09/01/2021 à 18:10, Marc_marc a écrit :
> Le 08.01.21 à 15:08, blef a écrit : >> sur le rendu standard la présence d'un amenity=shelter près d'un arrêt >> masque ce dernier à certains facteur de zoom. > un exemple ? cela mériterait probablement un ticket pour améliorer le rendu > > > > _______________________________________________ > Talk-fr mailing list > [hidden email] > https://lists.openstreetmap.org/listinfo/talk-fr Ici, par exemple: https://www.openstreetmap.org/node/5172950107 <https://www.openstreetmap.org/node/5172950107> _______________________________________________ Talk-fr mailing list [hidden email] https://lists.openstreetmap.org/listinfo/talk-fr |
Le 09/01/2021 à 18:29, blef - [hidden email] a écrit :
> Le 09/01/2021 à 18:10, Marc_marc a écrit : >> Le 08.01.21 à 15:08, blef a écrit : >>> sur le rendu standard la présence d'un amenity=shelter près d'un arrêt >>> masque ce dernier à certains facteur de zoom. >> un exemple ? cela mériterait probablement un ticket pour améliorer le >> rendu > > Ici, par exemple: > > https://www.openstreetmap.org/node/5172950107 Nos spécialiste nous diront ce qu'il en est et comment corriger proprement si c'est un problème de données. Par comparaison avec un arrêt bien rendu https://www.openstreetmap.org/node/1949826675, j'ai l'impression que le problème vient de l'ajout de : public_transport:version <https://wiki.openstreetmap.org/wiki/Key:public transport:version?uselang=fr> 2 _______________________________________________ Talk-fr mailing list [hidden email] https://lists.openstreetmap.org/listinfo/talk-fr |
Free forum by Nabble | Edit this page |