Re: [OSM-talk-fr] transport en commun à lyon et osmose

[Jérôme Amagat]

Le 5 décembre 2016 à 21:10, Jean-Yvon Landrac  a
écrit :

> Le 05/12/2016 à 20:54, Jérôme Amagat - jerome.ama...@gmail.com a écrit :
>
> Dans les données il y a aussi une liste des lignes qui s'arrête au point.
> Par exemple "296:R,C16A:R,C25B:R" pour dire que les bus de la ligne 296,
> C16 et C25 s'y arretent dans le sens retour(":R") (le "A" et le "B" avant
> les ":" je sais pas à quoi ils servent). Il ne me semble pas y avoir de tag
> pour exploiter cela à moins de le mettre dans un tag note=*.
>
> Logiquement il faut créer les relations. A priori les arrêts dans l'ordre
> des horaires ;-)
> Mais pour Osmose vérifier que les relations existent et que les arrêts y
> sont ?
>

ça doit être possible de vérifié que tous les arrêts sont dans la relation.
par contre ça aide pas à créé la relation au départ.

>
> En dessous j'ai mis le code avec seulement les arrêts de bus, les données
> donnent des points pour les arrêt de bus, tramway et métro.
> Puis une autre solution en integrant aussi les arrêts de tram (pour les
> trams, les points sont sur les platforms à côté des rails)
> Les tag pour les tram sont public_transport=platform, network=TCL,
> ref:FR:TCL=*, name=* et wheelchair=(yes ou no). Je ne sais pas s'il faut
> ajouter tram=yes et railway=platform.
>
> si, au moins pour tram=yes
>

c'est vrai que je voulais l'ajouter mais c'est pas indiqué sur la page du
wiki sur les public_transport=platform
 (https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dplatform)
ce tag, comme bus=yes d’ailleurs, est indiqué seulement sur
public_transport=stop_position
c'est peut être du au rendu qui affiche les arrêts de bus au platform pour
les bus et au stop_position pour les tram.

Pour les arret de metro je les ai exclu je sais pas où sont placés les
> points (sur les platform en sous sol je pense mais c'est peut etre tres
> loin de celle-ci vu que l'on voit rien du sous sol sur les photos aeriennes
> :P)
>
> Deep packet inspection by NSA? ;-)
>
> Jean-Yvon
>
>
___
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

[Jérôme Amagat]

liser ref:FR:STIF pour identifier les
>>> lignes et les zones d'arrêt même si cela ne correspond pas au même
>>> identifiant coté STIF. Le simple fait que cela s'applique à une ligne
>>> suffit à expliciter le type d'objet concerné.
>>>
>>> Tu dis qu'il y a déjà des objets avec ref:FR:STIF, je ne les ai pas
>>> trouvé, tu peux nous envoyer la requête Overpass utilisée stp ? Si
>>> d'autres
>>> références sont indiquées, il va falloir que l'on trouve ce à quoi cela
>>> correspond.
>>> Au doigt mouillé, je dirait que ce sont des identifiants de la RATP ou
>>> d'un autre transporteur qui ont été mal tagués.
>>>
>>> Est-ce que tu as intégré les données du STIF dans OSMOSE pour qu'on
>>> puisse
>>> "dégommer du rouge" avec toi ? ;)
>>>
>>> Le 4 décembre 2016 à 20:09, <osm.sanspourr...@spamgourmet.com> a écrit :
>>>
>>> Le 04/12/2016 à 18:41, Noémie Lehuby - noemie.leh...@openmailbox.org a
>>>> écrit :
>>>>
>>>> Je pensais partir simplement sur ref:FR:STIF pour indiquer les
>>>> identifiants. Mais :
>>>> * Il y a des déjà des objets avec ce tag dans la base. Je n'ai pas
>>>> trouvé
>>>> à quoi correspondent ces références actuelles. Ça ressemble un peu à la
>>>> colonne ExternalCode_ID du référentiel STIF, mais pas tout à fait...
>>>> Quelqu'un sait ce que c'est et si ça a toujours une réalité ?
>>>> * Est-ce que c'est choquant d'utiliser ce tag à la fois pour les
>>>> références des lignes, des points d'arrêts et des zones d'arrêts ?
>>>> Sinon,
>>>> on peut affiner la clef avec ref:FR:STIF:ID_Line et
>>>> ref:FR:STIF:ZDEr_ID_REF_A.
>>>>
>>>> Qu'en pensez-vous ?
>>>>
>>>> nlehuby
>>>>
>>>> Tu peux peut-être contacter des créateurs de ces références pour ne
>>>> avoir
>>>> le cœur net. Si l'intersection est vide, tu peux te contenter d'une clé,
>>>> sinon ça va être compliqué.
>>>> Ce que tu dis sur le wiki me semble correct.
>>>> Garder les 2 références permet sans doute de suivre plus facilement les
>>>> évolutions.
>>>>
>>>> Jean-Yvon
>>>>
>>>> ___
>>>> Talk-fr mailing list
>>>> Talk-fr@openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>>
>>>>
>>>>
>>>
>>> --
>>>
>>> *Florian Lainez*
>>> @overflorian <http://twitter.com/overflorian>
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>> -- section suivante --
>> Une pièce jointe HTML a été nettoyée...
>> URL:
>> <http://lists.openstreetmap.org/pipermail/talk-fr/attachment
>> s/20161205/183afb3b/attachment-0001.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] Problème de représentation avec des parcelles forestières

