Re: [OSM-talk-fr] Intégration du bornage du réseau routier national

[didier2020]

afin de trouver une solution sans "ref" :
proposition d'utilisation des attributs de la base rrndescription
complète  : 
http://dtrf.setra.fr/pdf/pj/Dtrf/0005/Dtrf-0005792/DT5792.pdf
Pour les "nodes" highway=milestoneattribut 
base rrnvaleur dans
la base rrntag osm
proposévaleur tag
osmnotarouteA0004ref:FR:rrn:routeA0004ref "A 4" est sur le
waypr22distance22information visible sur le terraindep77concessionC
concédé n'est pas synonyme de payantcoteDD,G ou
UgestionnaireSANEFoperatorSANEFplo77PR22DCref:FR:rrn:plo77PR22DCavec le
plo, on peut retrouver tous les autres attributs et inversement














et pour être cohérent, 
pour les "way" highway=*_link ou junction=roundabout
attribut 
base rrnvaleur dans
la base rrntag osmproposévaleur tag
osmnotaroute26N953220ref:FR:rrn:route26N953220on pourrait ne pas
l'intégrerpr2
le pr correspond a un n° de bretelledep77concessionN

coteDle coté est toujours
DgestionnaireDIRCEoperatorDIRCEplo26N953220_2ref:FR:rrn:plo

26N953220_2avec le plo, on peut retrouver tous les autres attributs et
inversement













dans le champs source:plo, l'attribution et le milésime

Le lundi 08 juin 2020 à 13:26 +0200, didier2020 a écrit :
> comme il n'y a pas de consensus sur l'utilisation des tags
> complémentaire a higway=milestone,
> 
> j'ai téléchargé le pbf de la france et filtrer les nodes
> highway=milestone pour voir ce qui existe :
> 
> sur 10935 higway=milestone, 
> - 9057 ont un tag ref
> - 442 ont un tag ref avec une valeur numerique
> - distance :
>  705 n'ont pas de valeur distance
>  60 sont du texte/inclus un . ou +
>  170 ont des valeurs supérieur a 1000, donc a prioris des metres
> plutot
> que des kilometres
> - 400 avec un tag ref:highway
> 
> 
> 
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Intégration du bornage du réseau routier national

[didier2020]

afin de trouver une solution sans "ref" :
proposition d'utilisation des attributs de la base rrndescription
complète  : 
http://dtrf.setra.fr/pdf/pj/Dtrf/0005/Dtrf-0005792/DT5792.pdf
Pour les "nodes" highway=milestoneattribut 
base rrnvaleur dans
la base rrntag osm
proposévaleur tag
osmnotarouteA0004ref:FR:routeA0004ref "A 4" est sur le
waypr22distance22information visible sur le terraindep77concessionC
concédé n'est pas synonyme de payantcoteDD,G ou
UgestionnaireSANEFoperatorSANEFplo77PR22DCref:FR:plo77PR22DCavec le
plo, on peut retrouver tous les autres attributs et inversement














et pour être cohérent, 
pour les "way" highway=*_link ou junction=roundabout
attribut 
base rrnvaleur dans
la base rrntag osm
proposévaleur tag
osmnotaroute26N953220ref:FR:route26N953220pr2
le pr correspond a un n° de bretelledep77concessionC

coteDle coté est toujours
DgestionnaireDIRCEoperatorDIRCEplo26N953220_2ref:FR:plo26N953220_2avec
le plo, on peut retrouver tous les autres attributs et inversement













dans le champs source:plo, l'attribution et le milésime

Le lundi 08 juin 2020 à 13:26 +0200, didier2020 a écrit :
> comme il n'y a pas de consensus sur l'utilisation des tags
> complémentaire a higway=milestone,
> 
> j'ai téléchargé le pbf de la france et filtrer les nodes
> highway=milestone pour voir ce qui existe :
> 
> sur 10935 higway=milestone, 
> - 9057 ont un tag ref
> - 442 ont un tag ref avec une valeur numerique
> - distance :
>  705 n'ont pas de valeur distance
>  60 sont du texte/inclus un . ou +
>  170 ont des valeurs supérieur a 1000, donc a prioris des metres
> plutot
> que des kilometres
> - 400 avec un tag ref:highway
> 
> 
> 
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Intégration du bornage du réseau routier national

[didier2020]

Le lundi 08 juin 2020 à 15:44 +0200, osm.sanspourr...@spamgourmet.com a
écrit :
> https://www.mapillary.com/app/?lat=48.8611312=2.4841852=17=G1IiVslryLcBZplrme2ENA=photo=0.30771109667569485=0.7322106887594706=3
> 
> Ce serait A 86 ou A 86 extérieur ? Sur le panneau il y a A 86
> extérieur.
il y a un petit 'D' en bas a droite.
extérieur n'est pas 'conforme'
> 
> Et à partir de ça on sait reconstituer la référence RRN ?
non ...,
pour le rrn, a cet endroit c'est
route=A00086 plo=93PR29D 
(ou 93 est le département gestionnaire, pas le département ou se situe
la borne)


> 
> "+" pour indiquer que la distance est positive ? Semble évident !
> 
> Le 08/06/2020 à 15:07, didier2020 - osm2...@free.fr a écrit :
> > Le lundi 08 juin 2020 à 14:31 +0200, Marc M. a écrit :
> > > Le 08.06.20 à 13:26, didier2020 a écrit :
> > > > - 9057 ont un tag ref
> > > ce serrait sans doute utile de chercher quelques photos
> > > de borne avec la ref visible.
> > https://www.mapillary.com/app/?lat=48.8247647=2.4636774=17=IlaESQuLBwKEqsw1F-FV4w=photo=0.5059995150967409=0.4975920048505564=0
> > 
> > https://www.mapillary.com/app/?lat=48.8611312002=2.484185199562=16.84333642656937=G1IiVslryLcBZplrme2ENA=photo
> > 
> > https://www.mapillary.com/app/?lat=49.073468617885425=2.332858531006834=17=vxFrND-wENkm_OfdYDqsmA=photo
> > 
> > > >   60 sont du texte/inclus un . ou +
> > > . est le séparateur décimal dans osm, du coup c'est numérique.
> > > le + est + étrange.
> > > 
> > > > ref:highway
> > > > serait une solution
> > > à mon avis, quand il n'y a pas consensus, osmose doit s'abstenir
> > > donc intégrons déjà toutes les bornes sans ref:highway
> > > 
> > > > "notre" besoin de référence unique
> > > quel besoin ? si la ref dans la source n'est pas unique, elle
> > > n'est
> > > pas
> > > unique.
> > > prenons un exemple fictif : si la sncf décide de peindre ses
> > > places
> > > de parking en commençant par 1 sur tous ces sites, cela ferra des
> > > ref=1
> > > non unique dans osm.
> > > ce n'est pas le rôle d'osm d'inventer une ref genre
> > > ref:FR:SNCF:siteA
> > > par dogme d'unicité dans osm.
> > > ou exemple réel : la route ref=1 n'est pas unique dans osm,
> > > c'est la réalité, cela n'empêche pas son utilisation.
> > > 
> > > dupliquer + tard un ref:highway s'il y a un cas d'usage et un
> > > consensus,
> > > c'est toujours possible
> > > 
> > > ___
> > > Talk-fr mailing list
> > > Talk-fr@openstreetmap.org
> > > https://lists.openstreetmap.org/listinfo/talk-fr
> > 
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Intégration du bornage du réseau routier national

[didier2020]

Le lundi 08 juin 2020 à 14:31 +0200, Marc M. a écrit :
> Le 08.06.20 à 13:26, didier2020 a écrit :
> > - 9057 ont un tag ref
> 
> ce serrait sans doute utile de chercher quelques photos
> de borne avec la ref visible.

https://www.mapillary.com/app/?lat=48.8247647=2.4636774=17=IlaESQuLBwKEqsw1F-FV4w=photo=0.5059995150967409=0.4975920048505564=0

https://www.mapillary.com/app/?lat=48.8611312002=2.484185199562=16.84333642656937=G1IiVslryLcBZplrme2ENA=photo

https://www.mapillary.com/app/?lat=49.073468617885425=2.332858531006834=17=vxFrND-wENkm_OfdYDqsmA=photo

> 
> >  60 sont du texte/inclus un . ou +
> 
> . est le séparateur décimal dans osm, du coup c'est numérique.
> le + est + étrange.
> 
> > ref:highway
> > serait une solution
> 
> à mon avis, quand il n'y a pas consensus, osmose doit s'abstenir
> donc intégrons déjà toutes les bornes sans ref:highway
> 
> > "notre" besoin de référence unique
> 
> quel besoin ? si la ref dans la source n'est pas unique, elle n'est
> pas
> unique.
> prenons un exemple fictif : si la sncf décide de peindre ses places
> de parking en commençant par 1 sur tous ces sites, cela ferra des
> ref=1
> non unique dans osm.
> ce n'est pas le rôle d'osm d'inventer une ref genre ref:FR:SNCF:siteA
> par dogme d'unicité dans osm.
> ou exemple réel : la route ref=1 n'est pas unique dans osm,
> c'est la réalité, cela n'empêche pas son utilisation.
> 
> dupliquer + tard un ref:highway s'il y a un cas d'usage et un
> consensus,
> c'est toujours possible
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Intégration du bornage du réseau routier national

[didier2020]

Le lundi 08 juin 2020 à 14:31 +0200, Marc M. a écrit :
> Le 08.06.20 à 13:26, didier2020 a écrit :
> > - 9057 ont un tag ref
> 
> ce serrait sans doute utile de chercher quelques photos
> de borne avec la ref visible.
> 
> >  60 sont du texte/inclus un . ou +
> 
> . est le séparateur décimal dans osm, du coup c'est numérique.
> le + est + étrange.
c'est quelqu'un dont le métier est la route
12+1600 veut dire 1600 m après 12
> 
> > ref:highway
> > serait une solution
> 
> à mon avis, quand il n'y a pas consensus, osmose doit s'abstenir
> donc intégrons déjà toutes les bornes sans ref:highway
> 
> > "notre" besoin de référence unique
> 
> quel besoin ? si la ref dans la source n'est pas unique, elle n'est
> pas
> unique.

dans la base de donnée du réseau rrn, 
route + borne = référence & localisation unique

> prenons un exemple fictif : si la sncf décide de peindre ses places
> de parking en commençant par 1 sur tous ces sites, cela ferra des
> ref=1
> non unique dans osm.
> ce n'est pas le rôle d'osm d'inventer une ref genre ref:FR:SNCF:siteA
> par dogme d'unicité dans osm.
> ou exemple réel : la route ref=1 n'est pas unique dans osm,
> c'est la réalité, cela n'empêche pas son utilisation.
> 

c'est comme une addr:housenumber sans addr:street ni relation
associated...
le numero seul a une réutilisation très limitée voir inexistante.



> dupliquer + tard un ref:highway s'il y a un cas d'usage et un
> consensus,
> c'est toujours possible
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Intégration du bornage du réseau routier national

[didier2020]

comme il n'y a pas de consensus sur l'utilisation des tags
complémentaire a higway=milestone,

j'ai téléchargé le pbf de la france et filtrer les nodes
highway=milestone pour voir ce qui existe :

sur 10935 higway=milestone, 
- 9057 ont un tag ref
- 442 ont un tag ref avec une valeur numerique
- distance :
 705 n'ont pas de valeur distance
 60 sont du texte/inclus un . ou +
 170 ont des valeurs supérieur a 1000, donc a prioris des metres plutot
que des kilometres
- 400 avec un tag ref:highway

ce ref:highway est peut etre redondant,
mais pas plus que addr:street/name pour les adresses,
serait une solution pour "notre" besoin de référence unique pour le
réseau routier national ?






 




___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Intégration du bornage du réseau routier national

[didier2020]

Le dimanche 07 juin 2020 à 11:04 +0200, Frédéric Rodrigo a écrit :
> Le 04/06/2020 à 17:09, Marc M. a écrit :
> > Le 04.06.20 à 17:02, didier2020 a écrit :
> > > dans le référentiel, la bretelle est définie par 2 plo, non
> > > visible
> > > sur le terrain
> > > - la référence métier est sur un way
> > séparer l'intégration en 2 :
> > - les bornes réelles d'un côté
> > - les ref de route non indiquée sur le terrain...
> > sans doute qlq chose pour unsigned_ref.
> > très pratique pour éviter qu'un guidage te propose
> > de suivre une ref que tu ne vois pas.
> 
> Je pense qu'il faut déjà se concentrer sur les bornes physiques.
> 
> 
> 
> Un borne est portée une route qui a une référence.
> 
> Le wiki de dit pas si la borne doit être sur ou a coté du la voie.
> 
> 
> 
> La borne a ensuite une référence unique par route, composé du 
> département, numéro d'ordre de la borne, coté de chaussée [...])
> 
> http://dtrf.setra.fr/pdf/pj/Dtrf/0005/Dtrf-0005792/DT5792.pdf page 12
> 
> Mais cette référence de borne n'inclut pas la référence de la route 
> (c'eût aurait été trop facile).
> 
> Nationalement il y a donc des doublons de référence de bornes. Ils
> font 
> donc les deux références pour l'identifier.
> 
> 
> 
> Soit on considère que par jointure/proximité avec la voie qui la
> porte 
> on retrouve cette référence, soit on cherche à rajouter la ref de la 
> route quand même sur la borne (mais dans quel tag ?), ou tout mettre 
> dans le même tag par concaténation.
> 
> 
> 
> Nota: la page du wiki en français sur interprète la version anglaise 
> actuelle 
> https://wiki.openstreetmap.org/wiki/FR:Tag:highway%3Dmilestone
> 
> 
Les versions Française et Anglaise ne sont pas aprouvée...

la proposition était simple : ref est le nom de la route 
https://wiki.openstreetmap.org/wiki/Proposed_features/Milestones


> 
> Frédéric.
> 
> (en direct depuis 976PR18aU)
> 
> 
> 
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Intégration du bornage du réseau routier national

[didier2020]

Le jeudi 04 juin 2020 à 16:54 +0200, Marc M. a écrit :
> Bonjour,
> 
> mon avis:
> - la ref de la voie n'est pas la ref de la borne
> - la distance c'est distance= :)
> - donc la réf de la borne, puisqu'elle est parfois visible
> sur le terrain, c'est tout simplement ref comme dans les autres pays
> :)
> 
> je n'ai pas compris le point B des bornes de bretelles,
> en quoi c'est différent pour osm d'une autre ?
- dans le référentiel, la bretelle est définie par 2 plo, non visible
sur le terrain
- la référence métier est sur un way

> 
> Cordialement,
> Marc
> 
> Le 04.06.20 à 16:37, Frédéric Rodrigo a écrit :
> > Je résume.
> > La question porte sur l'usage du tag ref pour un highway=milestone.
> > Certains utilisent la ref de voie (A 63), d'autres la distance. Il
> > y a
> > en plus une référence "métier" non inscrite sur les bornes.
> > https://wiki.openstreetmap.org/wiki/Tag:highway%3Dmilestone
> > 
> > Mon avis perso. La ref de la voie ne peut pas être la ref de la
> > borne
> > car ça ne rend pas cette référencée unique dans son contexte
> > d'utilisation, c'est à dire la voie.
> > 
> > 
> > Le 04/06/2020 à 16:04, didier a écrit :
> > > Bonjour,
> > > 
> > > Afin qu'osmose puis permettre d'intégrer des données du réseau
> > > routier
> > > national,
> > > F.Rodrigo m'a demandé de voir l'utilisation des tags pour
> > > highway=milestone
> > > 
> > > Préambule :
> > > Le céréma gère le référentiel du réseau routier national (RRN),
> > > qui est
> > > a l'origine une base de donnée patrimoniale :
> > >   - Une route et sa représentation géométrique (Polyline) :
> > > A0001, N0001
> > > etc...
> > >   - Une route pour les bretelles d'entrée, sortie, échange ou
> > > giratoire
> > > : 60A900130DC, 78A901310 etc...
> > >   - Des "points localisants" (plo) qui sont associés a une route
> > >+ chaque plo a une distance cumulée par rapport au début de la
> > > route
> > > (l'ecart entre deux plo est appelé inter-pr)
> > >   les 2 types de localisants qui sont "interressant" sont
> > >+ SC pour section courante (plo 93PR1D pr 1, 60PR30GC pr 30)
> > >+ DB pour début bretelle (plo DB1 pr 1, plo DB2 pr 2)
> > >+ FB pour fin bretelle (plo FB1 pr 1, plo FB2 pr 2)
> > > 
> > > ces 2 tables sont le référentiel rrn et sont suffisantes pour
> > > décrire
> > > le réseau routier et ses différentes caractéristiques et ceci
> > > sans
> > > coordonnées.
> > > exemple: sur la route A0001, 100 metres après le plo 93PR1D et
> > > jusqu'a
> > > 10 metres après le plo 93PR2D, le nombre de voie est de 5, la
> > > vitesse
> > > de 90 km/h
> > > 
> > > Différents export de cette base sont disponible sur data.gouv.fr
> > > mis a
> > > disposition par le Ministère de la Transition écologique et
> > > solidaire
> > > entre autre :
> > > https://www.data.gouv.fr/fr/datasets/bornage-du-reseau-routier-national/
> > > https://www.data.gouv.fr/fr/datasets/gestionnaires-du-reseau-routier-national/
> > > 
> > > 
> > > La question pour l'intégration dans Openstreetmap est sur
> > > l'utilisation
> > > des tags, lesquels utiliser ?:
> > > A) Pour les routes, il n'y a pas de données précise mis a
> > > disposition
> > > sur data.gouv.fr.
> > >   ref est utilisé sur les way et dans les relations routes mais
> > > avec un
> > > espace entre la lettre et les chiffres
> > > Il n'y a pas de donnée a intégrer
> > > 
> > > B) Pas retenu pour une intégration avec osmose :
> > >   Pour les plo de type DB ou FB, cela correspont a des entrées,
> > > sorties,
> > > giratoires ou bretelles d'interconnexion => type:way et
> > > highway=motorway_link, trunk_link, primary_link...
> > >   cela correspond :
> > > https://www.data.gouv.fr/fr/datasets/gestionnaires-du-reseau-routier-national/
> > > 
> > > (les données de bretelle et de bornage sont mélangées)
> > >   la référence ne sera pratiquement jamais visible sur le
> > > terrain.
> > >   je propose
> > >   nat_ref = 60A900130DC_1
> > >   car cela correspond a ce qu'utilise bison-futé pour la
> > > géolocalisation
> > > de ses données événementielles
> > > 
> > > C) Pour les plo de type SC, cela correspont au bornage routier =>
> > > type:node et highway=milestone
> > > les données sont disponibles :
> > > https://www.data.gouv.fr/fr/datasets/bornage-du-reseau-routier-national
> > > (les données de bretelle et de bornage sont mélangées)
> > > (pour info, les données intégrables commencent après la ligne
> > > 13454)
> > > 
> > > dans le wiki, les tags highway=milestone sont distance et ref
> > > 
> > > je propose cette correspondance pour des attributs du csv
> > > - x coordonnées lon epsg:2154
> > > - y coordonnées lat epsg:2154
> > > - z toujours a 0, a ignorer
> > > 
> > > - abs : toujours a 0,
> > > => a ignorer
> > > - cumul : distance cumulée depuis le début de la route
> > > => a ignorer ou inventer
> > > 
> > > - route: A0004 (a modifier pour faire correspondre a A 4)
> > > => ref
> > > - pr : 1 pour une meme route, il peut y avoir le meme pr dans
> > > chaque
> > > département
> > > 

