L'idée est justement de pas mettre tous les points sur une carte mais de traiter point par points, et de partager le travail entre plusieurs contributeurs, donc la base est là pour diffuser le travail. Seul les devs auront à "s’embêter" avec cette base installé en docker ou pas. Va falloir que j’étoffe le readme pour expliquer à quel problème j'imagine m'attaquer et résoudre.
Le mar. 5 mai 2020 à 16:26, Yves P. <yves.prat...@gmail.com> a écrit : > > pour l'instant curl, un formulaire d'upload serait pas compliqué à > proposer en coup unique. > Ok :) > > > mais vu que l'open data est évolutif et mis à jour, que ce soit > automatisé sera mieux. > Dans le cas d'un "gros" fichier mis à jour périodiquement, ça me parait > plus du ressort dOsmose. > > Dans le cas des "petits" fichiers de bibliothèque de Magalie, un > formulaire serait le bienvenu :) > > Et toujours pour les "petits" fichiers, est-ce que postgresql est vraiment > nécessaire ? > > Une carte peut charger directement en mémoire quelques centaines voir un > millier de POI. > (cas des requêtes Overpass). > > ça permettrait peut-être de déployer le code plus facilement, et en tout > cas d'éviter l'installation de Docker ou Postgresql. > (c'est facile pour un dév qui travaille avec ça toute la journée, plus > difficile pour les autres). > > > Le contributeur n'aura pas à rentrer dans node / postgres / clevercloud > / git … > Oui :) Je pensais plus à de gros logiciels QA comme Osmose ;) > > > Le premier fourni le fichier OD à od2osm le fera le langage/traitement > qui lui va, même un tableur pour produire un geojson. > > Les autres n'auront "qu'à" cliquer dans od2osm pour tout traiter. > > > __ > Yves > _______________________________________________ > 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
