Au cas où, je recolle ce qui a été dis auparavant : svn co http://josm.openstreetmap.de/svn/trunk josm
ou comme le suggère Vincent http://josm.openstreetmap.de/newticket A. 2012/6/8 Philippe Verdy <verd...@wanadoo.fr> > Le 8 juin 2012 10:44, Vincent de Chateau-Thierry <v...@laposte.net> 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 > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr > -- -------------------------------------------------------------------- Arnaud Van De Casteele Mines Paris Tech - CRC Sophia-Antipolis 0698 24 25 29 SIG - WebMapping - Spatial Ontology - GeoCollaboration Web Site http://perso.crc.mines-paristech.fr/~arnaud.van_de_casteele/ http://geotribu.net/ http://www.i2c.eu/
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr