Re: [OSM-dev-fr] Test Osmose-Mapillary
Le 08/07/2017 à 20:11, Frédéric Rodrigo a écrit : Salut, J'ai obtenu de Mapillary un mini dump du résultats de la détection des panneaux dans la région de Rennes. C'est rapproché des données OSM comme c'est fait avec de l'OpenData. Ça signalement donc quand l'effet d'un panneau n'est pas retrouvé dans les données OSM. cool, j'ai ajouté quelques stops Comme ce n'est pas toujours simple j'ai pour l'instant limité à certains types de panneau dont l'effet se traduit par un seul tag, ça essaye de retrouver ce tag à proximité. La distance est variable en fonction du panneau. Mais il y a plusieurs problème: - la localisation des panneaux est approximative en effet, la rocade déborde jusque le long du chemin de halage ;) https://www.mapillary.com/app/?lat=48.10593859663507&lng=-1.7144116702545489&z=17&signs=true&focus=map&trafficSign%5B%5D=regulatory--maximum-speed-limit-70--g1 - souvent dédoublé - les panonceaux ne sont pas pris en compte - pas différence entre un panneau d'application et un panneau d'approche ca detecte parfois un peut trop aussi :) - une vitesse de bus qui deviens une limitation https://www.mapillary.com/app/?lat=48.1312010610244&lng=-1.67386871309325&z=17&signs=true&focus=map&trafficSign%5B%5D=regulatory--maximum-speed-limit-90--g1 - ça remonte aussi bien des problèmes dans OSM que des problèmes dans la reconnaissance des panneaux (on peut marquer les faux positif dans Mapillary ?) Je n'ai pas trouvé, mais je connais mal mapillary. On pourrait aussi chercher à cartographier les panneaux eux mêmes et/ou leur effets. http://dev.osmose.openstreetmap.fr/en/map/#item=8300&useDevItem=true&zoom=14&lat=48.12522&lon=-1.67435&layer=Mapnik&overlays=T En tout cas c'est prometteur. Est ce que dans mapillary l'icone de hauteur est générique ? si non les hauteurs ne sont pas toujours détectées (3.1 au lieu de 2.5) https://www.mapillary.com/app/?lat=48.12780824036&lng=-1.683399190456&z=17&signs=true&focus=map&trafficSign%5B%5D=regulatory--height-limit--g1&pKey=wuf09rJKjlpb2F_78Lv6YA&x=0.5091192026214278&y=0.515137058569636&zoom=0 ps : si le lien mapillary etait cliquable dans osmose ca serait top! Merci de ton travail. -- JB ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Validation de bâtiments fractionnés par le cadastre
On 04/01/2017 12:49, Tyndare wrote: Petite mise à jour: - j'ai viré l'haricot rose et mis des boutons tout simple: + - ? - j'ai changé le mode de zoom pour moins zoomer pour les tout petits cas, mais peut être que ça zoom plus pour les plus gros cas donc je sais pas si c'est mieux. - j'ai rajouté un #id dans l'url pour pouvoir partagé des cas problématiques plus facilement. hier, quelqu'un a parlé de jointure proposé alors que les 2 étaient des "polygones de nature différent (wall=no d'un côté et normal de l'autre)." tu demandais des preuves, voila ;) http://cadastre.openstreetmap.fr/segmented/#32542 enfin... le cadastre affiche le triangle en jaune clair (wall=no) mais dans OSM le triangle n'a pas le tag. du coup ton algo a raison, mais les données d'entrée ne sont pas bonnes ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Validation de bâtiments fractionnés par le cadastre
On 03/01/2017 13:35, Tyndare wrote: Bonjour et bonne année à tous ! J'ai repris l'interface (et une partie du code) d'OpenSolarMap.org pour valider des prédictions de bâtiments fractionnés par les limites cadastrale. http://cadastre.openstreetmap.fr/segmented/ Ça fait suite à une discussion d'août dernier: https://lists.openstreetmap.org/pipermail/talk-fr/2016-August/thread.html#81789 Pour l’instant c'est en test, j'ai chargé que des cas de Guadeloupe dans la base. Je suis bluffé, ca marche super bien. Les seuls cas ou j'ai "hésité" c'est quand l'ortho et le cadastre était vraiment différents (des bâtiments orienté très différemment ou des décalages important). ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] outil adresse du plugin JOSM cadastre-fr
On 27/01/2014 11:37, V de Chateau-Thierry wrote:
De : "Julien Balas"
ca fonctionne, j'obtient bien des fichiers zip et osm
par contre quand je fait tourner le script "addrfantoir" ca plante
une histoire d'UTF ? (google+ xe9 indique que c'est le caractere 'é')
julien@yamcha:~/perso/osm/associatedStreet$ python addrfantoir.py
FK238-adresses.osm
fichier adresses : FK238-adresses.osm
Code INSEE : 35238
mise en cache des voies...
mise en cache des adresses...
rapprochement...
Traceback (most recent call last):
File "addrfantoir.py", line 127, in
ftmpkeys.write('Pas FANTOIR : '+rel_name+'\n')
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in
position 18: ordinal not in range(128)
Oops merci. C'est corrigé et commité, tu peux récupérer addrfantoir.py sur
github.
J'ai testé sur Rennes, les stats :
Nombre de relations creees : 1387
avec code FANTOIR : 1347 (97%)
avec rapprochement OSM : 1167 (84%)
2233 points addresses à affecter manuellement a la bonne rue
Voir le fichier numeros_ambigus_a_verifier.osm
merci, apres un pull ca marche
Je continue mes tests dans la semaine.
A premiere vue : il manque ma rue et dans la rue du boulot, il manque
l'adresse du bureau mais il y a celle avant et après.
décidément un cas de test parfait ;)
Et il y a des rues en double
RUE MACHIN
RUE_MACHIN
j'ai pas regardé si les contenu étaient identique mais les fichiers font
la même taille en octets.
--
JB
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] outil adresse du plugin JOSM cadastre-fr
On 25/01/2014 01:12, Tyndare wrote:
Je n'ai toujours pas corrigé le problème HTTP Error 500.
J'ai essayé de renouveler le cookie de session au bout de 5min mais a
priori ce n'est pas ça le problème.
J'ai l'impression que c'est une erreur transitoire côté site du
cadastre, et si ça se reproduit il faut réessayer.
Pour extraire les données de Rennes j'ai du corriger un autre plantage
du script, tu peu retenter je pense.
ca fonctionne, j'obtient bien des fichiers zip et osm
par contre quand je fait tourner le script "addrfantoir" ca plante
une histoire d'UTF ? (google+ xe9 indique que c'est le caractere 'é')
julien@yamcha:~/perso/osm/associatedStreet$ python addrfantoir.py
FK238-adresses.osm
fichier adresses : FK238-adresses.osm
Code INSEE : 35238
mise en cache des voies...
mise en cache des adresses...
rapprochement...
Traceback (most recent call last):
File "addrfantoir.py", line 127, in
ftmpkeys.write('Pas FANTOIR : '+rel_name+'\n')
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in
position 18: ordinal not in range(128)
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] outil adresse du plugin JOSM cadastre-fr
ps. si le service que permet l'outil de Tyndare se met en place de manière pérenne, nulle doute que la discussion reviendra rapidement sur talk-fr. On gagnerait en efficacité en synthétisant la présente discussion quelque part sur le wiki, avec les arguments pour et contre chaque méthode. Un avantage du point adresse non lié a un batiment, c'est que si le batiment change il n'y a rien a faire pour l'adresse. Et c'est plus fréquent que je l'imaginait, a Rennes j'ai essayé de garder le bati a jour en faisant des différentiels de cadastre, j'ai arrêté au bout de quelques mois car c’était épuisant avec toutes les maisons écroulé/reconstruite ou qui font des extensions. -- JB ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] outil adresse du plugin JOSM cadastre-fr
Oui. Désolé d'avoir relancé le débat :) Le 22 janv. 2014 23:59, =?ISO-8859-1?Q?Vincent_de_Ch=E2teau-Thierry?= a écrit : > > > Le 22/01/2014 23:46, Vincent Pottier a écrit : > > Le 22/01/2014 21:10, Christian Quest a écrit : > >> Mon tiercé ? 1 3 2 > > +1 > > > > Pour le cas mentionné de l'école, il y a fort à parier que l'école, pas > > seulement le bâtiment mais l' polygone amenity=school englobant le > > bâtiment, la cour, que l'école est sur rue. Le node housenumber doit > > donc être apposé sur le bord du area, en bourdure de rue. Cas 3 mâtiné > > de 1, où on considère l'area amenity plutôt que le bâtiment. > > En fait je n'ai pas de souci dès qu'on sait rattacher le n° à quelque > chose. Mon exemple avec l'école est donc mal choisi, vu que vous lui > tordez le cou :-). > Pour le dire autrement : ce que je regrette comme pratique, c'est celle > de poser un n° comme un node isolé de tout (building comme amenity ou > landuse), surtout lorsque l'environnement est truffé de points > d'accroche potentiels, dont les ways building bien sûr, mais pas que, > comme vous le soulignez. > > Mais bon, y'a pas consensus, oui, je sais :-) > > vincent > > ___ > dev-fr mailing list > dev-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/dev-fr ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] outil adresse du plugin JOSM cadastre-fr
On 22/01/2014 16:15, V de Chateau-Thierry wrote: De : "Julien Balas" Une fois qu'on a les fichiers par rue, c'est quoi la méthode a suivre ? celle là ? https://wiki.openstreetmap.org/wiki/FR:Num%C3%A9rotation_des_rues Il y a aussi celle-ci : https://wiki.openstreetmap.org/wiki/Relation:associatedStreet qui illustre bien le type de fichiers qu'on souhaite fabriquer en ce moment. Le reste-à-faire manuel, avec chaque fichier, consiste à vérifier la cohérence entre le contenu proposé et ses connaissances (au mieux) ou le cadastre (au moins), et aussi à repositionner les n° (les nodes addr:housenumber). Oui, je vais ne faire que les rues que je connais bien. On peut selon la configuration du terrain et ses propres préférences : Sur les différentes pratiques, la discussion est récurrente sur talk-fr, et en résumé il n'y a pas de consensus. J'avais suivi un peut ca de loin, j'avais espéré qu'un consensus avait émergé depuis. vincent [1] : pour le transfert des attributs et relations dans JOSM : sélectionner le node addr:housenumber et le way building, puis Ctrl+Shift+G => le node est supprimé et tous ses attributs sont ramenés sur le way merci pour l'astuce -- JB ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] outil adresse du plugin JOSM cadastre-fr
Est ce que toutes les communes sont censé etre présente ou bien c'est lié a la dispo vectorielle du cadastre ? Le bugue (CP 24260) n'est pas dispo par exemple Oui c'est normal, car en effet c'est à partir du cadastre vectoriel que tout se fait. Et Le Bugue est encore en format image. ok Il n'y a qu'un script valide c'est en effet addrfantoir.py. L'autre est obsolète. merci Le "rapprochement OSM" donne le nombre de voies issues du cadastre pour lesquelles, sur la foi du nom, j'ai considéré qu'une rue de la commune prise dans OSM était sa correspondante. Et en effet, pour le rapprochement OSM, un taux inférieur à 100% peut provenir d'un mélange de : - rue orthographiée différemment dans OSM et sur le Cadastre. Souvent ce sera avec présence d'abréviations dans le cadastre, qui ne sont pas (pas encore) traitées dans le script (qui cherche à faire converger les noms). Ça peut aussi être un type de voie différent : une 'avenue' dans OSM qui est une 'rue' dans le cadastre, par ex. - rue non nommée dans OSM - rue non tracée dans OSM ok, sur une autre commune il a bien trouvé que "RUE MIDI" du cadastre etait la "Rue du midi" dans OSM En tout cas merci pour ton retour :-) De rien. Une fois qu'on a les fichiers par rue, c'est quoi la méthode a suivre ? celle là ? https://wiki.openstreetmap.org/wiki/FR:Num%C3%A9rotation_des_rues ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] outil adresse du plugin JOSM cadastre-fr
Je trouverais bénéfique que des courageux testent l'exercice d'intégration des adresses en l'état de notre "chaîne" de traitements. Étape 1 : la génération des fichiers d'adresses issues du cadastre, c'est ici : http://37.187.60.59/cadastre-housenumber/adresses.php Est ce que toutes les communes sont censé etre présente ou bien c'est lié a la dispo vectorielle du cadastre ? Le bugue (CP 24260) n'est pas dispo par exemple Pour Rennes (CP 35000), http://37.187.60.59/cadastre-housenumber/adresses.php?dep=035&com=FK238 ca plante Teléchargement des adresses cadastrales de la commune FK238 : RENNES (35000) Téléchargement du cadastre au format PDF: Découpe la bbox en 5 * 5 FK238-0-0.pdf RGF93CC48:1346181.63,7219082.00,1348181.63,7221082.00 FK238-0-1.pdf RGF93CC48:1346181.63,7221082.00,1348181.63,7223082.00 FK238-0-2.pdf RGF93CC48:1346181.63,7223082.00,1348181.63,7225082.00 FK238-0-3.pdf RGF93CC48:1346181.63,7225082.00,1348181.63,7227082.00 Traceback (most recent call last): File "../../../cadastre_vers_osm_adresses.py", line 649, in cadastre_vers_adresses(sys.argv) File "../../../cadastre_vers_osm_adresses.py", line 635, in cadastre_vers_adresses export_pdfs = download_pdfs(cadastreWebsite, code_departement, code_commune) File "/var/www/cadastre-housenumber/cadastre_vers_pdf.py", line 63, in download_pdfs cadastreWebsite.open_pdf(sous_bbox, largeur, hauteur), File "/var/www/cadastre-housenumber/cadastre.py", line 201, in open_pdf return self.url_opener.open(url, urllib.urlencode(post_data)) File "/usr/lib/python2.7/urllib2.py", line 406, in open response = meth(req, response) File "/usr/lib/python2.7/urllib2.py", line 519, in http_response 'http', request, response, code, msg, hdrs) File "/usr/lib/python2.7/urllib2.py", line 444, in error return self._call_chain(*args) File "/usr/lib/python2.7/urllib2.py", line 378, in _call_chain result = func(*args) File "/usr/lib/python2.7/urllib2.py", line 527, in http_error_default raise HTTPError(req.get_full_url(), code, msg, hdrs, fp) urllib2.HTTPError: HTTP Error 500: Erreur Interne de Servlet Étape 2 : le rapprochement avec les contenus Fantoir (pour le code RIVOLI) et OSM (pour l'association aux ways de la "bonne" rue). C'est là : https://github.com/vdct/associatedStreet (Si ça vous rebute de jouer un script, faites au moins l'étape 1 et indiquez-moi ici (ou en privé) l'existence du résultat via son URL. Je peux jouer l'étape 2 et vous envoyer le résultat.) une fois qu'on a le fichier osm fait avec l'etape 1, il faut lancer quel script de l'etape 2 ? addrfantoir ou addr2associatedStreet ? ou les deux ? pour le 1er script les données ont l'air OK, sur une commune de test (Balazé) les 24 points a faire manuellement sont en rase campagne, sans vraiment de nom de rue je pense. Comment lire les infos console du script ? notamment la ligne " avec rapprochement OSM : 17 (44%)" quels conclusion peut on tirer du pourcentage ? - qu'il manque des rue dans OSM ? - qu'elles existent mais orthographié différement ? - autre chose ? - fichier adresses : FP015-adresses.osm Code INSEE : 35015 mise en cache des voies... mise en cache des adresses... rapprochement... Nombre de relations creees : 38 avec code FANTOIR : 29 (76%) avec rapprochement OSM : 17 (44%) 24 points addresses à affecter manuellement a la bonne rue Voir le fichier numeros_ambigus_a_verifier.osm ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Trouver des objets ne possédant pas certains tags
On 05/12/2013 22:51, François Lacombe wrote: Bonsoir, Je souhaite savoir si dans le modèle de données retenu par OSM il est possible de retrouver des objets ne possédant pas certains tags. Ca depends de ton modele. Si tu a une notion de "way" ou de "node" qui sont lié a des "tags" en SQL tu pourrait ecrire select * from way where une premiere condition and not exists (select 'bla' from tag where tag.key='truc' and tag.way_id = way.id) qui te permet de trouver les way pour lesquels il n'existe pas de tag 'truc' Note : le "not exists" peut etre couteux, ca depends des volumes de way, de tag, etc. A partir d'Overpass API par exemple ? Dans OAPI, on peut tout a fait fixer une clause pour trouver des objets qui possèdent un tag défini avec n'importe quelle valeur mais en revanche le langage ne permet pas de définir le conjugué d'une telle contrainte. Est-ce un "oubli" ou une lacune profonde du modèle ? Est ce qu'on interroge souvent le modèle OSM avec ce genre de question ? je ne pense pas. Quand on veut dessiner une carte ou utiliser les données on s’intéresse plutot a ce qui est présent, pas ce qui est absent. L'exception a la règle serait peut-être les outils de qualité de données genre osmose ou geofabrik. Osmose a par exemple une règle qui trouve les écoles n'ayant pas un tag d'ID officiel. http://osmose.openstreetmap.fr/en/error/556433378 Tu peut regarder comment ils ont fait -- JB ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Extraction thématique (était Verification du routage)
On 02/12/2013 18:41, Pierre Béland wrote: Christian, Je pense à plusieurs contextes où la bande passante cause problème. Pensons, par exemple, aux divers pays africains. Un fichier bzip réduirait de façon très significative la bande passante utilisée pour transférer le fichier. c'etait le sens du parametre "--compress" curl négocie avec le serveur web et si celui ci sait envoyer du contenu zippé, il le fait. et le serveur dont on parlait supporte le mog-gzip cf http://oapi-fr.openstreetmap.fr/#chapter.output_formats donc c'est bien zippé pour le transfert. -- JB ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Extraction thématique ( était Verification du routage)
On 02/12/2013 12:16, sly (sylvain letuffe) wrote: ça peut se faire coté client : curl --compress "http://oapi-fr.openstreetmap.fr/oapi/interpreter?data=blabal"; | bzip2 > pouf.osm.bz2 [snip] ésserpmoc àjéd tiaté xulf el euq tnemetsuj tiasicérp éuqidni ia'j euq lruc noitpo'l euq srola tnemegrahcélét ed spmet ed relap em av iuq nu a ne'y euq eirap ej C'est bizarre/dommage que cette option "compress" ne soit pas activé par défaut. Quasiment tous les apaches ont le mode_gzip d'activé non ? -- JB ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Verification du routage
On 29/11/2013 12:04, Rodolphe Quiédeville wrote: Nicolas Dumoulin writes: Le jeudi 28 novembre 2013 18:12:58 Ab_fab a écrit : Bonjour, Nicolas Dumoulin a fait des scripts avec OSRM pour le contrôle des axes routiers dans le Cantal. https://lists.openstreetmap.org/pipermail/dev-fr/2012-May/000893.html Après, il n'y a rien de bien compliqué dans mes scripts qui sont un peu fait à l'arrache. Mais si ça peut servir de base … Si tu analyses une grande quantité d'itinéraire, il serait par exemple utile de stocker tes longueur de référence dans une base de données plutôt que dans des fichiers plats comme moi ;-) Mon idée n'est pas forcément la longueur mais effectivement la comparer entre deux calculs peut donner une info intéressante. J'aime bien l'idée. Apres, pour que ca permette vraiment de trouver des modification malvenues, est ce que ca ne veut pas dire qu'on doit stocker les distances entre... tout et tout ? A l’époque ou géovélo existait pour Rennes je m'en etais servi pour voir si il proposait des itineraire cohérents avec mes pratiques de déplacements. et ca m'avait permis de trouver des pistes cyclable manquante ou mal connectées. On pourrait aussi ainsi quantifier les gains en distances des parcours cycliste suite a la mise en place des contres sens cyclable (les sens interdit en zone 30 sont maintenant ouvert dans les deux sens pour les vélos) -- JB ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Paratage de DEM ( était Héberger le rendu HOT?)
On 02/07/2013 14:29, Christian Quest wrote: En DEM, on peut récupérer celui du CRAIG (à 5m) et de PACA... de quoi démarrer ;) je ne suis pas sur d'avoir compris votre discussion MAIS :) a Rennes il y a des modeles numerique de terrain disponible pour une 40aine de commune http://www.data.rennes-metropole.fr/les-donnees/catalogue/?tx_icsopendatastore_pi1[keywords]=mnt&tx_icsopendatastore_pi1[page]=1&tx_icsopendatastore_pi1[uid]=151 une version plus récente (2012?2013?) est en fabrication je crois Le 2 juillet 2013 11:15, Yohan Boniface a écrit : On 06/30/2013 08:20 PM, Jérôme Cornet wrote: Juste quelques questions en vrac: - Pas tout compris l'objectif: ça serait d'avoir un serveur de DEM utilisable plus ou moins par tout le monde? Je sais pas répondre à la question, mais je sais qu'on a une réunion tech IRC demain soir à 19 heures pour discuter notamment de ça ;) Sinon, en très gros l'idée est surtout de se dire que, vu qu'on est plusieurs à avoir besoin de DEM, autant mutualiser nos efforts autant que possible, vu ce que c'est coûteux en temps et énergie comme process. ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Des IDs a votre bon coeur COMPLET J'ESPERE.
On 28/06/2013 16:56, Ista Pouss wrote: Le 28 juin 2013 16:31, Julien Balas <mailto:jul...@krilin.org>> a écrit : Il y a visiblemen une incomprehension du modele OSM de ton coté. Une rue de la réalité est representée par plusieurs segments OSM. Dans ton exemple il y a 2 segments pour la rue brossard, mais il pourrait y en avoir beaucoup +, avec des vitesses differentes, certains morceaux en sens unique, d'autre qui font parti d'un circuit(relation) de bus, un morceaux de bande cyclable, des pavés, etc. Chaque fois qu'on veut avoir des tags differents sur une portion de route, on coupe en 2 et ca crée 1 way(segment) suplementaire Alors il faudrait aussi l'expliquer à ceux qui ont fait le moteur de recherche d'OSM car eux, lorsque je demande cette rue, ils ne me renvoient qu'une seule portion de la rue. Tout a fait, le moteur de recherche est perfectible. L'idée (pas encore mis en oeuvre je trouve) c'est que le site OSM est le site des gens qui contribue a OSM. Donc avec une vision un peut technique. Et que les utilisateurs finaux vont (ou iront un jour) sur des sites grand public qui utilise OSM mais avec une autre interface mapquest (qui est un site grand public qui utilise les données OSM) donne UN point de la rue, ca résoud (ou pas) le probleme de l'utilisateur. http://mapq.st/112eqTU -- JB ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Des IDs a votre bon coeur COMPLET J'ESPERE.
Qu'observe-je ? Que la règle ne marche pas, car il y a des ways qui ont même highway et même nom, tel la rue Brossard, ici http://www.openstreetmap.org/browse/way/30878250 et là http://www.openstreetmap.org/browse/way/33630650 Donc, soit la règle est mauvaise, soit les données OSM sont mauvaises, soit tous les deux sont mauvais. Ici, je pense, si je puis me permettre, que les données OSM sont mauvaiises, car déjà il n'y a qu'une seule rue brossard à st etienne, et si je fais une recherche "Rue Brossard, saint etienne" (je ne sais pas comment faire pour vous donner le lien direct de cette recherche), alors j'obtiens une seule rue à st etienne (bien), mais il ne me la marque que sur une portion de la rue (mauvais). On voit qu'OSM n'est pas cohérent avec lui même : il devrait me marquer toute la rue Brossard, et non pas seulement une portion. Il y a visiblemen une incomprehension du modele OSM de ton coté. Une rue de la réalité est representée par plusieurs segments OSM. Dans ton exemple il y a 2 segments pour la rue brossard, mais il pourrait y en avoir beaucoup +, avec des vitesses differentes, certains morceaux en sens unique, d'autre qui font parti d'un circuit(relation) de bus, un morceaux de bande cyclable, des pavés, etc. Chaque fois qu'on veut avoir des tags differents sur une portion de route, on coupe en 2 et ca crée 1 way(segment) suplementaire Donc, je ne sais pas si ma règle est juste, mais au moins j'ai trouvé ce qui me semble être une erreur dans osm :-) non, tout vas bien :) la rue de Lodi un peut au nord de la rue de brossard est aussi en 2 segments, chacun en sens unique dans un sens différent. C'est normal, c'est la même rue, mais les deux morceaux ont un fonctionnement différents, donc on fait 2 segments, donc 2 way. -- JB ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Erreurs dans les fichiers cleo
On 02/13/2012 06:35 PM, didier2020 wrote: bonsoir, ci joint un fichier osm que j'ai créé et ou le validator de josm ne trouve pas d'erreur j'ai utilisé le script de Bruno Cortial afin d'en faire un corrigeant ces erreurs je j'ai essayé sur http://cadastre.openstreetmap.fr/data/091/Y0191-CROSNE-houses.osm le nombre d'erreur detecté par josm passe de 9 a 43. je ne suis pas sur d'avoir tout compris en reordonnant les way ca suffit a faire en sorte que josm detecte + d'erreur ? j'ai testé sur un fichier au hasard, pas de difference avant/apres http://cadastre.openstreetmap.fr/data/022/BE203-PLOEUC%20SUR%20LIE-houses.osm avec ton fichier d'exemple CROSNE croisement de batiments : 505 avant -> 491 apres superposition de batiment : 5 avant -> 7 apres on gagne certes 2 superpositions, mais on pert 14 croisements. JOSM 4927 > merci de vos remarques quand au code/syntaxe (je learn...) j'ai déjà eu du mal a trouver ce fichu module osmsax ;) https://gitorious.org/osmose/backend/blobs/master/modules/OsmSax.py ps : 500 erreurs, je comprends la discussion sur le fait qu'on ne corrige pas ca a la main. Moi qui trouvais que 100 erreurs c'etait déjà pénible Cordialement, -- JB ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Fichiers osm "full-history" - Création de la base de données
On 12/09/2011 08:49 AM, Ab_fab wrote: Tu es sûr d'avoir formulé ta ligne de commande comme demandé ? le fichier readme donne ceci comme exemple : ./osm-history-importer --debug --prefix "hist_" --dsn "host='172.16.0.73' dbname='histtest'" gau-odernheim.osh.pbf effectivement, le jour ou j'apprendrais a lire ca ira mieux voila le resultat http://www.youtube.com/watch?v=j_-Glh94ZTE même avec le soft-cut ca fait un effet bizarre sur l'apparition des premiers segments, mais bon. ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Fichiers osm "full-history" - Création de la base de données
On 12/08/2011 11:37 PM, Ab_fab wrote: Ca me rassure de voir qu'il n'y a pas que moi qui a du mal à lire les url et toc ! :-p Bon courage, et fais nous part de tes découvertes ./osm-history-importer -D osmhistory ../../osm-history-splitter/rennes.osh.pbf Segmentation fault je n'ai pas decouvert grand chose :( quels option je peut rajouter dans la compilation de l'importer pour avoir un message d'erreur un peut moins abrupte ? un -debug ? (j'y connais rien en C/C++) -- JB ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Fichiers osm "full-history" - Création de la base de données
On 12/08/2011 11:08 PM, Ab_fab wrote: Bonsoir Julien, Pourquoi ne pas avoir splitté l'historique France, plutôt ? ftp://ftp5.gwdg.de/pub/misc/openstreetmap/osm-full-history-extracts/110919/pbf/europe/ real1933m31.226s user2239m1.696s sys 140m38.351s c'est *un peut* cher de partir du planet mondial en effet je vais essayer avec celui de la france pour voir a combien ca tombe. ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Fichiers osm "full-history" - Création de la base de données
On 12/08/2011 11:08 PM, Ab_fab wrote: Bonsoir Julien, Pourquoi ne pas avoir splitté l'historique France, plutôt ? ftp://ftp5.gwdg.de/pub/misc/openstreetmap/osm-full-history-extracts/110919/pbf/europe/ parceque ! ;) non en fait je ne savait pas que ca existait je suis parti de http://planet.osm.org/full-experimental/ comme il etait dit dans le tutorial initial, je n'ai pas comparé l'url avec le tiens, j'ai supposé que c'etait la même bon, je laisse tourner jusqu'a demain matin et on verra Le 8 décembre 2011 22:46, julien balas mailto:jul...@krilin.org>> a écrit : Il y aura surement un pb pour la découpe par ville. Sur mon PC (qui n'est certes pas un foudre de guerre), je suis en train de splitter l'historique mondiale pour en extraire rennes. J'en suis a 1300 minutes et il a pas fini (mais il est en "second-pass" quoique ca veuille dire) En tout cas merci pour le lien, ca promet des anims sympa. -- JB _ dev-fr mailing list dev-fr@openstreetmap.org <mailto:dev-fr@openstreetmap.org> http://lists.openstreetmap.__org/listinfo/dev-fr <http://lists.openstreetmap.org/listinfo/dev-fr> -- ab_fab <http://wiki.openstreetmap.org/wiki/User:Ab_fab> "Il n'y a pas de pas perdus" ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Fichiers osm "full-history" - Création de la base de données
On 12/06/2011 11:24 AM, Ab_fab wrote: Bonjour, J'ai fait l'installation des outils nécessaires pour la création d'une base Postgis sous un schéma "full-history". Puis j'ai pu créer une base de données, basée sur un extrait de la zone de Nancy pour vérifier le bon fonctionnement de l'ensemble. [...] L'étape suivante intéressante serait de mettre en place une bdd avec l'extrait france sur un serveur osm-fr, Permettre d'y faire d'autres requêtes (par une interface de query [5] -> en lecture seule et avec un time-out of course), Présenter les résultats sous une forme attrayante sur le site principal. Il y a d'abord une contrainte d'espace disque pour la France, la base devant être un peu plus grosse que la base actuelle d'un extrait équivalent. Pas vraiment de contrainte concernant la vitesse de l'import initial et de la tenue à jour (pas de diff à appliquer) : le planet "full-history" n'est actualisé que quelques fois par an au mieux. On pourra aussi regarder plus dans le détail comment fonctionnent les rendus pour maîtriser la chaine de "production" jusqu'à obtenir une video _ dans un format libre et répandu, propre, léger, à la bonne résolution (web, HD, full HD), _ Pour une zone géographique donnée, Il y aura surement un pb pour la découpe par ville. Sur mon PC (qui n'est certes pas un foudre de guerre), je suis en train de splitter l'historique mondiale pour en extraire rennes. J'en suis a 1300 minutes et il a pas fini (mais il est en "second-pass" quoique ca veuille dire) _ Dans la période et au pas de temps la mieux adaptée. _ avec les règles de rendu de son choix (ce sont des feuilles de style xml Mapnik) == [1] Commandes ajustées pour Ubuntu 11.10 et PostgreSQL 9.1 sur ma ubuntu 10.04 LTS, j'ai été obligé de faire un lien symbolique pour la protobuf-lite mais sinon tout c'est bien passé pour le moment. Ha non en fait je compile le renderer en même temps que j'ecris ce mail et il rale sur un osmium.hpp manquant... pfff, j'y retourne. En tout cas merci pour le lien, ca promet des anims sympa. -- JB ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
[OSM-dev-fr] Import d'arbres
Salut, je suis en train de regarder pour importer les arbres a Rennes il y a deux fichiers dans l'open data - les arbres normaux - ceux qui sont dans un parc en particulier. pour les arbres normaux j'ai ce genre de contenu lon='-1.72156036981293'> pour ceux qui sont dans le parc, on a les especes en plus. J'arrive a ce genre de contenu, est ce que c'est correcte ? lon='-1.67238493234965'> j'ai mis un "source_id" pour faire le lien avec les fichiers source, est ce qu'il y a un nom de tag particulier a utiliser? une ref ? le tag "id_aorn" du deuxieme fichier est aussi un autre identifiant interne a Rennes Metropole. Est ce que ca vaut le coup de mettre les especes en minuscule ou pas ? A partir des especes on pourrait eventuellement trouver si c'est un feuillu ou un conifere, mais bon... http://wiki.openstreetmap.org/wiki/FR:Tag:natural=tree Mais mon principale soucis est que les deux fichiers ont des quasi-doublons, des arbres présent dans les deux fichiers, mais avec un chouilla de difference. Sur l'image suivante, les points 2 3 et 4 par ex. En gris un jeux de données, en pictogramme couleur l'autre jeux. http://ks30026.kimsufi.com/~julien/img/c04d4c10ea8970d9c5364f430c1ec686.jpg A votre avis, a partir de quel proximité on peut dire que c'est le même arbre? Les deux jeux de données sont censé avoir une précision métrique. Je dis qu'a partir de 2m de distance, ce sont deux arbres differents ? Comment vous avez resolu le probleme dans vos imports? Que ca soit deux sources de données differente ou une source et l'existant osm, le pb est le même non ? Note : je peut aussi tout importer a la sauvage et attendre qu'il y ai un plugin osmose "arbres trop proche" ;) Cordialement, -- JB ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] trouver des way en doublon que j'ai crée par erreur.
On 08/16/2011 11:53 PM, Black Myst wrote: Salut, Est-ce que tu sais si tu en a beaucoup ? Parce que s'il y en a peu, c'est peut-être plus facile de les corriger à la main : http://tools.geofabrik.de/osmi/?view=routing&lon=2.96596&lat=46.78626&zoom=7&opacity=1.00&overlays=duplicate_ways je pense qu'il y en a peu le pb d'osmi, c'est que ca donne tous les doublons de france. Je veut bien en corriger plein pour ma penitence d'avoir fait un bot buggé, mais ca vas prendre du temps ;) et puis ca reste une operation manuelle, on n'est pas sur que 100% des erreurs seront traitées. -- JB ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] trouver des way en doublon que j'ai crée par erreur.
On peut comparer tout le tableau de points d'un seul coup. cool > Mais la question est surtout de savoir si les nœuds sont aussi dupliqués ou pas. c'est en effet une bonne question... Sur les ways que j'ai suprimmé via josm, je ne souvient plus. voyont voir en cherchant dans mes dernieres modifs. une way crée par erreur http://www.openstreetmap.org/browse/way/120121798/history elle utilise les noeuds 26209791 et 253417504 la way qu'elle etait censé modifier http://www.openstreetmap.org/browse/way/25397273/history qui utilise aussi les mêmes noeuds oui, a priori les noeuds sont eux bien reutilisés et pas dupliqué ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] implémenter OSM dans une application java
On 08/16/2011 10:13 PM, damien wrote: Bonjour Le toolkit sera sans doute swing, j'ai besoin d'afficher les tuiles, de pouvoir zoomer et glisser. si il existe un composant swing qui fait navigateur web, c'est facile ? sinon il faut soit même aller chercher les tuiles la formule pour savoir lesquels ramener est ici http://wiki.openstreetmap.org/wiki/Slippy_map_tilenames J'aimerai aussi et c'est sans doute le plus compliquer, avoir des informations de localisation, par exemple, savoir le pays que l'on consulte, la région, la ville... Pour l’instant je n'ai pas besoin de calcule. pour savoir si ton point est dans un polygone (pays, region, commune) ou proche d'un point de reference (ville) tu aura des calculs a faire ;) tu pourrra extraire de la base les polygones des limites administrative et les lieux, pour le reste je pense qu'il faudra que tu le fasse à la main. Bon courage. -- JB ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] trouver des way en doublon que j'ai crée par erreur.
Je commencerais par charger les données en base PostGIS, dans un schéma Osmosis, et (en option) à opérer un filtre (osmosis aussi) pour ne garder que les ways avec un tag highway et un tag ref. L'intérêt ici d'Osmosis, c'est que le schéma te donne la liste ordonnée des nodes qui forment un way. Ensuite, une requête doit te permettre de compter, par exemple, les ways avec une combinaison de critères tels que : - même tag ref - même tag highway - même nombre de points - même id de 1er point - même id de dernier point - ET même id de deuxième point (histoire d'éliminer, s'il y en a, des configurations en boucle, connectés par les 2 extrémités). c'est le genre de requete que j'ai faite sur ma base perso - cherche 2 ways, qui ne sont pas les même mais qui ont même taille, une ref chacune, et le même 1er point. et une des deux a été crée par mon user. Quand le comptage est > 1, tu as une bonne chance d'être en présence de doublons, triplets, etc. Si besoin je peux défricher une requête, mais pas avant demain (là, je n'ai pas de base sous le coude). ok, ma methode prevue n'est donc pas deconnante, je continue sur cette voie Pour la requete, pas de speed. Le temps que mon PC charge la base, y'en a deja pour 2-3 jours ;) en plus les export geofabrik sont vide ce soir. Donc ca risque de pas commencer avant ce WE -- JB ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
[OSM-dev-fr] trouver des way en doublon que j'ai crée par erreur.
Salut, j'avais fait il y a quelques temps un petit robot pour rajouter des espaces manquant dans les tag "ref" (N10 -> N 10) Il y a quelques jours un utilisateur me fait remarquer que j'ai crée des way en doublon. Apres verif, en effet mon robot a dupliqué les way plutot que de faire des modifs. :( Comme le robot a tourné il y a pas mal de temps et que le pb ne se pose pas pour la majorité des way du changeset (il y en avait 5 sur la basse normandie), ca me parait plus simple de les laisser en l'etat et de chercher mes doublons pour les supprimer. Mais la je bloque un peut sur la marche a suivre. Avec mes petites moulinette maison je n'arrive a rien. Est ce que la methode suivante vous semble pertinente ? - prendre le dump FR - filtrer pour ne garder que les way ayant une REF (osmosis?) - charger ca dans une base (osmosis aussi?) - faire une requete postgis magique qui me donne la liste des ID a verifier/corriger ou alors je part des changeset(il y en avait un par region) et par un moyen que je connais pas, je verifie chaque way. C'est pas urgent urgent, ca ne gene pas le routage et visuellement ca ne se voit pas trop, les way sont superposées, mais j'aimerais autant nettoyer mes saloperies. Merci de vos idées. -- JB ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] implémenter OSM dans une application java
On 08/16/2011 09:24 PM, damien wrote: Bonjour Je souhaite intégrer OSM dans une application java, de manière native (sans utiliser de WekKit, ni JS, etc.), qu'existe-il pour m'aider ? quel toolkit ? swing, awt, swt ? quel sont les fonctions dont tu a besoin ? affichage, calcul, rendu personnalisé ? il y a la java lib osm, mais elle n'a pas bougé depuis 2009 http://linux.softpedia.com/get/Programming/Libraries/libosm-45085.shtml tu en trouvera probablement d'autres sur sourceforge ou github -- JB ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] [OSM-talk-fr] Import automatique du bâti
ma debian a moi (lenny) n'a pas de paquet podofo et je trouve pas de paquet proj4 non plus Houla, debian lenny... Je suis désolé, je ne peux pas supporter une distribution aussi vieille... Je te conseille de faire du pinning pour récupérer libpodofo-dev et libproj-dev depuis une squeeze. ok, je vais essayer, sinon je repartirais des sources des libs > Pour la compilation, il suffit de faire : > - qmake > - make > Et voilà, un binaire Qadastre2OSM est disponible... chez moi ca ne "suffit" pas :) jul...@bla:~/osm/qadastre2osm$ qmake QMAKESPEC has not been set, so configuration cannot be deduced. Error processing project file: /home/julien/osm/qadastre2osm/Qadastre2OSM.pro Est-ce bien un qmake Qt4 et pas un qmake Qt3 ? normalement oui pour l'avoir j'ai fait un apt-get install qt4-qmake petite remarque/amélioration, est ce que tu pourrais zippé les fichiers resultats ? Ca prendrais moins de disque chez toi et moins trafic reseaux aussi. Un peut plus de CPU par contre, forcement. Je vois l'outil Qadastre2osm comme une simple "brique" destinée à être surtout utilisée de manière automatisée (comme ce que fait Philippe sur son serveur). Je n'ai pas eu le besoin de supporter la compression, qui en prime m'aurait imposé la présence d'une dépendance supplémentaire... ca peut etre fait par Philippe en faisant un "bzip2 *" à la fin de l'execution si il pense que c'est une bonne idée. C'est son serveur apres tout ;) Si tu penses que c'est très important, je peux l'implémenter bien sûr, mais j'ai d'autres points prioritaires à traiter (quelques soucis rapportés par RatZilla sur talk-fr notamment)... non ca n'est pas trés important. mieux vaut corriger des "bugs" qu'ajouter des fonctionnalités. Ca pourrait même faire un bon exercice pour moi de rajouter l'option, quand j'aurais réussi a compiler :) -- JB ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] [OSM-talk-fr] Import automatique du bâti
> Notamment, la consommation en mémoire vive de mon convertisseur est beaucoup > plus faible (le logiciel pdf2svg ayant tendance à consommer énormément de > mémoire...), et, ayant obtenu de meilleures performances, j'ai pu intégrer des > fonctionnalités coûteuses en temps mais qui améliorent le résultat final. Ainsi > mon logiciel est capable de détecter sur le cadastre le bâti, les voies de > chemin de fer, les cours d'eau, mais aussi les cimetières et les églises. genial! j'etais parti sur de la reconnaissance de forme avec openCV pour les cimetieres et églises, mais si c'est déjà fait ;) > Le projet est disponible à cette adresse : > http://gitorious.org/qadastre/qadastre2osm > Les dépendances sont : > - Qt (core, gui et network... j'aimerais bien ne plus dépendre de Qt Gui, mais > ça sera pour plus tard, au moins je dépend pas d'un serveur X) > - l'inévitable Proj4 > - podofo (paquet libpodofo-dev sous debian), une librairie fort sympatique pour > la manipulation des PDFs ma debian a moi (lenny) n'a pas de paquet podofo et je trouve pas de paquet proj4 non plus > Pour la compilation, il suffit de faire : > - qmake > - make > Et voilà, un binaire Qadastre2OSM est disponible... chez moi ca ne "suffit" pas :) jul...@bla:~/osm/qadastre2osm$ qmake QMAKESPEC has not been set, so configuration cannot be deduced. Error processing project file: /home/julien/osm/qadastre2osm/Qadastre2OSM.pro si je fait jul...@bla:~/osm/qadastre2osm$ qmake -project -o Qadastre2OSM.pro je n'ai pas d'erreur, mais il ne se passe pas grand chose de visible et ensuite quand je fait "make" il me dit make: *** No targets specified and no makefile found. Stop. pour prendre le projet depuis git j'ai fait git clone git://gitorious.org/qadastre/qadastre2osm.git c'est bien ca qu'il fallait faire? (c'est la 1ere fois que j'utilise git) petite remarque/amélioration, est ce que tu pourrais zippé les fichiers resultats ? Ca prendrais moins de disque chez toi et moins trafic reseaux aussi. Un peut plus de CPU par contre, forcement. -- JB ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] [OSM-talk-fr] (sans objet)
suite d'une discussion commencé sur talk-fr Il y a plusieurs choses a regarder déjà. - Bâtiments qui contient le + de points? Il faut regarder dans la table polygone et regarder la colonne building et ensuite utiliser la fonction ST_NPoints sur la géométrie. Tu peux ensuite trier normalement avec un order by select ST_Npoints(way) nb_pts, * from planet_osm_polygon where building='yes' order by nb_pts desc limit 100 En france c'est le louvre qui est number one avec 1763 points Me reste plus qu'a ne faire la requete que sur la bbox de ma ville. -- JB ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] osmosis, filtrer un changeset
sur http://gis.638310.n2.nabble.com/Osmosis-Bounding-polygon-does-not-support-change-data-as-input-td4363185.html ils disent que ca n'est pas possible, donnent des raisons et expliquent qu'il vaut mieux importer les diff mondiales puis de temps en temps supprimé tout ce qui ne nous interesse pas. Vous faites comme ca vous aussi, ou bien vous avez tous une base mondiale ? :) en relisant des mails précedents de la liste je suis tombé sur la réponse, on peut filtrer par bbox avec osm2pgsql... ./osm2pgsql -S default.style --slim --bbox -6.44,40.98,10.36,51.36 -d osm -C 1024 --append ../../planet/changes.osc.gz -- JB ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
[OSM-dev-fr] osmosis, filtrer un changeset
Salut dans le but d'avoir une base FR a jour, j'applique la procédure cité ici http://wiki.openstreetmap.org/wiki/Minutely_Mapnik ca fonctionne mais ca me donne les diff mondiale je cherche donc a filtrer les minutely diff pour ne garder que celles FR. Pour ca je pensait utiliser osmisis, mais il semble que ne j'arrive pas a trouver les bon parametres 1) je lit bien un xml-change 2) j'ecris bien un xml-change 3) mais visiblement on ne peut pas faire de bounding box sur un change jul...@dende:~/osm/planet/planet$ zcat changes2.osc.gz | osmosis --read-xml-change file=/dev/stdin --bounding-box left=-6.44 bottom=40.98 right=10.36 top=51.36 --write-xml-change file=-\ | gzip > changes2.osc.fr.gz Oct 31, 2010 11:40:24 PM org.openstreetmap.osmosis.core.Osmosis run INFO: Osmosis Version 0.37 Oct 31, 2010 11:40:25 PM org.openstreetmap.osmosis.core.Osmosis run INFO: Preparing pipeline. Oct 31, 2010 11:40:25 PM org.openstreetmap.osmosis.core.Osmosis main SEVERE: Execution aborted. org.openstreetmap.osmosis.core.OsmosisRuntimeException: Task 2-bounding-box does not support data provided by default pipe stored at level 1 in the default pipe stack. at org.openstreetmap.osmosis.core.pipeline.common.PipeTasks.retrieveTask(PipeTasks.java:157) [...] une recherche sur google m'a inciter a essyer une option "--read-xml-0.5" ou "--migrate" mais ces taches n'existent pas dans osmosis 0.37 sur http://forum.openstreetmap.org/viewtopic.php?id=3328 ils n'y arrivent pas non plus. sur http://gis.638310.n2.nabble.com/Osmosis-Bounding-polygon-does-not-support-change-data-as-input-td4363185.html ils disent que ca n'est pas possible, donnent des raisons et expliquent qu'il vaut mieux importer les diff mondiales puis de temps en temps supprimé tout ce qui ne nous interesse pas. Vous faites comme ca vous aussi, ou bien vous avez tous une base mondiale ? :) -- JB ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
