Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-06 Par sujet Christian Quest 
Il faut SI POSSIBLE se baser sur l'id qu'on peut voir sur le terrain... et
des id "STIF" j'en ai déjà vu sur des réseaux non RATP.

Le 7 décembre 2016 à 02:05, Jérôme Amagat  a écrit
:

> pour le STIF dans le GTFS le "ref" des arrêts dans tous les fichier sauf 1
> c'est un stop_id différent du ZDEr_ID_REF_A mais il y a quand même un
> fichier pour passer du
> ZDEr_ID_REF_A au stop_id
>
>
> Le 6 décembre 2016 à 22:20, Florian LAINEZ  a écrit :
>
>> Si OSMOSE se met à manger du GTFS c'est certain que ça permettrai de
>> passer à une autre échelle.
>> Fred tu comptes l'implémenter du coup ?
>> Comment comptes-tu gérer l'évolution des données sources dans le temps ?
>> Autant avec un jeu de données statiques tu peux valider/ignorer un POI,
>> autant si les données évoluent il faut être certain de disposer d'un
>> identifiant pérenne.
>>
>> Fred en attendant peut-être vaut-il déjà intégrer les données statiques
>> du STIF comme première étape.
>> Merci
>>
>>
>>
>> Le 6 décembre 2016 à 20:44, Frédéric Rodrigo  a
>> écrit :
>>
>>> Le 06/12/2016 à 19:13, Florian LAINEZ a écrit :
>>>

 Le 6 décembre 2016 à 13:45, Christian Quest >>> > a écrit :

 J'ai regardé dans mon quartier desservi par la RATP... c'est
 "correct" à 50m près.

 J'en ai à peu près le même souvenir. J'ai checké une belle quantité
 d'arrêts autour de gares Transilien cet été, j'en ai trouvé certains sur
 les quais de gares ... d'autres très bien placés.

 Le STIF agrégeant des données provenant d'une multitude de
 sociétés de transport, la qualité géométrique n'est sûrement pas
 homogène

 exactement.

 Fred tu peux considérer le champs ZDEr_ID_REF_A comme notre
 ref:FR:STIF, merci

 Au passage je vous signale cette issues sur osmose-backend:
>>>
>>> https://github.com/osm-fr/osmose-backend/issues/163
>>>
>>> qui propose de faire la même chose à un niveau industriel.
>>>
>>>
>>>
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>
>>
>>
>> --
>>
>> *Florian Lainez*
>> @overflorian 
>>
>> ___
>> 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

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-06 Par sujet Jérôme Amagat 
pour le STIF dans le GTFS le "ref" des arrêts dans tous les fichier sauf 1
c'est un stop_id différent du ZDEr_ID_REF_A mais il y a quand même un
fichier pour passer du
ZDEr_ID_REF_A au stop_id


Le 6 décembre 2016 à 22:20, Florian LAINEZ  a écrit :

> Si OSMOSE se met à manger du GTFS c'est certain que ça permettrai de
> passer à une autre échelle.
> Fred tu comptes l'implémenter du coup ?
> Comment comptes-tu gérer l'évolution des données sources dans le temps ?
> Autant avec un jeu de données statiques tu peux valider/ignorer un POI,
> autant si les données évoluent il faut être certain de disposer d'un
> identifiant pérenne.
>
> Fred en attendant peut-être vaut-il déjà intégrer les données statiques du
> STIF comme première étape.
> Merci
>
>
>
> Le 6 décembre 2016 à 20:44, Frédéric Rodrigo  a
> écrit :
>
>> Le 06/12/2016 à 19:13, Florian LAINEZ a écrit :
>>
>>>
>>> Le 6 décembre 2016 à 13:45, Christian Quest >> > a écrit :
>>>
>>> J'ai regardé dans mon quartier desservi par la RATP... c'est
>>> "correct" à 50m près.
>>>
>>> J'en ai à peu près le même souvenir. J'ai checké une belle quantité
>>> d'arrêts autour de gares Transilien cet été, j'en ai trouvé certains sur
>>> les quais de gares ... d'autres très bien placés.
>>>
>>> Le STIF agrégeant des données provenant d'une multitude de
>>> sociétés de transport, la qualité géométrique n'est sûrement pas
>>> homogène
>>>
>>> exactement.
>>>
>>> Fred tu peux considérer le champs ZDEr_ID_REF_A comme notre ref:FR:STIF,
>>> merci
>>>
>>> Au passage je vous signale cette issues sur osmose-backend:
>>
>> https://github.com/osm-fr/osmose-backend/issues/163
>>
>> qui propose de faire la même chose à un niveau industriel.
>>
>>
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
>
> --
>
> *Florian Lainez*
> @overflorian 
>
> ___
> 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 représentation avec des parcelles forestières

