[OSM-talk-fr] Utilisation de subway_entrance pour autre chose que du métro ?
Bonjour, J'aimerais réussir à cartographier clairement les entrées/sorties de stations et gares de transports en commun en Île-de-France. A la fois pour le rendu, mais aussi pour les applications de routing piéton. Le tag railway=subway_entrance [1] existe et est (logiquement) utilisé à Paris pour les stations de métro. Autant en anglais ou allemand, le wiki est clair et parle de subway ou d'U-Bahn, autant le wiki FR le décrit comme "l'entrée qui permet d'accéder au réseau de transport métropolitain". C'est large, ne précise pas si le réseau est enterré ou non et donc pas forcément cohérent avec ce que font les autres pays (ni l’étymologie du tag). D'après-vous, est-ce que ça s'applique-t-il aussi aux stations de RER (qui font partie d'un réseau bien distinct du métro et dont le voies ne sont généralement pas souterraines) ? Par exemple, subway_entrance est assez étrange à la gare de Massy-Palaiseau, complètement extérieure [2]. De plus, autant la question peut se poser pour les RER, autant le tag subway_entrance ne me semble pas avoir beaucoup de sens pour les gares de banlieue desservies par les trains transilien, qui font pourtant partie de l'offre de transport métropolitain (au sens premier, pas au sens "métro). De façon générale, la liste tagging propose d'utiliser entrance=* pour les entrées/sorties des gares/stations et d'ajouter le nœud à la relation "public_transport=stop_area" associée [3]. J'aime beaucoup le modèle Public Transport qui permet à la fois de modéliser des réseaux complexes, mais aussi de décrire la réalité vue du côté utilisateur, mais j'ai conscience que l'utilisation de relations n'est pas toujours très intuitive pour un utilisateur lambda. Est-ce qu'on utilise subway_entrance seulement pour le métro (RATP) ou alors toute station souterraine (quel que soit le réseau) ? Voire même tous les transports en commun ? (mais ça pose un problème de cohérence pour les gares à mon avis). Je serais d'avis de ne garder "subway_entrance" que pour les entrées clairement identifiées "Métro" et d'utiliser "entrance=*" couplé à une relation Public Transport pour le reste (RER + gares de banlieue) pour tous les accès au périmètre de la gare. Qu'est-ce que vous en pensez ? Vincent Génin (Pingolin) [1] http://wiki.openstreetmap.org/wiki/FR:Tag:railway%3Dsubway_entrance [2] http://overpass-turbo.eu/s/aBT "entrance" des gares du réseau Transilien et "subway_entrance" en Île-de-France [3] http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Stop_area ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Efficacité d'une requête Overpass (around)
Merci beaucoup à tous pour vos réponses.
Je pensais vraiment qu'une area bien definie faciliterait la tâche à
Overpass et je n'ai même pas testé sans...
Je vais tenter avec un BBox grossière et sans et voir ce que ça donne.
Pour le tilde, je ne vais pas pouvoir m'en passer si je veux faire un truc
propre, puisque qu'une gare peut desservir plusieurs lignes.
Je vais ajouter et nettoyer un peu les appels pour les services et
équipements (supprimer les acces=private/no ou voir comment avoir qq chose
de plus propre pour les terrains de tennis par exemple).
Merci en tout cas pour vos retours, et je vous tiens au courant de
l'avancée du projet.
Le 17 juil. 2015 02:25, "Thierry Bézecourt" a écrit :
> Oui, et on pourrait même supprimer carrément la bounding box car la
> condition sur la relation limite les résultats de manière équivalente
> (d'ailleurs la ligne C est, sauf erreur, entièrement en Île-de-France).
>
> De plus, il me semble que le tilde (présente dans le lien sur Overpass)
> ralentit la requête.
>
> La requête suivante (http://overpass-turbo.eu/s/atj) dure moins de 10
> secondes et devrait être facile à adapter pour d'autres lignes de RER.
> Evidemment, il faut faire attention à ne pas mettre une condition trop
> large sur la relation...
>
> [out:json];
>
> rel["line:SNCF"="C"];
> node(around:800)[sport=swimming];
> out body qt;
>
> rel["line:SNCF"="C"];
> way(around:800)[sport=swimming];
> out body center qt;
>
>
> Thierry
>
> Le 17/07/2015 08:19, Philippe Verdy a écrit :
>
>> La délimitation a l'Île-de-France au sens strict construit un polygone
>> très complexe. Ce serait peut-être plus rapide avec juste une bounding
>> box. Quitte a chercher des picines "autour" des gares et qu'il n'y a pas
>> tant que ca de gares, il suffit juste d'avoir une bounding bix englobant
>> les gares. Et après on n'est guère mieux qu'a 1 km près pour trouver les
>> piscines mais on n'a pas besoin de la précision fine des frontieres de
>> l'Île-de-France... Est-genant si tu as des résultats en Normandie ou
>> Picardie ?
>>
>> Le 16 juil. 2015 16:11, "Pierre-Yves Berrard"
>> mailto:pierre.yves.berr...@gmail.com>> a
>> écrit :
>>
>> Le 16 juillet 2015 15:09, Vincent Génin > <mailto:vincent.ge...@gmail.com>> a écrit :
>>
>> Bonjour à tous,
>>
>> Désolé si la question est un peu spécifique, mais je n'ai pas
>> trouvé de liste pour Overpass.
>>
>> Pour une utilisation personnelle, je recherchais des piscines
>> autour des gares de la ligne C du RER.
>> J'ai fait quelques tests et utilise cette requête :
>> http://overpass-turbo.eu/s/asI
>>
>> {{geocodeArea:Île-de-France}}->.searchArea;
>>
>> rel["line:SNCF"="C"](area.searchArea);
>> node(around:800)[sport=swimming](area.searchArea);
>> out body qt;
>>
>> rel["line:SNCF"="C"](area.searchArea);
>> way(around:800)[sport=swimming](area.searchArea);
>> out center qt;
>>
>>
>> Cependant, elle prend pas mal de temps à s'exécuter (~60s).
>>
>>
>> Bonjour,
>>
>> Il y aurait peut-être à creuser sur la première ligne, en lui
>> passant directement le numéro de la relation Ile-de-France.
>> Je n'ai plus en tête la syntaxe exacte : quelque chose du style
>> 3600 + le numéro de la relation.
>> Ça éviterait de passer par nominatim (?), mais je ne sais pas si ça
>> gagne beaucoup de temps.
>>
>> PY
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Efficacité d'une requête Overpass (around)
Bonjour à tous,
Désolé si la question est un peu spécifique, mais je n'ai pas trouvé de
liste pour Overpass.
Pour une utilisation personnelle, je recherchais des piscines autour des
gares de la ligne C du RER.
J'ai fait quelques tests et utilise cette requête :
http://overpass-turbo.eu/s/asI
{{geocodeArea:Île-de-France}}->.searchArea;
rel["line:SNCF"="C"](area.searchArea);
node(around:800)[sport=swimming](area.searchArea);
out body qt;
rel["line:SNCF"="C"](area.searchArea);
way(around:800)[sport=swimming](area.searchArea);
out center qt;
Cependant, elle prend pas mal de temps à s'exécuter (~60s).
Ça fonctionne pour une utilisation ponctuelle, mais je me suis dit que je
pourrais pousser un peu le projet et rendre tout ça interactif et
accessible. J'ai intégré ça avec leaflet et publié mes premiers tests sur
Github : http://pingolin.github.io/
Le problème est que la requête est tellement longue que ça rend la carte
très difficilement utilisable. J'ai testé en restreignant à la partie de la
carte affichée (bbox) mais ça reste long et je me retrouve avec des erreurs
429 (Too Many Request).
J'aimerais bien rendre la carte vraiment dynamique (changement du rayon, du
type de service recherché et de la ligne de transport à la volée) donc
j'aimerais bien rester sur une requête API et non sur des extracts.
Est-ce que vous auriez des idées pour améliorer et accélérer la requête
Overpass ?
Merci,
PS : Je ferai une vraie présentation du projet http://pingolin.github.io/
si j'arrive à avancer un peu dessus. Pour l'instant ce sont vraiment des
tests techniques pour prendre en main Overpass et Leaflet.
L'idée est de trouver des services et équipements sur sa ligne de
transport. On ne connait pas forcément toutes les villes ou quartiers qu'on
traverse et il est souvent plus facile de couper son trajet plutôt que de
l'allonger au départ ou à l'arrivée.
Vincent Génin
Pingolin (http://www.twitter.com/pingolin)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
