<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:verdana,helvetica,sans-serif;font-size:10pt"><span style="font-weight: bold;">>>>></span><b><span style="font-weight: bold;">De :</span></b> hamster <hamster@suna.fdn.fr> et autres<br><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt;"><font face="Tahoma" size="2"><b><span style="font-weight: bold;"></span></b></font><br><span style="font-weight: bold;">>>>></span>>> On pourrait imaginer un système de filtre en téléchargeant les données dans JOSM. Chacun pourrait alors exclure/inclure les données dont ...<br><span style="font-weight: bold;">>>>></span>les filtres sont efficaces pour l'affichage mais ne changent rien a la quantite de donnees en memoire et donc a la puissance necessaire au niveau hardware<br><br>A ce sujet lorsque je dois exploiter une trace gps sur l agglo
 grenobloise par exemple je trouve la fonction JOSM "telecharger le long de la trace GPS" vraiment tres pratique. Cela permet de ne pas recuperer des tonnes de données tout en travaillant sur des zones etendues.<br>Est ce qu il y aurait une fonctionnalite similaire qui permettrait de faire la meme chose autour de ways ? points ? elements d une relation ? ou de la selection courante ?<br>Je pense qu on a rarement besoin de la totalite d une grande zone mais plutot de zones restreintes autour de POI ou de choses qui nous interessent lorsque l on edite. SI l on prend le cas concret d un polygone CLC j aurais tendance a me concentrer plutot sur les donnees regroupees autour de son perimetre que sur la totalite de la surface.<br><br>Pour ce qui est de Potlach je pense qu il n est clairement pas adapte pour les zones avec beaucoup d infos et qu il vaudrait mieux voir ce que vaut la version 2.0 niveau perf<br><br>Julien<br></div>
</div><br>




      </body></html>