Re: [OSM-talk-fr] Plans lignes RER?

2015-02-27 Diskussionsfäden Paul Mallet
http://overpass-turbo.eu/s/7UC ?

Paul MALLET

Le 27 février 2015 23:59, Shohreh codecompl...@free.fr a écrit :

 Bonjour

 Ça fait 15mn que je cherche par Google et rien trouvé

 J'ai besoin, pour chaque ligne RER, de trouver le tracé géographique,
 c.a.d.
 avec l'IdF en fond de carte, par le plan de ligne administratif type
 SNCF/RATP.

 Pour la ligne C, par exemple:

 Transilien, c'est juste les plans de ligne:
 http://www.transilien.com/static/plans-reseau/plan-ligne

 Wikipedia est illisible
 http://upload.wikimedia.org/wikipedia/commons/b/b4/RER_C.svg

 Pas de carte sur le site officiel SNCF:
 http://malignec.transilien.com/

 OSM rendu Transport affiche tout sans information:
 http://www.openstreetmap.org/#map=11/48.8516/2.4091layers=T

 Quelqu'un a une idée?

 Merci.



 --
 View this message in context:
 http://gis.19327.n5.nabble.com/Plans-lignes-RER-tp5835260.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] BDCarthage - Ruisseau, cours d'eau et temporalité / saisonnalité

2014-09-25 Diskussionsfäden Paul Mallet
Sur le rendu HOT c'est pris en compte (hachuré) de mémoire...

Paul MALLET

Le 25 septembre 2014 11:57, Pieren pier...@gmail.com a écrit :

 2014-09-25 11:32 GMT+02:00 Jérôme Seigneuret jseigneuret-...@yahoo.fr:

  Y a t'il un fond OSM avec un style particulier pour cela?


 Peut-être voir du côté des cartes de ITO World:
 http://www.itoworld.com/map/group/3

 Je n'ai rien trouvé sur les intermittent ou seasonal mais je sais
 qu'ils sont assez ouverts pour les suggestions (depuis leur site web)

 Pieren

 ___
 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] BDCarthage - Ruisseau, cours d'eau et temporalité / saisonnalité

2014-09-25 Diskussionsfäden Paul Mallet
@Jérôme : http://www.openstreetmap.org/#map=16/12.3058/8.0343layers=H


Paul MALLET

Le 25 septembre 2014 17:02, Jérôme Seigneuret jseigneuret-...@yahoo.fr a
écrit :

 @Paul as-tu un lien pour que je puisse visualiser cela.

 Sinon avec le tuilage BD-Carthage dans l'éditor ID
 http://{switch:a,b,c}.
 tile.openstreetmap.fr/route500hydro/{zoom}/{x}/{y}.png
 http://tile.openstreetmap.fr/route500hydro/%7Bzoom%7D/%7Bx%7D/%7By%7D.png
 Mais il n'y a pas cette info c'est dommage. Il faudrait un tuilage par
 paramètre thématique.

 D'ailleurs je viens de me rendre compte qu'ID n'accepte pas de faire de la
 superposition et qu'il ne prend le tile comme une surcouche mais comme un
 fond de carte... Pas cool


 Le 25 septembre 2014 14:04, Paul Mallet cont...@paulmallet.net a écrit :

 Sur le rendu HOT c'est pris en compte (hachuré) de mémoire...

 Paul MALLET

 Le 25 septembre 2014 11:57, Pieren pier...@gmail.com a écrit :

 2014-09-25 11:32 GMT+02:00 Jérôme Seigneuret jseigneuret-...@yahoo.fr:

  Y a t'il un fond OSM avec un style particulier pour cela?


 Peut-être voir du côté des cartes de ITO World:
 http://www.itoworld.com/map/group/3

 Je n'ai rien trouvé sur les intermittent ou seasonal mais je sais
 qu'ils sont assez ouverts pour les suggestions (depuis leur site web)

 Pieren

 ___
 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] Questions de tagging

2014-09-21 Diskussionsfäden Paul Mallet
Attention a ne pas confondre natural=heath et heaLth ;)

https://wiki.openstreetmap.org/wiki/Tag:natural%3Dheath

Pas vraiment la même chose..

Paul MALLET

Le 21 septembre 2014 18:40, Pierre-Yves Berrard 
pierre.yves.berr...@gmail.com a écrit :

 Bonjour,

 Le 21 septembre 2014 18:06, Greg ewala...@gmail.com a écrit


 https://www.openstreetmap.org/node/3089170320

 Ajouter cuisine=kebab.

 https://www.openstreetmap.org/node/3089172021

 Il existe shop=e-cigarette.



 ___
 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] Relation route et giratoire

2014-07-18 Diskussionsfäden Paul Mallet
OMG mais non surtout pas !!! Des fois un bus passe par une rue, tourne,
puis repasse par cette rue plus loin ! Impossible a mapper dans ton cas !

Pour les turn restrictions je n'en parle pas, vu que je n'ai jamais
pratiqué... (ce que tout le monde devrait faire a mon avis)
Le 18 juil. 2014 08:28, Francescu GAROBY windu...@gmail.com a écrit :

 Quand je renomme des rues (Bano) et que je tombe sur des rues coupées en
 tout petit morceaux à cause des bus (et des limitation de vitesse...), ça
 me fait bien ch...! mais tout le monde trouve ça normale.

 Couper une rue parce qu'un tag apparaît/disparaît/change de valeur, c'est
 normal...

 Par contre, je trouve ça très con de devoir couper une rue en deux, parce
 qu'un bus ne l'emprunte qu'en partie et tourne dans une autre rue...
 De-même, quand on fait une relation restriction=no_left_turn (ou autre
 restriction), où il faut parfois couper les rues en 2 pour que les tronçons
 'from' et 'to' s'arrêtent bien au node 'via' : tout aussi débile, selon moi
 !

 Bref, tout ça pour dire qu'on morcelle les éléments, sans garantie que les
 morceaux seront bien recollés plus tard (si le tracé de la ligne de bus
 vient à changer ou si l'interdiction de tourner à gauche disparaît, pour
 rester dans mes 2 exemples).

 Tout ça, pour moi, devrait pouvoir être déduit en toute logique : le bus
 passe cette rue, puis celle-là, c'est donc qu'il tourne à ce node.

 Francescu

 Le 18 juillet 2014 02:10, Jérôme Amagat jerome.ama...@gmail.com a écrit
 :

 Je vais donner mon avis moi aussi pourquoi pas.
 Avant de lire cette discussion je croyais (je l'avais surement lu ici
 meme) qu'il ne fallait pas couper les rond point mais maintenant je me dis
 pourquoi pas?
 Quand je renomme des rues (Bano) et que je tombe sur des rues coupées en
 tout petit morceaux à cause des bus (et des limitation de vitesse...), ça
 me fait bien ch...! mais tout le monde trouve ça normale. Le rond point
 c'est un bout de route aussi qui tourne en rond. on peut aussi voir le rond
 point comme UNE entité ronde ( ou plus ou moins) et non sécable mais a ce
 compte la pourquoi ne pas mettre les morceaux de route dans une relation
 avec le tag roundabout dans cette relation seulement (encore des
 relations!!).
 C'est du micro mapping, mais on est plus près de la réalité en coupant le
 rond point. pourquoi interdire ça plutôt que bien d'autre chose.

 Pour l'histoire des débutants, s'occuper des routes c'est pas le plus
 facile, les couper, mettre la même chose dans plusieurs tronçons,créer des
 relations routes...je pense pas que cette histoire de rond point change
 quoi que ce soit.



 Le 18 juillet 2014 01:00, Jo winfi...@gmail.com a écrit :

 L'argument des débutants qui ne comprendraient plus ou qui
 abandonneraient n'est pas solide non plus. Ils quitteront pour d'autres
 raisons que ça. Tronçonner un rond point n'ajoute pas de complexité.

 http://www.openstreetmap.org/#map=16/50.4151/4.4311layers=T

 C'est très visible, car c'est pour le moment la première relation bus à
 Charleroi.




 2014-07-18 0:37 GMT+02:00 Philippe Verdy verd...@wanadoo.fr:

 JOSM n'a aucun problème à afficher la continuité des chemins passant par
 un giratoire non tronçonné, et même à gérer les deux directions dans la
 même relation (avec certains parties séparées (en forward, très rarement
 en backward car la séparation implique presque toujours un sens unique dans
 la voie qui devrait être aussi tracée dans sa propre direction
 forwardavec oneway=yes, et pas à l'envers avec oneway=-1) et tout le
 reste bidirectionnel (rôle par défaut, y compris pour les giratoires).


 Le 16 juillet 2014 22:34, Pierre-Yves Berrard 
 pierre.yves.berr...@gmail.com a écrit :

 Toutes ces considérations sur le routage seraient valables si on avait
 un modèle de relation route avec des points de passage (comme exposé par
 Étienne).
 Or ce n'est pas le cas : la route est censée être entièrement
 déterminée par des segments. À aucun moment je ne vois dans la doc,
 l'itinéraire est défini par les segments de routes, *sauf sur les
 giratoires où il faudra faire appel à un algorithme de routage*.
 Donc, bien que cela soit coûteux en nombre d'objets dans osm, je ne
 vois pas comment,* avec le modèle actuel*, faire sans tronçonner ces
 maudits giratoires.

 ___
 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




 --
 Cordialement,
 Francescu GAROBY

 ___
 Talk-fr mailing list
 

Re: [OSM-talk-fr] Relation route et giratoire

2014-07-17 Diskussionsfäden Paul Mallet
Donc OK on tag en fonction d'un algorithme...


-__-


Paul MALLET


Le 17 juillet 2014 14:13, Pierre-Yves Berrard pierre.yves.berr...@gmail.com
 a écrit :

 Il aura quand même fallu attendre un bon paquet de messages avant que
 quelqu'un donne un exemple concret de problème causé par un tronçonnage de
 giratoire.

 Merci Christophe.

 Le 17 juillet 2014 13:52, Christophe Merlet red...@redfoxcenter.org a
 écrit :

 Le 17/07/2014 10:13, Jo a écrit :

  Sans un way continue marqué explicitement junction=roundabout la
 navigation vocale devient incompréhensible incapable de dire
 correctement où et quand sortir d'un rond-point.

 Idem en terme de description d'itinéraire :
 Avec rond-point : http://osrm.at/8vT

 Direction nord-ouest sur D 817
 Au rond-point, prenez la première sortie sur D 817
 Au rond-point, prenez la deuxième sortie sur D 817
 Au rond-point, prenez la deuxième sortie sur D 817
 Au rond-point, prenez la première sortie sur D 817
 Vous êtes arrivé

 Sans rond-point : http://osrm.at/8vU

 Direction sud sur Avenue Jean Mermoz
 Tournez légèrement à droite sur Rond-Point du Souvenir Français
 Tournez légèrement à droite sur Boulevard Champetier de Ribes
 Tournez légèrement à gauche sur Rue Michelet
 Tournez légèrement à droite
 Vous êtes arrivé


 ___
 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] Relation route et giratoire

2014-07-17 Diskussionsfäden Paul Mallet
Paul MALLET


Le 17 juillet 2014 16:06, Vincent Pottier vpott...@gmail.com a écrit :


 Un objet sur le terrain = un objet dans OSM
 C'est ça la visée d'OSM.



Ah bon ?

Et pour compter les routes, on compte les highway=* ?  et je ne parle pas
de la modélisation 3d des batiments ^^
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Relation route et giratoire

2014-07-17 Diskussionsfäden Paul Mallet
Depuis le début de ce débat on parle de tagger pour le rendu, d'algo de
routage etc. mais pour moi la seule chose à prendre en compte c'est la
réalité du terrain, hors dans la réalité, un bus (ou tout autre route) ne
fait pas le tour du rond point, donc seule la portion empruntée par le bus
devrait avoir la relation correspondante !

Pour découper le reste du rond point, c'est pour moi inutile si les ways
possèdent les mêmes tags et les mêmes relations...

PS : N'y a t'il pas des problèmes + importants ?

Paul MALLET


Le 17 juillet 2014 23:37, Éric Gillet fear.hardc...@gmail.com a écrit :

 Non; ce n'est pas pour faire joli sur un rendu, c'est pour se conformer à
 la réalité. Un rendu tire parti de ces modification, tant mieux.

 Évidemment que tout tagging est fait pour le rendu. Les données sont
 faites pour miroitier le plus près possible la réalité, et doit être
 exploitable par des outils, pour fournir un rendu (résultat) pour des
 humains...
 La règle de ne pas tagger pour le rendu veut plutot dire ne pas tagger
 pour UN rendu, pour éviter que des personnes pervertissent les données
 présentes dans la base afin que ça soit visible sur Mapnik.




 2014-07-17 21:50 GMT+01:00 Sylvain Maillard sylvain.maill...@gmail.com:

 Je maintient mon avis précédent : la totalité (ou quasiment) des
 rond-points cités en exemple ne sont découpés que pour 1 faire joli sur 1
 rendu particulier ...

 si le contributeur décide de découper le rond-point, alors il faut aller
 jusqu'au bout du modèle et faire une découpe complète à toutes (et
 uniquement) les entrées/sorties, et ne pas laisser des rond-points découpés
 là ou ça fait plus joli sur un rendu et non (ou mal) découpés là ou ça ne
 se vois pas !


 Sylvain


 Le 17 juillet 2014 22:12, Jo winfi...@gmail.com a écrit :

 http://www.openstreetmap.org/#map=17/50.71025/4.60467layers=T

 http://www.openstreetmap.org/#map=18/50.74104/4.68945layers=T

 http://www.openstreetmap.org/#map=18/50.81559/4.26312layers=T

 http://www.openstreetmap.org/#map=18/50.83748/4.11484layers=T

 http://www.openstreetmap.org/#map=18/50.84873/2.91817layers=T


 ___
 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] Relation route et giratoire

2014-07-16 Diskussionsfäden Paul Mallet
Pas forcément, si le bus (ou n'importe quel autre trajet) ne concerne que
2 intersections, il n'y a aucune raison de séparer le rond point au niveau
des autres intersections... (pourquoi séparer une voie en 2 segments
partageant les mêmes tags et faisant partie des mêmes relations ?)

Paul MALLET


Le 16 juillet 2014 12:20, Sylvain Maillard sylvain.maill...@gmail.com a
écrit :

 Surtout qu'on peut dire que la travail à été fait à moitié : si on veut
 vraiment découper un rond-point, dans ce cas il faut aller au bout de la
 démarche et le faire à chaque connexion de route, et pas seulement 2
 sorties sur 4 ...


 Sylvain


 Le 16 juillet 2014 12:14, Pierre-Yves Berrard 
 pierre.yves.berr...@gmail.com a écrit :

 Le 16 juillet 2014 11:52, Pieren pier...@gmail.com a écrit :

 2014-07-16 11:26 GMT+02:00 Stéphane Péneau stephane.pen...@wanadoo.fr:

  Connaître le parcours exact du véhicule. C'est vrai que cela peut
  compliquer l'édition, mais pas de façon insurmontable, selon moi.

 Mouais, c'est en général la réponse de ceux qui font ces découpages
 lorsque le giratoire est déjà là et bien rond ;-) L'opinion peut
 changer quand il faut réparer plusieurs giratoires altérés par des
 contributeurs peu attentifs. En plus, on pourrait se retrouver avec
 des giratoires incohérents (une partie en tertiary, une autre en
 secondary, etc).


 Les incohérences de tag sont faciles à détecter et à corriger. Et pour
 redéssiner un giratoire éclaté bien rond, on peut créer un chemin
 temporaire reprenant tous les points, faire un rond avec ce chemin, puis le
 supprimer.

 Le parcours exact du véhicule peut se reconstituer par logiciel.
 Mais c'est vrai que ça nécessite un peu de travail pour ceux qui
 veulent exploiter ces données. Mais il vaut mieux donner ce peu de
 travail supplémentaire aux data consumers, aux experts plutôt qu'aux
 contributeurs qui sont, pour leur immense majorité, des débutants.


 Cet argument me convainc davantage que celui de la difficulté d'édition.
 Peut-être que je ne couperai plus les giratoires à l'avenir...

 PY

 ___
 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] centre de jeux pour enfants

2014-07-16 Diskussionsfäden Paul Mallet
Juste une suggestion :

building=yes
leisure=playground
fee=yes

Paul MALLET


Le 16 juillet 2014 13:54, Pierre-Yves Berrard pierre.yves.berr...@gmail.com
 a écrit :

 Comment renseigner un centre de jeux pour enfants ? (avec structure
 gonflables, activités, anniversaires...)

 leisure=playground ne me semble pas adapté car c'est pour l'extérieur,
 public et en général gratuit.
 Là, c'est aussi à l'intérieur et payant.

 PY (the_knife)

 ___
 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] Relation route et giratoire

2014-07-16 Diskussionsfäden Paul Mallet
+1, on ne tag pas pour le rendu, mais on va tagger en fonction des algos de
routage ?

Si en vrai le bus ne fait pas le tour complet du rond point, alors c'est +
précis (et donc forcément + complexe, et alors ?) de spécifier la portion
empruntée par celui-ci !

Paul
Le 16 juil. 2014 22:34, Pierre-Yves Berrard pierre.yves.berr...@gmail.com
a écrit :

 Toutes ces considérations sur le routage seraient valables si on avait un
 modèle de relation route avec des points de passage (comme exposé par
 Étienne).
 Or ce n'est pas le cas : la route est censée être entièrement déterminée
 par des segments. À aucun moment je ne vois dans la doc, l'itinéraire est
 défini par les segments de routes, *sauf sur les giratoires où il faudra
 faire appel à un algorithme de routage*.
 Donc, bien que cela soit coûteux en nombre d'objets dans osm, je ne vois
 pas comment,* avec le modèle actuel*, faire sans tronçonner ces maudits
 giratoires.

 ___
 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] bus : rôles stop, start, end ?

2014-07-12 Diskussionsfäden Paul Mallet
Pour les terminus, il y a les rôles stop_entry_only et stop_exit_only (et
les rôles platform correspondant)

Pour les stop_position ça ne me pose pas de pbm que les noeuds des 2 sens
soient fusionnés si ils sont proches, a condition qu'il soit présent dans
les 2 relations.

