Ces boundary=urban ont été tracés effectivement approcimativement mais visiblement uniquement pour gérer les restrictions de limite de vitesse en agglomération et fournir des "règles" par défaut pour toutes les voies incluses sans avoir à renseigner sur chaque voie les limites effectives. Je pense que le principe est juste de d'appuyer sur les points marqués par les panneaux d'entrée en agglomération, et les relier entre eux en un polygone fermé, car les points des panneaux seuls ne suffisent pas.
Ces polygones n'indiquent en aucun cas un objet physique, une limite administrative réelle, un réel zonage urbain (au sens de l'Insee), c'est juste un complément pour les restrictions du code de la route applicable aux véhicules motorisés. Leur seul intérêt c'est qu'ils délimitent les zones où les tags de limitation de vitesse sont à renseigner (leur source devrait indiquer la règle "urban") ou remettre à jour. Ce sont des objets de "construction" et de 'maintenance" plus que des objets réels. Ils ne remplacent pas le besoin de marquer et détailler les limites de vitesse voie par voie. Mais ils peuvent servent pour détecter les oublis ou incohérences. Cependant je pense que leur place serait plutôt dans une base cartographique séparée (cartosm ?) qu'on peut charger sélectivement. Ce serait d'ailleurs intéressant de mettre en place cette base centralisée externe pour gérer ça, et ensuite pouvoir mettre à jour ou maintenir les vitesses des voies dans OSM (avec un tag mentionnant l'origine et la raison de la vitesse indiquée : un aspect réglementaire en France lié aux panneaux d'entrée en aglolomération). Cette base est assez facile à construire et maintenir, et devrait ensuite permettre de faire des recherches croisées dans OSM en s'appuyant sur les polygones simples fournis par cette base pour chercher dans OSM les voies incohérentes ou non renseignées. Cela peut grandement faciliter la maintenance (y compris les évolutions locales quand les panneaux d'entrée d'agglomération sont déplacés). Cette base externe pourrait aussi gérer des zones plus réglementées (zones 30, zones mixtes prioritaires aux piétons). Elle pourrait servir à d'autres zonages réglementaires (pollution...) Le mer. 1 juil. 2020 à 15:27, Pierre-Yves Mevel via Talk-fr < talk-fr@openstreetmap.org> a écrit : > Bonjour, > > Pour information, j'ai eu la désagréable surprise de voir ressurgir ces > abominations que nous avions patiemment supprimées au cours de ces derniers > mois du territoire de l'Ille-et-Vilaine (cf. ce changeset : > https://www.openstreetmap.org/changeset/87258927?way_page=3 par exemple). > La méthode est toujours la même que celle pointée par Christian R il y a un > an et demi : tracé approximatif (il passe allègrement à travers des > quartiers d'habitation, voire des maisons), chevauchement de ses polygones, > absence de fondement administratif alors qu'il les range dans un > "admin_level", pas de concertation avec les locaux. > À cette liste, il faut ajouter que des appli comme OSMand fait apparaître > ces limites avec la même symbologie que les vraies limites communales, ce > qui rend la carte particulièrement illisible dans certains cas. > > Pour ma part, je dégage à vue sur le territoire de mon EPCI, mais il > faudrait sans doute trouver une solution plus efficace pour traiter ce > problème. > > Bonne journée, > > P-Y > > Le ven. 16 nov. 2018 à 10:21, Christian Rogel < > christian.ro...@club-internet.fr> a écrit : > >> > Le 16 nov. 2018 à 07:59, Stéphane Péneau <stephane.pen...@wanadoo.fr> >> a écrit : >> > Il en a été question ici même, en aout 2016 : >> > >> https://lists.openstreetmap.org/pipermail/talk-fr/2016-August/081842.html >> >> Bien que lecteur assidu de la liste, je n’avais pas remarqué ce post. >> Il n’empêche que la page a été créée bien avant la tentative de >> discussion/demande d’aide. >> La justification par les besoins de l’aviation est admissible, mais le >> choix d’une réalisation “sauvage” beaucoup moins. >> On ne voit pas le bénéfice de troquer la facilité de se référer aux >> limites officielles des parcelles bâties pour une exécution approximative >> basée sur un nombre d’accroche limité. >> >> Christian R. >> >> _______________________________________________ >> 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 >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