2016-12-06 Par sujet Philippe Verdy 
Je ne vois pas en quoi ce changement de "multipolygon" en "boundary"
devrait avoir un impact sur l'interprétation et la "remontée" des tags des
ways membres vers les relations qui les référence.

Cela reste un bogue de la conversion OSM en pgsql, qui ne tient pas compte
des critères nécessaires (tags identiques dans tous les ways membres ayant
un rôle "outer" ou vide, ce qui n'était pas le cas des "name=*").

En revanche remonter les "highway=*" vers la relation (peu importe que ce
soit une "boundary" ou un "multipolygon") est problématique, dans les faits
tous les "highway=*" sont linéaires (exceptions faite des
"highway=pedestrian" et à condition qu'ils soient tagués avec "area=yes",
ce qui n'était pas du tout le cas ici, car par défaut les "highway=*" sont
soit linéaires, soit des noeuds isolés pour des passages piétons,
priorités, stops...).

Il reste donc bien une anomalie de osm2pgsql ici, et je ne vois pas
pourquoi osm2pgsql devrait se demander ce que sont ces "multipolygon",
d'autant plus qu'ils ont déjà des tags nécessaires, qu'ils soient tagués
comme "multipolygon", boundary", ou encore comme "landuse", "natural" (qui
n'ont eux rien non plus à voir avec les "highway=*")



Le 6 décembre 2016 à 23:38, LeTopographeFou  a
écrit :

> J'ai basculé ces "type=multipolygon" en "type=boundary"... et tout rentre
> dans l'ordre comme je l'avais imaginé dans mon précédent message qui n'a
> visiblement pas été lu ;)
>
> Bonjour et merveilleux !! Je n'avais pas compris le sous-entendu. Merci.
>
> En terme de logique de tagging je verrai plutôt quelque chose comme:
> type=boundary (il s'agit d'une frontière qui découpe un ensemble plus
> grand)
> boundary=forest (frontière forestière)
> forest=section (il s'agit d'une section)
>
> Mais ça mérite discussion sur le wiki plutôt que d'y aller à l'arrache...
> [...]
>
> Tout là fait d'accord (sans rentrer dans la discussion ici : j'aime bien
> ta proposition, elle est plus proche de l'existant et donc plus naturelle
> que la proposition Section).
>
> Pour info il se trouve que j'ai eu un échange de mail avec l'auteur de la
> proposition Section cet été (à propos d'un cimetière que je
> visitais/cartographiais à l'époque) et il m'a dit qu'il n'avait pas eu le
> courage pour animer sa proposition jusqu'au bout. Il m'a encouragé à la
> retravailler voir à faire une contre-proposition, car il reste persuadé du
> besoin initial (parcelles forestières, sections dans un cimetière...).
>
>
> Mais ça mérite discussion sur le wiki plutôt que d'y aller à l'arrache...
> surtout que l'import des données est pas génial non plus car les données
> d'origine ne sont pas forcément bien calées...
>
> Exemple: http://umap.openstreetmap.fr/en/map/test-rendu-osmfr_99740#
> 18/48.53494/1.97682
>
> Alors là c'est drôle car pendant que tu changeais le type de relation je
> recalais exactement l'endroit que tu cite (ce qui m'a valu de résoudre
> quelques conflits d'éditions quand j'ai voulu envoyer sur le serveur). Donc
> en me basant sur le cadastre j'ai regroupé hier ce qui devait l'être dans
> la zone (je n'ai pas déplacé les frontières administratives mais les
> layons, chemins et bordures de forêt. Il reste encore une bonne partie du
> périmètre à recaler) et j'en avais profité pour ajouter un gros morceau de
> forêt manquant côté Yvelines (http://www.openstreetmap.org/
> relation/6770020).
>
> Bref il reste du boulot mais problème de rendu de parcelle réglé, je
> déploierai la solution sur les forêts alentours qui ont le même soucis,
> merci !
>
> Cordialement
>
> LeTopographeFou
>
> Le 05/12/2016 à 23:18, Christian Quest a écrit :
>
> J'ai basculé ces "type=multipolygon" en "type=boundary"... et tout rentre
> dans l'ordre comme je l'avais imaginé dans mon précédent message qui n'a
> visiblement pas été lu ;)
>
> Ces sections forestières sont bien des frontières et ça évite à osm2pgsql
> de chercher à savoir par une euristique imparfaite ce que sont ces
> multipolygones mystérieux...
>
> En terme de logique de tagging je verrai plutôt quelque chose comme:
> type=boundary (il s'agit d'une frontière qui découpe un ensemble plus
> grand)
> boundary=forest (frontière forestière)
> forest=section (il s'agit d'une section)
>
> Mais ça mérite discussion sur le wiki plutôt que d'y aller à l'arrache...
> surtout que l'import des données est pas génial non plus car les données
> d'origine ne sont pas forcément bien calées...
>
> Exemple: http://umap.openstreetmap.fr/en/map/test-rendu-osmfr_99740#
> 18/48.53494/1.97682
>
> Les tuiles sont en train de se remettre à jour... un peu de patience.
>
>
> Le 5 décembre 2016 à 22:17,  a écrit :
>
>> Le 05/12/2016 à 21:57, LeTopographeFou - letopographe...@gmail.com a
>> écrit :
>>
>> Bonsoir à tous,
>>
>> A vrai dire je croyais que le moteur ne dessinait que les objets issus
>> d'une requête (donc les objets connus) et pas tous les objets. Visiblement
>> ce n'est pas le cas.
>>
>> Jusqu'à peu c'était le cas. J'ai vu que maintenant les "noms" des
>> transf

Re: [OSM-talk-fr] Problème de représentation avec des parcelles forestières

2016-12-06 Par sujet LeTopographeFou 
J'ai basculé ces "type=multipolygon" en "type=boundary"... et tout 
rentre dans l'ordre comme je l'avais imaginé dans mon précédent 
message qui n'a visiblement pas été lu ;)

Bonjour et merveilleux !! Je n'avais pas compris le sous-entendu. Merci.


En terme de logique de tagging je verrai plutôt quelque chose comme:
type=boundary (il s'agit d'une frontière qui découpe un ensemble plus 
grand)

boundary=forest (frontière forestière)
forest=section (il s'agit d'une section)

Mais ça mérite discussion sur le wiki plutôt que d'y aller à 
l'arrache... [...]
Tout là fait d'accord (sans rentrer dans la discussion ici : j'aime bien 
ta proposition, elle est plus proche de l'existant et donc plus 
naturelle que la proposition Section).


Pour info il se trouve que j'ai eu un échange de mail avec l'auteur de 
la proposition Section cet été (à propos d'un cimetière que je 
visitais/cartographiais à l'époque) et il m'a dit qu'il n'avait pas eu 
le courage pour animer sa proposition jusqu'au bout. Il m'a encouragé à 
la retravailler voir à faire une contre-proposition, car il reste 
persuadé du besoin initial (parcelles forestières, sections dans un 
cimetière...).




Mais ça mérite discussion sur le wiki plutôt que d'y aller à 
l'arrache... surtout que l'import des données est pas génial non plus 
car les données d'origine ne sont pas forcément bien calées...


Exemple: 
http://umap.openstreetmap.fr/en/map/test-rendu-osmfr_99740#18/48.53494/1.97682
Alors là c'est drôle car pendant que tu changeais le type de relation je 
recalais exactement l'endroit que tu cite (ce qui m'a valu de résoudre 
quelques conflits d'éditions quand j'ai voulu envoyer sur le serveur). 
Donc en me basant sur le cadastre j'ai regroupé hier ce qui devait 
l'être dans la zone (je n'ai pas déplacé les frontières administratives 
mais les layons, chemins et bordures de forêt. Il reste encore une bonne 
partie du périmètre à recaler) et j'en avais profité pour ajouter un 
gros morceau de forêt manquant côté Yvelines 
(http://www.openstreetmap.org/relation/6770020).


Bref il reste du boulot mais problème de rendu de parcelle réglé, je 
déploierai la solution sur les forêts alentours qui ont le même soucis, 
merci !


Cordialement

LeTopographeFou

Le 05/12/2016 à 23:18, Christian Quest a écrit :
J'ai basculé ces "type=multipolygon" en "type=boundary"... et tout 
rentre dans l'ordre comme je l'avais imaginé dans mon précédent 
message qui n'a visiblement pas été lu ;)


Ces sections forestières sont bien des frontières et ça évite à 
osm2pgsql de chercher à savoir par une euristique imparfaite ce que 
sont ces multipolygones mystérieux...


En terme de logique de tagging je verrai plutôt quelque chose comme:
type=boundary (il s'agit d'une frontière qui découpe un ensemble plus 
grand)

boundary=forest (frontière forestière)
forest=section (il s'agit d'une section)

Mais ça mérite discussion sur le wiki plutôt que d'y aller à 
l'arrache... surtout que l'import des données est pas génial non plus 
car les données d'origine ne sont pas forcément bien calées...


Exemple: 
http://umap.openstreetmap.fr/en/map/test-rendu-osmfr_99740#18/48.53494/1.97682


Les tuiles sont en train de se remettre à jour... un peu de patience.


Le 5 décembre 2016 à 22:17, > a écrit :


Le 05/12/2016 à 21:57, LeTopographeFou - letopographe...@gmail.com
 a écrit :


Bonsoir à tous,

A vrai dire je croyais que le moteur ne dessinait que les objets
issus d'une requête (donc les objets connus) et pas tous les
objets. Visiblement ce n'est pas le cas.


Jusqu'à peu c'était le cas. J'ai vu que maintenant les "noms" des
transformateurs apparaissent sur la carte.
Assez absurde pour une carte générique.


Entre nous, ce système de "je fais remonter les valeurs communes"
me parait biaisé et n'incite pas à correctement tagger. Je
préfère 100x plus un moteur de rendu stricte et exigent qui
pousse à bien faire mais dessine avec ce qu'on lui donne plutôt
qu'un qui interprète les données avec des attributs qui
n'existent pas et dessine des relations qu'il ne connait pas
(avec 50% de risque de se planter). Si le moteur ne connait pas
une relation, il devrait l'ignorer. Si il lui manque une
propriété, il devrait pouvoir faire sans. Dixit un gars qui n'a
pas sué dans le développement de ces beaux outils :-) .


Si c'est une info commune, pourquoi pas ? Je dis bien commune
c'est à dire identique dans tous les membres.
Sinon c'est éventuellement un candidat pour un outil d'assurance
qualité (que des noms identiques ou pas de noms : peut-être que
les sans noms devraient avoir le même nom, ça peut avoir du sens
pour des réseaux, des trajets tels que des pistes cyclables sans
nom connectés à d'autres pistes cyclables ayant un nom... ou une
référence).

Jean-Yvon

__

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-06 Par sujet Florian LAINEZ 
Si OSMOSE se met à manger du GTFS c'est certain que ça permettrai de passer
à une autre échelle.
Fred tu comptes l'implémenter du coup ?
Comment comptes-tu gérer l'évolution des données sources dans le temps ?
Autant avec un jeu de données statiques tu peux valider/ignorer un POI,
autant si les données évoluent il faut être certain de disposer d'un
identifiant pérenne.

Fred en attendant peut-être vaut-il déjà intégrer les données statiques du
STIF comme première étape.
Merci



Le 6 décembre 2016 à 20:44, Frédéric Rodrigo  a
écrit :

> Le 06/12/2016 à 19:13, Florian LAINEZ a écrit :
>
>>
>> Le 6 décembre 2016 à 13:45, Christian Quest > > a écrit :
>>
>> J'ai regardé dans mon quartier desservi par la RATP... c'est
>> "correct" à 50m près.
>>
>> J'en ai à peu près le même souvenir. J'ai checké une belle quantité
>> d'arrêts autour de gares Transilien cet été, j'en ai trouvé certains sur
>> les quais de gares ... d'autres très bien placés.
>>
>> Le STIF agrégeant des données provenant d'une multitude de
>> sociétés de transport, la qualité géométrique n'est sûrement pas
>> homogène
>>
>> exactement.
>>
>> Fred tu peux considérer le champs ZDEr_ID_REF_A comme notre ref:FR:STIF,
>> merci
>>
>> Au passage je vous signale cette issues sur osmose-backend:
>
> https://github.com/osm-fr/osmose-backend/issues/163
>
> qui propose de faire la même chose à un niveau industriel.
>
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



-- 

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

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-06 Par sujet Frédéric Rodrigo 

Le 06/12/2016 à 19:13, Florian LAINEZ a écrit :


Le 6 décembre 2016 à 13:45, Christian Quest > a écrit :


J'ai regardé dans mon quartier desservi par la RATP... c'est
"correct" à 50m près.

J'en ai à peu près le même souvenir. J'ai checké une belle quantité 
d'arrêts autour de gares Transilien cet été, j'en ai trouvé certains 
sur les quais de gares ... d'autres très bien placés.


Le STIF agrégeant des données provenant d'une multitude de
sociétés de transport, la qualité géométrique n'est sûrement pas
homogène

exactement.

Fred tu peux considérer le champs ZDEr_ID_REF_A comme notre 
ref:FR:STIF, merci



Au passage je vous signale cette issues sur osmose-backend:

https://github.com/osm-fr/osmose-backend/issues/163

qui propose de faire la même chose à un niveau industriel.



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

[OSM-talk-fr] Isolation du bâti sur OSM et efficacité énergétique, ce que vous allez découvrir va vous étonner

2016-12-06 Par sujet François Lacombe 
Bonsoir à tous,

Une idée est revenue plusieurs fois dans différentes discussions sur ce que
nous faisons sur les réseaux de transport d'énergie : l'isolation des
lignes/câbles.
De fil en aiguille, on pense également à l'isolation thermique de certains
pipelines
Et enfin on en vient à rêver d'avoir les infos sur l'isolation thermique du
bâti.

Une proposition va être écrite en ce sens sur le wiki
https://wiki.openstreetmap.org/wiki/Proposed_features/Insulation_proposal

On nous parle de plus en plus de rénovation de l'habitat, d'efficacité
énergétique. Donnons les moyens à OSM de rassembler de l'information
factuelle à ce propos.

Peut-être avez-vous déjà des idées, commencé à réfléchir ?

Le sujet est vaste, il existe beaucoup de technique/matériaux. Progressons
par étapes.
Techniquement, on utiliserait la clé insulation=* pour classifier dans les
grandes lignes l'isolation en présence (peut-être carrément le type
thermique, électrique, acoustique, étanchéité,...).
Ensuite on pourra exploiter le namespace insulation:* pour donner plus
d'infos.
Ça reste à définir.


Nul doute que ce peut être génial.

A+

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

Re: [OSM-talk-fr] RNIL ?

2016-12-06 Par sujet osm . sanspourriel 

Effectivement c'est bien la RN 2 :
https://fr.wikipedia.org/wiki/Route_nationale_2_(France_m%C3%A9tropolitaine) 


Donc ref=N 2

Et les Routes National d'Intérêt National ce sont les autoroutes et les 
voies express ? ;-)


https://fr.wikipedia.org/wiki/Autoroute_A1_(France) 

https://fr.wikipedia.org/wiki/Autoroute_A2_(France) 



L'avantage de la relation :
https://www.openstreetmap.org/relation/6099321#map=14/48.9660/2.5647
c'est qu'on voit que la N 2 est appelée Francilienne / A 104 sur un 
tronçon : est-ce bien raisonnable ?


Effectivement, c'est le cas.
http://routes.wikia.com/wiki/Liste_historique_des_routes_nationales_1_%C3%A0_50

Par contre RNIL semble utilisé exclusivement sur routes.wikia.com 
 
dans le 9 3.

Pas vu une seule image sur le site qui affiche RNILxx.

Jean-Yvon

Le 06/12/2016 à 13:25, Christian Quest - cqu...@openstreetmap.fr a écrit :
Je tombe à l'instant sur de drôle de ref=* dans le 93 sur la N 2 qui 
s'est vue affublée un "ref=RNIL 2".


De même une relation "route" a été créé: 
https://www.openstreetmap.org/relation/6106772



RNIL kézako ? 
https://fr.wikipedia.org/wiki/Route_nationale_d'int%C3%A9r%C3%AAt_local


Ce terme de "Routes Nationales d'Intérêt Local" est vraiment du jargon 
administratif et il me semble abusif de mettre cet acronyme en ref=*


Je compte remettre tout ça en "N 2", en mettant un tag operator pour 
indiquer que c'est le CG93 qui les gère... et je ne vois pas non plus 
l'intérêt de la relation "route" qui n'en est pas une et qui ne 
correspond de mon point de vue qu'à une collection.


J'a mis un commentaire sur un des changesets: 
https://www.openstreetmap.org/changeset/38312447


Votre avis ?



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

Re: [OSM-talk-fr] Salon Pollutec

2016-12-06 Par sujet François Lacombe 
Bonsoir Christian,

Merci pour ton message (désolé du temps mis à la réponse, gmail qui colle
laposte.net en spam encore).

Je donnais l'exemple de pollutec parce qu'il m'est venu en tête.
Aucune idée cependant des contraintes pour disposer d'un stand à ce genre
de salon.
C'est valable aussi pour le salon des maires et bien d'autre.

C'est à murir collectivement ici avant toute chose


Bonne soirée

*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux 

Le 28 novembre 2016 à 11:10,  a écrit :

> Salut François
>
> de tout coeur avec toi sur le sujet, d'ou la question complementaire à ta
> proposition de sensibiliser la Métropole :
> - Que doit-t'on/peut-t'on faire pour t'aider dans ta demarche ?
> Nota: Sylvain avait fait une carte des exposants du salon Primevere,
> est-ce une base de départ !
>
> A+
> Christian - gnrc
>
> --
> *De: *"François Lacombe" 
> *À: *"Discussions sur OSM en français" 
> *Envoyé: *Lundi 28 Novembre 2016 09:41:55
> *Objet: * [OSM-talk-fr] Salon Pollutec
>
> Bonjour à tous,
>
> Cette semaine se tient le salon Pollutec, grand rendez-vous de certains
> acteurs investis dans la gestion des ressources et de l'environnement.
>
> Essayons une petite recherche :
> http://www.pollutec.com/Visiter/Les-Exposants-2016.
> htm?SType=CRITERIA&Search=words_openstreetmap_&From=Box
>
> C'est pas encore foufou, est-ce que l'asso souhaite investir dans ce genre
> d'actions de visibilité ?
> Parce que, en attendant Suez et les autres ils continuent à publier des
> cartes de bennes à ordure sur Google Maps.
>
> Avec tous les contacts qu'on peut avoir ici avec la métropole lyonnaise,
> je devrais bien arriver à faire quelque chose pour un stand l'année
> prochaine.
>
> A+
>
> François
>
>
> *François Lacombe*
>
> fl dot infosreseaux At gmail dot com
> www.infos-reseaux.com
> @InfosReseaux 
>
> ___
> 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 des référentiels STIF

2016-12-06 Par sujet Florian LAINEZ 
Le 6 décembre 2016 à 13:45, Christian Quest  a
écrit :

> J'ai regardé dans mon quartier desservi par la RATP... c'est "correct" à
> 50m près.

J'en ai à peu près le même souvenir. J'ai checké une belle quantité
d'arrêts autour de gares Transilien cet été, j'en ai trouvé certains sur
les quais de gares ... d'autres très bien placés.

Le STIF agrégeant des données provenant d'une multitude de sociétés de
> transport, la qualité géométrique n'est sûrement pas homogène
>
exactement.

Fred tu peux considérer le champs ZDEr_ID_REF_A comme notre ref:FR:STIF,
merci


-- 

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

Re: [OSM-talk-fr] Liste de choix JOSM

2016-12-06 Par sujet bernard 

OK merci


Le 06/12/2016 à 16:24, Vincent de Château-Thierry a écrit :

Bonjour,


De: "bernard" 

La liste de choix (attribut) pour school:FR ne permet que :
- maternelle
- élémentaire
Dans le wiki, on trouve :
Une correction de la liste de choix serait la bienvenue.

Si tu parles de la liste déroulante de suggestions pour la saisie, après 
double-clic dans le panneau des attributs, elle est alimentée par les données 
présentes dans ton calque courant. Donc en chargeant une zone avec différents 
types d'établissements tu devrais trouver autant de propositions dans la liste.

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] Liste de choix JOSM

2016-12-06 Par sujet Vincent de Château-Thierry 
Bonjour,

> De: "bernard" 
> 
> La liste de choix (attribut) pour school:FR ne permet que :
> - maternelle
> - élémentaire
> Dans le wiki, on trouve :
> Une correction de la liste de choix serait la bienvenue.

Si tu parles de la liste déroulante de suggestions pour la saisie, après 
double-clic dans le panneau des attributs, elle est alimentée par les données 
présentes dans ton calque courant. Donc en chargeant une zone avec différents 
types d'établissements tu devrais trouver autant de propositions dans la liste.

vincent

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

[OSM-talk-fr] Liste de choix JOSM

2016-12-06 Par sujet bernard 

Bonjour,
La liste de choix (attribut) pour school:FR ne permet que :
- maternelle
- élémentaire
Dans le wiki, on trouve  :
Une correction de la liste de choix serait la bienvenue.
Bernard
-
École   school:FR   Tag principal
Maternelle (petite à grande section) 	school:FR 
=maternelle 
amenity =kindergarten 

Élémentaire (CP à CM2) 	school:FR 
=élémentaire 
amenity =*school*
Primaire (maternelle et élémentaire) 	school:FR 
=primaire 	amenity 
=*school*
Collège (6e à 3e) 	school:FR 
=collège 	amenity 
=*school*
Lycée (2nde à Terminale) 	school:FR 
=lycée 	amenity 
=*school*
Secondaire (collège et lycée) 	school:FR 
=secondaire 
amenity =*school*
Université 	 ? 	amenity 
=university 


Autres écoles supérieures

	 ? 	amenity =college 



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

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-06 Par sujet Christian Quest 

Le 06/12/2016 à 12:25, Frédéric Rodrigo a écrit :

Le 06/12/2016 à 10:05, Florian LAINEZ a écrit :


Le 6 décembre 2016 à 01:42, Jérôme Amagat > a écrit :


Pour l'instant, dans osmose, l'ajout de donnée externe c'est
l'ajout d'un node ou l'ajout de tag sur un objet déjà existant.
Donc dans notre cas, ça marche bien pour ajouter les arrêts de bus.


en effet. Noémie, si tu veux t'attaquer aux lignes avant tout, il va 
nous falloir un outil adapté ... tu nous code ça vite fait bien fait 
? ;)


Fred tu penses que tu pourrais nous intégrer ce jeu de données 
https://opendata.stif.info/explore/dataset/referentiel-arret-tc-idf/ 
dans Osmose stp ? On pourra déjà commencer à bosser sur les arrêts 
comme ça.

Merci d'avance

C'est faisable.

À note que j'avais déjà ajouté les arrêts de bus RATP que puis retiré, 
parce que la qualité était trop mauvaise. Dans les données SITF à mon 
avis il doit y a voir du bon et du moins bon. Vous avez déjà une idée 
de la qualité (-> distance de conflation pour Osmose) ?




J'ai regardé dans mon quartier desservi par la RATP... c'est "correct" à 
50m près.


Le STIF agrégeant des données provenant d'une multitude de sociétés de 
transport, la qualité géométrique n'est sûrement pas homogène. Il faut 
donc regarder à d'autres endroits, hors petite couronne.


--
Christian Quest - OpenStreetMap France


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

[OSM-talk-fr] RNIL ?

2016-12-06 Par sujet Christian Quest 
Je tombe à l'instant sur de drôle de ref=* dans le 93 sur la N 2 qui 
s'est vue affublée un "ref=RNIL 2".


De même une relation "route" a été créé: 
https://www.openstreetmap.org/relation/6106772



RNIL kézako ? 
https://fr.wikipedia.org/wiki/Route_nationale_d'int%C3%A9r%C3%AAt_local


Ce terme de "Routes Nationales d'Intérêt Local" est vraiment du jargon 
administratif et il me semble abusif de mettre cet acronyme en ref=*


Je compte remettre tout ça en "N 2", en mettant un tag operator pour 
indiquer que c'est le CG93 qui les gère... et je ne vois pas non plus 
l'intérêt de la relation "route" qui n'en est pas une et qui ne 
correspond de mon point de vue qu'à une collection.


J'a mis un commentaire sur un des changesets: 
https://www.openstreetmap.org/changeset/38312447


Votre avis ?

--
Christian Quest - OpenStreetMap France


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

[OSM-talk-fr] Missing Maps et les collectivités territoriales + Rappel Mapathon OSM OGP jeudi 8/12 Paris

2016-12-06 Par sujet Violaine Doutreleau 

Bonjour à tous,

Un message rapide pour partager avec vous le travail que l'on mène avec 
les coopérations décentralisées et vous (re)proposer de passer au 
*mapathon OSM, side-event de la conférence OGP* (Open Government 
Partnership) de *ce jeudi 8/12 *à Paris.