Par contre c'est pour moi essentiel de mettre a la fois les données de stop
(sur la voie) et de plateform (abribus) pour couvrir tous les usages que
l'on peut faire de ces données (notamment la recherche ou l'optimisation
d'itinéraires, mais pas que...)
Le 12 juil. 2014 01:47, Jo winfi...@gmail.com a écrit :

 Pour placer les arrêts je m'amuse également à chercher des:

 /\/\/\/\ en France
 B U S en Belgique
 ou les abris.

 Si ce n'est pas possible j'essaye de les placer le mieux que possible.
 Tous les détails pertinents sont là, s'ils sont mal placés il y aura
 certainement quelqu'un avec les connaissances locales pour les placer mieux
 dans les années qui viennent.

 Jo

 Pour les bancs, je ne sais pas. J'ai trouvé très peu de poses-fesses
 jusqu'à présent.


 2014-07-12 1:16 GMT+02:00 Muselaar musel...@ouvaton.org:

  Ça, c'est la classe…
 Quand je pense que je passe un temps non négligeable à chercher d'après
 mes photos où sont précisément les arrêts !
 Quelquefois, ce n'est pas évident de retrouver la bonne maison sur Bing,
 surtout dans les lotissements. Et je me méfie des données de l'entreprise
 de transport, j'ai déjà repéré quelques erreurs d'emplacements d'arrêts (du
 moins par rapport au calculateur d'itinéraire proposé sur le site… qui
 utilise pour cette fonction OSM :
 http://info.optymo.fr/votre-voyage/horaires-et-plans)

 Muselaar


 Le 12/07/2014 01:03, Jo a écrit :

  Personnellement, je n'ajoute pas les stop_position. Ils font déjà
 partie des chemins. Donc je n'ajoute que les
 public_transport=platform/highway=bus_stop, en ordre consécutive. Donc si
 le bus passe deux fois le même arrêt il est là 2 fois. Comme j'ai les
 données de 2 des 3 entreprises de transport en Belgique à disposition, les
 relations route sont créées de façon automatique pour toutes les variations.

  Polyglot


 2014-07-12 0:54 GMT+02:00 Francescu GAROBY windu...@gmail.com:

 'from' et 'to font partie des tags permettant d'enrichir la relation, au
 même titre que 'type', 'operator', ... Ce ne sont pas des rôles (les rôles
 sont associés aux éléments qui composent la relation).

 Quant à la complétion automatique, je ne crois pas qu'elle filtre sur
 les valeurs autorisées pour une relation donnée. Si tu tentes de taper un
 tag qui n'a rien à voir avec ta relation, tu verras que Josm te le propose
 quand même.

 Francescu


 Le 12 juillet 2014 00:31, Muselaar musel...@ouvaton.org a écrit :

  En fait, j'ai découvert la valeur « start » simplement par le fait que
 c'est ce qui est proposé dans l'éditeur de relation quand on commence à
 taper « st ». Et il faut toujours ajouter le « o » pour obtenir « stop ».
 Et puis sur l'article :

 https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Route_direction.2Fvariant

 il y a :

   from
 https://wiki.openstreetmap.org/w/index.php?title=Key:fromaction=editredlink=1
   *Initial
 stop*  Initial stop where the variant starts.  recommended   to
 https://wiki.openstreetmap.org/w/index.php?title=Key:toaction=editredlink=1
   *Terminal
 stop*  Terminal stop where the variant ends.  recommended
 Voilà, si quelqu'un peut donner plus d'éclaircissements… Il est vrai
 que l'anglais n'est pas mon point fort.
 En attendant, je laisse tout en « stop ».

 Muselaar

 Le 12/07/2014 00:16, Francescu GAROBY a écrit :

  Bonsoir,
 Concernant les start/end, je découvre ces valeurs possibles. Est-ce
 nouveau ? Car je n'ai pas souvenir d'avoir lu quoi que ce soit à ce sujet.
 Peux-tu nous dire où tu as vu ça ?

 Concernant le stop_position unique pour 2 arrêts en (quasi) face à
 face, c'est aussi ce que j'ai fait, sur certains arrêts de l'agglomération
 caennaise. Et ce, pour les mêmes raisons que toi.
 Techniquement parlant, je ne vois pas pourquoi ça coincerait : le point
 étant sur la voie, rien n'indique, en soi, s'il appartient à un sens de
 circulation ou à l'autre. C'est son association à une relation, voire à
 plusieurs, qui indique que ce point est utilisé dans tel ou tel sens de
 circulation.

  Francescu




 Le 11 juillet 2014 23:46, Muselaar musel...@ouvaton.org a écrit :

 Bonsoir,

 Dans les routes de bus, faut-il employer les rôles start et end, ou
 bien uniquement stop pour tous les arrêts (y compris les arrêts de départs
 et de terminus) ?

 2e question : dans l'application du nouveau shéma des transports
 publics, j'ai pris l'option, n'ayant pas trouvé la réponse sur le wiki, de
 ne garder qu'un seul « stop position » (donc par un nœud sur la voie
 elle-même) lorsque les arrêts des deux sens sont face à face. Est-ce que
 c'est bien/acceptable/à éviter/inacceptable ?
 Mon avis, c'est que placer 2 stop-positions différents à 5 ou 10 m
 l'un de l'autre (pour qu'ils soient exactement au 

Re: [OSM-talk-fr] bus : rôles stop, start, end ?

2014-07-12 Diskussionsfäden Paul Mallet
Ah et pour les pose fesses, pour moi il faut un tag particulier (ou une
valeur ?), imaginez qu'une une personne âgée (ou pas) veuille choisir son
arrêt en fonction de la présence d'un banc, et que lorsqu'elle arrive il
n'y a que ce truc inutile ?
Le 12 juil. 2014 10:58, Paul Mallet cont...@paulmallet.net a écrit :

 Pour les terminus, il y a les rôles stop_entry_only et stop_exit_only (et
 les rôles platform correspondant)

 Pour les stop_position ça ne me pose pas de pbm que les noeuds des 2 sens
 soient fusionnés si ils sont proches, a condition qu'il soit présent dans
 les 2 relations.

 Par contre c'est pour moi essentiel de mettre a la fois les données de
 stop (sur la voie) et de plateform (abribus) pour couvrir tous les usages
 que l'on peut faire de ces données (notamment la recherche ou
 l'optimisation d'itinéraires, mais pas que...)
 Le 12 juil. 2014 01:47, Jo winfi...@gmail.com a écrit :

 Pour placer les arrêts je m'amuse également à chercher des:

 /\/\/\/\ en France
 B U S en Belgique
 ou les abris.

 Si ce n'est pas possible j'essaye de les placer le mieux que possible.
 Tous les détails pertinents sont là, s'ils sont mal placés il y aura
 certainement quelqu'un avec les connaissances locales pour les placer mieux
 dans les années qui viennent.

 Jo

 Pour les bancs, je ne sais pas. J'ai trouvé très peu de poses-fesses
 jusqu'à présent.


 2014-07-12 1:16 GMT+02:00 Muselaar musel...@ouvaton.org:

  Ça, c'est la classe…
 Quand je pense que je passe un temps non négligeable à chercher d'après
 mes photos où sont précisément les arrêts !
 Quelquefois, ce n'est pas évident de retrouver la bonne maison sur Bing,
 surtout dans les lotissements. Et je me méfie des données de l'entreprise
 de transport, j'ai déjà repéré quelques erreurs d'emplacements d'arrêts (du
 moins par rapport au calculateur d'itinéraire proposé sur le site… qui
 utilise pour cette fonction OSM :
 http://info.optymo.fr/votre-voyage/horaires-et-plans)

 Muselaar


 Le 12/07/2014 01:03, Jo a écrit :

  Personnellement, je n'ajoute pas les stop_position. Ils font déjà
 partie des chemins. Donc je n'ajoute que les
 public_transport=platform/highway=bus_stop, en ordre consécutive. Donc si
 le bus passe deux fois le même arrêt il est là 2 fois. Comme j'ai les
 données de 2 des 3 entreprises de transport en Belgique à disposition, les
 relations route sont créées de façon automatique pour toutes les variations.

  Polyglot


 2014-07-12 0:54 GMT+02:00 Francescu GAROBY windu...@gmail.com:

 'from' et 'to font partie des tags permettant d'enrichir la relation,
 au même titre que 'type', 'operator', ... Ce ne sont pas des rôles (les
 rôles sont associés aux éléments qui composent la relation).

 Quant à la complétion automatique, je ne crois pas qu'elle filtre sur
 les valeurs autorisées pour une relation donnée. Si tu tentes de taper un
 tag qui n'a rien à voir avec ta relation, tu verras que Josm te le propose
 quand même.

 Francescu


 Le 12 juillet 2014 00:31, Muselaar musel...@ouvaton.org a écrit :

  En fait, j'ai découvert la valeur « start » simplement par le fait
 que c'est ce qui est proposé dans l'éditeur de relation quand on commence 
 à
 taper « st ». Et il faut toujours ajouter le « o » pour obtenir « stop ».
 Et puis sur l'article :

 https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Route_direction.2Fvariant

 il y a :

   from
 https://wiki.openstreetmap.org/w/index.php?title=Key:fromaction=editredlink=1
   *Initial
 stop*  Initial stop where the variant starts.  recommended   to
 https://wiki.openstreetmap.org/w/index.php?title=Key:toaction=editredlink=1
   *Terminal
 stop*  Terminal stop where the variant ends.  recommended
 Voilà, si quelqu'un peut donner plus d'éclaircissements… Il est vrai
 que l'anglais n'est pas mon point fort.
 En attendant, je laisse tout en « stop ».

 Muselaar

 Le 12/07/2014 00:16, Francescu GAROBY a écrit :

  Bonsoir,
 Concernant les start/end, je découvre ces valeurs possibles. Est-ce
 nouveau ? Car je n'ai pas souvenir d'avoir lu quoi que ce soit à ce sujet.
 Peux-tu nous dire où tu as vu ça ?

 Concernant le stop_position unique pour 2 arrêts en (quasi) face à
 face, c'est aussi ce que j'ai fait, sur certains arrêts de l'agglomération
 caennaise. Et ce, pour les mêmes raisons que toi.
 Techniquement parlant, je ne vois pas pourquoi ça coincerait : le
 point étant sur la voie, rien n'indique, en soi, s'il appartient à un sens
 de circulation ou à l'autre. C'est son association à une relation, voire à
 plusieurs, qui indique que ce point est utilisé dans tel ou tel sens de
 circulation.

  Francescu




 Le 11 juillet 2014 23:46, Muselaar musel...@ouvaton.org a écrit :

 Bonsoir,

 Dans les routes de bus, faut-il employer les rôles start et end, ou
 bien uniquement stop pour tous les arrêts (y compris les arrêts de 
 départs
 et de terminus) ?

 2e question : dans l'application du nouveau shéma des transports
 publics, j'ai pris l'option, n'ayant pas trouvé la

