sly (sylvain letuffe) a écrit : > On peut rêver, et que osmose devienne le premier outil capable d'analyser > (après import dans une base) les super-relations.
Pourquoi passer par une base... j'ai beaucoup plus rapide !!! Lancer un petit programme magique : <test> pc-rech-echove% time ./new_analyse_mega_relation.py france-xxl.osm 11980 open at node id=28205067, lat=48.770456, lon=-3.215019 open at node id=301271736, lat=47.758740, lon=7.537527 open at node id=28205153, lat=48.759137, lon=-3.234748 open at node id=28214068, lat=48.637305, lon=-4.567676 open at node id=498872583, lat=42.798134, lon=-0.523747 open at node id=28201318, lat=48.830360, lon=-3.088679 open at node id=28215524, lat=48.629499, lon=-4.547707 open at node id=28215533, lat=48.627083, lon=-4.555755 open at node id=28215603, lat=48.625985, lon=-4.561136 open at node id=28215640, lat=48.622731, lon=-4.592750 open at node id=28215675, lat=48.620476, lon=-4.570248 open at node id=28215709, lat=48.613744, lon=-4.575066 open at node id=28215789, lat=48.605154, lon=-4.584465 open at node id=28215804, lat=48.604560, lon=-4.571688 open at node id=28215860, lat=48.600812, lon=-4.583169 open at node id=28215881, lat=48.599394, lon=-4.620623 open at node id=28215901, lat=48.599348, lon=-4.632992 open at node id=28215922, lat=48.599145, lon=-4.610950 open at node id=28215928, lat=48.598654, lon=-4.609389 open at node id=28215945, lat=48.598349, lon=-4.612858 open at node id=28215983, lat=48.591979, lon=-4.646283 open at node id=28215992, lat=48.590201, lon=-4.645065 open at node id=28216605, lat=48.585275, lon=-4.639881 open at node id=28216663, lat=48.584428, lon=-4.618212 open at node id=28216685, lat=48.582664, lon=-4.669940 open at node id=28216690, lat=48.581069, lon=-4.638199 open at node id=28216699, lat=48.578524, lon=-4.663621 open at node id=496848800, lat=43.128464, lon=5.748971 open at node id=498872594, lat=42.798134, lon=-0.523747 open at node id=28201344, lat=48.833686, lon=-3.098005 open at node id=473060666, lat=50.828995, lon=2.627197 open at node id=43595228, lat=50.812894, lon=2.635080 open at node id=28215625, lat=48.623290, lon=-4.570722 open at node id=28215769, lat=48.612959, lon=-4.576202 open at node id=323928030, lat=47.754844, lon=7.540063 open at node id=28215973, lat=48.598295, lon=-4.616722 real 0m14.958s user 0m13.485s sys 0m0.804s </test> Rapide non ? 15 secondes pour faire le tour de France dans un fichier de 7.5Go ! Il ne reste qu'à générer les fichier xml compréhensible par le front end... mais j'aimerai rendre ce programme générique d'abord, et du coup l'inclure dans le backend déjà existant qui utilise la même bibliothèque d'accès aux fichiers osm mais n'est pas récursif. > D'ailleurs il me semble remarquer avec un heureux étonnement que l'outil > d'analyse est lui capable de traiter ces super-relations. > (encore que je n'ai pas réussi à le lancer sur la 11980, ça doit mouliner > dans > les chaumières) Tout à fait, mais comme il utilise les données issues de l'api d'osm, c'est relativement long :-( > Pour les relations type=boundary qui sont des membres de la 11980, on > pourrait > imaginer : > 1) les ignorer car elles appartiennent à une autre relation (galère) > 2) Les renseigner correctement dans osm (il m'apparaît en fait qu'il n'est > pas > logique d'avoir un même type pour deux objets de structure différente. Je me > lance... > http://wiki.openstreetmap.org/wiki/Relations/Proposed/boundary_segment Je vote pour 2, c'est le plus logique. > Encore une fois, il me semble que osmose a raison et qu'il s'agit bien > d'erreurs Alors je laisse comme ça et ça m'arrange ;-) et puis faut que je bosse un peu. -- Etienne _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
