Le 8 juin 2012 10:44, Vincent de Chateau-Thierry <[email protected]> a écrit : > Bonjour, > >> De : "Philippe Verdy" >> >> Toutefois on pourrait aussi imaginer pour cette dernière utilisation >> un plugin capable de traiter une source CSV ou tabulée >> > > Sur ce point, voir : > http://wiki.openstreetmap.org/wiki/JOSM/Plugins/OpenData > > qui fait déjà ça.
Pas vraiment encore... Les éléments nécessaires aux recherches et permettant de croiser les fichiers de données pour les associer aux éléments de géométrie stockés dans OSM ne marchent pas du tout. Faute de cohérence des données (davantage d'ailleurs qu'à cause des tracés encore absents, pour lequelq je ne comprend toujours pas pourquoi on n'a pas au minimum créé une relation contenant un nœud, même si on n'a pas toutes les frontières, ce qui permet cependant des fusions ultérieures, tout en assurant la complétude des données importées). Ce projet devrait s'assurer : - de rechercher les relations manquantes, celles en doublon (noeuds à fusionner quand ils représentent en fait la même entité, mais n'ont pas été trouvés par un import précédent car il manquait certains attributs permettant de les trouver facilement même en cas de géométrie incomplète ou cassée), et d'assurer une couverture à 100 % ave toutes les relations nécessaires. - de permettre ensuite les rapprochements faciles par des clés de recherche qui donnent exactement 100% de couverture (sans trou et sans doublon) - de rationnaliser les tags utilisés, y compris des tags ajoutés par soucis de compatibilité entre divers outils de vérification, même si dans un premier survol cela peut paraître redondant (il y a encore trop de façon de voir la modélisation). - de simplifier et accélérer les recherches dans la base OSM, avec des requêtes moins volumineuses et moins complexes à traiter qu'actuellement (voir mon dernier message sur les subareas que TOUS les pays ont adopté — sauf pour la France où vous souhaitez encore faire cavaliers seuls —, ce qui a pourtant énormément stabilisé par la suite leur géométrie et facilité la maintenance en évitant des tas d'oublis et consolidé leur schéma pour toutes sortes d'usages avec beaucoup moins d'erreurs et même beaucoup moins de réparations nécessaires, car la situation actuelle demande de charger trop de données que le serveur ne permet même pas de toujours obtenir: erreurs 500 du serveur, requêtes simples qui nécessitent de charger sans arrêt des centaines de milliers de points là où il n'y a eu que des modifs très locales, conflits d'édition augmentés et mal réparés...) - d'automatiser les mises à jour de certaines données datées (par exemple : données démographiques). - de faciliter des changements au schéma initial par des reclassifications automatisables - finalement même de réduire nombre de redondances qui ne sont plus nécessaires (par exemple les traductions, les noms des rues et villes rapportés aux relations, les classements de types de routes : aller davantage vers un mode relationnel, là où il marche déjà très bien dans tous les outils de base (Nominatim, Mapnik, Mapquest, outils de vérification, outils produisant des cartes imprimés, rapports statistiques et d'avancement des projets ; en ne gardant les coûteuses requêtes géométriques que pour les recherches globales des éléments selon leur distance quand ils sont au départ non corrélés ensemble par un lien relationnel fort : tous les systèmes GIS le font, pas encore OSM et surtout pas en France !). Avoir une intégration de données sans autoriser les liens relationnels est une aberration. Très coûteuse en plus en temps homme comme en ressources machine/réseau ! C'est même totalement anticollaboratif, car les volumes à traiter empêchent trop de monde de pouvoir participer sans faire trop d'erreurs ; la moindre modif locale mineure représente un travail titanesque pour ***trop*** de monde, qui n'a pas forcément la bande passante réseau ni la puissance nécessaire sur son PC (oui avec le système actuel, machnie puissante nécessaire : OS 64 bits obligatoire, au moins 8 Go de RAM, plutôt 12..., au moins 4 coeurs CPU, processeur rapide pour gérer des centaines de milliers ou des millions de points dans un même fichier OSM et encore pouvoir faire glisser les cartes dans un édteur comme JOSM. Rationnalisez ! _______________________________________________ Talk-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-fr