Re: [OSM-talk-fr] bus : rôles stop, start, end ?

2014-07-12 Diskussionsfäden Paul Mallet
Chacun est libre de contribuer ce qu'il veut, et si une partie seulement
des tags vous suffisent, alors très bien! Mais ne dissuadez pas les autres
contributeurs de tagger le modèle complet, qu'il vous plaise ou non :/
Le 12 juil. 2014 16:24, JB jb...@mailoo.org a écrit :

  Tiens, plus j'en lis, plus je reste au highway=bus_stop. Mais pas trop
 fort, c'est politiquement limite…
 JB.

 Le 12/07/2014 13:28, Éric Gillet a écrit :

 Attention; il ne faudrait pas surestimer ce qui est calculable.

  La platform doit être mise dans la relation type=route pour expliciter
 quelle plateforme doit être utilisée pour quel itinéraire (surtout dans le
 cas de gares routières).
 Idem pour les stop_positions, si deux routes passent par les même chemins,
 il y aura des arrêts en trop...

  La quantité ne prime pas forcément sur la qualité ! Remplir OSM de
 données difficilement exploitables par des outils ne sert pas OSM. De plus
 se dire Je ne complète pas avec les données que j'ai sous la main,
 quelqu'un d'autre pourra le faire, obligera un autre contributeur à faire
 le même long travail pour rajouter les détails omis (le temps des
 contributeurs OSM n'est pas une ressource infinie).


 2014-07-12 11:20 GMT+01:00 Jo winfi...@gmail.com:

Pour moi il est impératif que créer et maintenir des relations route
 ça reste pratique pour les contributeurs, donc tout ce qui peut être
 calculé est non essentiel.

  Si tu peux choisir entre pas avoir des relations route, car personne ne
 veut les créer/maintenir

  ou des relations route avec tous les chemins en ordre consécutive + tous
 les arrêts (les noeuds à coté de la route, bien sûr)

 qu'est-ce que tu prends? Ceux qui ont besoin de stop_position pour leurs
 besoins peuvent les calculer.

  Bon, je dois probablement ajouter que je n'ajoute même pas toujours les
 stop_position. A la limite on peut les déduire en tirant un ligne
 perpendiculaire à partir de l'arrêt vers le chemin.

  Il faudra probablement également ajouter que je viens d'ajouter une
 bonne 3 d'arrêts et des centaines de routes avec leur variations,
 durant l'an passé, chose qui aurait été impossible avec le schéma complet.

 Bien sûr, là où les trams étaient concernés ou les arrêts partagés les
 stop positions sont bien inclus + des relations stop_area.

  Mais le plus important reste le noeud
 public_transport=platform/highway=bus_stop.

  Polyglot


 2014-07-12 10:58 GMT+02:00 Paul Mallet cont...@paulmallet.net:

  Pour les terminus, il y a les rôles stop_entry_only et stop_exit_only
 (et les rôles platform correspondant)

 Pour les stop_position ça ne me pose pas de pbm que les noeuds des 2
 sens soient fusionnés si ils sont proches, a condition qu'il soit présent
 dans les 2 relations.

 Par contre c'est pour moi essentiel de mettre a la fois les données de
 stop (sur la voie) et de plateform (abribus) pour couvrir tous les usages
 que l'on peut faire de ces données (notamment la recherche ou
 l'optimisation d'itinéraires, mais pas que...)
 Le 12 juil. 2014 01:47, Jo winfi...@gmail.com a écrit :

 Pour placer les arrêts je m'amuse également à chercher des:

  /\/\/\/\ en France
  B U S en Belgique
  ou les abris.

  Si ce n'est pas possible j'essaye de les placer le mieux que possible.
 Tous les détails pertinents sont là, s'ils sont mal placés il y aura
 certainement quelqu'un avec les connaissances locales pour les placer mieux
 dans les années qui viennent.

  Jo

  Pour les bancs, je ne sais pas. J'ai trouvé très peu de poses-fesses
 jusqu'à présent.


 2014-07-12 1:16 GMT+02:00 Muselaar musel...@ouvaton.org:

  Ça, c'est la classe…
 Quand je pense que je passe un temps non négligeable à chercher
 d'après mes photos où sont précisément les arrêts !
 Quelquefois, ce n'est pas évident de retrouver la bonne maison sur
 Bing, surtout dans les lotissements. Et je me méfie des données de
 l'entreprise de transport, j'ai déjà repéré quelques erreurs 
 d'emplacements
 d'arrêts (du moins par rapport au calculateur d'itinéraire proposé sur le
 site… qui utilise pour cette fonction OSM :
 http://info.optymo.fr/votre-voyage/horaires-et-plans)

 Muselaar


 Le 12/07/2014 01:03, Jo a écrit :

  Personnellement, je n'ajoute pas les stop_position. Ils font déjà
 partie des chemins. Donc je n'ajoute que les
 public_transport=platform/highway=bus_stop, en ordre consécutive. Donc si
 le bus passe deux fois le même arrêt il est là 2 fois. Comme j'ai les
 données de 2 des 3 entreprises de transport en Belgique à disposition, les
 relations route sont créées de façon automatique pour toutes les 
 variations.

  Polyglot


 2014-07-12 0:54 GMT+02:00 Francescu GAROBY windu...@gmail.com:

 'from' et 'to font partie des tags permettant d'enrichir la relation,
 au même titre que 'type', 'operator', ... Ce ne sont pas des rôles (les
 rôles sont associés aux éléments qui composent la relation).

 Quant à la complétion automatique, je ne crois pas qu'elle filtre sur
 les valeurs autorisées pour une relation donnée

Re: [OSM-talk-fr] Plusieurs relations associatedStreet pour la même voie

2014-07-10 Diskussionsfäden Paul Mallet
Cela peut être pertinent lorsque la voie sépare deux communes, afin de
fournir les 2 codes fantoir, non ?
Le 10 juil. 2014 21:37, Éric Gillet fear.hardc...@gmail.com a écrit :

 Normalement non, pour les fusionner il est possible de sélectionner tous
 les membres de la relation et de les ajouter dans l'autre. JOSM notifiera
 des doublons lors de l'ajout, et il sera possible de refuser l'ajout de ces
 doublons.


 2014-07-10 20:14 GMT+01:00 mga_geo mga_...@yahoo.fr:

 Bonsoir à tous,

 Je viens de découvrir qu'une voie pouvait plus d'une relation
 associatedStreet, par exemple à Rennes le Boulevard de la Duchesse Anne
 (relations 556776 et 3326043).
 Est-il souhaitable de fusionner ces relations et si oui comment faire ?

 A+
 Marc



 --
 View this message in context:
 http://gis.19327.n5.nabble.com/Plusieurs-relations-associatedStreet-pour-la-meme-voie-tp5811054.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] Batiment invisible

2014-07-09 Diskussionsfäden Paul Mallet
C'est juste que le highway=pedestrian devrait être un multipolygone
excluant le/les bâtiments non ?

Paul MALLET


Le 9 juillet 2014 09:50, François Lacombe 
francois.laco...@telecom-bretagne.eu a écrit :

 Bonjour,

 J'ai remarqué le même cas ici : http://www.openstreetmap.org/way/75748046

 A mon avis c'est le highway=pedestrian + area=yes qui pose un problème.

 A+

 *François Lacombe*

 francois dot lacombe At telecom-bretagne dot eu
 http://www.infos-reseaux.com


 Le 9 juillet 2014 09:24, JB jb...@mailoo.org a écrit :

 À première vue, j'opterai plutôt pour la superposition avec le chemin :
 http://www.openstreetmap.org/way/157853589 taggué un peu dans plusieurs
 directions (highway sans area, historic, tourism). Pour vérifier, il
 faudrait le déformer un peu, voir si le batiment sort d'en dessous.
 JB.

 Le 09/07/2014 09:12, Antoine Riche a écrit :

  Bonjour,

 Quelqu'un a une idée pourquoi ce bâtiment n'apparaît pas dans le rendu
 standard : http://www.openstreetmap.org/way/74546319 ?
 Il est visible sur les rendus Mapquest, Transport et Humanitaire.
 Est-ce dû au tag amenity=social_centre, ou à start_date=1884 ? Leur
 usage me semble correct.

 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



 ___
 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] Correction de noms de voie pour jointure BANO [was: Trouver les noeuds non rapportés à un bâtiment avec JOSM]

2014-06-23 Diskussionsfäden Paul Mallet
Garde name=Rue Henri Dunant et rajoute ref:FR:FANTOIR=010040370G ?

Paul MALLET


Le 23 juin 2014 11:28, jean navarro jean.nava...@laposte.net a écrit :


 Bonjour
 un quatrième cas :
 http://layers.openstreetmap.fr/?zoom=9lat=48.94104lon=2.10869layers=
 00B00FFT


 henri Dunant est l'inventeur de la croix-rouge... il n'existe pas de
 Dunand avec un D  ni sur le terrain, ni dans le cadastre.
 donc le nom du code Fantoir ne correspond ni à osm ni au cadastre.
 comment fait-on ?

 cordialement
 jean navarro

 FANTOIR :
 0100040370GRUE HENRI DUNAND   R 0 00
 0001987001   003651   DUNAND


 Le 19/05/2014 10:59, Christian Quest a écrit :

 C'est parfait.

 Tu as un troisième cas... quand il y a un libellé sans correspondance
 FANTOIR !

 Dans ce cas, je pense que ref:FR:FANTOIR=no pourrait être exploité par
 le scripts.



 Le 19 mai 2014 10:51, Jean-Marc Liotier j...@liotier.org
 mailto:j...@liotier.org a écrit :


 On 19/05/2014 10:39, Jean-Marc Liotier wrote:

 Ayant bleui quelques points rouges de la BANO dans mon quartier
 hier soir, je confirme qu'il est loin d'être rare que le nom
 originaire du cadastre soit erroné... Le terrain d'abord !


 La procédure que j'ai adoptée est:
 - Si le name est incorrect et que sa correction correspond à la
 valeur donnée par le cadastre, alors je corrige le name
 - Si le name est correct mais différent de la valeur donnée par le
 cadastre, alors je rajoute ref:FR:FANTOIR pour que le script BANO de
 Christian puisse quand même faire la jointure

 Ca vous paraît correct ?

 _
 Talk-fr mailing list
 Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org
 https://lists.openstreetmap.__org/listinfo/talk-fr

 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] Rendu BANO

2014-05-21 Diskussionsfäden Paul Mallet
Une autre règle un peu bizarre : dans FANTOIR, quand le type de voie est VC
(voie communale ?) STE correspond à Sente, sinon ca correspond à Saint(e)
Trucmuche.

Actuellement dans BANO j'ai l'impression que tous les STE deviennent des
Saint(e), et du coup le rapprochement avec la voie n'est pas fait

C'est corrigible en ajoutant le ref:FR:FANTOIR sur la voie, mais autant
affiner la règle de rapprochement en amont...

Paul MALLET


Le 21 mai 2014 10:31, Jean-Marc Liotier j...@liotier.org a écrit :


 On 21/05/2014 08:40, Christian Quest wrote:

 Il faut qu'on vérifie pour les codes FANTOIR, il y en a qui correspondent
 à des voies temporairement nommées ou des voies qui n'existent plus et on a
 une info à ce sujet qu'on n'exploite pas encore.


 http://www.collectivites-locales.gouv.fr/files/files/gestion_locale_dgfip/
 Descriptif_FANTOIR_2013.pdf dit que le premier caractère de la clé RIVOLI
 est Y ou Z pour les voies provisoires à annuler.

 J'ai bien constaté l'usage de Z - par chez moi, quelques voies qui
 étaient nommé Impasse Bidule ont été renommées Villa Bidule parce que
 c'est plus classe mais Openstreetmap n'était pas à jour du renommage...
 J'ai donc mis Impasse Bidule en old_name

 Mais quid de Y ? Doit on considéré que l'enregistrement dit provisoire'
 est actuel ou ancien comme un enregistrement annulé Z ?

 Notons aussi le lignes annulées (cf. Caractère d'annulation : 'O' sans
 transfert, 'Q' avec - j'ignore ce qu'est un transfert).


 ___
 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... premiers pas...

2014-05-10 Diskussionsfäden Paul Mallet
Hello,

Si j'ai bien compris les adresses déjà intégrées dans OSM sont prioritaires
sur celles du cadastre.

Du coup je ne comprends pas trop pourquoi aucune des adresses de
Boulogne-Billancourt (92) et beaucoup des adresses de Paris ne sont pas
prises en compte (du coup il y a doublon avec celles venant de l'import
cadastral, est ce un problème du script d'import ou manque t-il des infos
dans OSM pour faire la liaison ?

De même quoi faire quand les noms de rues du cadastre ne correspondent pas
au terrain (et a OSM), et que du coup les adresses ressortent en rouge ?

En tout cas bravo pour le taf, c'est très prometteur !

Paul MALLET


Le 10 mai 2014 20:19, nono pingven...@free.fr a écrit :

 Bonsoir

 Merci pour vos réponses, c'est plus clair dans ma tête maintenant ;-)

 Je vais donc continuer à importer et mettre à jour le bâti ;-)
 D'ailleurs en un an, c'est fou les modification qu'il y a (extension,
 nouveaux lotissements, disparition avant reconstruction, etc...), une
 ville ça vie ;-)

 a+

 nono



 Le samedi 10 mai 2014 à 15:06 +0200, Christian Quest a écrit :
  Version courte: Il ne s'agit pas d'un import du cadastre. BANO ne touche
  pas aux données OSM, mais va permettre aux contributeurs de les
 améliorer.
 
  Version longue:
 
  Le projet BANO a pour but de créer une Base d'Adresses Nationale
 Ouverte...
  cette base est constituée des adresses présentes dans OSM, auxquelles on
  ajoutes les adresses disponibles en opendata puis celles extraites
  (automatiquement) du cadastre.
 
  Elle ne sera pas importée massivement en l'état dans OSM, mais pourra
  l'être petit à petit avec le travail de vérification manuel estimé
  nécessaire vu la qualité variable d'une commune à l'autre.
 
  L'intégration du bâti manuelle dans OSM est utile à BANO, car les
 adresses
  sont repositionnées sur les façades des bâtiments présents dans OSM quand
  ils s'y trouvent.
  De plus, les noms des rues sont aussi repris d'OSM quand on arrive à
 faire
  le lien.
 
  Pour les améliorations que BANO va permettre aux contributeurs:
  - identifier les rues manquantes... soit juste le nom manquant, soit le
  tracé complet
  - identifier les lieux-dits
  et il y en a sûrement d'autres !
 
  Le projet est décrit sur:
 
 http://wiki.openstreetmap.org/wiki/WikiProject_France/WikiProject_Base_Adresses_Nationale_Ouverte_(BANO)
 
 
 
  Le 10 mai 2014 14:50, nono pingven...@free.fr a écrit :
 
   Salut
  
   Le samedi 10 mai 2014 à 14:20 +0200, Christian Quest a écrit :
