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