[Christian Quest]

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
>
> ___
> 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] Drones et reconnaissance automatique

[Philippe Verdy]

Le 5 décembre 2016 à 22:19, Christian Rogel <
christian.ro...@club-internet.fr> a écrit :

>
> > Le 2016 Kzu. 4 à 18:31, Philippe Verdy  a écrit :
> >
> >  Me suis-je limité à Osmose dans son état actuel ?
>
>
> Je trouve aventureux d’imaginer qu’un primo-contributeur, et surtout un
> contributeur temporaire, pourra  explorer en même temps l’interface de
> collecte et l’interface de vérification.
>

Pourquoi "en  même temps". Quand les tâches se spécialiseront, il y aura
des activités différentes utilisant chacune leurs outils. Ce sera
inévitable à mon avis (et le plus gros du travail ne sera plsu en fait dans
les éditeurs actuels, mais par ces outils où on travaillera sur des données
plus spécialisées pour les intégrer plus facilement.

Tout le monde n'utilisera pas tous les outils, chacun trouvera son intérêt
à travailler avec l'un ou l'autre pour des domaines différents. Mais on ne
peut pas passer outre le fait que le travail d'intégration est déjà
nécessaire (et même obligatoire) dans OSM ! iD existera encore mais pour
des besoins locaux bien plus limités.
___
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

[osm . sanspourriel]

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
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Drones et reconnaissance automatique

[Christian Rogel]

> Le 2016 Kzu. 4 à 18:31, Philippe Verdy  a écrit :
> 
>  Me suis-je limité à Osmose dans son état actuel ?


Je trouve aventureux d’imaginer qu’un primo-contributeur, et surtout un 
contributeur temporaire, pourra  explorer en même temps l’interface de collecte 
et l’interface de vérification.
Cette dernière ne pourrait aller au-delà de quelques commandes très simples 
intégrées à iD ou tout autre éditeur basique.
Cela limitera les possibilités de casse, mais l’avenir est sans doute à un JOSM 
plus « user friendly » pour les contributeurs qui persévèrent.
Un iD stand alone avec un mode simpe et un mode avancé serait souhaitable, mais 
il manque le « business model ».

S’agissant d’un activité ludique, la contrepartie est qu'il peut exister une 
phobie des outils sans abord facile.


Christian R.
___
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

[LeTopographeFou]

Bonsoir à tous,

Merci pour vos réponses. A l'heure actuelle le rendu est pire encore car 
j'ai (à priori) terminé de réparer les mp mal taggés. Et il apparait que 
si la précédente carte était plutôt bien dessinée, c'est plus par 
"chance" que par la qualité des mp qui existaient. Maintenant avec des 
parcelles "propres" (fermées, etc.) les bugs ressortent et... c'est 
catastrophique.


Je partage globalement ton analyse Philippe (nom sélectionné arbitraire 
et valeur par défaut supposément erronées de area). Au delà du fait que 
se soient des relations non reconnues, je pense qu'il y a un 
comportement par défaut bizarre du rendu (ou de la moulinette qui le 
nourrit). Je ferai remonter les bugs à Mapnik à l'occasion (que mes 
dernières modifs se stabilisent).


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.


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 :-) .