On va y aller calmement... plutôt le soir et week-end histoire de ne
pas faire surchauffer les serveurs de Bercy lorsqu'ils sont les plus
sollicités.
   
   
L'Alsace est en cours d'extraction... on met la priorité sur les
régions les plus complètes en bâti/voirie, histoire d'avoir un
 maximum
de rapprochements avec les données OSM, d'où le choix
Nord-Pas-de-Calais, Alsace, Pays-de-la-Loire...
  
   Je lis ce fil mais n'y comprends pas grand chose, donc je me pose des
   questions ;-)
  
   Vous semblez tester un import automatique du cadastre.
  
   Donc faut-il que je continue à importer les bâtis du cadastre des
   patelins de mon coin et les mettre à jour manuellement ?
  
   Dans le cas d'un import automatique comme le vôtre, que fait-il
   exactement ?
   Supprime-t-il les build déjà présents dans osm pour y mettre les siens
 ?
  
   En bref, en tant que contributeur, faut-il continuer à consacrer du
   temps individuel sur l'import cadastral ?
  
   nono
  
  
  
  
   --
   Chuck Norris est au courant de l'existence des extraterrestres. Du
 moins
   les races qu'il a exterminé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


 ___
 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] Représentation des éoliennes

2013-09-02 Diskussionsfäden Paul Mallet
Attention, une éolienne et un arbre, ce n'est pas du tout la même
échelle, pour moi cela fait sens de représenter son périmètre au sol,
comme on peut le faire pour les petits batiments.

Une image pour se rentre compte :
http://commons.wikimedia.org/wiki/File:Eolienne_-_fondation_en_béton.JPG
Paul MALLET


Le 2 septembre 2013 11:25, François Lacombe
francois.laco...@telecom-bretagne.eu a écrit :
 Nous sommes d'accord.

 Du coup comment identifier les cas, les éviter, les corriger ?
 Avec Osmose ?

 Parallelement, je vois très bien des bâtiments de 2 ou 3 m² qui méritent
 d'être représentés par des zones fermées plus que par des noeuds.

 François Lacombe

 francois dot lacombe At telecom-bretagne dot eu
 http://www.infos-reseaux.com


 Le 2 septembre 2013 11:18, Christophe Merlet red...@redfoxcenter.org a
 écrit :

 Le 02/09/2013 10:43, Otourly Wiki a écrit :

 Ceci est à cause du cadastre, mais je vois pas le problème d'afficher
 l'empreinte au sol bien au contraire.
 Florian.
 
 *De :* François Lacombe francois.laco...@telecom-bretagne.eu
 *À :* Discussions sur OSM en français talk-fr@openstreetmap.org
 *Envoyé le :* Lundi 2 septembre 2013 9h54
 *Objet :* [OSM-talk-fr] Représentation des éoliennes


 Bonjour,

 D'après la way suivante
 http://www.openstreetmap.org/browse/way/111510472

 on voit qu'une petite 20aine de noeuds est nécessaire pour représenter
 une éolienne, quelque chose d'à peu près ponctuel sur le terrain.

 Est-ce bien raisonnable ? (sans remettre en cause la qualité de la carto
 et de l'effort de son auteur).


 Une vingtaine de nœuds pour représenter un simple cercle de 4m de diamètre
 est évidemment déraisonnable.

 Il vaut mieux utiliser 1 seul nœud pour le mat et les autres nœuds pour
 définir un landuse=industrial pour la parcelle réservé à l'éolienne et la
 voie de service permettant d'y accéder...


 Librement,
 --
 Christophe Merlet (RedFox)


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



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


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


Re: [OSM-talk-fr] Rendu osmfr : barrier=gate visible à un niveau de zoom trop faible ?

2013-08-22 Diskussionsfäden Paul Mallet
Complètement d'accord pour les barrier=gate (on pourrait aussi ajouter les
=lift, =entrance etc.)

Par contre concernant les access=private, ne soit on pas plutôt les placer
sur gate et non sur fence ? Parce que j'ai un peu de mal à visualiser des
barrières publiques ^^
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] tag name sur highway

2013-07-23 Diskussionsfäden Paul Mallet
Sinon il y a http://qa.poole.ch/

Paul MALLET


Le 23 juillet 2013 14:07, Mides mides@gmail.com a écrit :
 Oups, j'avais oublié de regarder ce qu'il se passait du coté du
 LayerSwitcher, je dois avoir besoin de vacances.

 Toujours est il, merci pour le coup de pouce  ;-)

 Michel


 Le 23 juillet 2013 13:54, Jean-Baptiste Holcroft jb.holcr...@gmail.com a
 écrit :

 Bonjour,

 Tu peux utiliser le calque noname sur Osmose (appuyer sur le plus à
 droite) :


http://osmose.openstreetmap.fr/fr/map/?zoom=12lat=45.04896lon=-0.0697layers=B0TFFitem=0level=1,2,3

 Il est aussi possible de le mettre dans JOSM, peut-être avec :

 tms:
http://layers.openstreetmap.fr/tiles/renderer.py/noname/{zoom}/{x}/{y}.png

 --
 Jean-Baptiste Holcroft


 Le 23 juillet 2013 13:02, mides.map mides@gmail.com a écrit :

 Bonjour,

 il me semble avoir vu passer, en son temps, un site permettant de
 contrôler les tag:name manquants sur les highway.

 Je n'arrive plus à retrouver son adresse. (mais peut être ai-je tout
 simplement rêvé) :-)

 Auriez vous une idée ?

 Michel

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



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



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

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