[OSM-talk-fr] JOSM en touche "enter"

Ven 8 Juin 13:37:12 UTC 2012

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 <verdy_p at wanadoo.fr>

> Le 8 juin 2012 10:44, Vincent de Chateau-Thierry <vdct at 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 at 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/
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20120608/ee97cd8c/attachment.htm>