Cordialement,

LeTopographeFou

Le 03/12/2016 à 22:17, Philippe Verdy a écrit :
Ceci dit si je prend l'exemple du triangle formé entre les carrefours 
de la Réserve, des Grès et de Madame par les trois routes forestières 
de la Fresnaye, des Grès et de Madame, il y a bien un attribut highway 
commun, mais aucun nom commun.


L'attribut highway est "remonté" au niveau de la relation mais le nom 
"Route Madame" (pioché au hasard entre les 3 possibles) n'a pas à 
l'être car il n'est pas commun: c'est bien un bogue de la conversion 
OSM-GIS.


D'autre part, remonter l'attribut highway **linéaire** (par défaut) à 
la relation ne devrait pas avoir lieu non plus (les 3 chemins sont des 
"highway=*" qui ne sont pas tagués avec "area=yes" donc à interpréter 
comme "area=no" par défaut, conformément à la documentation de 
"highway=*"). Donc là encore un bogue de la conversion OSM-GIS.



Le 3 décembre 2016 à 22:05, Philippe Verdy > a écrit :


Le rendu ne fait pas cette interprétation tout seul: il ne le fait
que si tous les chemins membres d'une même relation partagent
exactement le même attribut, et dans ce cas il rapporte cet
attribut à la relation, et seulement si cette relation décrit une
surface fermée (en un ou plusieurs anneaux s'il y a des enclaves).
Certains attributs sont exclus de ce traitement (dont highway qui
est la plupart du temps uniquement linéaire, à moins qu'il y ait
aussi sur les chemins un area=yes).

Ces cas de transformation sont détectés dans la validation de JOSM
qui indique de taguer la relation et non les chemins membres.

Ensuite si la relation n'est pas exclue comme surface par ses
attributs (dont area=no), elle peut être rendue comme une surface

Le 3 décembre 2016 à 18:52, JB > a écrit :

Oui, les multipolygones, c'est élégant d'un point de vue
intellectuel et parfois, c'est absolument impraticable dans la
réalité. Et impossible à maintenir. Pour 3 nœuds et trois
ways, pourquoi inventer un MP plutôt qu'utiliser un chemin
fermé simple ?
Sinon, je pense (à confirmer) que le rendu brun avec le nom de
rue au milieu, c'est Mapnik qui considère que le MP représente
un chemin (highway=*) : comme il ne reconnait pas le type de
multipolygone utilisé (forest=section + ref), il prend le
premier way, voit un highway=*, et considère que la surface
est un highway avec un multipolygone mal conditionné. Et hop.
Foireux pour foireux, tant qu'à faire…
JB.


Le 03/12/2016 à 18:29, LeTopographeFou a écrit :


Bonjour,

Suite à mon sujet sur les intersections en forêt j'ai essayé
de savoir pourquoi certaines parcelles et chemins en forêt de
Saint-Arnoult (mais pas que...) génèrent des soucis de dessin
alors qu'elles paraissent toutes homogènes en terme de tags
et qu'elles sont toutes fermées. Marron, gris, blanc,
transparent... ce n'est pas homogène !

A noter que je suppose que les parcelles ne sont à priori pas
dessinées (sinon on verrait son numéro, il n'y aurait pas de
statut "proposition", et le rendu serait plus homogène que cela).

Voici mes constatations :

  * Rendu 

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

[Noémie Lehuby]

ps://lists.openstreetmap.org/listinfo/talk-fr





--

*Florian Lainez*
@overflorian <http://twitter.com/overflorian>

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



-- section suivante --
Une pièce jointe HTML a été nettoyée...
URL:
<http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20161205/183afb3b/attachment-0001.html>

--


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

[OSM-talk-fr] transport en commun à lyon et osmose

[Jérôme Amagat]

J'ai fait la même chose pour Lyon que ce que j'ai fait à Rennes (en
essayant de faire moins d'erreur...)
les données sont là :
http://data.grandlyon.com/equipements/points-darrft-du-rfseau-tcl
Sur les points des données (ils sont, je pense, là où les bus s'arrête donc
la plupart du temps sur les zébras c'est pas tout a fait les platform mais
presque) j'ai mis les tags highway=bus_stop, public_transport=platform,
bus=yes, network=TCL, ref:FR:TCL=*, name=* et wheelchair=(yes ou no)
Dans les données il y a aussi une liste des lignes qui s'arrête au point.
Par exemple "296:R,C16A:R,C25B:R" pour dire que les bus de la ligne 296,
C16 et C25 s'y arretent dans le sens retour(":R") (le "A" et le "B" avant
les ":" je sais pas à quoi ils servent). Il ne me semble pas y avoir de tag
pour exploiter cela à moins de le mettre dans un tag note=*.
En dessous j'ai mis le code avec seulement les arrêts de bus, les données
donnent des points pour les arrêt de bus, tramway et métro.
Puis une autre solution en integrant aussi les arrêts de tram (pour les
trams, les points sont sur les platforms à côté des rails)
Les tag pour les tram sont public_transport=platform, network=TCL,
ref:FR:TCL=*, name=* et wheelchair=(yes ou no). Je ne sais pas s'il faut
ajouter tram=yes et railway=platform.
Pour les arret de metro je les ai exclu je sais pas où sont placés les
points (sur les platform en sous sol je pense mais c'est peut etre tres
loin de celle-ci vu que l'on voit rien du sous sol sur les photos aeriennes
:P)

Pour Frédéric : je sais pas trop si ce que j'ai fait c'est bon pour les
coordonnées et le where pour ne prendre que les arrêt de bus (ou bus et
tram)


#!/usr/bin/env python
#-*- coding: utf-8 -*-

from Analyser_Merge import Analyser_Merge, Source, SHP, Load, Mapping,
Select, Generate


class Analyser_Merge_Public_Transport_FR_TCL(Analyser_Merge):
def __init__(self, config, logger = None):
self.missing_official = {"item":"8040", "class": 91, "level": 3,
"tag": ["merge", "public transport"], "desc": T_(u"TCL stop not
integrated") }
self.possible_merge   = {"item":"8041", "class": 93, "level": 3,
"tag": ["merge", "public transport"], "desc": T_(u"TCL stop, integration
suggestion") }
self.update_official  = {"item":"8042", "class": 94, "level": 3,
"tag": ["merge", "public transport"], "desc": T_(u"TCL stop update") }
Analyser_Merge.__init__(self, config, logger,
"
http://data.grandlyon.com/equipements/points-darrft-du-rfseau-tcl;,
u"Points d'arrêt du réseau TCL",
CSV(Source(attribution = u"SYTRAL", millesime = "12/2016",
fileUrl = "
https://download.data.grandlyon.com/wfs/rdata?SERVICE=WFS=2.0.0=SHAPEZIP=GetFeature=EPSG:4326=tcl_sytral.tclarret;,
zip = "tcl_sytral.tclarret.shp")),
Load(("ST_X(geom)",), ("ST_Y(geom)",), srid = 4326,
where = lambda res: not 'T' in res['desserte'] and not '30'
in res['desserte']), # "desserte" donne la liste des lignes s'arrétant à ce
point. Pour enlever les arrêts de tram (les noms des lignes commencent par
"T") et de métro (les noms des lignes commencent par "30") (et aucune ligne
de bus ne contiennent "T" ou "30")
Mapping(
select = Select(
types = ["nodes", "ways"],
tags = {"highway": "bus_stop"}),
osmRef = "ref:FR:TCL",
conflationDistance = 100,
generate = Generate(
static1 = {
"highway": "bus_stop",
"public_transport": "platform",
"bus": "yes",
"network": "TCL"},
static2 = {"source": self.source},
mapping1 = {
"ref:FR:TCL": "id",
"name": "nom",
"wheelchair": lambda res: "yes" if res["pmr"] ==
"t" else "no" if res["pmr"] == "f" else None},
text = lambda tags, fields: {"en": u"TCL stop of %s" %
fields["nom"], "fr": u"Arrêt TCL de %s" % fields["nom"]} )))

# en integrant aussi les arrêts de tramway

class Analyser_Merge_Public_Transport_FR_TCL(Analyser_Merge):
def __init__(self, config, logger = None):
self.missing_official = {"item":"8040", "class": 91, "level": 3,
"tag": ["merge", "public transport"], "desc": T_(u"TCL stop not
integrated") }
self.possible_merge   = {"item":"8041", "class": 93, "level": 3,
"tag": ["merge", "public transport"], "desc": T_(u"TCL stop, integration
suggestion") }
self.update_official  = {"item":"8042", "class": 94, "level": 3,
"tag": ["merge", "public transport"], "desc": T_(u"TCL stop update") }
Analyser_Merge.__init__(self, config, logger,
"
http://data.grandlyon.com/equipements/points-darrft-du-rfseau-tcl;,
u"Points d'arrêt du réseau TCL",
CSV(Source(attribution = u"SYTRAL", millesime = "12/2016",

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

[Jérôme Amagat]

J'ai regardé un peu les données.
Déjà pour les arrêts les "Zones d'Embarquement d'Île-de-France (ZDE)" (les
public_transport=platform dans osm) les coordonnées semble de bonne
qualité. (pour les noms par contre c'est pas homogène certains sont tout en
majuscule d'autres non, avec bien sur des problèmes avec les accents non
présents sur les majuscules)
C'est un bon candidat pour osmose je pense. (les tags ajoutés seraient
public_transport=platform name=* et pour les arrêt de bus :
highway=bus_stop bus=yes il y a aussi les arrêts de tram et métro)
Pour les autres données : Zone de Lieu (ZDL) Lieu d’arrêt (LDA) possibilité
de créer une relation public_transport = stop_area qui regroupe des
platforms mais je sais pas pour lequel des 2 et c'est plus compliqué pour
osmose.

Par contre les ref: il y en a beaucoup dans les fichiers. je dirais qu'il
faut utiliser ref:FR:STIF et c'est suivant les autres tags que l'on sait
quel ref c'est.
par contre pour les arrêts, il y a un ID_REFA avec les "Zones
d'Embarquement" et dans le fichier "Arrêts par lignes de transport en
commun en Ile-de-France" il y a un stop_id (qui peut être par exemple
"StopPoint:81:255"). c'est une partie des valeurs déjà présentent dans osm.
Dans osm il y a des ref:FR:STIF (http://overpass-turbo.eu/s/kty) et des
ref:FR:stif (http://overpass-turbo.eu/s/ktA)

Le 5 décembre 2016 à 08:49, Florian LAINEZ  a écrit :

> Salut Noémie,
> L'identifiant ref:FR:STIF me parait également le plus pérenne et donc il
> devrait être préféré systématiquement. Ceci dit, il n'y a aucun problème à
> ajouter le code technique si cela peut t'être utile.
>
> Il ne me semble pas choquant d'utiliser ref:FR:STIF pour identifier les
> lignes et les zones d'arrêt même si cela ne correspond pas au même
> identifiant coté STIF. Le simple fait que cela s'applique à une ligne
> suffit à expliciter le type d'objet concerné.
>
> Tu dis qu'il y a déjà des objets avec ref:FR:STIF, je ne les ai pas
> trouvé, tu peux nous envoyer la requête Overpass utilisée stp ? Si d'autres
> références sont indiquées, il va falloir que l'on trouve ce à quoi cela
> correspond.
> Au doigt mouillé, je dirait que ce sont des identifiants de la RATP ou
> d'un autre transporteur qui ont été mal tagués.
>
> Est-ce que tu as intégré les données du STIF dans OSMOSE pour qu'on puisse
> "dégommer du rouge" avec toi ? ;)
>
> Le 4 décembre 2016 à 20:09,  a écrit :
>
>> Le 04/12/2016 à 18:41, Noémie Lehuby - noemie.leh...@openmailbox.org a
>> écrit :
>>
>> Je pensais partir simplement sur ref:FR:STIF pour indiquer les
>> identifiants. Mais :
>> * Il y a des déjà des objets avec ce tag dans la base. Je n'ai pas trouvé
>> à quoi correspondent ces références actuelles. Ça ressemble un peu à la
>> colonne ExternalCode_ID du référentiel STIF, mais pas tout à fait...
>> Quelqu'un sait ce que c'est et si ça a toujours une réalité ?
>> * Est-ce que c'est choquant d'utiliser ce tag à la fois pour les
>> références des lignes, des points d'arrêts et des zones d'arrêts ? Sinon,
>> on peut affiner la clef avec ref:FR:STIF:ID_Line et
>> ref:FR:STIF:ZDEr_ID_REF_A.
>>
>> Qu'en pensez-vous ?
>>
>> nlehuby
>>
>> Tu peux peut-être contacter des créateurs de ces références pour ne avoir
>> le cœur net. Si l'intersection est vide, tu peux te contenter d'une clé,
>> sinon ça va être compliqué.
>> Ce que tu dis sur le wiki me semble correct.
>> Garder les 2 références permet sans doute de suivre plus facilement les
>> évolutions.
>>
>> Jean-Yvon
>>
>> ___
>> 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

[OSM-talk-fr] Rencontre mensuelle OSM-Lyon 13/12/2016 18h30 - Invitation

[gnrc]

Bonjour à tous, 

Les mappeurs OSM de Lyon se rencontrent régulièrement le 2ème mardi de chaque 
mois, et chacun peut s'inviter et participer à ces rencontres. La prochaine 
aura lieu : 

le MARDI 13 DECEMBRE à partir de 18h30 
à l'espace "Infolab TUBA, 1 Place Charles Béraudier, 69003 LYON" (esplanade 
gare Part-dieu) 
Accès : M° "Gare Part-Dieu"; Tram T1; Bus C1, C2, C6, C7, C13, C25, 25, 37, 38, 
70 ; Vélo'V "Gare Part-Dieu Ouest" 

Le CR de la rencontre précédente se trouve sur la page du Wiki-OSM au lien : 
https://wiki.openstreetmap.org/wiki/Lyon/Reunion_8_novembre_2016 

Si vous souhaitez mettre un sujet particulier à l'ordre du jour de la rencontre 
à venir, vous pouvez commenter la page préparatoire au lien : 
https://wiki.openstreetmap.org/wiki/Lyon/Reunion_13_decembre_2016 

Venez nombreux ! 
Amicalement 

gnrc69 - Chaque goutte fait l’océan ! 

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

hebdoOSM Nº 332 22/11/2016-28/11/2016

[weeklyteam]

Bonjour,

Le résumé hebdomadaire n° 332 de l'actualité OpenStreetMap vient de paraître en 
français. Un condensé à retrouver à:

http://www.weeklyosm.eu/fr/archives/8390/

Bonne lecture!

hebdoOSM?
Qui?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr