Note: les petites communes ou com.com peuvent aussi collaborer avec leurs département qui peut les aider (exemple de la BAL en Dordogne) sans que ce soit nécessairement pour toute la com.com qui n'a pas encore cette compétence (mais souhaiterait le faire à terme avec leurs communes membres qui le souhaitent et qui justement n'ont pas les moyens de faire ça seules). Nombres de petites communes périphériques de grandes villes ont du mal à suivre (même si la grosse commune centre a fait déjà elle-même une publication BAL): le frein est justement la com.com qui n'arrive pas à mettre en place la structure nécessaire (ou a du faire des arbitrages qui l'en a empêché ou repoussé "sine die" en attendant des jours meilleurs quand la grosse commune centre est déjà elle-même trop endettée et ne peut augmenter la compétence de ses services pour servir les autres).
Les intercommunalités ne fonctionnent pas toujours de façon rêvée car il y a souvent de gros déséquilibres en termes de besoins et des arbitrages font face à des oppositions locales très fortes. Les enjeux politiques locaux aboutissent aussi à des situations de blocage où aucune décision ne peut être prise ou est sans cesse repoussée (surtout si la fiscalité locale est déjà très élevée et touche en premier les communes les moins favorisées où la priorité est clairement pour l'aide sociale immédiate ou la sécurité publique, et non le développement économique à plus long terme, on peut voir ce qui se passe dans le "Grand Paris" où c'est flagrant: chacun défend son pré carré, les coopérations sont difficiles, il est dur de convaincre qu'il est dans l'intérêt même des zones mieux loties d'aider celles qui les entourent). Il n'y a aucune "frontière" étanche, les problèmes des uns finissent toujours par déborder chez les voisins (et pas de la façon la plus agréable) ; pourtant des moyens il y en a mais ils existent à d'autres niveaux que les seules collectivités: l'opendata est une bonne solution qui augmente le nombre de collaborations et permet justement d'éviter la dispersion de ses moyens (qui alors ne d'ajoutent pas mais ont plutôt tendance à avoir des effets contradictoires qui s'annulent entre eux, en pure perte pour tout le monde) grace à des objectifs communs (d'abord un minimum, puis progressivement on peut aller plus loin). Le dim. 24 févr. 2019 à 14:41, Philippe Verdy <verd...@wanadoo.fr> a écrit : > La BAL 1.1 est une spécif proposée mais pas obligatoire pour figurer dans > l'opendata gouvernemental et participer à la BAN. > Si tu regardes le catalogue de la BAN, certaines bases sont en BAL 1.1, > d'autres non; certaines sont en ODbL, d'autres en Licence Ouverte (LO/OL). > La commune ou l'intercommunalité peut choisir les champs qui lui > conviennent, au format qui lui convient et qu'elle sait déjà gérer. La BAL > 1.1 est un guide plutôt pour faire évoluer ces données vers un format > d'échange commun (cette spécificartion 1.1 est extensible, il peut être > revu pour couvrir des besoins non couverts mais nécessaires à une > collectivité). > Le but n'est pas d'ajouter une masse de travail imprévue, mais aider à la > transition vers des données ouvertes. Au besoin d'autres proposeront leurs > services ou leur aide pour "renormaliser", mais les communes peuvent > proposer leurs extensions (métadonnées). Le descriptif de leurs données n'a > pas besoin d'être spécifié dans un format ouvert, les communes peuvent se > contenter de publier un document texte, PDF, Word ou ODF, ou une page web, > ce sera suffisant pour décrire les données incluses. > Les communes n'ont pas non plus à s'engager à faire des mises à jour > fréquentes au "fil de l'eau", une mise à jour annuelle suffit. > > C'est plus lors de la première publication qu'il y aura des retours lors > des tentatives d'intégration de ces données chez d'autres acteurs: il est > souhaitable donc d'avoir une adresse de contact pour ces retours > (anomalies, oublis, doublons, incohérences, orthographe, ambiguité, > défusions nécessaires sur des éléments confondus, erreurs de > positionnement, différences constatées sur le terrain): ces retours peuvent > venir de n'importe où: professionnels (architectes/bureaux d'étude, > constructeurs, sociétés de service informatique, designers/intégrateurs de > sites web, notaires, etc.), particuliers, autres collectivités (notamment > les communes voisines), services divers de l'état (services locaux de > secours et de police, ministères), agences paritaires (chambres de > commerce, d'agriculture), écoles et universités, assos (y compris OSM ou > ses contributeurs). > > Le point de contact peut être une adresse mail, un forum, une page en > ligne de réseau social pour les questions non privées (twitter, github, ou > d'autres services moins connus mais plus accessibles en français...), mais > il faut éviter que l'échange se finalise juste par du courrier postal (long > et lourd à suivre, et ne facilitant pas les collaborations) ou une demande > à un guichet physique: l'opendata est destiné à être utilisé sur une > échelle plus large que locale et permettre justement à ces petites communes > de parvenir à communiquer leurs ressources et leurs besoins à une échelle > plus large (y compris internationale) pour permettre même à leurs propres > résidents de bénéficier de ces ouvertures et développer leurs propres > activités de façon pérenne et à moindre coût. > > Et grâce à l'échange, les communes peuvent aussi faire des économies en > ayant alors un retour efficace et permanent d'informations venant de > nombreux acteurs sans que cela leur coûte en terme de collecte: ce qu'elles > vont gérer c'est l'intégration de ces retours, et ensuite la republication > de ces résultats, mais elles géreront elles-mêmes leurs priorités et cela > en fonction des compétences et moyens qu'elles ont ou qu'elles sont > capables d'obtenir (et aussi de justifier ensuite grâce justement à la > publication des résultats... ce qui peut leur amener ensuite de nouvelles > recettes pour les aider à aller plus loin tout en ayant elles-mêmes moins > besoin de puiser dans leurs propres ressources, on sait les communes en > grosse difficultés financières et les arbitrages sont souvent durs quand > ensuite l'état se désengage ou quand de nouvelles normes et lois leurs sont > imposées). > > > Le dim. 24 févr. 2019 à 13:34, deuzeffe <opensm....@deuzeffe.org> a > écrit : > >> Le 24/02/2019 à 11:42, Brice MALLET a écrit : >> > Le 23/02/2019 à 12:46, deuzeffe a écrit : >> >> J'aimerai bien aider, je ne sais pas comment. M'enfin, je verrai bien >> >> où ils en sont. >> > >> > Leur faire construire un fichier BAL ? >> > https://adresse.data.gouv.fr/bases-locales >> >> Ça fait partie de l'un de mes objectifs (en plus de savoir ce que la BAN >> va devenir — oui, je viens de lire le dernier message de Jérôme sur le >> forum GeoRezo ad hoc). Je m'interroge pour l'instant sur les capacités >> techniques locales (les leurs, parce que pour ce qui est des miennes, je >> sais qu'elles sont très réduites :P) >> >> Je viens de lire la spécification du format d'échange, pas très simple >> pour eux... (peut-être en récupérant un bout de la BAN — qui n'est pas >> forcément précise quant au géocodage, ni à jour et pour cause, comme >> proposé sur la page ?) et je suppose que malgré la date de la spécif., >> comme la page le dit, c'est celle qui est en vigueur. >> >> Parfois, je me dit que la mutualisation de telles compétences au sein >> d'un EPCI «petit modèle » (les com. com., en particulier) serait un vrai >> plus. Mais je crains que cela ne rentre pas entièrement dans les >> "compétences déléguées"... (oui, il y a la voirie en facultatives, mais >> c'est l'entretien/la création, pas la gestion des données, ou je n'ai >> pas tout lu comme il faut :/) >> >> -- >> deuzeffe, impatiente >> >> _______________________________________________ >> 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
