En revanche "boundary=urban" serait approprié pour le zonage urbain statistique de l'Insee: aires urbaines, pôle urbains... Mais là ces zones sont composées de zones administratives: communes entières ou divisions infracommunales officielles, et pour les plus petites zones les IRIS... Voire les "TRIRIS", quand les IRIS sont trop privés car les IRIS sont typés résidentiel/commercial... le TRIRIS corrige cet effet en devenant neutre et respectant les contraintes du secret statistique obligatoire et les obligations issues de la loi Informatique et libertés et les recommandations de la CNIL (un TRIRIS est un assemblage de souvent 3 IRIS, d'où leur nom, et tous les IRIS n'ont pas besoin d'être ainsi regroupés et ils ne le sont pas tous, le TRIRIS est un substitut aux IRIS quand les données détaillées par IRIS typé ne peuvent pas être légalement publiées: données fiscales par exemple)
Le mer. 1 juil. 2020 à 16:57, Philippe Verdy <ver...@gmail.com> a écrit : > En fait le choix du tag "boundary=urban" me semble pas approprié. > > Ce devrait être "boundary=restriction" avec les tags habituels des > restrictions (maxspeed=*) et éventuellement un tag franco-français > indiquant le type de limite. > > Ce genre de relation pourrait avoir comme membre les noeuds des panneaux > indicateurs, comme prérequis indispensable, le polygone lui-même avec le > rôle "outer" (ou l'ensembles des ways dont des "outer" et d'éventuels > "inner" étant optionnel). > > Dans la plupart des cas, les polygones sont "flous", sauf pour les > communes entièrement urbaines ayant décidé d'appliquer ces limites à la > totalité de leur territoire adminiqtratif (dans ce cas pas besoin de ces > relations). > > > Le mer. 1 juil. 2020 à 16:51, Philippe Verdy <ver...@gmail.com> a écrit : > >> 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
