[OSM-talk-fr] Pourquoi inventer un aire urbaine imaginaire ?

[Philippe Verdy]

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 <verdyp at 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 at 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.rogel at club-internet.fr> a écrit :
>>
>>> > Le 16 nov. 2018 à 07:59, Stéphane Péneau <stephane.peneau at 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 at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>> _______________________________________________
>> Talk-fr mailing list
>> Talk-fr at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20200701/1ace9f72/attachment-0001.htm>