Depuis quelques mois CartONG a commencé à travailler avec des villes 
françaises pour cartographier sur OSM les villes avec lesquelles elles 
ont des projets de coopérations décentralisées (coopération entre 
collectivités locales dans un objectif de développement). Ces projets 
sont intéressants à plusieurs titres :


 * création d'une carte à jour du territoire, généralement inexistante
   auparavant
 * participation citoyenne en France aux projets de solidarité
   internationale
 * découverte d'OpenStreetMap par un public qui ne le connaissait peu
   (membres d'associations notamment)
 * co-construction de la carte avec les communautés locales / les
   personnes originaires de ces territoires en France (excellent
   exemple ici
   

   [1] avec la ville d'Ivry et Phillippe Jarry)
 * accessibilité accrue de la cartographie aux acteurs institutionnels
   locaux mais aussi à la société civile, et autonomisation sur ces
   technologies, notamment via la connexion des acteurs locaux avec les
   communautés OSM du Sud

Nous avons ainsi monté un petit projet avec la coopération Chambéry 
Ouahigouya qui doit permettre : a) de produire une carte du territoire 
(si vous voulez participer, vous pouvez jeter un coup d’œil au projet du 
TM  [2]), b) de faciliter le 
développement de communauté OSM sur place! (OSM-Burkina Faso a déjà bien 
fait avancer la carto).


Ainsi, vous êtes plus que les bienvenus à venir participer à ce mapathon 
OSM qui aura lieu au *Liberté Living Lab à Paris, jeudi 8 à 18h30 
(**infos et inscriptions ici 
**[3])* 
sur ce projet. Ce mapathon est co-organisé avec *HOT et OSM France*. 
Pour les contributeurs parisiens qui n'auront pas l'occasion de 
participer au sommet OGP, c'est une opportunité de rencontrer les 
membres des nombreuses communautés OSM du monde entier qui participent à 
la conférence !


A bientôt j'espère,

Bises,

Violaine

[1] : 
https://94.citoyens.com/2016/a-ivry-sur-seine-337-km-de-rajoutes-sur-la-carte-du-mali-grace-a-un-mapathon,13-11-2016.html


[2]: http://tasks.hotosm.org/project/2333

[3] : 
https://www.eventbrite.fr/e/billets-mapathon-openstreetmap-paris-decembre-2016-lll-29743343140 



--

Violaine Doutreleau

Email:v_doutrel...@cartong.org 
Phone: +33 (0)4 79 26 28 82
Mobile: +33 (0)6 95 02 42 44
Skype: doutreleau.violaine  
CartONG Humanitarian mapping and information management
Website: cartong.org  | Twitter: @assocCartONG 
 | Address: Chambéry, France | Lon: 
05°55'24'' | Lat: 45°30'20''



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

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-06 Par sujet Frédéric Rodrigo 

Le 06/12/2016 à 10:05, Florian LAINEZ a écrit :


Le 6 décembre 2016 à 01:42, Jérôme Amagat > a écrit :


Pour l'instant, dans osmose, l'ajout de donnée externe c'est
l'ajout d'un node ou l'ajout de tag sur un objet déjà existant.
Donc dans notre cas, ça marche bien pour ajouter les arrêts de bus.


en effet. Noémie, si tu veux t'attaquer aux lignes avant tout, il va 
nous falloir un outil adapté ... tu nous code ça vite fait bien fait ? ;)


Fred tu penses que tu pourrais nous intégrer ce jeu de données 
https://opendata.stif.info/explore/dataset/referentiel-arret-tc-idf/ 
dans Osmose stp ? On pourra déjà commencer à bosser sur les arrêts 
comme ça.

Merci d'avance

C'est faisable.

À note que j'avais déjà ajouté les arrêts de bus RATP que puis retiré, 
parce que la qualité était trop mauvaise. Dans les données SITF à mon 
avis il doit y a voir du bon et du moins bon. Vous avez déjà une idée de 
la qualité (-> distance de conflation pour Osmose) ?


Le champ ZDEr_ID_REF_A on la mappe vers quel tag ?

Frédéric.


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

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-06 Par sujet Florian LAINEZ 
Le 6 décembre 2016 à 01:42, Jérôme Amagat  a écrit
:

> Pour l'instant, dans osmose, l'ajout de donnée externe c'est l'ajout d'un
> node ou l'ajout de tag sur un objet déjà existant. Donc dans notre cas, ça
> marche bien pour ajouter les arrêts de bus.


en effet. Noémie, si tu veux t'attaquer aux lignes avant tout, il va nous
falloir un outil adapté ... tu nous code ça vite fait bien fait ? ;)

Fred tu penses que tu pourrais nous intégrer ce jeu de données
https://opendata.stif.info/explore/dataset/referentiel-arret-tc-idf/ dans
Osmose stp ? On pourra déjà commencer à bosser sur les arrêts comme ça.
Merci d'avance

-- 

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