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 <cqu...@openstreetmap.fr> a écrit : > Le dim. 16 sept. 2018 à 13:01, Frédéric Rodrigo <fred.rodr...@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@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
