[OSM-talk-fr] Les bretelles

[djakk djakk]

Ça n’est pas fait au hasard, je te l’ai pourtant expliqué avant que tu
n'écrives ce mail :
https://www.openstreetmap.org/changeset/62524278
 :O

Le mar. 18 sept. 2018 à 09:48, Philippe Verdy <verdy_p at wanadoo.fr> a écrit :

> Note: djakk djakk s'est maintenant lancé dan la conversion de "village" en
> "town", en piochant au hasard (là encore en Bretagne et à proximité autour
> en Basse-Normandie, Maine, Anjou, Loire-Atlantique et Vendée).
> Du coup on a des villages mieux classés que les réelles villes pourtant
> pas loin.
> Et ça se voit dans le rendu final par défaut sur osm.org !
> Il n'y a pas de critère bien défini. On dirait qu'il a décidé de piocher
> non pas les bourgs-centre des bassins de vie comme il semble l'indiquer
> mais n'importe quelle commune siège d'une communauté de communes (dont
> certaines n'existent déjà plus depuis début 2017 ou sont devenues des
> communes nouvelles).
>
> Note: les intercommunalités depuis 2017 ont toutes au moins 15 000
> habitants, mais ça s'est fait de façon forcée, et pas forcément selon les
> bassins de vie (qui sont plutôt concertés au niveau des "pays" qui
> regroupaient déjà des intercommunalités mais ont été aussi redessinés un
> peu lorsque les intercommunalités ont été forcées de fusionner).
>
> Je ne pense pas que les intercommunalités soient pertinentes, d'autant
> plus que leur siège n'est pas forcément non plus dans la commune centre. La
> distribution des présences de services publics résulte d'accords locaux
> entre communes, le siège de l'intercommunalité résulte aussi de choix
> budgétaires et des ressources immobilières, ou de la présence de lignes de
> transports. Et même regroupées de force, les intercommunalités ne sont pas
> centrées sur leur ville siège dont le bassin de vie et l'attractivité
> réelle peut sortir aussi de leur propre territoire et couvrir des communes
> de l'intercommunaltié voisine.
>
> Je suggère de ne pas expérimenter ces changements dans la base OSM
> elle-même mais plutôt de mettre au point une base à part sous forme de
> liste à partir d'une feuille de calcul pour créer un CSV et générer une
> carte uMap permettant de visualiser ces listes sous forme de nuage de
> points selon plusieurs critères. Ca permet de ne pas aller trop vite dans
> la sélection, vérifier la densité des points selon le niveau de zoom,
> ajuster les critères pertinents à retenir sur chaque niveau de zoom, et
> ensuite définir éventuellement des tags OSM adaptés, et d'en discuter et
> les documenter sur une liste internationale.
>
> Et ensuite cela permettra aussi de faire les éventuels changements dans
> les clés existantes sans en oublier et non au hasard, et même de les
> vérifier automatiquement (par exemple, analyse Osmose vérifiant ces
> critères). Le rendu suivra ensuite concernant les éventuelles clés
> supplémentaires documentées sur lesquelles on aura importé correctement les
> valeurs de façon cohérente et vérifiable. Le rendu ensuite pourra suivre et
> s'adapter aux critères retenus pour chacun de ses niveaux de zoom. ou en
> fonction de la densité relative des libellés
>
> En attendant, les changements apportés sont plus une pollution et sont une
> gêne visuelle évidente pour les réutilisateurs des cartes rendues
> standards, notamment pour les rendus voisins des niveaux de zoom 9-10-11 en
> France.
>
>
>
> Le mar. 18 sept. 2018 à 09:26, Christian Quest <cquest at openstreetmap.fr>
> a écrit :
>
>> Le dim. 16 sept. 2018 à 13:01, Frédéric Rodrigo <fred.rodrigo at gmail.com>
>> a écrit :
>>
>>> > Du coup je propose link_from et link_to : pour une bretelle dans le
>>> > sens autoroute vers tertiary, on aura link_from=motorway et
>>> > link_to=tertiary.
>>>
>>> Cette information peut être calculé depuis la topologie et là n'apporte
>>> rien, même pas de la cohérence.
>>>
>>
>> Je ne vois pas l'intérêt non plus.
>>
>> L'info est déjà dans la topologie des données et une requête postgis (ou
>> autre) permet de savoir à quoi est connecté un tronçon de _link si on en a
>> vraiment besoin.
>>
>> Les données OSM sont des données GEO et à ce titre, on a plein
>> d'informations latentes que nous offrent la topologie et la géo, même si
>> elle ne figurent pas sur chaque objet en tant que tel.
>> Par contre pour tirer le maximum des données OSM il faut savoir exploiter
>> topologie et géo, sinon on passe à côté de l'essentiel et on a tendance à
>> rajouter des infos redondantes sans grand intérêt (et qui, en plus, ne
>> seront pas évident à conserver à jour).
>>
>> --
>> Christian Quest - OpenStreetMap France
>> _______________________________________________
>> 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/20180918/54358079/attachment.htm>