Re: [OSM-talk-fr] Tarif des péages

[didier2020]

Le mardi 21 février 2017 à 09:15 +0100, David Crochet a écrit : 
> Bonjour
> 
> 
> Le 20/02/2017 à 23:41, osm.sanspourr...@spamgourmet.com a écrit :
> > Pour obtenir des infos, on peut dire qu'à défaut on pénalisera à 99,99 
> > €/km ;-).
> 
> L'idée de mettre un forfait en cas de service inconnu peut soit inciter 
> les autoroutiers à donner ses tarifs, ou alors à ne rien faire car il 
> sait que le consommateur aura une fausse information
> 
> Le prix moyen du kilomètre, c'est quoi du 10-15 c€ ? (exception faite de 
> « Paris -Orgeval » et de « Chambéry - Genève »)
pour un tarif a la louche ça colle sauf pour les tarifs dont  le tarif
varie avec les horaires. tu peu x 10 pour les sections tunnels. 
> 
> Cordialement
> 



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Parcourir toutes les routes d'une commune

[didier2020]

c'est le fameu probleme du voyageur de commerce mais ramené a une
ville ...

tu peu essayé ca :
https://www.multiroute.de/?locale=fr


Le mardi 04 octobre 2016 à 19:01 +0200, Stéphane Péneau a écrit : 
> Bonsoir tout le monde,
> 
> Si vous deviez parcourir toutes les routes d'une commune, comment est-ce 
> que vous vous y prendriez ?
> 
> On part du principe qu'on met de côté tout ce qui est highway=path ou 
> track pour conserver les routes adaptées aux voitures.
> 
> Je peux facilement récupérer ces routes dans Josm avec un requête 
> overpass, puis faire quelques corrections, comme ajouter les routes qui 
> sont très légèrement au-delà des limites admin, mais ensuite, comment 
> trouver le parcours le plus court  et être guidé, depuis OsmAnd par exemple.
> 
> J'avoue que je sèche.
> 
> Le première application pourrait se faire ce week-end pour l'opération 
> libre de montreuil-en-touraine
> 
> http://www.openstreetmap.org/relation/171408
> 
> Stf
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] PR points routiers et adresse

[didier2020]

Le mercredi 21 septembre 2016 à 19:57 +0200, JB a écrit : 
> Le 21/09/2016 à 19:49, osm.sanspourr...@spamgourmet.com a écrit :
> > On est alors plus dans un modèle style associatedStreet.
> Ourk… surtout pas ! (Pour élaborer un peu plus : surtout pas de 
> relations inutiles, surtout à cette échelle !)
> Mais oui, ça fait bizarre de voir tout le monde intégrer ça à « grande » 
> échelle avec chacun sa modélisation.
> Et tant que j'y suis, ça me fait aussi bizarre de voir comme argument : 
> « ce modèle ne va pas, Nominatim ne l'exploite pas »… En plus qu'on ne 
> taggue pas pour le géocodeur, je ne suis pas persuadé que les PR soient 
> vraiment utilisés par le grand public, et que ceux qui en auront 
> l'utilité auront développé des outils pour ça.
c'est en cours pour les "autoroutiers" de france, avec la publication de
leurs événements/incident avec la norme date2 qui utilise la description
du réseau riu (réseau inter-urbain) non dispo en opendata :-(
et donc pr mais dans leur description complete (departement - pr- sens)

les tags actuels d'osm ne permettront pas de renvoyer un localisant
unique :
une recherche de pr 5 sur la N118 renverra 4 localisation
- sens D (vers province) et sens G (vers paris)
- entre Paris et Vélizy (pr 0 a 6) et entre Vélizy et Les Ulis (pr 0 à
15)




___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] PR points routiers et adresse

[didier2020]

Le mardi 20 septembre 2016 à 04:16 +0200, Philippe Verdy a écrit : 
> On remarquera aussi l'inscription à même la chaussée dans la bande
> d'arrêt (perpendiculairement à celle-ci) devant les bornes d'appel
> d'urgence (le repère kilométrique est aussi en vis-à-vis sur la voie
> en contre-sens.
> 
> 
> Les deux bornes d'appel ont un numéro proche, mais pas équivalent (en
> préfixe un chiffre 1 ou 2 pour indiquer le sens, puis un tiret, puis
> uniquement la mention du kilomètre, et ensuite une lettre ou un
> chiffre que je suppose être une clé de validation ou un code de
> section d'autoroute).
> 
il n'y a aucune normalisation commune sur les bornes d'appel d'urgence
en france.

Il se peut qu'il y ait une normalisation par gestionnaire:
par exemple en ile de france (reseau dirif) sur la majorité des axes  
MZ09a correspond
2 lettres = code de l'axe ici (A4 pour MetZ)
2 chiffres = "pas loin" du pr 9
1 lettre = 
début d'alphabet (a,b...) pour "vers province" pour les radiales et
"intérieur" pour les rocades
fin d'alphabet (r,s...) pour "vers paris" pour les radiales et
"extérieur" pour les rocades






___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] PR points routiers et adresse

[didier2020]

petites précisions sur le contenu du fichier
+ le nom de route peut etre une donnée SANS BORNE (ou trait blanc sur la
chaussée) sur le terrain
comme 02N900202

02 = departement
N900202 = Numéro d'échangeur avec N9002 => Bretelle attachée a la N2 (Si
A9 => Bretelle attachée a la Axxx) ; 02 = bretelle numéro 2 de cet
échangeur 
dans ce cas, le pr n'est pas un pr mais un numéro de bretelle

+ c'est du lambert 93 (espg 2154)
+ pour le champ coté
D = sens des pr croissant
G = sens des pr décroissant

mes 0.01c

Le mardi 20 septembre 2016 à 01:40 +0200, Donat ROBAUX a écrit : 
> Bonjour,
> 
> 
> Suite au tweet de Christian
> (https://twitter.com/cq94/status/774631454764568576?lang=fr)
> concernant la mise à dispo en open-data des points routiers (ce qu'on
> appelle vulgairement les points kilométriques).
> 
> 
> J’ai repéré un PR sur Josm et l’ai marqué
> 
> Highway=milestone
> 
> Distance=13
> 
> Source=data.gouv.fr
> 
>  
> 
> Puis je me suis aperçu que de chaque côté de la voie il y avait une
> toute petite bande blanche perpendiculaire aux bandes blanches
> latérales et que ca se voit « pas trop mal » sur la BD Ortho.
> 
> Donc j’ai mis une soixantaine de kms d’autoroute comme ca.
> 
> 1km = environ 19 bandes blanches latérales pour la petite histoire
> 
>  
> 
> J’ai cartographié dans l’espoir que ca équivale à un « point
> d’adresse ».
> 
> Ex : j’ai un accident sur l’autoroute et je me situe au PR19, le samu
> sait où je suis.
> 
> Malheureusement, impossible de faire ressortir le PR avec la barre de
> recherche d’openstreetmap.org. J’ai testé pourtant pas mal de
> combinaisons.
> 
> Par contre en mettant addr :housenumber=15, ca ressort. Ex : 15, A 33,
> Grand-Est, France
> 
> Le souci c’est que le validateur Josm n’aime pas et ca me met une
> erreur.
> 
> Comme j'ai un copain qui bosse au Samu et qu'ils n'ont pas de carto à
> part G..gle, je me disais que ca pourrait être pas mal qu'il ait accès
> via OSM aux données des PR et à les rechercher comme des "adresses".
> 
> 
> Christian me déconseille cette méthode et propose plutôt dans un
> moindre mal de mettre un name=PR13 A 31 pour que ca ressorte (même si
> on tague pas pour le rendu lol)
> 
> 
> En faisant une requête Overpass, j'ai repéré également d'autres façon
> de faire.
> 
> Ex: mettre la ref de la route en ref alors que par définition le node
> fait partie de la route.
> 
> Autre point, sur les PR, les distances hectométriques sont notées 8.9
> avec un point. Vaut-il mieux mettre un point ou une virgule?
> 
> 
> Vos avis éclairés sur la question avant que tout le monde fasse un
> import automatique (ou pas) de ces données?
> 
> 
> Donat
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] botdidier2020 est mort !

[didier2020]

http://www.openstreetmap.org/changeset/4643

il re-su-sitera peut etre quand il se sera calmé 


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Re : Re: Inondations dans le Centre et fermeture d'autoroutes

[didier2020]

+1

vu que les autoroutiers ne communiquent pas ...
vu qu'il n'y a plus de cricr ...
vu que le site bison est tellement bien fait que meme si on sait qu'une route 
est fermée on ne peut pas voir ou ...

voila (c'était mon moment rougnouf)




- Mail d'origine -
De: Christian Quest 
À: Discussions sur OSM en français 
Envoyé: Wed, 01 Jun 2016 19:57:39 +0200 (CEST)
Objet: Re: [OSM-talk-fr] Inondations dans le Centre et fermeture
d'autoroutes

OSM n'est pas adapté pour ce genre d'info temporaire... c'est plus pour
OpenEventDatabase ;)


Le 1 juin 2016 à 18:50, Yannick  a écrit :

> Le 01/06/2016 17:49, François Lacombe a écrit :
> > -1 pour utiliser access=no.
> > Ce n'est pas parce qu'il y a de l'eau sur le tronçon que la route
> > n'est pas destinée à accueillir la circulation des véhicules.
> >
> > Par contre, utiliser OpenEventDb avec en géométrie le tronçon concerné
> > et les dates issues du communiqué de la préfecture, c'est mieux :)
> > https://github.com/openeventdatabase
> >
> > A+
> > François Lacombe
> >
> > fl dot infosreseaux At gmail dot com
> > www.infos-reseaux.com
> > @InfosReseaux
> >
> >
> > Le 1 juin 2016 à 17:31, Francescu GAROBY  a écrit :
> >> Bonjour,
> >> La préfecture du Loiret vient d'annoncer que l'autoroute A10 restera
> fermé
> >> plusieurs jours, entre Artenay et Tours.
> >> Je me demandais donc si un tel délai était suffisant pour marquer comme
> >> "access=no" le tronçon concerné...
>
>
> Bonsoir,
>
> Pourquoi en complément ne pas ajouter le fait que la route est inondable?
>
> Amitiés
>
> --
> Yannick VOYEAUD
> Nul n'a droit au superflu tant que chacun n'a pas son nécessaire
> (Camille JOUFFRAY 1841-1924, maire de Vienne)
> http://www.voyeaud.org
> Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/
> Journées du Logiciel Libre: http://jdll.org
> Généalogie en liberté avec Ancestris http://www.ancestris.org
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Christian Quest - OpenStreetMap France


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Problème d'accès à FR-BAN et FR-Cadastre !

[didier2020]

Le mardi 24 mai 2016 à 14:55 +0200, Francois Gouget a écrit : 
> Depuis environ 48h iD n'arrive plus à afficher la couche FR-BAN et la 
> couche FR-Cadastre.
> 
> Il semblerait que dans les deux cas ce soit parce que 
> inspire.cadastre.gouv.fr ne répond plus sur le port 80 (pas seulement de 
> mon adresse).
> 
> Quelqu'un sait-il ce qui se passe ?
maintenance :
http://www.cadastre.gouv.fr 
> 
> -- 
> Francois Gouget   http://fgouget.free.fr/
>   Any sufficiently advanced Operating System is indistinguishable from Linux
> ___ Talk-fr mailing list 
> Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Je ne comprends pas ces points ?

[didier2020]

bonsoir,

je n'arrive pas a ouvrir le wiki pour t'indiquer les pages
concernées ...

- le premier point = monument historique (les tags sont différens quand
c'est classé ou inscrit)
http://www.culture.gouv.fr/public/mistral/merimee_fr?ACTION=CHERCHER_1=REF_1=PA6343

- le 2eme point = base des établissements sanitaires et sociaux 
je trouve compliqué de trouver un tag pour ces établissements 
http://finess.sante.gouv.fr/finess/jsp/rechercheSimple.jsp




Le vendredi 13 mai 2016 à 20:13 +0200, Vincent Bergeot a écrit : 
> Bonjour,
> un peu par hasard, je suis tombé sur ce premier point qui m'intrigue :
> http://www.openstreetmap.org/node/3886714389#map=19/45.77735/3.09172
> 
> le point n'est associé à aucun élément tangible, type batiment, 
> l'article dans wikipedia n'existe pas, ...
> On dirait que cela vient d'une liste des bâtiments historiques ?
> 
> Du coup sur la base du contributeur, j'ai vu cela en second et la encore 
> une fois ce n'est associé à aucun bâtiment, la aussi cela semble 
> provenir d'une liste finess ?
> http://www.openstreetmap.org/node/4176821295#map=18/48.80928/2.15700
> 
> Avant de regarder un peu plus, je pars du principe que peut-être qu'il y 
> a quelque chose que je ne comprends pas ?
> 
> Quelques lumières ?
> 
> Bonne soirée
> 
> --
> Vincent Bergeot
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Radar stop

[didier2020]

une piste avec ces trop nombreux tags complémentaires mais qui a la
final ne décrivent pas ton cas ...

camera:mount=pole
camera:type=fixed
man_made=surveillance
surveillance:type=camera
surveillance:zone=trafic
surveillance=outdoor

Le dimanche 03 avril 2016 à 20:20 +0200, Éric Gillet a écrit : 
> 
> 
> Le 3 avril 2016 à 19:15, Philippe Verdy  a écrit :
> En principe les radars automatiques font la même chose, il
> faut aussi un agent assermenté pour valider les
> enregistrements transmis (éliminer aussi les fausses
> détections). 
> 
> 
> J'ai du mal à vérifier si c'est une personne qui rédige le PV, mais
> dans tous les cas la personne ne peut constater l'excès de vitesse et
> ne se base uniquement sur la valeur constatée par le radar. La seule
> validation humaine possible c'est celle de la plaque
> d'immatriculation.
>  
> Qui te dit qu'il n'y a QUE la caméra et aucun capteur de
> franchissement et de vitesse?
> 
> Il y a un capteur, ou au moins de la reconnaissance d'image, c'est
> pour ça que j'ai dit :
> 
> 
> c'est une caméra qui indique à un agent assermenté quand
> regarder plus attentivement l'enregistrement vidéo. 
> 
> 
> Dans le cas de caméra-stop le fait que l'automobiliste ne s'arrête pas
> est constatée par l'agent, contrairement au radar de vitesse où la
> preuve est émise directement par l'appareil.
> 
> 
> Mais oui on est d'accord que ça reste semblable est que la distinction
> est floue, et je ne suis pas contre la création d'une valeur pour le
> tag enforcement=*
> 
> 
> Autre exemple : la vidéo-verbalisation pour le stationnement interdit.
> Le dispositif est-il une caméra d'usage général, également utilisé à
> des fins de répression (enforcement) ? Ou est-ce un appareil dédié à
> la répression ?
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Radar stop

[didier2020]

bonjour,

je n'ai jamais tagué ça mais c'est avec les radar de vitesse :
http://wiki.openstreetmap.org/wiki/FR:Relation:enforcement


Le samedi 02 avril 2016 à 16:36 +0200, olivier delaune a écrit :
> Bonjour,
> 
> depuis le début de l'année, la ville de Yerres, dans l'Essonne, a fait
> installé un radar qui détecte le non-arrêt à un stop
> 
> http://www.leparisien.fr/automobile/securite-routiere/video-securite-routiere-le-premier-radar-de-stop-teste-dans-l-essonne-20-02-2016-5563595.php
> 
> D'après l'article ci-dessus, le radar semble se trouver au croisement
> de la rue Marc Sangnier et de la rue de l'Abbé Moreau
> (https://www.openstreetmap.org/query?lat=48.71538=2.49038)
> 
> Comment taggue-t-on ce genre de radar ?
> 
> Merci d'avance
> 
> Olivier
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [talk-ph] Massive deletion of nodes?

[didier2020]

Le jeudi 25 février 2016 à 02:36 +0800, Eugene Alvin Villar a écrit : 
> Hello didier,
> 
> 
> Thank you for the explanation, and for the clean-up!
> 
> 
> I know about Osmose and I know that it already covered the Philippines
> since late 2013 (after Typhoon Haiyan). You said you used your own
> Osmose tool? Is there anything there that is not covered by the main
> Osmose instance?
> 
not really, osmose-backend find issues, the front-end show them.
I use the tool to facilitate my corrections (list of ways, area, detect
changesets...)

> 
> ~Eugene
> 
> 
> On Tue, Feb 23, 2016 at 2:10 AM, didier2020 <didier2...@free.fr>
> wrote:
> hello,
> 
> a small présentation :
> botdidier2020 is not a bot, it's me.
> 
> You may know osmose
> (http://wiki.openstreetmap.org/wiki/Osmose)
> which is a quality tool for reporting issues.
> 
> in this time i use a personal osmose tool on country wich are
> not
> covered by osmose
> 
> (http://osmose.openstreetmap.fr/fr/map/#zoom=2=44.2=10.3=Mapnik=FFTFT)
> after i try  to fix Duplicated geometry and tags
> - multiple way with same geometry and same tags or tags of one
> in the
> other
> - mutiple node with the same geometry
> and orphaned node if the node is older than month
> it's now done.
> 
> reponse to the discussion of this changeset
> http://www.openstreetmap.org/changeset/37317639
> 
> - Earlier, i tell to users the errors, but i had only a very
> very few
> responded. So ...
> - For the deleted nodes : the user who create the node
> (without way) and
> no changeset since months is
> https://www.openstreetmap.org/user/cyril_mac/history
> 
> I hope I answered your questions
> 
> didier 
> 
> 
> ___
> talk-ph mailing list
> talk-ph@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ph
> 
> 
> 



___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

Re: [talk-ph] Massive deletion of nodes?

[didier2020]

hello, 

a small présentation :
botdidier2020 is not a bot, it's me.

You may know osmose (http://wiki.openstreetmap.org/wiki/Osmose)
which is a quality tool for reporting issues.

in this time i use a personal osmose tool on country wich are not
covered by osmose 
(http://osmose.openstreetmap.fr/fr/map/#zoom=2=44.2=10.3=Mapnik=FFTFT)
after i try  to fix Duplicated geometry and tags
- multiple way with same geometry and same tags or tags of one in the
other
- mutiple node with the same geometry 
and orphaned node if the node is older than month 
it's now done.

reponse to the discussion of this changeset
http://www.openstreetmap.org/changeset/37317639

- Earlier, i tell to users the errors, but i had only a very very few
responded. So ...
- For the deleted nodes : the user who create the node (without way) and
no changeset since months is
https://www.openstreetmap.org/user/cyril_mac/history

I hope I answered your questions

didier


___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

[talk-ph] Massive deletion of nodes?

[didier2020]

hello, 

a small présentation :
botdidier2020 is not a bot, it's me.

You may know osmose (http://wiki.openstreetmap.org/wiki/Osmose)
which is a quality tool for reporting issues.

in this time i use a personal osmose tool on country wich are not
covered by osmose 
(http://osmose.openstreetmap.fr/fr/map/#zoom=2=44.2=10.3=Mapnik=FFTFT)
after i try  to fix Duplicated geometry and tags
- multiple way with same geometry and same tags or tags of one in the
other
- mutiple node with the same geometry 
and orphaned node if the node is older than month 
it's now done.

reponse to the discussion of this changeset
http://www.openstreetmap.org/changeset/37317639

- Earlier, i tell to users the errors, but i had only a very very few
responded. So ...
- For the deleted nodes : the user who create the node (without way) and
no changeset since months is
https://www.openstreetmap.org/user/cyril_mac/history

I hope I answered your questions

didier


___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

[OSM-talk-fr] JOSM et Opendata

[didier2020]

est-ce lié au fait que les liens de
http://wiki.openstreetmap.org/wiki/WikiProject_France/data.gouv.fr

ne sont plus valides ?






___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Dispositif d'enquête photo DIY

[didier2020]

Le dimanche 31 janvier 2016 à 21:45 +0100, Vincent de Château-Thierry a
écrit : 
> Le 31/01/2016 14:15, Jean-Michel Pouré a écrit :
> >
> > J'ai testé le roaming avec mon smartphone et la géolocalisation de
> > photos. Cela fonctionne bien ... mais je trouve cela un peu dangereux :
> > conduire et tenir l'appareil à la main.
http://joby.com/action-series/suction-cup-arm

ok pour les fenetres , pour le parebrise la longueur peut etre un
probleme (depend de l'inclinaison du parebrise)

> >
> > J'imagine un mécanisme reposant sur un simple téléphone mobile pour la
> > géolocalisation et le routage, qui lance des commandes MTP à trois
> > téléphones mobiles (frontal, gauche, droit). Ce qui pourrait faire
> > l'objet d'un plugin OSMand. Avec un petit clavier déporté, on pourrait
> > imaginer de déclencher la prise de vue en rafale ou à l'unité.
> >
> > Avez connaissance d'un mécanisme similaire développé par des
> > utilisateurs OSM ?
> 
> Connais-tu Mapillary ? Sinon ça mérite que tu y jettes un œil :
> http://wiki.openstreetmap.org/wiki/FR:Mapillary
> et
> http://www.mapillary.com/
> 
> vincent
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Petite question

[didier2020]

en complément il y a le plugin "turnrestrictions" de josm qui permet de
créer et afficher les interdictions ou obligations

Le mardi 19 janvier 2016 à 12:06 +0100, lenny.libre a écrit :
> Bonjour
> explique ce qui n'est pas clair (quel éditeur utilises-tu pour tes
> contributions ?.
> voici un exemple : http://www.openstreetmap.org/relation/2648441
> tu es sur le chemin "Route de Grenade", il a le rôle "from"
> tu arrive sur le noeud, il a le rôle "via"
> tu ne peux pas tourner à gauche sur la "Rue de la Marquette" qui a le
> rôle "to"
> 
> cordialement
> Lenny
> 
> 
> 
> 
> Le 19/01/2016 10:53, Ludovic Hirlimann a écrit :
> 
> > On 19/01/2016 09:47, Francescu GAROBY wrote:
> > 
> > > Bonjour,
> > > 
> > > Dans ce cas, il faut utiliser une relation "restriction", avec les
> > > tags suivants :
> > > 
> > > * type=restriction
> > > 
> > > * restriction=no_left_turn
> > > 
> > > 
> > > Et lui inclure les 3 membres suivants :
> > > * from : le tronçon au sud du croisement de la d820 (il faudra
> > > donc couper la voie au niveau du point servant d'intersection)
> > > 
> > > * via : le node de l'intersection
> > > 
> > > * to : la voie "Grand'Rue" 
> > Cette partie n'est pas clair pas plus que sur le wiki après une
> > première lecture.
> > 
> > Ludo
> > 
> > 
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] (sans objet)

[didier2020]

c'est dans le wiki (kidiwikidivrai?)
http://wiki.openstreetmap.org/wiki/FR:Key:turn
mais peu utilisé:
http://taginfo.openstreetmap.fr/keys/turn#overview

le modele d'attribut dans josm n'aide pas ...
donc je n'ai pas utilisé



Le samedi 16 janvier 2016 à 11:30 +0100, Laurent Combe a écrit : 
> Bonjour,
> 
> 
> suite a un message de julien thevenon (le 20 nov) sur cette liste,
> j'ai essayé magic earth (logiciel de navigation routière sur android
> qui utilise les données OSM)
> 
> effectivement l'appli mérite d'être connue
> 
> 
> 
> du coup, je me suis interessé à l'aide directionnelle que le logiciel
> peut donner à l'approche d'un carrefour
> 
> il y a les tags
> 
> lanes
> 
> direction
> ...
> 
> et continuant à chercher
> 
> je suis tombé sur ça :
> https://www.mapbox.com/blog/turn-lanes-mapping/
> 
> 
> avec un mode opératoire bien détaillé
> 
> 
> ma question c'est du spécifique mapbox où la méthodo proposée est
> acceptable ?
> 
> je pose la question avant que j'en mette un peu partout sur les
> intersections de mon secteur
> 
> 
> je suis preneur de vos avis.
> 
> 
> Laurent
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Recherche de formation en Python

[didier2020]

et commencer par l'achat d'un livre ?
dans ce cas je te conseille :
http://www.editions-ellipses.fr/product_info.php?products_id=6891

ensuite tu peu regarder ca
http://www.geoinformations.developpement-durable.gouv.fr/qgis-le-coin-des-developpeurs-r727.html


Le jeudi 07 janvier 2016 à 00:57 -0700, Tony Emery a écrit : 
> Bonjour à tous,
> 
> Je cherche à me former aux rudiments de Python dans le cadre professionnel.
> 
> Je recherche donc un organisme de formation pour cela et pas trop cher.
> 
> L'orientation de la formation est essentiellement SIG et OpenStreetMap mais
> si on peut aussi faire du web, je prends...
> 
> Voilà, si vous connaissez un organisme (ou que vous êtes formateur), merci
> de me contacter.
> 
> Je peux envisager une formation sur Paris ou sur Montpellier si l'organisme
> ne peut pas se déplacer chez nous (Avignon).
> 
> Merci d'avance
> 
> 
> 
> -
> Tony EMERY
> Administrateur OpenStreetMap.fr
> Mandataire Grand Sud-Est
> Géomaticien & chef de projets
> --
> View this message in context: 
> http://gis.19327.n5.nabble.com/Recherche-de-formation-en-Python-tp5864169.html
> Sent from the France mailing list archive at Nabble.com.
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Communes nouvelles - fusion de communes

[didier2020]

un peu en dehors du sujet :
le suivi des communes n'est plus accessible
http://suivi.openstreetmap.fr/communes/


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Géo-référencement images aérienne

[didier2020]

si qgis est tres lent avec un wms chargé,
c'est qu'il transforme les images pour etre "déformées" dans la
projection de ton projet.

http://sigea.educagri.fr/fileadmin/user_upload/public/Ressources_pedagogiques/WMS/SIGEA_connection_qgis_wms.pdf
ce document te fournira le pourquoi et comment



Le dimanche 13 décembre 2015 à 19:30 +0100, Jean-Claude Repetto a
écrit : 
> Le 13/12/2015 18:50, Stéphane Péneau a écrit :
> >
> >
> > Tiens, je me rends compte que j'ai un problème de projection, l'imagerie
> > me fait des cisaillements. Bizarre, je suis bien en pseudo mercator
> > 3857, comme dans Josm.
> >
> 
> Tu as défini la projection de ton projet, de la couche, ou les deux ?
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

[didier2020]

j'ai vu ca mais 
http://www.ardennes.gouv.fr/IMG/pdf/RAA_no_50_du_17_septembre_2015_cle717d42.pdf
http://www.openstreetmap.org/relation/5710693

mais pas trouvé de lien légifrance ...



Le samedi 12 décembre 2015 à 09:45 +0100, Damouns a écrit : 
> Bonjour à tous,
> 
> 
> Comme l'année dernière je vous propose de rassembler les infos sur les
> communes nouvelles issues de fusion de communes en France sur cette
> page :
> 
> http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives/Modifications_planifi%C3%A9es
>  (avant la partie "historique" de fin 2014...)
> 
> 
> Pour rappel les communes supprimées gardent en fait un certain statut
> ce qui se traduit par passer en admin_level=10 leurs limites et leur
> relation (certains penchent plutôt pour un admin_level=9 mais si un
> consensus est trouvé on pourra toujours les basculer).
> 
> 
> Pour l'instant je n'ai vu passer aucun arrêté mais tout porte à croire
> que cette année nous aurons un nombre record de fusions de communes
> dans toute la France. Le travail sera donc conséquent !
> 
> 
> Merci de noter dans la page du wiki si vous vous chargez d'une commune
> nouvelle.
> 
> 
> Damouns
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Cadastre indispo?

[didier2020]

josm 8989:
- le plugin cadastre est ok
- le wms (ou l'on doit saisir le code insee de la commune) est ok 
wms:http://inspire.cadastre.gouv.fr/scpc/15028.wms?service=WMS=GetMap=1.3={proj}={width}={height}={bbox}=BU.Building,AMORCES_CAD,CP.CadastralParcel,HYDRO,BORNE_REPERE,DETAIL_TOPO,LIEUDIT,VOiE_COMMUNICATION==image/png

par contre le cadastre ne fonctionne plus
tms:http://tms.cadastre.openstreetmap.fr/*/tout/{z}/{x}/{y}.png 



Le vendredi 13 novembre 2015 à 19:17 +0100, Jérôme Seigneuret a écrit : 
> Salut, J'ai le même problème sous JOSM
> 
> 
> Jérôme
> 
> Le 13 novembre 2015 14:01, pepilepi...@ovh.fr  a
> écrit :
> Le 13/11/2015 12:34, Donat ROBAUX a écrit :
> 
> > Bonjour,
> > 
> > 
> > J'ai l'impression que la couche cadastre est indispo.
> > 
> > Quelqu'un pour vérifier?
> > 
> > 
> > 
> > Donat
> > 
> 
> En effet, [14:00] j'ai aussi "Error : problem loading tile"...
> 
> JP
> 
> > 
> > 
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] le rendu ca va, mais quand on édite la zone ...

[didier2020]

il faut juste editer 
http://www.openstreetmap.org/#map=18/44.05847/0.96871

validation josm, on ne sait pas par ou commencer !


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Base de données "vitesse maximale" pour la France

[didier2020]

Le mardi 06 octobre 2015 à 08:08 +0200, Nicolas Dumoulin a écrit : 
> Le lundi 5 octobre 2015 22:33:42 willemijns a écrit :
> > hello
> > 
> > oui il faudra voir si la base de donnees sera en GPX ou en nom officiel de
> > rue... ne pas oublier les vitesses différentes selon le sens de
> > circulation
> 
> En fait, je fais plus confiance à des projets comme Mapillary ou @OSMThis. 
> Bref, je suis d'accord avec Christian, dans 2 ans, on fera le bilan des 
> vitesses dans OSM et du projet de l'État. À moins, que les forces (vives) de 
> l'État se joignent à OSM … en mode agile comme tu dis.
le droit de réserve m'interdit des commentaires désobligeants
force, ce sont des groupes de gens
vives, oui ils sont vivant
agile, euh ... un nouveau mot ?


> D'ici deux ans j'y crois pas, mais on peut rêver
> 



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Test carte Police/Justice...

[didier2020]

404, 403 ... moi j'ai une bx 

... désolé ...

Le dimanche 30 août 2015 à 11:06 +0200, osm.sanspourr...@spamgourmet.com
a écrit :
 Tu veux dire 403 je suppose.
 Actuellement j'ai un 403 (ça marchait l'autre jour).
 
 N. B. : pour les POI, Guilhem avait bien précisé ni iOS ni Android.
 
 Jean-Yvon
 
 Le 30/08/2015 09:18, dHuy Pierre - dh...@yahoo.fr a écrit :
 
  @Cquest: Ton lien me renvoie un beau 404, suis je seul dans ce cas? 
  
  
  
  
  
  Le Jeudi 20 août 2015 21h26, Christian Quest
  cqu...@openstreetmap.fr a écrit :
  
  
  
  Des morceaux d'OSM dedans... essentiellement les contours de
  communes
  utilisés pour recréer les limites des TGI et des zones
  Police/Gendarmerie, le reste c'est 4 jeux de données opendata dispo
  sur
  data.gouv.fr
  
  https://www.data.gouv.fr/fr/reuses/carte-des-ressorts-des-tgi/
  
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] sytadin utilise osm

[didier2020]

c'est en cours suite a 2 coupure d'axe importantes :

http://www.sytadin.fr/sys/alert_reseau.jsp.html

merci a
- osrm pour les traces gpx générées
- umap pour la création rapide des cartes
- openstreetmap pour les données



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Re : Re: Localisation photo, et corrélation gpx

[didier2020]

tu m'envoies un fichier nom photo, date time
(j'utiliserais un tableur pour gérer ça)
pour créér une liste de commande exiftool 


- Mail d'origine -
De: Stéphane Péneau stephane.pen...@wanadoo.fr
À: talk-fr@openstreetmap.org
Envoyé: Thu, 27 Aug 2015 12:31:31 +0200 (CEST)
Objet: Re: [OSM-talk-fr] Localisation photo, et corrélation gpx

Le 27/08/2015 12:08, didier2020 a écrit :
 je n'ai pas tout saisi ...
 si tu as des photos en double,
 elles sont numérotées, un nom différent ou ...

Elles ne sont pas en double, et je ne souhaite pas en supprimer une partie.
Oui, elles ont des noms différents, mais les algo de géolocalisation 
depuis une trace gpx se basent sur l'heure de la prise de vue.
Comme le tag exif DateTimeOriginal (ou CreateDate) est limité à une 
précision à la seconde, plusieurs photos (2 ou 3) comportent la même info.
Du coup, lorsque je veux geotagger ces photos, comme elles ont la même 
heure, elles se retrouvent placées à la même position alors qu'il y a eu 
un déplacement entre temps.

Tu vois mieux le problème ?

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Re : sytadin utilise osm

[didier2020]

il faut cliquer sur les liens nommés itinéraire ...

- Mail d'origine -
De: didier2...@free.fr
À: talk-fr@openstreetmap.org
Envoyé: Thu, 27 Aug 2015 17:17:13 +0200 (CEST)
Objet: [OSM-talk-fr] sytadin utilise osm

c'est en cours suite a 2 coupure d'axe importantes :

http://www.sytadin.fr/sys/alert_reseau.jsp.html

merci a
- osrm pour les traces gpx générées
- umap pour la création rapide des cartes
- openstreetmap pour les données



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Re : Re: Localisation photo, et corrélation gpx

[didier2020]

commande pour extraire les coordonnées

exiftool -filename -GPSLongitude -GPSLatitude -DateTimeOriginal
-subsectimeoriginal -n -T *.jpg  liste.csv

ci-joint le fichier openoffice pour generer les commandes

il suffit juste de copier la colonne des commandes dans un editeur de
texte
puis enregistrer dans un fichier a lancer 



Le jeudi 27 août 2015 à 19:50 +0200, Stéphane Péneau a écrit : 
 Tu peux faire ça ?
 Je pourrai le reproduire ensuite ?
 
 Je t'envoie le fichier en privé, la pièce jointe ne passera pas sur la 
 liste.
 
 Stf
 
 Le 27/08/2015 17:19, didier2...@free.fr a écrit :
  tu m'envoies un fichier nom photo, date time
  (j'utiliserais un tableur pour gérer ça)
  pour créér une liste de commande exiftool
 
 
  - Mail d'origine -
  De: Stéphane Péneau stephane.pen...@wanadoo.fr
  À: talk-fr@openstreetmap.org
  Envoyé: Thu, 27 Aug 2015 12:31:31 +0200 (CEST)
  Objet: Re: [OSM-talk-fr] Localisation photo, et corrélation gpx
 
  Le 27/08/2015 12:08, didier2020 a écrit :
  je n'ai pas tout saisi ...
  si tu as des photos en double,
  elles sont numérotées, un nom différent ou ...
 
  Elles ne sont pas en double, et je ne souhaite pas en supprimer une partie.
  Oui, elles ont des noms différents, mais les algo de géolocalisation
  depuis une trace gpx se basent sur l'heure de la prise de vue.
  Comme le tag exif DateTimeOriginal (ou CreateDate) est limité à une
  précision à la seconde, plusieurs photos (2 ou 3) comportent la même info.
  Du coup, lorsque je veux geotagger ces photos, comme elles ont la même
  heure, elles se retrouvent placées à la même position alors qu'il y a eu
  un déplacement entre temps.
 
  Tu vois mieux le problème ?
 
  ___
  Talk-fr mailing list
  Talk-fr@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/talk-fr
 
 
  ___
  Talk-fr mailing list
  Talk-fr@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/talk-fr
 
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



liste.ods
Description: application/vnd.oasis.opendocument.spreadsheet
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Localisation photo, et corrélation gpx

[didier2020]

je n'ai pas tout saisi ...
si tu as des photos en double,
elles sont numérotées, un nom différent ou ...


Le jeudi 27 août 2015 à 11:58 +0200, Stéphane Péneau a écrit : 
 Le 27/08/2015 11:32, didier2020 a écrit :
  tu as regardé les données exif des photo ?
  http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/EXIF.html
  il y a peut etre un tag qui permet de les différencier ...
 
 Oui, j'ai regardé, mais il n'y a absolument aucune différence utile.
 La seule solution que je vois, c'est un outil qui regarderait les photos 
 avec des heures de prise de vue identique, et qui ferait une 
 interpolation pour créer le tag subsectimeoriginal
 
 Par exemple :
 
 Photo1 : 8h15mn21s
 Photo2 : 8h15mn21s
 Photo3 : 8h15mn22s
 
 deviendraient :
 
 Photo1 : 8h15mn21s + tag subsectimeoriginal=000
 Photo2 : 8h15mn21s + tag subsectimeoriginal=500
 Photo3 : 8h15mn22s + tag subsectimeoriginal=000
 
 Mais c'est au-delà de mes capacités.
 
 Ensuite, restera à trouver un algo de création des geotags exif qui en 
 tienne compte.
 
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Localisation photo, et corrélation gpx

[didier2020]

tu as regardé les données exif des photo ?
http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/EXIF.html
il y a peut etre un tag qui permet de les différencier ...

Le jeudi 27 août 2015 à 10:02 +0200, Stéphane Péneau a écrit : 
 J'ai réussi à horodater un gpx que j'ai construit depuis les routes
 d'Osm à l'aide de ce site :
 http://gotoes.org/strava/Add_Timestamps_To_GPX.php
 
 Malheureusement, à cause des variations de vitesse, il faut quand même
 recaler la majorité des photos à la main, ce qui est particulièrement
 fastidieux. J'en ai fait une partie mais ça m'étonnerait que j'arrive
 au bout.
 
 En revanche, pour écrire dans les photos, l'information de direction
 depuis le gpx, j'ai réussi. J'ai tout simplement utilisé le script
 python interpolate_direction proposé par Mapillary :
 https://github.com/mapillary/mapillary_tools/tree/master/python
 Il faut toujours corriger certaines images, mais on peut le faire
 directement dans Josm à l'aide du plugin Photoadjust, et on repère
 vite les endroits à problème : Les changements brutaux de direction
 (carrefour, etc..)
 
 Il me reste à trouver une solution pour mes photos prises toutes les
 0.5 seconde.
 
 Stf
 
 
 Le 18/08/2015 22:17, Jo a écrit :
 
  Le plugin de Mapillary est capable d'aider à améliorer les positions
  et les directions boussole. Malheureusement c'est à la main et ça
  devient fastidieux si c'est pour des milliers de photos. Il est
  également capable d'envoyer les photos vers le serveur directement,
  dès à présent.
  
  
  (je teste la version développement, je ne suis pas complètement sûr
  quelles sont les possibilités de la version qui vient
  automatiquement avec JOSM)
  
  
  Polyglot
  
  
  2015-08-18 12:21 GMT+02:00 Stéphane Péneau
  stephane.pen...@wanadoo.fr:
  Le 18/08/2015 11:18, Nicolas Dumoulin a écrit :
  Le mardi 18 août 2015 10:31:00 Stéphane Péneau a
  écrit :
  Hello tout le monde,
  
  Pendant les vacances, j'ai commencé à tester
  une petite action cam type
  Gopro, la Xiaomi Yi, qui se vend dans les 70
  €.
  Je l'ai surtout utilisée en mode time
  lapse pour prendre des photos en
  voiture.
  Ok, et ça donne quoi comme qualité ?
  
  C'est pas mal du tout, l'optique est de qualité, mais le
  software pêche un peu pour le moment.
  Le firmware évolue régulièrement, et une communauté commence
  à la bidouiller dans tous les sens.
  Je reviendrai plus en détail sur ces points forts/faibles un
  peu plus tard.
  
  Je l'ai fixée via un système Ram-mount que j'avais déjà,
  j'ai juste ajouté l'adaptateur qui va bien (filetage type
  appareil photo).
  Là je pars l'essayer à vélo, montée sur un système
  d'amortisseur à câble prévu à l'origine pour mon smartphone,
  pour diminuer les vibrations.
  Ça me paraît franchement hasardeux :-/
  Tu penses considérer que tu avais une vitesse
  constante entre le départ et
  l'arrivée et utilisée la route empruntée comme
  support ?
  Remarque, ça se tente :-)
  Tu peux peut-être faire un gpx avec l'itinéraire
  emprunté et ensuite ajouter
  avec un script l'horodatage par incrément dans le
  gpx …
  Non, bien sûr que ce n'est pas une vitesse stable, ce serait
  trop facile :-)
  Disons que si je pouvais déjà les fixer sur un trajet,
  puis les faire glisser dessus, je pense que je pourrais m'en
  sortir, mais je ne sais pas du tout si ce genre d'outil
  existe.
  
  
  Stf 
  
  
  
  ___
  Talk-fr mailing list
  Talk-fr@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/talk-fr
  
  
  
  
  
  ___
  Talk-fr mailing list
  Talk-fr@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/talk-fr
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Re : Re: Localisation photo, et corrélation gpx

[didier2020]

il y a gpxpy (bibliotheque python) qui permets de faire ça


- Mail d'origine -
De: Stéphane Péneau stephane.pen...@wanadoo.fr
À: Discussions sur OSM en français talk-fr@openstreetmap.org
Envoyé: Tue, 18 Aug 2015 12:21:28 +0200 (CEST)
Objet: Re: [OSM-talk-fr] Localisation photo, et corrélation gpx

Le 18/08/2015 11:18, Nicolas Dumoulin a écrit :
 Le mardi 18 août 2015 10:31:00 Stéphane Péneau a écrit :
 Hello tout le monde,

 Pendant les vacances, j'ai commencé à tester une petite action cam type
 Gopro, la Xiaomi Yi, qui se vend dans les 70€.
 Je l'ai surtout utilisée en mode time lapse pour prendre des photos en
 voiture.
 Ok, et ça donne quoi comme qualité ?

C'est pas mal du tout, l'optique est de qualité, mais le software pêche 
un peu pour le moment.
Le firmware évolue régulièrement, et une communauté commence à la 
bidouiller dans tous les sens.
Je reviendrai plus en détail sur ces points forts/faibles un peu plus tard.

Je l'ai fixée via un système Ram-mount que j'avais déjà, j'ai juste 
ajouté l'adaptateur qui va bien (filetage type appareil photo).
Là je pars l'essayer à vélo, montée sur un système d'amortisseur à câble 
prévu à l'origine pour mon smartphone, pour diminuer les vibrations.
 Ça me paraît franchement hasardeux :-/
 Tu penses considérer que tu avais une vitesse constante entre le départ et
 l'arrivée et utilisée la route empruntée comme support ?
 Remarque, ça se tente :-)
 Tu peux peut-être faire un gpx avec l'itinéraire emprunté et ensuite ajouter
 avec un script l'horodatage par incrément dans le gpx …
Non, bien sûr que ce n'est pas une vitesse stable, ce serait trop facile :-)
Disons que si je pouvais déjà les fixer sur un trajet, puis les faire 
glisser dessus, je pense que je pourrais m'en sortir, mais je ne sais 
pas du tout si ce genre d'outil existe.



Stf


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] osmose: analyse croisement BANO/OSM à tester...

[didier2020]

cool ! 
j'en profite pour te remercier de ces dernieres idees qui sont une aide
précieuse pour les ajouts/corrections

Le samedi 15 août 2015 à 13:23 +0200, Christian Quest a écrit : 
 Effectivement, le '.' n'était pas bien pris en compte dans la
 comparaison OSM/Route500.
 C'est corrigé.
 
 
 Le 14 août 2015 07:11, didier2020 didier2...@free.fr a écrit :
 slt,
 
 je pense qu'il y a une amélioration a faire sur les route avec
 indice
 comme ici :
 
 http://osmose.openstreetmap.fr/fr/map/#zoom=16lat=48.35267lon=1.30634item=7170
 
 osm vs route500
 D 129.3 vs D129.3 
 
 
 Le mercredi 05 août 2015 à 14:16 +0200, Christian Quest a
 écrit :
  Le 05/08/2015 11:33, Yves Pratter a écrit :
Pour l'instant c'est en test uniquement sur le serveur
 dev
d'osmose, il est préférable d'avoir vos retours avant de
 mettre ça
sur l'instance de prod, donc c'est ici:
   
   
 http://dev.osmose.openstreetmap.fr/fr/map/#item=7170class=33
(voies à tracer)
   
   Nickel pour les quelques cas que j’ai regardé :
 lotissement en
   construction ou rues bien visibles sur Bing :)
  
   
 http://dev.osmose.openstreetmap.fr/fr/map/#item=7170class=32
(name à ajouter)
   
   Correct. La puce n’est pas exactement sur le tracé de la
 route…
  
  
   et surtout il y a des rues aux alentours sans noms et sans
 retour de
   la part d’Osmose :
  
 
 http://dev.osmose.openstreetmap.fr/fr/map/#item=7170class=32zoom=17lat=46.940308lon=6.03245layer=Mapnik-osmfroverlays=FFFT
  
  
  
  
 
  Oui, l'analyse pêche par excès de prudence ;)
 
  Souvent quand un manque est signalé il y a du grain à moudre
 sur la
  zone...
 
 
   
 http://dev.osmose.openstreetmap.fr/fr/map/#item=7170class=31
(name à modifier)
   
   Semble correct. Idem pour la puce
  
   
 http://dev.osmose.openstreetmap.fr/fr/map/#item=7170class=30
 (cas
ambigus)
   
   Là c’est plus problématique. Il en sort pleins (peut-être
 celles qui
   manques pour « name à ajouter » ?)
  
  
   Beaucoup ? de faux positifs :
  
 
 http://dev.osmose.openstreetmap.fr/fr/map/#item=7170class=30zoom=17lat=46.914597lon=6.30978layer=Mapnikoverlays=FFFT
   Ici une rue est correctement nommée, l’autre est à
 corriger (Rue du
   Tilleul à la place de Rue des Tilleuls »)
 
  Bien sûr la limite ce sont les noms récupérées par les
 scripts BANO
  sur le cadastre... si ils sont incorrects, osmose va
 proposer une
  correction qui n'a pas lieu d'être.
 
  L'analyse tient compte des signalements faits sur
  http://cadastre.openstreetmap.fr/fantoir/
  Les voies où l'on a indiqué un problème sont éliminées de
 l'analyse.
 
  
  
  
 
 http://dev.osmose.openstreetmap.fr/fr/map/#item=7170class=30zoom=16lat=46.9126lon=6.3407layer=Mapnikoverlays=FFFT
   Rue Branly proposé à la place de Rue Édouard Branly,
 idem pour
   Eiffel, Mermoz… Propose « Rue Edgard Fauré » avé
 l’assent ;-)
   …
  
  
 
  Pareil... à signaler sur
 http://cadastre.openstreetmap.fr/fantoir/
 
  L'analyse pourrait aussi proposer l'ajout du ref:FR:FANTOIR
 plutôt que
  de juste proposer de changer le name=*. C'est un moyen
 d'indiquer que
  c'est la bonne voie (BANO pourra faire son rapprochement)
 même si le
  libellé ne correspond pas (et donc que c'est une erreur dans
 FANTOIR).
  Je vais voir pour ajouter ça dans les cas de noms
 divergents.
 
  --
  Christian Quest - OpenStreetMap France
 
  ___
  Talk-fr mailing list
  Talk-fr@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/talk-fr
 
 
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr
 
 
 
 
 -- 
 Christian Quest - OpenStreetMap France
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr

Re: [OSM-talk-fr] osmose: analyse croisement BANO/OSM à tester...

[didier2020]

slt,

je pense qu'il y a une amélioration a faire sur les route avec indice
comme ici :
http://osmose.openstreetmap.fr/fr/map/#zoom=16lat=48.35267lon=1.30634item=7170

osm vs route500 
D 129.3 vs D129.3


Le mercredi 05 août 2015 à 14:16 +0200, Christian Quest a écrit :
 Le 05/08/2015 11:33, Yves Pratter a écrit :
   Pour l'instant c'est en test uniquement sur le serveur dev
   d'osmose, il est préférable d'avoir vos retours avant de mettre ça
   sur l'instance de prod, donc c'est ici:
   
   http://dev.osmose.openstreetmap.fr/fr/map/#item=7170class=33
   (voies à tracer)
   
  Nickel pour les quelques cas que j’ai regardé : lotissement en
  construction ou rues bien visibles sur Bing :) 
  
   http://dev.osmose.openstreetmap.fr/fr/map/#item=7170class=32
   (name à ajouter)
   
  Correct. La puce n’est pas exactement sur le tracé de la route… 
  
  
  et surtout il y a des rues aux alentours sans noms et sans retour de
  la part d’Osmose : 
  http://dev.osmose.openstreetmap.fr/fr/map/#item=7170class=32zoom=17lat=46.940308lon=6.03245layer=Mapnik-osmfroverlays=FFFT
   
  
  
  
  
 
 Oui, l'analyse pêche par excès de prudence ;)
 
 Souvent quand un manque est signalé il y a du grain à moudre sur la
 zone...
 
 
   http://dev.osmose.openstreetmap.fr/fr/map/#item=7170class=31
   (name à modifier)
   
  Semble correct. Idem pour la puce 
  
   http://dev.osmose.openstreetmap.fr/fr/map/#item=7170class=30 (cas
   ambigus)
   
  Là c’est plus problématique. Il en sort pleins (peut-être celles qui
  manques pour « name à ajouter » ?) 
  
  
  Beaucoup ? de faux positifs : 
  http://dev.osmose.openstreetmap.fr/fr/map/#item=7170class=30zoom=17lat=46.914597lon=6.30978layer=Mapnikoverlays=FFFT
   
  Ici une rue est correctement nommée, l’autre est à corriger (Rue du
  Tilleul à la place de Rue des Tilleuls ») 
 
 Bien sûr la limite ce sont les noms récupérées par les scripts BANO
 sur le cadastre... si ils sont incorrects, osmose va proposer une
 correction qui n'a pas lieu d'être.
 
 L'analyse tient compte des signalements faits sur
 http://cadastre.openstreetmap.fr/fantoir/
 Les voies où l'on a indiqué un problème sont éliminées de l'analyse.
 
  
  
  http://dev.osmose.openstreetmap.fr/fr/map/#item=7170class=30zoom=16lat=46.9126lon=6.3407layer=Mapnikoverlays=FFFT
   
  Rue Branly proposé à la place de Rue Édouard Branly, idem pour
  Eiffel, Mermoz… Propose « Rue Edgard Fauré » avé l’assent ;-) 
  … 
  
  
 
 Pareil... à signaler sur http://cadastre.openstreetmap.fr/fantoir/
 
 L'analyse pourrait aussi proposer l'ajout du ref:FR:FANTOIR plutôt que
 de juste proposer de changer le name=*. C'est un moyen d'indiquer que
 c'est la bonne voie (BANO pourra faire son rapprochement) même si le
 libellé ne correspond pas (et donc que c'est une erreur dans FANTOIR).
 Je vais voir pour ajouter ça dans les cas de noms divergents.
 
 -- 
 Christian Quest - OpenStreetMap France
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] osmose: analyse croisement BANO/OSM à tester...

[didier2020]

Le dimanche 09 août 2015 à 10:37 +0200, DH a écrit : 
 Le 08/08/2015 17:50, Christian Quest a écrit :
 
  ... 
  
  
  
  
  Le wiki est il me semble clair, les name et ref sont bien à mettre
  sur les way de voirie, pas sur les relations qui établissent le lien
  adresse/voie.
  
  
  
 Oui mais, dans JOSM, quand tu as une liste de 70 relations
 associatedStreet, c'est quand même bien pratique quand elles portent
 chacune un nom différent. C'est déjà assez pénible de vérifier qu'on
 est bien sur la Rue du Stade| de l'Église|de la Mairie du bon patelin
 (quelle imagination ces maires) quand on a chargé une zone à cheval
 sur plusieurs communes.
 Donc mes associatedStreet ont chacune leur nom, en plus de celle de
 la voie.
http://wiki.openstreetmap.org/wiki/FR:Num%C3%
A9rotation_des_rues#Cas_:_relations_.28facile_pour_les_ordinateurs.2C_difficile_pour_les_humains.29
c'est même recommandé d'après cette page de wiki ...
 
 Denis 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Recyclage du rendu QA dans osmose: les carreaux INSEE

[didier2020]

c'est parfais tout ça !

il ne manque plus que la mise a jour d'osmose pout l'utilisation dans
josm :
http://wiki.openstreetmap.org/wiki/Quality_Assurance_Tools_script/Installation


Le lundi 27 juillet 2015 à 23:02 +0200, Christian Quest a écrit : 
 L'item 7170 regroupe désormais 2 analyses:
 - celle se basant sur les carreaux INSEE
 - une nouvelle se basant sur Route500 pour détecter les ref=* manquants
 ou incorrects (voire carrément pas de route tracée)
 
 L'analyse fonctionne de la manière suivante:
 - extraction des sommets des linéaires du Route500 comportant un numéro
 de route (nos ref=*)
 - recherche dans OSM aux alentours (200m environ actuellement) d'un
 highway=* avec un ref=* ou old_ref=* correspondant
 si on ne trouve pas, ça remonte une erreur dans osmose pour le sommet en
 question.
 
 Le old_ref permet de limiter les faux-positifs sur les routes qui ont
 changé de numéro depuis 2012 (Route500 date de 2012 et n'a jamais été
 mis à jour par l'IGN depuis sa mise en opendata ce qui est bien dommage).
 
 Hier, la première analyse a eu un problème de mise à jour et avait du
 coup disparue... mais c'est revenu ce soir après correction d'un bug
 dans osmose.
 
 J'ai terminé l'Yonne assez rapidement à l'aide de cette analyse et de la
 couche Route500 dans JOSM alors que j'avais déjà fait une grosse passe
 avec les fichiers CSV de comparaison OSM/Route500 qui sont mis à jour
 chaque nuit sur http://osm13.openstreetmap.fr/~cquest/routes/
 
 
 Le 27/07/2015 18:38, didier2...@free.fr a écrit :
  maintenant l'item fait apparaitre une comparaison avec route500 ?
 
  Voilà un petit ajout pour osmose, la répartition de la population faite
  par l'INSEE sur des careaux de 200m de côté servait déjà au rendu QA
  pour indiquer là où des routes manquent potentiellement (ou des bâtiments).
  Pour faciliter la recherche de ces carreaux sans route à proximité, ils
  sont désormais transmis chaque nuit à osmose...
  http://osmose.openstreetmap.fr/fr/map/#item=7170
  ___
  Talk-fr mailing list
  Talk-fr@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/talk-fr
 



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Recyclage du rendu QA dans osmose: les carreaux INSEE

[didier2020]

maintenant l'item fait apparaitre une comparaison avec route500 ?

Voilà un petit ajout pour osmose, la répartition de la population faite
par l'INSEE sur des careaux de 200m de côté servait déjà au rendu QA
pour indiquer là où des routes manquent potentiellement (ou des bâtiments).

Pour faciliter la recherche de ces carreaux sans route à proximité, ils
sont désormais transmis chaque nuit à osmose...

http://osmose.openstreetmap.fr/fr/map/#item=7170

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Comment charger un WMS/WTS OSM dans SIG (QGIS) ?

[didier2020]

je suis pas un pro de qgis ... mais :
pour gerer les wms, c'est qgis browser.

exemple pour les tuiles mapnik
lancer qgis browser
dans la barre d'outil (mapemonde avec un +) - gérer wms
dans l'onglet couche = nouveau

dans la fenetre detail de connexion
nom = mapnik (ou celui que tu désires)
url = http://irs.gis-lab.info/?layers=osm;



- Mail d'origine -
De: René-Luc Dhont rldh...@gmail.com
À: talk-fr@openstreetmap.org
Envoyé: Mon, 27 Jul 2015 10:54:54 +0200 (CEST)
Objet: Re: [OSM-talk-fr] Comment charger un WMS/WTS OSM dans SIG (QGIS) ?

Bonjour,

Tu peux utiliser un fichier XML pour GDAL.
Cette article est un peu vieux mais est toujours d'actualiter :
http://www.3liz.com/blog/rldhont/index.php?post/2012/07/17/Les-Tuiles-OpenStreetMap-dans-QGIS

Il faudra juste mettre à jour le XML avec pour CRS: EPSG3857 à la place 
de EPSG:900913.
Tu trouveras une version valide ici :
http://www.gdal.org/frmt_wms.html

Cordialement,

Le 27/07/2015 10:25, image93 a écrit :
 Bonjour à tous,

 je compte charger un fond WTS ou WMS d'openstreetmap dans un sig (qgis). je
 ne compte pas passer par le plugin qgis nommé openlayersplugin qui me fait
 trop de misère.

 Je souhaite pouvoir charger ces couches wts/wms en renseignant des URL
 serveurs par exemple. A moins qu'il y ait d'autres méthodes. Je ne suis pas
 developpeur mais un simple geomaticien.

 Une personne pourrait elle m'aider?

 Merci beaucoup.



 --
 View this message in context: 
 http://gis.19327.n5.nabble.com/Comment-charger-un-WMS-WTS-OSM-dans-SIG-QGIS-tp5850979.html
 Sent from the France mailing list archive at Nabble.com.

 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Recyclage du rendu QA dans osmose: les carreaux INSEE sans route...

[didier2020]

Le lundi 20 juillet 2015 à 22:59 +0200, Christian Quest a écrit : 
 Ah les devoirs de vacances ;)
+1 c bien les vacances

 
 Voilà un petit ajout pour osmose, la répartition de la population faite
 par l'INSEE sur des careaux de 200m de côté servait déjà au rendu QA
 pour indiquer là où des routes manquent potentiellement (ou des bâtiments).
 
 Pour faciliter la recherche de ces carreaux sans route à proximité, ils
 sont désormais transmis chaque nuit à osmose...
 
 http://osmose.openstreetmap.fr/fr/map/#item=7170
 
 Ceci permet de charger rapidement la zone en question dans JOSM (ou iD)
 et de rajouter la ou les routes manquantes. En général il y a pas mal
 d'autres choses à ajouter car il est rare qu'une zone soit détaillée et
 que des routes n'y soient pas présentes !
 
 Attention: Il peut y avoir des faux positifs... les données de l'INSEE
 ne sont pas parfaites.
 Parfois il s'agit de décalage d'un carreau, parfois il n'y a vraiment
 rien sur la zone en question (j'ai eu des cas en plein champs).
 Dans ce cas, vous pouvez indiquer le faux-positif à osmose.
 
 Sur les zones de forêt, penser à utiliser le cadastre en complément des
 images aériennes pour retrouver les routes et chemins masqués par les
 arbres.
 
 Il y a un peu plus de 31000 carreaux sans route à proximité... à vous de
 jouer !
31 000 me semble faible : 
http://tile.openstreetmap.fr/?zoom=15lat=49.4462575043827lon=4.56345641933607layers=B000TFF
http://osmose.openstreetmap.fr/fr/map/#zoom=15lat=49.4462575043827lon=4.56345641933607item=7170




 D'autres analyses de ce type pourront s'ajouter avec le croisement
 d'autres données (le Route500 par exemple).
 



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Rendu QA: retour à la normale...

[didier2020]

good job, c bien mieux maintenant!


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] OSM Boundaries réduit la France

[didier2020]

la relation est ouverte au niveau du mont blanc
http://www.openstreetmap.org/#map=19/45.83243/6.86439

il y a 5 nodes au meme endroit ...

je ne sais pas corriger car le cadastre ne correspond pas du tout au
tracé de frontiere.


Le mercredi 27 mai 2015 à 14:59 +0200, Antoine Riche a écrit :
 Bonjour,
 
 Est-ce quelqu'un sait qui maintient le service OSM Boundaries :
 https://osm.wno-edv-service.de/boundaries/  ?  C'est un outil plutôt
 bien fait pour récupérer les limites administratives, mais aujourd'hui
 la France a perdu sa partie métropolitaine, ne reste que la France
 d'outre-mer.
 
 Cela semble dû à l'absence de la relation de niveau 3, du coup on ne
 peut pas accéder à celles de niveaux supérieurs. Pourtant celle-ci a
 l'air en bon état et n'a pas été modifiée récemment :
 http://www.openstreetmap.org/relation/1403916
 
 Antoine.
 
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Code Fantoir sur deux communes

[didier2020]

pour me faciliter le travail,
j'ai ajouter un lien vers la carte bano

et puis pour changer un peu ... 
j'ai ajouté quelques zones a mapper  
(rendu QA ordre decroissant de population)


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] bano - nom de voie - point bleu

[didier2020]

un petit exemple :
http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#18/49.54018/1.36171

c'est quoi les points bleu ...
celui-ci est largement eloigné de sa commune 



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] bano - nom de voie - point bleu

[didier2020]

je me demandais si c'etait une source x,
j'ai bien trouvé la rue au cadastre image et donc adapaté son emprise

en tout cas merci ;)

Le dimanche 24 mai 2015 à 22:04 +0200, Vincent de Château-Thierry a
écrit : 
 Bonsoir,
 
 Le 24/05/2015 19:16, didier2020 a écrit :
  un petit exemple :
  http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#18/49.54018/1.36171
 
  c'est quoi les points bleu ...
  celui-ci est largement eloigné de sa commune
 
 Les points bleus sont calculés à partir de la géométrie des voies OSM.Le 
 but est de pouvoir résumer chaque voie à un point, ce qui est utile par 
 exemple pour géocoder une adresse dont on connaît le nom de voie mais 
 pas le numero.
 Le calcul est par principe discutable. Et notamment, jusqu'à présent, on 
 ne cherche pas à vérifier que le point calculé tombe dans la bonne 
 commune. Au passage, ce serait un test assez simple à mettre en place, a 
 posteriori, pour détecter les incohérences.
 
 Dans le cas que tu pointes, le way OSM qui permet de produire ce point 
 état jusqu'à cet après-midi un bel exemple de route à cheval sur 
 plusieurs communes. Comme un certain didier2020 ;) est passé par là : 
 http://www.openstreetmap.org/way/347978859#map=14/49.5322/1.3899 on n'a 
 plus la situation d'une voie et nommée et chevauchante. Si tout se passe 
 correctement, demain matin après le process nocture BANO, le point bleu 
 sera quelques centaines de mètres plus au sud, dans Boissay.
 
 vincent
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Code Fantoir sur deux communes

[didier2020]

je ne sais pas si ce rendu est utilisé ou pas,
je fais une mise a jour apres mes corrections

Le vendredi 22 mai 2015 à 11:16 +0200, Frédéric Rodrigo a écrit : 
 Le 22/05/2015 09:04, Francescu GAROBY a écrit :
  Merci pour cette carte, déjà fort pratique !
 
  Puis-je me permettre de proposer quelques améliorations futures ?
  * pouvoir marquer qu'un point a été corrigé ;
  * proposer les modifications à apporter (en se basant sur les noms et
  codes FANTOIR des voies censées être là) et regrouper tout ça dans un
  bouton fix-josm ;
pour fix-josm :
je ne pense pas que cela soit possible car les corrections sont trop
différentes:
- way qui a été decoupé , le name est erroné sur ce morceau, pas de name
a mettre
- way qui a été decoupé , le name est erroné sur ce morceau, au moins un
autre name a mettre (decoupage du way)
- le name est ok mais l'emprise est beaucoup trop longue
- valeur maxspeed présente fausse car way trop long et traverse des
villes
- ref non présent (route500)
- way associé a relation adresse 
- name reellement faux (mauvaise localisation), apres vérification sur
cadastre image
- tracé anguleux, ajout de node, decoupage way pour les ponts
- je sais pas si c'est bon ou pas 



 
  Ces 2 points reprenant en fait le fonctionnement que l'on peut déjà
  rencontrer avec Osmose.
 
 Ça ressemble tellement à Osmose que ça pourrait bien aller dans Osmose ;)
+1 
 
 Avec Didier on a travaillé sur les way nommé sur plusieurs communes, 
 c'est la même chose à faire. Donc le travail pour intégration dans 
 Omsose déjà en cours. Toute aide est la bine venu, y comprit un push 
 request de code ;). Voir talk-dev-fr
 
 Frédéric.
 
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Code Fantoir sur deux communes

[didier2020]

ways dont le name commence par Rue,
qui a prioris ont besoins d'amélioration

http://osm2020.free.fr/wayname


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Code Fantoir sur deux communes

[didier2020]

Le dimanche 17 mai 2015 à 16:59 +0200, Eric SIBERT a écrit : 
 Le 15/05/2015 18:36, Christian Quest a écrit :
  Suite à cet échange et à une demande de didier2020, j'ai sorti un CSV
  des highway qui portent un nom et qui croisent plusieurs communes.
 
 J'ai regardé. Pas facile à exploiter comme ça juste avec le tableau. Un 
 tri par département peut-être.
 
Essaye de filtrer les names qui commencent par Rue ...
il n'y a pratiquement pas de faux positif 
 J'ai aussi étudié en détail quelques Route de Grenoble. Ce n'est pas 
 parce que ça traverse plusieurs communes que c'est faux. Justement, les 
 données Fantoir sont une opportunité de vérifier ça sans aller sur le 
 terrain. Il faut juste que les banoteurs soient vigilants sur les 
 changements de commune.
 
  A affiner pour une future analyse osmose ?
 
 Bof. Attendre que la bano avance et faire du contrôle sur la bano:
 - code Fantoir bien dans le périmètre de la commune
 - voie avec name=* et pas de code Fantoir (genre Chemin de Machin à 
 Trucmuche recopié du cadastre).
 
 Eric
 
 
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Code Fantoir sur deux communes

[didier2020]

j'ai exactement eu ce genre de soucis, j'ai resolu de façon empirique ne
connaissant pas le sujet.

comme ca marchait pas, j'ai essayé avec l'extract de la corse
(tout petit ca devait marcher...) en mode slim sans number-processes

j'ai corrigé suivant les msg erreur par recherche internet
http://wiki.openstreetmap.org/wiki/Osm2pgsql#Optimization
http://wiki.openstreetmap.org/wiki/PostgreSQL#Tune_the_database
... et d'autres dont je n'ai pas gardé de liens

2 eme etape, controle de l'utilisation des ressources avec le moniteur
systeme (memoire, swap et taille disque utilisé) et du log postgresql

modification des parametres postgresql pour voir ce que ca fait et si
cela utilise plus ou moins de ressources.

ca a ete laborieux


Le samedi 16 mai 2015 à 03:47 +0200, Jérôme Amagat a écrit : 
 Par contre c'est quoi la bonne façon de nommer une route? Quand la
 route à un nom jusque qu'a la limite de commune, où on arrête la
 route? moi jusqu'à maintenant je coupais au niveau d'un nœud prêt de
 la frontière. Là dans le fichiers il va y avoir beaucoup des routes
 que je pensais nommer comme il faut.
 
 Le 15 mai 2015 18:36, Christian Quest cqu...@openstreetmap.fr a
 écrit :
 Suite à cet échange et à une demande de didier2020, j'ai sorti
 un CSV des highway qui portent un nom et qui croisent
 plusieurs communes. 
 Les motorway ont été retiré, et c'est trié par nombre de
 communes croisées, puis par kilométrage décroissant. 
 La liste des codes INSEE des communes croisées est indiquée. 
 
 
 C'est ici: http://osm105.openstreetmap.fr/~cquest/routes.csv 
 
 
 A affiner pour une future analyse osmose ? 
 
 
 
 
 
 Le 14 mai 2015 14:10, Eric SIBERT courr...@eric.sibert.fr a
 écrit :
 Le 14/05/2015 13:48, Frédéric Rodrigo a écrit :
 Non, le code FANTOIR est en partie composé du
 code INSEE qui est unique
 par commune.
 
 Ok. Donc un boulet (de plus :-p) qui met le nom (et
 maintenant le code fantoir) au début d'une rue sans se
 préoccuper de jusqu'où va le way, en particulier
 lorsqu'il franchit la limite de commune.
 
 Au moins, le code Insee me permet de détecter la
 branche incorrecte.
 
 Eric 
 
 
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr
 
 
 
 
 
 -- 
 Christian Quest - OpenStreetMap France 
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr
 
 
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [RER B] Pourquoi noms gares Parc de Sceaux et Croix de Berny pas affichées?

[didier2020]

http://www.openstreetmap.org/way/79725350
n'a pas le tag railway=station
comme antony http://www.openstreetmap.org/way/80405300

?

Le vendredi 15 mai 2015 à 15:55 -0700, Shohreh a écrit : 
 Bonjour
 
 Par curiosité, quelqu'un sait-il pourquoi les gares RER Parc de Sceaux et
 Croix de Berny ne sont pas visibles, même sur le rendu OSM FR?
 
 http://www.openstreetmap.org/#map=15/48.7713/2.3041
 http://tile.openstreetmap.fr/
 
 Même en zoomant un maximum, leur nom n'apparaît pas. Il faut les connaître
 pour savoir qu'elles existent. 
 
 Pour ceux qui ne connaissent pas le coin, ces deux stations se trouvent
 entre Bourg-La-Reine et Antony sur le RER B au sud de Paris.
 
 Merci.
 
 
 
 --
 View this message in context: 
 http://gis.19327.n5.nabble.com/RER-B-Pourquoi-noms-gares-Parc-de-Sceaux-et-Croix-de-Berny-pas-affichees-tp5844779.html
 Sent from the France mailing list archive at Nabble.com.
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rapprochement des adresses OSM et BANO pour l'Aude

[didier2020]

il y a ca :
http://zverik.osm.rambler.ru/whodidit/

sinon en utilisant un script sur un fichier osm 
http://svn.openstreetmap.org/applications/utils/planet.osm/perl/statistics.pl


Le jeudi 07 mai 2015 à 23:20 +0200, Paul Desgranges a écrit : 
 Bonjour,
 
Je fais partie du groupe OSM Grenoble, et (à l'initiative de PiRK, 
 voir 
 http://fr.slideshare.net/onpeutchangersonadresseuneseulefois/bano-osm-grenoble20150305),
  
 nous avons commencé à faire le rapprochement des adresses OSM et BANO 
 pour toutes les communes de l'Isère. Ce travail est organisé par ce 
 mapcraft : http://mapcraft.nanodesu.ru/pie/472. C'est un vaste chantier, 
 mais ça avance...
 
   J'ai voulu initier le même travail pour le département de l'Aude.
 Voir le mapcraft : http://mapcraft.nanodesu.ru/pie/495
 
   Voir aussi ici : 
 https://wiki.openstreetmap.org/wiki/Contribuer_%C3%A0_la_BANO#Projets_locaux
 
 Paul Desgranges
 
 
 PS : une question pour finir, y-a-t-il une façon de connaitre les 
 contributeurs principaux d'une zone donnée, d'une commune, d'un 
 département etc ?
 
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Re : Re: Voie de gauche réservée aux bus et aux taxis sur l'autoroute A1

[didier2020]

- il y a en meme temps une voie sur le bp extérieur qui est neutralisée
http://www.dir.ile-de-france.developpement-durable.gouv.fr/la-voie-dediee-comment-ca-marche-a646.html
- ca va tomber en panne dans pas longtemps (oups)


- Mail d'origine -
De: Stéphane Péneau stephane.pen...@wanadoo.fr
À: Discussions sur OSM en français talk-fr@openstreetmap.org
Envoyé: Wed, 29 Apr 2015 11:15:30 +0200 (CEST)
Objet: Re: [OSM-talk-fr] Voie de gauche réservée aux bus et aux taxis sur 
l'autoroute A1

Le 29/04/2015 09:29, Francescu GAROBY a écrit :
 Ah oui, en effet !
 Du coup, je ne sais pas comment indiquer des horaires sur un access...

 Francescu


Si tu es courageux, tu auras la réponse ici :
http://wiki.openstreetmap.org/wiki/Conditional_restrictions

Stf

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Taginfo.fr et JOSM

[didier2020]

ca a l'air de marcher avec overpass ...
http://overpass-turbo.eu/s/8V5


Le mardi 21 avril 2015 à 15:33 +0200, Vincent Pottier a écrit :
 Bonjour,
 Sur les pages de Taginfo fr (par exemple [1]) en cliquant sur le lien
 JOSM à droite, j'obtiens un message d'erreur dans JOSM [2] : 
 Impossible d'ouvrir l'URL
 'http://oapi-fr.openstreetmap.fr/xapi/xapi?*[social_facility%
 3Dgroup_home]' Les tâches de téléchargement acceptent les modèles
 d'URL suivants:
 (Suit une liste de modèle d'url)
 
 C'est un problème Taginfo ou JOSM ?
 
 [1] http://taginfo.openstreetmap.fr/tags/social_facility=group_home
 [2] JOSM version 8240
 --
 FrViPofm 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] BANO : suivi des rapprochements, par département

[didier2020]

Le dimanche 05 avril 2015 à 23:53 +0200, Jérôme Amagat a écrit : 
 je sais pas ce que c'est que indice 2020 mais je pense qu'il y a
 quelque chose qui ne va pas.
 Ça ne serai pas plutôt ((1 - a/c)*(c-a))...  (pourcentage qui manque x
 nombre qui manque)
 là ça ne va pas, par exemple une commune sans rapprochement (a=0) elle
 a 0

oups gourance ! c'est effectivement ça que j'utiliserais ...

(((c-a)^2)/c) + (((b-a)^2)/c) + (((d-b)^2)/d)

stp vincent, merci de corriger ...




 
 Sinon l'ajout d'une ligne pour tout le département pourrait être utile
 et pourquoi pas aussi un tableau de tous les départements pour
 comparer l'avancement sur le pays.
 
 Le 5 avril 2015 23:24, didier2020 didier2...@free.fr a écrit :
 Le dimanche 05 avril 2015 à 20:22 +0200, Vincent de
 Château-Thierry a
 écrit :
  Le 05/04/2015 19:49, didier2020 a écrit :
   ((a/c)*(c-a)) + ((b/c)*(c-b)) + ((b/d)* (d-b))
  
   qui qualifie mieux la notion déficitaire que le simple
 ecart relatif
   (plus le chiffre est gros, plus y a de boulot)
 
  Ajouté (je te laisse voir le nom de la colonne ;) ).
 cool ! 
 
  Garder à l'esprit que le comptage qui inclut les lieux-dits
 donne
  parfois des chiffres artificiellement gonflés, tant il peut
 y avoir un
  décalage entre les lieux-dits vécus, pratiqués, constatés,
 et ceux
  inventoriés sur le cadastre. Toute tambouille qui s'appuie
 sur ce
  chiffre héritera du biais.
 
  vincent
 
  ___
  Talk-fr mailing list
  Talk-fr@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/talk-fr
 
 
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr
 
 
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] BANO : suivi des rapprochements, par département

[didier2020]

Le lundi 06 avril 2015 à 13:22 +0200, didier2020 a écrit : 
 Le dimanche 05 avril 2015 à 23:53 +0200, Jérôme Amagat a écrit : 
  je sais pas ce que c'est que indice 2020 mais je pense qu'il y a
  quelque chose qui ne va pas.
  Ça ne serai pas plutôt ((1 - a/c)*(c-a))...  (pourcentage qui manque x
  nombre qui manque)
  là ça ne va pas, par exemple une commune sans rapprochement (a=0) elle
  a 0
 
 oups gourance ! c'est effectivement ça que j'utiliserais ...
 
 (((c-a)^2)/c) + (((b-a)^2)/c) + (((d-b)^2)/d)
faux vraiment que je me repose ... ou que je change de lunettes !
(((c-a)^2)/c) + (((b-c)^2)/c) + (((d-b)^2)/d) 
stp vincent, merci de corriger ... :$

 
 
 
 
  
  Sinon l'ajout d'une ligne pour tout le département pourrait être utile
  et pourquoi pas aussi un tableau de tous les départements pour
  comparer l'avancement sur le pays.
  
  Le 5 avril 2015 23:24, didier2020 didier2...@free.fr a écrit :
  Le dimanche 05 avril 2015 à 20:22 +0200, Vincent de
  Château-Thierry a
  écrit :
   Le 05/04/2015 19:49, didier2020 a écrit :
((a/c)*(c-a)) + ((b/c)*(c-b)) + ((b/d)* (d-b))
   
qui qualifie mieux la notion déficitaire que le simple
  ecart relatif
(plus le chiffre est gros, plus y a de boulot)
  
   Ajouté (je te laisse voir le nom de la colonne ;) ).
  cool ! 
  
   Garder à l'esprit que le comptage qui inclut les lieux-dits
  donne
   parfois des chiffres artificiellement gonflés, tant il peut
  y avoir un
   décalage entre les lieux-dits vécus, pratiqués, constatés,
  et ceux
   inventoriés sur le cadastre. Toute tambouille qui s'appuie
  sur ce
   chiffre héritera du biais.
  
   vincent
  
   ___
   Talk-fr mailing list
   Talk-fr@openstreetmap.org
   https://lists.openstreetmap.org/listinfo/talk-fr
  
  
  
  ___
  Talk-fr mailing list
  Talk-fr@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/talk-fr
  
  
  
  ___
  Talk-fr mailing list
  Talk-fr@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/talk-fr
 
 
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] BANO : suivi des rapprochements, par département

[didier2020]

Le dimanche 05 avril 2015 à 22:50 +0200, Donat ROBAUX a écrit : 
 C'est super ça Vincent. On dirait que c'est Noël en ce moment! après
 les nouvelles infos sur tile!
 
 
 Est-il possible de bloquer la 1ère ligne quand on scrolle?
 What's indice 2020?
a/c, b/c et b/d sont des ecarts relatifs
l'inconvénient des ecarts relatifs , c'est qu'ils ont relatif ... (50%
peut représenter 50% de 2)
ce qu'a nommé vincent en indice2020 c'est le produit de l'ecart net par
l'ecart relatif
c'est un moyen de trier/trouver les plus gros ecart 
 
 
 Donat
 
 
 PS: Pour information, j'ai repris depuis quelques temps déjà dans une
 autre page wiki, un bout de la page de la Bano, parce que ae commence
 à faire beaucoup de choses (sur la page de la Bano et en terme
 d'outils). J'ai dans l'idée de la développer et de mettre plus de
 détails et screenshot pour faciliter la compréhension de la Bano aux
 nouveaux contributeurs. Il n'y a pas encore de lien depuis le wiki
 Bano, mais ca permettrait de libérer un peu la page wiki Bano.
 
 
 https://wiki.openstreetmap.org/wiki/Contribuer_%C3%A0_la_BANO
 
 
 
 Donat
 
 
 
 
  
 -- Message transféré --
 From: Vincent de Château-Thierry v...@laposte.net
 To: Discussions sur OSM en français
 talk-fr@openstreetmap.org
 Cc: 
 Date: Sun, 05 Apr 2015 00:37:49 +0200
 Subject: [OSM-talk-fr] BANO : suivi des rapprochements, par
 département
 Bonsoir,
 
 Dans la série des outils autour de BANO, je vous propose une
 nouvelle page, qui donne pour un département quelques chiffres
 commune par commune :
 - le nombre de voies avec adresses, rapprochées
 - le nombre de voies rapprochées (qu'elles aient des adresses
 ou pas)
 - le nombre de voies recensées au FANTOIR, hors lieux-dits
 - le nombre de voies _et_ lieux-dits recensés au FANTOIR
 et des calculs de pourcentages combinant ces 4 effectifs.
 
 La prise en compte des lieux-dits permet de s'adapter au cas
 où des rapprochements de voies OSM sont faits sur des FANTOIRs
 de lieux-dits. Ça sera pertinent dans certaines communes
 seulement.
 
 L'outil est ici :
 http://cadastre.openstreetmap.fr/fantoir/stats_dept.html
 
 Ces tableaux généralisent un outil qui a émergé pour
 accompagner le travail en cours sur l'Isère [1]. L'idée était
 de voir, à l'échelle d'un département, où se situaient les
 communes les plus déficitaires dans OSM en voies nommées, donc
 celles sur lesquelles on pourrait mettre la priorité en terme
 de contribution.
 
 Questions  retours bienvenus,
 vincent
 
 [1] :
 
 https://lists.openstreetmap.org/pipermail/talk-fr/2015-March/075627.html
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] BANO : suivi des rapprochements, par département

[didier2020]

Le dimanche 05 avril 2015 à 20:22 +0200, Vincent de Château-Thierry a
écrit : 
 Le 05/04/2015 19:49, didier2020 a écrit :
  ((a/c)*(c-a)) + ((b/c)*(c-b)) + ((b/d)* (d-b))
 
  qui qualifie mieux la notion déficitaire que le simple ecart relatif
  (plus le chiffre est gros, plus y a de boulot)
 
 Ajouté (je te laisse voir le nom de la colonne ;) ).
cool ! 
 
 Garder à l'esprit que le comptage qui inclut les lieux-dits donne 
 parfois des chiffres artificiellement gonflés, tant il peut y avoir un 
 décalage entre les lieux-dits vécus, pratiqués, constatés, et ceux 
 inventoriés sur le cadastre. Toute tambouille qui s'appuie sur ce 
 chiffre héritera du biais.
 
 vincent
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] BANO : suivi des rapprochements, par département

[didier2020]

Le dimanche 05 avril 2015 à 00:37 +0200, Vincent de Château-Thierry a
écrit : 
 Bonsoir,
 
 Dans la série des outils autour de BANO, je vous propose une nouvelle 
 page, qui donne pour un département quelques chiffres commune par commune :
 - le nombre de voies avec adresses, rapprochées
 - le nombre de voies rapprochées (qu'elles aient des adresses ou pas)
 - le nombre de voies recensées au FANTOIR, hors lieux-dits
 - le nombre de voies _et_ lieux-dits recensés au FANTOIR
 et des calculs de pourcentages combinant ces 4 effectifs.
 
 La prise en compte des lieux-dits permet de s'adapter au cas où des 
 rapprochements de voies OSM sont faits sur des FANTOIRs de lieux-dits. 
 Ça sera pertinent dans certaines communes seulement.
 
 L'outil est ici :
 http://cadastre.openstreetmap.fr/fantoir/stats_dept.html
 
 Ces tableaux généralisent un outil qui a émergé pour accompagner le 
 travail en cours sur l'Isère [1]. L'idée était de voir, à l'échelle d'un 
 département, où se situaient les communes les plus déficitaires dans OSM 
 en voies nommées, donc celles sur lesquelles on pourrait mettre la 
 priorité en terme de contribution.

formule cretine :

((a/c)*(c-a)) + ((b/c)*(c-b)) + ((b/d)* (d-b))

qui qualifie mieux la notion déficitaire que le simple ecart relatif
(plus le chiffre est gros, plus y a de boulot)


 
 Questions  retours bienvenus,
 vincent
 
 [1] : 
 https://lists.openstreetmap.org/pipermail/talk-fr/2015-March/075627.html
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] code FANTOIR avec nom de rue et de résidence

[didier2020]

je sais pas trop quoi faire avec ces noms ...


027890082C RUE FOSSE AUX LOUPS R ARDENNE
027890084E RUE FOSSE AUX LOUPS R SOLOGNE
027890083D RUE FOSSE AUX LOUPS RES ARTOIS
027890138N RUE RICHEPIN RES ACADIE 
027890154F RUE L ESCARBOT RES QUEBEC
027890162P RUE MERMOZ RES THIERACHE

j'ai mis name=Résidence xxx sur le batiment


http://cadastre.openstreetmap.fr/fantoir/#insee=02789
http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#18/49.8342125108/3.91602302206
http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#20/49.83549/3.91634


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] code FANTOIR avec nom de rue et de résidence

[didier2020]

vu qu'il y a une rue qui existe dans le cadastre, mais plusieurs fantoir
(rue + nom résidence)
name sur la rue, (name sur le batiment ou pas) mais quid fantoir ?

Le samedi 04 avril 2015 à 14:44 +0200, Jérôme Seigneuret a écrit : 
 En effet sur le cadastre il y a le nom mais juste à coté du bâtiment.
 Je mettrai pas ça sur le bâtiment même si ça ce fait car une résidence
 peut être composé de plusieurs bâtiment (dans ce cas le bâtiment porte
 un numéro ou une lettre). La délimitation et assez visible sur le
 cadastre pour faire un place de type surfacique
 
 
 place=neighbourhood permet d'ajouter:
   *  name=* pour le nom. 
   *  Éventuellement aussi wikipedia=* pour créer un lien vers
 l'article Wikipédia correspondant, 
   *  start_date=*, pour l'année ou date à partir de laquelle ce
 quartier a vu le jour. 
   * architect=* pour le nom de l'urbaniste ou de l'entreprise
 d'architecture qui a conçu le site. (Ce tag n'est pas
 disponible pour landuse... d'où ma réticence à m'en servir
 dans ce cas) 
 Mon problème c'est que je vois le nom que sur la carte cyclable à un
 zoom de 18. Les autres couches ne l'affiche pas... Peut être est-il
 possible de corriger ça sur les autres couches???
 
 
 http://www.openstreetmap.org/#map=18/43.59552/3.84836layers=C
 
 
 
 
 
 PS : Sur JOSM c'est soit l'ortho soit le cadastre et donc les
 bâtiments qui sont pas très bien calé sur ta zone. J'ai regardé les
 traces GPS mais c'est pas assez quadrillé sur la zone pour savoir
 quelle est la couche à corriger.
 
 
 
 
 
 Le 4 avril 2015 14:10, Jérôme Seigneuret jseigneuret-...@yahoo.fr a
 écrit :
 Moi je fais un place=neighbourhood + name=Résidence *** avec
 les parcelles visibles sur le fond cadastral et Bing en
 support dans certains cas pour les parcelles redécoupés 
 
 
 D'autre mettent ça avec un landuse=residential +
 name=Résidence *** 
 
 
 Pour l'adresse pour la correspondance, si il n'y a pas de
 correspondance, je rajoute la référence Fantoir 
 
 
 Landuse reste pour moi un moyen de définir la fonction globale
 de l'occupation du sol. Donc je me refuse à l'utiliser pour
 nommer et encore plus pour des Résidence. En plus, il y a déjà
 un Landuse=residential dans 90% des cas qui englobe l'ensemble
 de la ville dont la dite résidence. 
 
 
 Je regarde sur JOSM pour voir si les rues ne sont pas déjà
 marqué mais mettre le nom de la résidence dans la rue je
 trouve ça pas propre. D'ailleurs j'ai corrigé des rues sur
 Montpellier en mettant ça comme highway=service car c'est la
 voirie de la résidence (voie privé qui plus est) 
 
 2015-04-04 11:53 GMT+02:00 didier2020 didier2...@free.fr:
 je sais pas trop quoi faire avec ces noms ...
 
 
 027890082C RUE FOSSE AUX LOUPS R ARDENNE
 027890084E RUE FOSSE AUX LOUPS R SOLOGNE
 027890083D RUE FOSSE AUX LOUPS RES ARTOIS
 027890138N RUE RICHEPIN RES ACADIE
 027890154F RUE L ESCARBOT RES QUEBEC
 027890162P RUE MERMOZ RES THIERACHE
 
 j'ai mis name=Résidence xxx sur le batiment
 
 
 http://cadastre.openstreetmap.fr/fantoir/#insee=02789
 
 http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#18/49.8342125108/3.91602302206
 
 http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#20/49.83549/3.91634
 
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr 
 
 
 
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] code FANTOIR avec nom de rue et de résidence

[didier2020]

ok merci pour la réponse . 
question en + : les highway=service ne sont pas rapprochés ?

Le samedi 04 avril 2015 à 21:13 +0200, Vincent de Château-Thierry a
écrit : 
 Bonsoir,
 
 Le 04/04/2015 18:10, Jérôme Seigneuret a écrit :
  ARFFF Je mettrai ça en erreur Fantoir car normalement c'est la rue qui
  doit faire foi et là tu as la rue plus autre type d'info
 
  Erreur la plus cohérente: Voie incorporée à une autre.
 
  Ton problème est un peu chiant car les trois Fantoir déservent le même
  nom de rue qui n'exista pas tous seul... (Sauf pour certaines dont tu as
  Rue + Résidence
 
 Pour la rue de la Fosse aux Loups, on a 4 Fantoir : 1 par résidence + 1 
 pour la rue seule. N'en jetez plus. Les codes semblent bien s'appliquer 
 aux voies et pas aux résidences, dixit la doc Fantoir [1]. On peut 
 imaginer affecter chacun des 3 codes des résidences à 3 portions de la 
 voie Rue de la Fosse au Loups qui partent de là :
 https://www.openstreetmap.org/node/3436827988
 mais ça laisse sur le carreau le Fantoir de la voie seule. Pour lui je 
 n'ai aucune idée, sachant qu'en plus aucune parcelle du cadastre n'est 
 rattachée à cette voie : le 027890079Z est dans les voies sans adresses.
 
 En regardant la rue Hirson, c'est un peu différent :
 http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#18/49.8374866646/3.91359296038
 On a encore une voie par résidence et une voie pour la rue seule, mais 
 il semble plus simple d'affecter un Fantoir à chacune, même si elles 
 portent toutes le même nom Rue d'Hirson dans OSM. Le Fantoir de la rue 
 seule irait sur https://www.openstreetmap.org/way/336628661, et les 
 autres sur les voies de service devant chaque immeuble.
 
 Dans tous les cas, avoir plusieurs codes Fantoir avec le même nom de 
 voie OSM va laisser, pour l'instant, du rouge sur le calque Bano, car la 
 gestion de Fantoirs multiples pour un seul nom n'est pas encore 
 branchée. Du coup je rajoute ces exemples dans le ticket :
 https://github.com/osm-fr/bano/issues/71
 
 vincent
 
 
 [1] : 
 http://www.collectivites-locales.gouv.fr/files/files/gestion_locale_dgfip/national/FANTOIR_Descriptif.pdf
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Mapillary et les panneaux

[didier2020]

Sinon tu peux 
aller la :
http://www.mapillary.com/map/im/bbox/48.70418842904476/48.72618968922067/2.23846435546875/2.29339599609375

- en bas a gauche, filter et ensuite a droite tu click 1 foi sur
Traffic signs
- tu refermes le filter 
- choisir une sequence (itinéraire)
= tu peu valider les images, ajouter des panneaux ...
l'inconvénient est que l'image est petite



Le jeudi 05 mars 2015 à 08:08 +0100, Jean-Baptiste Holcroft a écrit :
 Pour information, mon ticket pour mieux repartir les photos et ne pas
 traiter que les pays avec le plus de photo a été accepté et traité.
 Globalement, plein de photos en Allemagne alors que c'est la zone la
 mieux couverte dans osm... Si quelqu'un voit la différence, je serai
 intéressé par un retour.
 
 https://github.com/mapillary/mapillary_issues/issues/643
 
 Le 19 févr. 2015 11:56, Yves Pratter yves.prat...@gmail.com a
 écrit :
 
  Mais là, je veux bien aider, mais est-ce que les sources de
  leur algo sont 
  dispo sous licence libre ? 
 
 
 ils utilisent OPENCV :  http://opencv.org 
 
 
 Leur algo n'est probablement pas Open Source mais il doit en
 exister d’autres. Recherche «traffic sign recognition opencv»
 sur google… 
 
 
 — 
 Yves 
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rencontre parisienne ce jeudi

[didier2020]

Le mardi 24 février 2015 à 20:09 +0100, Vincent de Château-Thierry a
écrit : 
 La fin du mois approche, Si vous êtes parisien(ne)s ce jeudi soir,
jeudi !
me deplacer je ferais ... 
 vous 
 êtes les bienvenus à partir de 19:00 à la Maison des Associations du IIè 
 arrondissement, 23, rue Greneta.
 = http://www.openstreetmap.org/node/691721185
 
 À jeudi,
 vincent ( Christian)
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Reconnaissance automatique des panneaux routiers ?

[didier2020]

Le jeudi 29 janvier 2015 à 20:20 +0100, Yves Pratter a écrit : 
  Je me demande quelle sera la prochaine étape !
  
  Détection de POI grâce à la reconnaissance de caractères ou de logo usuel ?
  Détection d'objets grâce à leur forme ? Je pense à tout ce qui est proche 
  de la route (feux de signalisation, arrêt de bus, parkings vélos, passages 
  piétons...)
  
 Détection des meilleures patisseries dans les boutiques… ou autres 
 gourmandises ;D
il reve ...
http://www.est.cerema.fr/ireve-a2747.html 
 
 C’est (presque) la fin de la semaine,
 
 —
 Yves
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] 149 nouvelles communes au format vectoriel au cadastre ?

[didier2020]

149 d'un coup ?

dept cog name
02 02104 BOUFFIGNEREUX
02 02177 CHERET
02 02215 CORBENY
02 02349 GOUDELANCOURT LES BERRIEUX
02 02364 GUYENCOURT
02 02448 MACHECOURT
02 02454 LA MALMAISON
02 02531 MOUSSY VERNEUIL
02 02546 LA NEUVILLE EN BEINE
02 02582 PAISSY
02 02675 SAINTE CROIX
02 02026 ARTONGES
02 02099 BONNESVALYN
02 02125 BRUMETZ
02 02241 LA CROIX SUR OURCQ
02 02305 FERE EN TARDENOIS
02 02356 GRISOLLES
02 02411 LATILLY
02 02428 LICY CLIGNON
02 02466 MARIZY SAINTE GENEVIEVE
02 02509 MONTHIERS
02 02679 SAINT GENGOULPH
03 03010 AUDES
03 03153 LOUROUX-HODEMENT
03 03213 REUGNY
03 03297 VALLON-EN-SULLY
10 10181 JULLY SUR SARCE
10 10236 MESNIL LETTRE
10 10284 PERIGNY LA ROSE
10 10335 SAINT BENOIST SUR VANNE
11 11007 ALBIERES
11 11017 ARTIGUES
11 11020 AURIAC
11 11033 BELPECH
11 11044 BOUISSE
11 11057 CAHUZAC
11 7 DAVEJEAN
11 8 DERNACUEILLETTE
11 11137 FELINES TERMENES
11 11186 LAIRIERE
11 11187 LANET
11 11191 LAROQUE DE FA
11 11224 MASSAC
11 11236 MOLANDIER
11 11244 MONTFORT SUR BOULZANE
11 11250 MONTJOI
11 11260 MOUTHOUMET
11 11290 PLAIGNE
11 11302 PUILAURENS
11 11321 ROQUEFORT DE SAULT
11 11374 SALZA
11 11388 TERMES
11 11426 VILLEGLY
11 11435 VILLEROUGE TERMENES
15 15011 ARNAC
15 15057 CROS-DE-MONTVERT
15 15092 LANOBRE
15 15189 SAINT-GERONS
15 15199 SAINT MARTIAL
15 15241 LA TRINITAT
24 24270 MILHAC-D AUBEROCHE
24 24439 SAINT-LAURENT-SUR-MANOIRE
24 24521 SARLIAC-SUR-L ISLE
24 24106 LA CHAPELLE AUBAREIL
26 26024 BARCELONNE
26 26081 CHATEAUDOUBLE
26 26100 COMBOVIN
26 26212 MONTVENDRE
26 26232 PEYRUS
27 27266 FRANQUEVILLE
28 28366 SANTEUIL
28 28331 ST DENIS D AUTHOU
30 30201 PONTEILS-ET-BRESIS
30 30218 ROCHEGUDE
30 30237 SAINT-BRES
30 30293 SAINT-PRIVAT-DE-CHAMPCLOS
42 42287 SAINT-SAUVEUR-EN-RUE
43 43031 BLASSAC
43 43067 CHAVANIAC-LAFAYETTE
43 43072 LA CHOMETTE
43 43106 JAX
43 43178 SAINT-DIDIER-SUR-DOULON
43 43222 SAINT-PRIVAT-DU-DRAGON
43 43264 VILLENEUVE-D ALLIER
51 51023 AULNAY-SUR-MARNE
51 51117 CHAMPIGNEUL-CHAMPAGNE
51 51142 CHAVOT-COURCOURT
51 51285 HAUSSIMONT
51 51594 VASSIMONT-ET-CHAPELAINE
55 55332 MENAUCOURT
55 55358 CHANTERAINE
55 55370 NAIX AUX FORGES
55 55160 DOMPIERRE AUX BOIS
55 55245 HEUDICOURT SOUS LES COTES
55 55258 GEVILLE
55 55274 LAMORVILLE
55 55303 LOUPMONT
55 55578 WARCQ
55 55583 WOEL
57 57153 CORNY-SUR-MOSELLE
65 65128 CASTELBAJAC
65 65150 CLARENS
65 65183 GALAN
65 65184 GALEZ
65 65224 HOUEYDETS
65 65245 LAGRANGE
65 65274 LIBAROS
65 65315 MONLEON-MAGNOAC
65 65318 MONTASTRUC
65 65376 RECURT
65 65381 SABARROS
65 65419 SENTOUS
65 65449 TOURNOUS-DEVANT
66 66030 CALCE
67 67009 ALTWILLER
67 67183 HARSKIRCHEN
67 67241 KIRRBERG
67 67553 WOLSCHHEIM
71 71142 COMELLE (LA)
71 71162 CURGY
71 71440 SAINT-LEGER-SOUS-BEUVRAY
71 71464 ST MAURICE LES COUCHES
71 71527 SOMMANT
71 71004 ALLERIOT
71 71052 BOYER
71 71256 LESSARD-EN-BRESSE
71 71262 LONGEPIERRE
71 71315 MONT-LES-SEURRE
71 71329 NAVILLY
71 71341 PALLEAU
71 71355 PONTOUX
71 71363 PULEY (LE)
71 71423 SAINT-GERVAIS-EN-VALLIERE
71 71498 SANTILLY
77 77504 VILLEMARECHAL
77 77190 FONTAINS
77 77446 SAVINS
78 78321 JOUARS-PONTCHARTRAIN
78 78307 HERMERAY
80 80571 MORISEL
80 80368 FRIVILLE-ESCARBOTIN
80 80373 GAMACHES
83 83025 BRUE-AURIAC
83 83052 ESPARRON
89 89330 SACY
91 91175 CORBREUSE
91 91525 ROINVILLE-SOUS-DOURDAN
91 91630 VAL-SAINT-GERMAIN (LE)



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Problème de rendu dans l'Ain

[didier2020]

a voir si cela suffit :
http://www.openstreetmap.org/changeset/28403845

je corrige régulierement ce genre d'erreur qui provient généralement de
l'éditeur id qui permet d'attribuer une modification a une relation a la
place du way voulu



Le dimanche 25 janvier 2015 à 20:44 +0100, Michael Delorme a écrit : 
 Bonsoir
 
 Une grande partie est du département de l'Ain n'affiche plus les
 landuse ; il semble qu'il y ait un polygone que je n'ai pas identifié
 (un arrondissement ?) qui s'intercale sur différents rendu :
 http://www.openstreetmap.org/#map=13/45.9446/5.8167
 
 C'est visible à différents niveaux de zoom (mais pas tous, une histoire
 de caches j'imagine) et sur différent rendus, par ex sur HOT :
 http://www.openstreetmap.org/#map=14/45.9337/5.8138layers=H
 
 ou sur le rendu FR :
 http://tile.openstreetmap.fr/?zoom=14lat=45.9543lon=5.8358layers=B000FFF
 
 Les données de landuse sont toujours présentes cependant (visibles dans
 JOSM par exemple).
 
 Je ne sais pas si ça apparaît dans d'autres coins de France ou du monde,
 mais ça a quand même l'air d'être lié à l'Ain vu la limite
 départementale sur le Rhône...
 
 Une idée de la cause et du moyen de réparer ?
 
 Cordialement
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Problème de rendu dans l'Ain

[didier2020]

Le dimanche 25 janvier 2015 à 20:58 +0100, JB a écrit : 
 Battu par DidierBot !
c'est marron ... c'est batiment : c'est mon kravail ...

j'ai aussi informé le contributeur (son tout premier changeset) 
 Grace à iD qui a permis d'ajouter un building=yes à cet élément :
  
 https://www.openstreetmap.org/relation/3078420
 (C'est vraiment sérieux, ces relations de 429 membres pour définir un 
 massif montagneux ?)
 JB.
 
 Le 25/01/2015 20:44, Michael Delorme a écrit :
  Bonsoir
 
  Une grande partie est du département de l'Ain n'affiche plus les
  landuse ; il semble qu'il y ait un polygone que je n'ai pas identifié
  (un arrondissement ?) qui s'intercale sur différents rendu :
  http://www.openstreetmap.org/#map=13/45.9446/5.8167
 
  C'est visible à différents niveaux de zoom (mais pas tous, une histoire
  de caches j'imagine) et sur différent rendus, par ex sur HOT :
  http://www.openstreetmap.org/#map=14/45.9337/5.8138layers=H
 
  ou sur le rendu FR :
  http://tile.openstreetmap.fr/?zoom=14lat=45.9543lon=5.8358layers=B000FFF
 
  Les données de landuse sont toujours présentes cependant (visibles dans
  JOSM par exemple).
 
  Je ne sais pas si ça apparaît dans d'autres coins de France ou du monde,
  mais ça a quand même l'air d'être lié à l'Ain vu la limite
  départementale sur le Rhône...
 
  Une idée de la cause et du moyen de réparer ?
 
  Cordialement
 
  ___
  Talk-fr mailing list
  Talk-fr@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/talk-fr
 
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Problème de rendu dans l'Ain

[didier2020]

Le dimanche 25 janvier 2015 à 21:05 +0100, Michael Delorme a écrit : 
 Bien vu, ça semble être résolu. Merci !
 
 Pour ma culture générale comment as-tu identifié la source du problème ?
le marron ... qui est sur des carrés et qui apparement ne correspond a
rien ... = c'est un tag building=yes ou landuse=quarry sur une
relation, ici une grande
pour trouver:
- avec josm, regarder les tags des relations avec beaucoup de membres
ou
- avec la carte openstreemap, dezoumer et cliquer sur historique (en
vert au dessus de la carte) puis regarder les changeset ayant une tres
grande emprise (rectangle orange sur la carte)

 
 Cordialement
 
 Le 25/01/2015 20:56, didier2020 a écrit :
  
  a voir si cela suffit :
  http://www.openstreetmap.org/changeset/28403845
  
  je corrige régulierement ce genre d'erreur qui provient généralement de
  l'éditeur id qui permet d'attribuer une modification a une relation a la
  place du way voulu
  
  
  
  Le dimanche 25 janvier 2015 à 20:44 +0100, Michael Delorme a écrit : 
  Bonsoir
 
  Une grande partie est du département de l'Ain n'affiche plus les
  landuse ; il semble qu'il y ait un polygone que je n'ai pas identifié
  (un arrondissement ?) qui s'intercale sur différents rendu :
  http://www.openstreetmap.org/#map=13/45.9446/5.8167
 
  C'est visible à différents niveaux de zoom (mais pas tous, une histoire
  de caches j'imagine) et sur différent rendus, par ex sur HOT :
  http://www.openstreetmap.org/#map=14/45.9337/5.8138layers=H
 
  ou sur le rendu FR :
  http://tile.openstreetmap.fr/?zoom=14lat=45.9543lon=5.8358layers=B000FFF
 
  Les données de landuse sont toujours présentes cependant (visibles dans
  JOSM par exemple).
 
  Je ne sais pas si ça apparaît dans d'autres coins de France ou du monde,
  mais ça a quand même l'air d'être lié à l'Ain vu la limite
  départementale sur le Rhône...
 
  Une idée de la cause et du moyen de réparer ?
 
  Cordialement
 
  ___
  Talk-fr mailing list
  Talk-fr@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/talk-fr
  
  
  
  ___
  Talk-fr mailing list
  Talk-fr@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/talk-fr
  
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Mise à jour du bâti sur une commune

[didier2020]

Le vendredi 16 janvier 2015 à 22:01 +0100, jean navarro a écrit : 
 Bonsoir
 
 merci pour vos réponses... je fais des tests ...
 
 dans Josm je ne peux que télécharger une zone rectangulaire pas une 
 commune... 
tu peu utiliser ca:
http://osm2020.free.fr/dwcadastre/index.html




___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] rendu qa : analyse par commune

[didier2020]

Bonjour a tous,

c'est toujours la : http://osm2020.free.fr/qa-commune/suivi-cadastre.htm

nouveautés pour 2015 :
- la base de données exclus les iles anglo-normandes et Genève. 
- Top 10 des modifications (nombre de creation,modification ou
effacement par user) entre 2 analyses (maintenant quotidienne si j'oubli
pas d'allumer mon pc le soir ...)
- Posibilité de télécharger un fichier .osm ouvrable dans josm pour
telecharger tout le contenu dans l'emprise d'une commune (pratique pour
le post-import cadastre) : http://osm2020.free.fr/dwcadastre/index.html




___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] cadastre - telechargement commune pour josm

[didier2020]

bonjour,

a disposition la liste des emprises des communes du cadastre 
http://osm2020.free.fr/dwcadastre/index.html

c'est pour josm et remote activé

le fichier est vide, il suffit d'aller dans le menu Fichier = Mettre
a jour les données

cela telecharge par petit carré toutes les données de la commune

Si ca peut servir a quelqu'un d'autre que moi ...





___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

[didier2020]

Le vendredi 02 janvier 2015 à 12:13 +0100, Christian Quest a écrit : 
 Et une petite carte overpass-turbo pour l'occasion:
 http://overpass-turbo.eu/s/6MO

je connaissais pas ce type de requete c'est plutot pratique ! 
 
 
 
 -- 
 Christian Quest - OpenStreetMap France
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

[didier2020]

2 questions :

Le jeudi 01 janvier 2015 à 09:11 +0100, Damouns a écrit : 
 Bonjour et bonne année à tous !
 
 
 J'ai répertorié 13 communes nouvelles créées au 1er janvier en France,
 qui sont listées sur cette page :
 http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives/Modifications_planifi%C3%A9es
 
 
 Pour le dire simplement, les communes nouvelles sont en fait des
 fusions de communes qui conservent un certain statut aux communes
 supprimées.
 
 Je fais appel aux bonnes volontés pour les intégrer dans OSM : c'est à
 dire passer en admin_level=9 
le wiki dit que c'est pour paris,marseille et lyon ...


 les anciennes communes et créer une nouvelle commune en admin_level=8,
 et choisir le bon chef-lieu en admin_centre (il est indiqué dans
 l'arrêté).
le ref:INSEE de la nouvelle relation ? 
 
 
 Merci de noter dans la page du wiki si vous vous chargez d'une commune
 nouvelle.
 
 
 
 Il y a aussi des modifications sur les arrondissements (ressorts des
 sous-préfectures) mais je ne les ai pas listés et il faudra peut-être
 attendre le Code Officiel Géographique 2015 de l'INSEE pour les
 intégrer dans OSM.
 
 
 Merci et tous mes voeux pour 2015
 
 
 Damouns
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Bonne année

[didier2020]

Le jeudi 01 janvier 2015 à 22:05 +0100, Francescu GAROBY a écrit : 
 Bonne année à vous tous.
 
 Pour la peine, je vous envoie une carte de Voeu :
 http://www.openstreetmap.org/node/319553763#map=16/47.0249/1.8784
ils devraient faire un echange ces 2 la :

http://www.openstreetmap.org/node/2311124984

 
 
 Francescu
 
 
 Le 1 janvier 2015 21:55, Christian Quest cqu...@openstreetmap.fr a
 écrit :
 Le découpage NUTS n'est pas (en théorie) administratif...
 chaque niveau représente en principe une population plus ou
 moins comparable d'un pays à l'autre. 
 
 
 Il serait donc de mon point de vue plus logique de conserver
 le découpage NUTS sur l'ensemble Rhône + Métropole, plutôt que
 d'avoir 2 polygones avec le même ref:NUTS. 
 
 
 
 Le 1 janvier 2015 21:42, Otourly Wiki otou...@yahoo.fr a
 écrit : 
 Donc il faux créer une relation qui englobe le tout
 spécifiquement pour la subdivision NUTS ? 
   
 Florian
 
 
 
 
 Le Jeudi 1 janvier 2015 20h42, Philippe Verdy
 verd...@wanadoo.fr a écrit :
 
 
 
 Note que la subdivision NUTS contient encore tout le
 département du Rhône y compris la métropole de Lyon
 qui s.'en est détachée. Pas sûr que NUTS soit invalidé
 ou mis à jour avant longtemps) 
 Le 1 janv. 2015 16:43, Otourly Wiki
 otou...@yahoo.fr a écrit : 
 Bonne année
 
 Et pour bien commencer l'année une
 modification non des moindres : 
 http://www.openstreetmap.org/relation/1663048
 
 http://www.openstreetmap.org/relation/7378
 
 
 
 Du coup il faudra prévoir une mise à jour
 du(des) jeu(x) de données concernés sur le
 portail Opendata 
 
 
 Florian
 
 
 
 
 -- 
 Christian Quest - OpenStreetMap France 
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr
 
 
 
 
 -- 
 Francescu
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Couche QA malade ?

[didier2020]

Le dimanche 21 décembre 2014 à 15:13 +0100, Christian Quest a écrit : 
 Je pense revoir le mode de génération de ce rendu. Actuellement un
 gros croisement est fait entre les données OSM et les carreaux de
 l'INSEE... c'est à dire des millions d'objets croisées avec des
 millions d'objets.
 
il y a 25% des batiments avec wall=no ...
un batiment leger n'a pas necessairement d'habitant ?
 
 J'envisage pour chaque carreau INSEE, de maintenir son état de
 couverture dans OSM. Il serait possible de ne mettre à jour que ceux
 qui avaient été détectés comme incomplets, car c'est bien rare qu'on
 supprime des données. Plus on avance, moins il y aura de carreaux à
 vérifier, alors qu'il y a de plus en plus de données.
 
rien n'empeche de faire les 2 ... 
le 1er du mois, analyse complete
les autres jours un diff

 
 Devoirs de vacances ;)
 
vacances = procrastination+ : pourquoi faire aujourd'hui ce que
quelqu'un autre peut faire a ta place demain
 
 
 Le 21 décembre 2014 14:05, Tetsuo Shima tets...@gmail.com a écrit :
 Ou mieux une heatmap des zone a mapper...
 
 
 Le 21 décembre 2014 14:04, Tetsuo Shima tets...@gmail.com a
 écrit : 
 
 En passant, serait il possible sur la couche QA de
 mettre en évidence - peut etre en séparant les couche
 - les zone a mappée. Elle se retrouve caché sous les
 point commune/cadastre au faible zoom et on a du mal a
 prendre conscience de l'ampleur du travail qu'il reste
 a faire pour mapper rien que les voies qui conduisent
 aux habitations...
 
 
 Plus je mappe les rue avec le mapcraft BANO plus je
 m'apercoit qu'il manque quantité de voies surtout a la
 campagne!!! Mais vraiment beaucoup.
 
 
 Le 19 décembre 2014 17:01, Christian Quest
 cqu...@openstreetmap.fr a écrit : 
 
 Oui, quelques pépins avec QA qui me bouffe
 bien trop de temps de calculs.
 
 
 Je vais avoir un peu de temps dispo sur les 2
 semaines qui viennent pour m'y pencher plus
 sérieusement...
 
 
 2014-12-19 14:41 GMT+01:00 JB
 jb...@mailoo.org:
 La couche QA ne supporte pas la
 pluie ? On a perdu plein
 d'information, aujourd'hui (mais je ne
 sais pas de quand ça date) :
 
 http://tile.openstreetmap.fr/?zoom=9lat=47.97976lon=4.75217layers=B000TFF
 
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 
 https://lists.openstreetmap.org/listinfo/talk-fr 
 
 
 
 -- 
 Christian Quest - OpenStreetMap France 
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr
 
 
 
 
 
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr
 
 
 
 
 
 -- 
 Christian Quest - OpenStreetMap France
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Mise à jour cadastre.openstreetmap.fr

[didier2020]

la requete overpass ne recupere pas les relations type multipolygon
avec le tag building= yes ET l'outer/inner n'a pas de tag building

par exemple  : http://www.openstreetmap.org/relation/974888

Le lundi 22 décembre 2014 à 02:13 +0100, Yoann Cornec a écrit : 
 Le problème est sur la rue Paul Vaillant Couturier, à Alfortville.
 
 J'ai relancé l'extraction à l'instant (avec l'overpass DE). Elle
 continue à m'intégrer des données supprimées depuis 20 jours.
 Voilà le zip contenant les données qui posent problème. Chaque
 nouvelle extraction écrase les précédentes ?
 
 
 Le 21 décembre 2014 22:02, Vincent de Château-Thierry
 osm.v...@free.fr a écrit :
 
 Le 21/12/2014 18:47, Vincent de Château-Thierry a écrit :
 
 Le 21/12/2014 17:06, Yoann Cornec a écrit :
 Là, elle a au moins 20 jours de retard.
 Est-ce que le script ne conserverai pas des
 données osm de précédentes
 exécutions en cache ?
 Mes modifs non prises en compte ont été faites
 après la première
 extraction des adresses de cette ville.
 
 Et tu as rejoué l'extraction récemment, mais sans
 bénéficier des mises à
 jour ? Je viens de regarder et on n'a pas de cache, du
 moins en théorie.
 Si tu peux m'indiquer la commune, je regarde ça ce
 soir.
 
 Possible que les soucis soient liés à l'overpass FR. J'ai
 basculé les traitements sur l'Overpass DE (overpass-api.de) et
 j'ai des résultats différents et cohérents. Si tu peux
 ré-essayer ?
 
 vincent 
 
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr
 
 
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] download.openstreetmap.fr/replication/ http://suivi.openstreetmap.fr/communes/ en panne

[didier2020]

Le vendredi 19 décembre 2014 à 19:15 +0100, Jocelyn Jaubert a écrit : 
 Le 19/12/2014 18:52, didier2020 a écrit :
  tout est dans le titre ...
 
 download avait l'air bon vu d'ici, par contre, suivi était en carafe. J'ai
 redémarré apache sur suivi, et ça remarche.
 
 Tu as toujours des problèmes ?
pas la semaine de Noel ...

sinon la replication france date du 17 
http://download.openstreetmap.fr/replication/europe/france/minute/state.txt 




___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] osm3.openstreetmap.fr OSM OverpassDB lag

[didier2020]

pour les gestionnaires ...
http://munin.openstreetmap.fr/osm-day.html




___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Couche QA - zones à mapper

[didier2020]

peut rien a voir mais les diffs se sont arrétés au 29/11:
http://download.openstreetmap.fr/replication/europe/france/minute/state.txt

- Mail d'origine -
De: JB jb...@mailoo.org
À: Discussions sur OSM en français talk-fr@openstreetmap.org
Envoyé: Mon, 01 Dec 2014 10:45:50 +0100 (CET)
Objet: [OSM-talk-fr] Couche QA - zones à mapper

Bonjour,
La couche QA - zones à mapper est-elle entretenue, notamment pour les 
communes dont le cadastre est vectoriel n'ayant pas de batiments ? Les 
données semblent un peu en retard.
JB.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] BANO/FANTOIR : portion de rue sans nom mais avec des adresses rapprochées !?

[didier2020]

Actuellement, les scripts de rapprochement ne sont pas géographiques

osmose fait cette analyse :
http://osmose.openstreetmap.fr/fr/errors/?country=france*item=2060class=9


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Qualification des erreurs en lien avec FANTOIR

[didier2020]

Actuellement il y a 4 colonnes avec/sans adresse et avec/sans rapprochement 
osm
il serait peut etre interessant de n'avoir que 2 colonnes et l'info si adresse 

Code FANTOIR - Voie FANTOIR - Adresse - Voie OSM - Cartes - Édition - Statut 
FANTOIR

cela permettrait de mieux voir les libellés des voie Fantoir (place truc, rue 
truc, rue trucx) indépendement du fait quelles ait des adresses ou pas
le but etant de nommer au mieux toutes les voies 

en tout cas, compliment au travail de l'equipe Bano


- Mail d'origine -
De: Vincent de Château-Thierry osm.v...@free.fr
À: Discussions sur OSM en français talk-fr@openstreetmap.org
Envoyé: Thu, 27 Nov 2014 09:19:28 +0100 (CET)
Objet: [OSM-talk-fr] Qualification des erreurs en lien avec FANTOIR

Bonjour,

http://cadastre.openstreetmap.fr/fantoir/ permet maintenant de 
qualifier, ligne par ligne, des divergences et/ou anomalies constatées 
lors des tentatives de rapprochement des données OSM, Cadastre et 
Fantoir (pensez à purger vos caches navigateur).

La liste des items avait été amorcée ici-même, je l'ai un peu revue et 
actualisée sur le wiki [1], elle reste évidemment ouverte à suggestions, 
tant sur les formulations que sur l'inventaire des cas.
Le premier bénéfice attendu est d'identifier visuellement les voies 
qualifiés, et en creux le vrai reste à faire sur une commune, en 
distinguant les lignes à 'Ok' des autres. Incidemment, la qualification, 
stockée en base et historisée, permettra d'alimenter un dialogue avec la 
DGFiP le jour où nous aurons un peu de matière accumulée.

vincent

[1] : 
http://wiki.openstreetmap.org/wiki/WikiProject_France/WikiProject_Base_Adresses_Nationale_Ouverte_(BANO)#Typologie_des_anomalies_FANTOIR

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Re : Re: Base officielle et libre des Codes Postaux

[didier2020]

Bano ! (plutot chapeau...)

- Mail d'origine -
De: Christian Quest cqu...@openstreetmap.fr
À: Discussions sur OSM en français talk-fr@openstreetmap.org
Envoyé: Fri, 14 Nov 2014 12:33:52 +0100 (CET)
Objet: Re: [OSM-talk-fr] Base officielle et libre des Codes Postaux

Mais... la journée n'est pas terminée ;)

Dans le cadre de la semaine de l'innovation publique, ce soir à 17h au 104
à Paris sera signé un accord sur la Base Adresse Nationale entre
- l'Administrateur Général des Données
- le SGMAP/Etalab
- l'IGN
- Le Poste
et
... OpenStreetMap France

Donc ça va aussi se décoincer de ce côté. C'est l'aboutissement de plus de
2 ans passés à établir le climat de confiance et à porter la bonne parole
du libre qui se concrétise enfin.
La pression mise par BANO et le projet de BANO^2 ont aidé de faire bouger
les lignes en quelques mois plutôt qu'en quelques années.

Cet accord va permettre à OSM de diffuser les données de la BAN sous
licence ODbL, et un portail national de l'adresse permettra de contribuer
dans la BAN et OSM pour tout ce qui est corrections, améliorations,
signalements, etc.
Nous convergeons donc plutôt que de créer des bases parallèles qui
formeraient des silos bien idiots (comme si il n'y avait pas déjà trop de
Bases d'Adresses en silos).


Le 14 novembre 2014 12:18, Pieren pier...@gmail.com a écrit :

 2014-11-14 11:13 GMT+01:00 Christian Quest cqu...@openstreetmap.fr:

 Euh, je pense qu'on aurait pu se passer de ce fichier (même s'il peut
 accélérer le travail). Ce qui nous manque, si j'ai bien compris, c'est
 uniquement le découpage intra-communal lorsqu'il y a plusieurs codes.
 Là, à part sonner à chaque porte pour demander le code postal (ou
 interroger les facteurs), il n'y a guère que la Poste qui puisse
 fournir cette information (peut-être les mairies)

 Pieren

 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr




-- 
Christian Quest - OpenStreetMap France


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Site web pour récupérer coordonnées coin gauches, coin droite?

[didier2020]

j'ai creusé car ça m'interesse aussi
clic sur la carte ...

http://osm2020.free.fr/videophoto/showbbox/showbb.html


Le jeudi 13 novembre 2014 à 09:28 -0700, Shohreh a écrit : 
 Greg wrote
  Comme je constate qu'il s'agit d'une conversation fleuve et que le
  challenge m'a plu, j'ai fait une solution 1-clic.
 
 J'ai testé mais outre qu'il faut avoir le JS dans son navigateur, ça ne
 prend pas en compte le zoom effectué dans la carte : les coordonnées sont
 juste celles d'origine, avant de zoomer/se déplacer dans la carte.
 
 The search goes on…
 
 
 
 --
 View this message in context: 
 http://gis.19327.n5.nabble.com/Site-web-pour-recuperer-coordonnees-coin-gauches-coin-droite-tp5823551p5824255.html
 Sent from the France mailing list archive at Nabble.com.
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Site web pour récupérer coordonnées coin gauches, coin droite?

[didier2020]

- Mail d'origine -
De: Sylvain Maillard sylvain.maill...@gmail.com
À: Discussions sur OSM en français talk-fr@openstreetmap.org
Envoyé: Wed, 12 Nov 2014 16:01:52 +0100 (CET)
Objet: Re: [OSM-talk-fr]Site web pour récupérer coordonnées coin 
gauches, coin droite?

Le 10 novembre 2014 15:03, Shohreh codecompl...@free.fr a écrit :

 J'ai cliqué sur Export en haut et ça télécharge le fichier de 1.4MB.

 J'ai besoin des quatre coins (coordonnées) de la carte pour construire mon
 URL : comment faire?

avec josm:
menu fichier-Telecharger
= dans l'onglet carte glissante, sélectionner l'emprise voulue (sans 
telecharger)
= clic sur l'onglet zone delimitée = utiliser les coordonnées maxi et mini 
des latitude et longitude


Salut,

pour ma part quand je clique sur le bouton Exporter du menu principal, ça
m'ouvre un onglet sur la gauche avec une petite boite qui affiche les
coordonnées nord/sud/est/ouest + un lien Sélectionner manuellement une
autre zone, et seulement en dessous le bouton exporter qui fait
télécharger un fichier.

Les chiffres présents dans la boite correspondent aux coordonnées dont il y
a besoin pour afficher la carte topo sur la zone voulue (testé).
Pas besoin de télécharger de fichier, juste un copier/coller depuis le site
principal osm ...


Sylvain


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] cadastre-fantoir-bano

[didier2020]

on gere ca comment ?

- insee 19229
Saint-Pantaléon-de-Larche

- fantoir
192290133M AV PIERRE MENDES FRANCE
http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#18/45.1428453613/1.46711803791

- cadastre, intérogation des parcelles de la zone
il y a plusieurs adresses sur une meme parcelle, comme celle-ci :

Références de la parcelle 000 BC 187
   Référence cadastrale de la parcelle 000 BC 187
   Contenance cadastrale   898 mètres carrés
   Adresse 63 AV PIERRE MENDES
   FRANCE
   19600 SAINT-PANTALEON-DE-
   LARCHE
   Adresse 63 N RN 89
   19600 SAINT-PANTALEON-DE-
   LARCHE



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Lot Talk-fr, Vol 100, Parution 36

[didier2020]

Le mercredi 05 novembre 2014 à 16:52 +0100, Enrico Mattea a écrit : 
  Bonjour,
 
  De: Enrico Mattea ocirn...@gmail.com
  je veux ajouter le nom à un batiment qui a eté importé du cadastre.
  La geometrie du batiment est divisée en trois, et j'aimerais bien
  préserver cette division, mais le nom s'applique a tout le batiment et ça 
  n'a
  pas de sens d'appliquer la tag trois fois. Comment faire?
  Est-ce que tu peux donner un lien vers la carte de l'endroit ?
 
  vincent
 
 
 
  Message: 4
  Date: Wed, 5 Nov 2014 16:16:37 +0100
  From: Christian Quest cqu...@openstreetmap.fr
  To: Discussions sur OSM en français  talk-fr@openstreetmap.org
  Subject: Re: [OSM-talk-fr] Nom des batiments importées
  Message-ID:
  CAAXY6DMdJ0ddmx=spdb=_6nSVy_ibAdRh6otbsMVRe4=ncn...@mail.gmail.com
  Content-Type: text/plain; charset=iso-8859-1
 
  Si il s'agit d'un bâtiment, divisé en trois morceaux, tu peux utiliser
  building:part=* qui sert justement à ça
  http://wiki.openstreetmap.org/wiki/FR:Key:building:part
 
  Ajoute un polygone building=* sur l'ensemble et met le nom sur celui là...
 
  Le 5 novembre 2014 14:29, Enrico Mattea ocirn...@gmail.com a écrit :
 
  Bonjour,
  je veux ajouter le nom à un batiment qui a eté importé du cadastre. La
  geometrie du batiment est divisée en trois, et j'aimerais bien préserver
  cette division, mais le nom s'applique a tout le batiment et ça n'a pas de
  sens d'appliquer la tag trois fois. Comment faire?
  Merci,
  Enrico
 
  ___
  Talk-fr mailing list
  Talk-fr@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/talk-fr
 
 
 Bonjour, merci pour vos réponses.
 Les trois voies sont 97309966, 97318747 et 97324585.
 Je ne sais pas pourquoi le bâtiment a eté divisé en trois morceaux par 
 le cadastre, puisque la division interieure est bien plus compliquée que ça.


on zoomant sur la carte de chamonix mont blanc de cadastre.gouv.fr
on arrive a peine a voir un filet blanc dans l'orange qui explique ce
découpage 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] cadastre-fantoir-bano

[didier2020]

Le mercredi 05 novembre 2014 à 17:12 +0100, Christian Quest a écrit : 
 La bonne adresse est la première... mais oui c'est un cas
 particulier intéressant pour renseigner un alias du nom de voie,
 peut être via un alt_name mais c'est un peu tordu.
 

dans le doute , pour osm : je fais rien . 
de plus je pense que c'est une erreur du cadastre ou la premiere adresse
n'est pas la bonne . (j'y passe dans 2 jours ..)

j'ai trouvé le meme cas a nogent le roi ... (récurrent ?)
http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#18/48.6445377396/1.52643627314
pour la parcelle
Référence cadastrale de la parcelle 000 AC 62
Contenance cadastrale   801 mètres carrés
Adresse 627L CHE DU CIMETIERE
28210 NOGENT LE ROI
Adresse 11 RUE DU BOIS AUX DAIMS
28210 NOGENT LE ROI

 
 
 Le 5 novembre 2014 16:50, didier2020 didier2...@free.fr a écrit :
 on gere ca comment ?
 
 - insee 19229
 Saint-Pantaléon-de-Larche
 
 - fantoir
 192290133M AV PIERRE MENDES FRANCE
 
 http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#18/45.1428453613/1.46711803791
 
 - cadastre, intérogation des parcelles de la zone
 il y a plusieurs adresses sur une meme parcelle, comme
 celle-ci :
 
 Références de la parcelle 000 BC 187
Référence cadastrale de la parcelle 000 BC 187
Contenance cadastrale   898 mètres carrés
Adresse 63 AV PIERRE MENDES
FRANCE
19600
 SAINT-PANTALEON-DE-
LARCHE
Adresse 63 N RN 89
19600
 SAINT-PANTALEON-DE-
LARCHE
 
 
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr 
 
 
 
 -- 
 Christian Quest - OpenStreetMap France
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Plugin Osmose pour Josm

[didier2020]

sous debian, j'utilise le jre, josm-tested lancé en ligne de commande du genre 
java -jar --Xmx=2048M josm-tested.jar


- Mail d'origine -
De: Yves Pratter yves.prat...@gmail.com
À: Discussions sur OSM en français talk-fr@openstreetmap.org
Envoyé: Mon, 03 Nov 2014 09:14:06 +0100 (CET)
Objet: Re: [OSM-talk-fr] Plugin Osmose pour Josm

 Idem ici sous linux, relire la doc qui est complète qui couvre bien : prendre 
 la jar, l'ajouter dans le menu de josm, lancer le script
 
C’est fait ;-)

Mais j’ai quand même le problème.
En affichant la console de Java, ce message apparait : « ATTENTION : Version 
principale du greffon jython manquante. » 
Ça confirme juste ce que dit le greffon scripting de JOSM.

Jean-Baptiste et Didier, quel Java utilisez-vous ? le JRE  (version exécution) 
ou le JDK (version développement) ?
Didier, ta machine tourne aussi sous Linux ?

J’ai une version JRE 1.7.0_71-b14.
J’ai essayé aussi avec jython2.5.3 et il fonctionne bien en ligne de commande.

Il y a peut-être un bug avec Java sous la dernière version de Mac OS X (les 2 
premiers jours, impossible de lancer java)

Je télécharge le JDK 8.0 (je n’arrive pas à trouver un JDK 7.0 pour cette 
version de Mac OS)

—
Yves

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Plugin Osmose pour Josm

[didier2020]

Le lundi 03 novembre 2014 à 21:20 +0100, Yves Pratter a écrit : 
  Le plugin n'est plus à jour. Il ne compile plus avec le JOSM actuel.
  Je peux donner l'URL des sources (le temps que je la retrouve). Mais le 
  plugin est plutôt un hack du plugin de OpenStreetBug que un vrais plugin.
 Je vais essayer l’outil Python sur un PC pour me faire une idée de son 
 intérêt.
 De même pour OpenStreetBug.
 
 Frédéric — ou d’autres — avez-vous essayer les 2, les 3 ?
l'interet/non interet de qat_script est 
- d'avoir les detecteurs d'erreurs que l'on désire 
- choisir le niveau de gravité des erreurs
- choix du type d'erreur que l'on désire (moins pratique que sur le web)
- choix de la zone étudiee 
- telechargement par bbox sur les erreurs
- qualifier les faux positifs

je trouve qu'il est plus pratique quand on a choisi une typologie
d'erreur a corriger que pour voir toutes les erreurs d'une zone

pour faire simple : +1 

 
 —
 Yves
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Bano en panne ?

[didier2020]

Le lundi 03 novembre 2014 à 21:45 +0100, Vincent de Château-Thierry a
écrit : 
 Le 03/11/2014 21:29, Yves Pratter a écrit :
 
  Toujours pas de changements depuis plus d’une semaine…
 
  Tu as des nouvelles ?
 
 Le rechargement évoqué par Christian a à son tour échoué. Donc rebelote 
 depuis hier soir, avec le dernier planet.
 Les thermomètres sont ici :
 http://munin.openstreetmap.fr/osm12.free.org/osm105.openstreetmap.fr/postgres_size_ALL.html
  
 pour le remplissage de la base,
 et là :
 http://munin.openstreetmap.fr/osm12.free.org/osm105.openstreetmap.fr/osm_replication_lag_osm2pgsql.html
 pour le retard des données.
 
 Tant que cette base n'a pas atteint sa cible de remise à jour en 
 continu, et de rattrapage de son retard, les services affectés sont côté 
 BANO la base elle même (le contenu est figé), et ses dérivés : les 
 tuiles carto, et les listes Fantoir. On continue de faire rentrer les 
 nouvelles communes vectorielles du cadastre, mais faute de confrontation 
 au contenu OSM, rien n'est publié en sortie.
 
  On 26 Oct 2014, at 22:59, Vincent de Château-Thierry osm.v...@free.fr
  mailto:osm.v...@free.fr wrote:
 
  = À voir, comment récupérer cette info dans le process.
  Peut-être en récupérant la date la plus récente sur les objets ou les
  changesets récupérés lors de la dernière synchro ?
 
 L'heuristique consiste à récupérer la date de création du node avec l'ID 
 le plus élevé. Il faut juste le faire sans abuser d'appels à la base. 
 Donc attente de la remise sur pied du contenu pour tester l'idée.
 
 vincent
 
S'il y a mise a jour de la base, il y a un fichier state, le timestamp
est dedans non ?

 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Plugin Osmose pour Josm

[didier2020]

Le dimanche 02 novembre 2014 à 11:32 +0100, Yves Pratter a écrit :
 Bonjour,
 
 
 J’ai passé du temps à corriger les erreurs sur les pharmacies avec
 Josm et Osmose sur une page web.
 À force de crier, mes phalanges m’ont suggérées l’idée d’une
 plugin :-)
 
 
 Une petite consultation du web, et miracle il existe depuis plus de 3
 ans :-)
 [OSM-dev-fr] Plugin Osmose pour Josm
 
 
 Je l’aurais bien essayé mais le lien n’est plus valable et il n’est
 pas disponible dans la liste des greffons de Josm.
 
 
 Pouvez-vous m’éclairer ?

regarde plutot ici
http://wiki.openstreetmap.org/wiki/Quality_Assurance_Tools_script


 
 
 Merci d’avance,
 
 
 —
 Yves
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Plugin Osmose pour Josm

[didier2020]

Le dimanche 02 novembre 2014 à 13:01 +0100, Yves Pratter a écrit : 
  regarde plutot ici
  http://wiki.openstreetmap.org/wiki/Quality_Assurance_Tools_script
 
 Merci, je regarde demain :-)
 
 Et aussi pourquoi il n’apparait pas dans la liste des greffons ;-)
ce n'est pas un greffon : qat_script utilise l'api d'osmose
http://wiki.openstreetmap.org/wiki/FR:Osmose/api/0.2 
 
 —
 Yves
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr