Re: [OSM-talk-fr] Landuse:farm et centre équestre
En considérant qu'un centre équestre représente une activité agricole, l'étiquette landuse=farmyard serait plus appropriée (désigne les bâtiments et infrastructures agricoles d'une ferme). L'étiquette landuse=farm désigne quant à elle les champs et prés (pour ces derniers, l'usage semble préférer landuse=meadow). Ceci conviendrait pour les prés où pâturent les chevaux, mais pas pour le centre équestre en tant que tel. Par ailleurs, pour un centre équestre leisure=sport_centre + sport=equestrian me semble approprié, non ? Zigeuner ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] loc_name ou short_name (ou autre ?)
Peut-être très utilisé, mais reste une abréviation familière et locale. Short_name et alt_name me semblent servir à rentrer dans la base des noms susceptibles d'être recherchés/utilisés. Je vois mal quelqu'un chercher dans la base Sainté, et, toi-même, l'utilisation de cette abréviation te gêne. Même l'utilisation de loc_name, plus adéquate, me semble un peu limite (Sainté n'est pas seulement local, mais familier). J'aime bien fam_name. On pourra l'utiliser pour Paname, Besac, Montpel, et tous les petits diminutifs locaux de chaque ville, quartier... Zigeuner ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] landuse=residential à Paris
Bonsoir, À Paris, ce sont les relations boundary limitant chaque arrondissement qui portent les étiquettes landuse=residential (ex. http://www.openstreetmap.org/relation/9519). Ceci conduit à un recouvrement avec les autres landuse que l'on peut trouver dans Paris. De plus, cela ne semble pas reconnu par certains moteurs de rendu. Avant de me lancer dans la création de multipolygones dédiés aux landuse=residential, je voudrais quand même m'assurer que cet état de fait n'est pas volontaire, que l'on peut retirer cette étiquette des relations-arrondissement. Zigeuner___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Landuse:farm et centre équestre
Personnellement, je ne chercherais pas à tout prix à mettre un landuse=farm/farmyard au prétexte que le ministère français a classé les centres équestres activité agricole, alors que ce n'est pas perçu sur le terrain comme une ferme. Mais si on veut le faire, farmyard semble plus approprié que farm ou meadow. Un centre équestre ressemble plus à une ferme qu'à un champ/pré. Ça me semble même pas mal correspondre à un terrain accueillant une maison, une écurie, un fenil, et l'espace entre eux. En tout cas plus qu'à un champ de maïs, ou une prairie où l'on va faire les foins dans deux semaines...___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Voies sans nom de Paris
Merci de vos réponses. J'ai supprimé cet objet highway=residential+area=yes. J'ai renommé les parties est et ouest de la place Rue Philippe de Girard, car c'est ce qui apparaît sur le cadastre et sur le terrain (en ajoutant alt_name=Place T/10 pour en conserver une trace). name=Place T/10 apparaît maintenant sur les deux parties de la place qui enjambent les voies. Le Mercredi 28 mai 2014 11h35, Pieren pier...@gmail.com a écrit : 2014-05-27 23:57 GMT+02:00 Christian Quest cqu...@openstreetmap.fr: [3] exemple de la Place T/10 : http://www.openstreetmap.org/way/10657703 À propos, que faire d'un tel objet : http://www.openstreetmap.org/way/157775359 (à part une relation multipolygone avec le rond intérne en inner). Si on veut être rigoureux, il devrait couvrir toute la zone goudronnée dédiée aux automobiles. Mais où placer la limite avec les autres rues ? Au final, ne vaudrait-il pas mieux le supprimer dans la mesure où l'on ne cartographie pas les surfaces des routes ? Bizarre cet area=yes surtout avec un oneway... pas cohérent du tout, je pense que le area=yes est en trop. Oui, je suis d'accord. Surtout avec un highway=residential et un oneway=yes. L' area=yes est normalement utilisé pour des places ouvertes où la circulation est libre dans toutes les directions, ce qui n'est pas le cas ici (terre-plein central, signalisation horizontale guidant les véhicules, sens de circulation). Il semble aussi que ce carrefour n'est pas un sens giratoire, donc il est normal d'y ajouter un oneway=yes au lieu d'un junction=roundabout. Si quelqu'un veut tracer l'emprise surfacique de la route, il doit utiliser un polygone additionel et le tag area:highway=residential 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] Relations
Pour une ligne de chemin de fer (au sens d'ensemble de voies, pas de service commercial), on peut utiliser une relation type=route + route=railway (http://wiki.openstreetmap.org/wiki/Tag:route%3Drailway) Une partie de la ligne, voire la totalité, pouvant être abandonnée, je ne vois pas ce qui empêcherait d'y regrouper des railway=disused. Zigeuner___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Voies sans nom de Paris
La réponse a déjà été donnée par Pieren au détour d'une conversation [1], mais je voudrais quand même être sûr de ce que je fais avant de dégommer du rouge. Pour les voies non nommées de Paris [2], on ajoute la référence utilisée par la ville de Paris en tant que 'name=', et pas en tant que 'alt_name' ou 'official_name', même dans les cas où cette référence n'apparaît pas du tout sur le terrain [3] ? Zigeuner [1] http://gis.19327.n5.nabble.com/Utilisation-du-cadastre-pour-les-numeros-de-voies-td5733499.html [2] http://fr.wikipedia.org/wiki/Voies_sans_nom_de_Paris [3] exemple de la Place T/10 : http://www.openstreetmap.org/way/10657703 À propos, que faire d'un tel objet : http://www.openstreetmap.org/way/157775359 (à part une relation multipolygone avec le rond intérne en inner). Si on veut être rigoureux, il devrait couvrir toute la zone goudronnée dédiée aux automobiles. Mais où placer la limite avec les autres rues ? Au final, ne vaudrait-il pas mieux le supprimer dans la mesure où l'on ne cartographie pas les surfaces des routes ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] alt_name et associatedStreet
Y a-t-il une position des Français vis-à-vis des associatedStreet ? En tout cas, quel est le modèle que vous utilisez de préférence ? Pour les quelques adresses que j'ai rentrées jusqu'à maintenant, j'ai utilisé addr:street (par simplicité, mais aussi parce que c'est ce que j'avais le plus souvent rencontré). J'ai du mal à faire une idée précise sur l'opportunité ou non d'utiliser le modèle associatedStreet. J'ai glané les idées que c'était un modèle qui évitait les redondances, facilitait les corrections, mais plus délicat à réutiliser, que la maintenance des relations était délicate. Y a-t-il d'autres points qui m'ont échappé ? Zigeuner Le Lundi 19 mai 2014 10h58, Pieren pier...@gmail.com a écrit : 2014-05-19 10:22 GMT+02:00 Christian Quest cqu...@openstreetmap.fr: De toute façon, le plus simple c'est de tester ! Et de toute façon, comme il y a des applications qui ne reconnaissent pas les associatedStreet (et pour longtemps encore, semble-t-il, vu la position des allemands sur cette relation), le minimum est de conserver le tag sur le highway. 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] alt_name et associatedStreet
C'est vrai que ça ne semble pas être des relations très complexes à créer, ni à réparer ! Merci de la réponse très claire Mais bon... au risque de me répéter... remplacer du rouge par du bleu (résoudre les rapprochements qui ne se font pas) est plus utile dans l'immédiat que par du vert (import d'adresses). Le message est bien reçu, j'ai d'ailleurs commencé à la faire là où je pouvais ! Le 21 mai 2014 22:59, Copro Grammes coprogram...@yahoo.fr a écrit : Y a-t-il une position des Français vis-à-vis des associatedStreet ? En tout cas, quel est le modèle que vous utilisez de préférence ? Pour les quelques adresses que j'ai rentrées jusqu'à maintenant, j'ai utilisé addr:street (par simplicité, mais aussi parce que c'est ce que j'avais le plus souvent rencontré). J'ai du mal à faire une idée précise sur l'opportunité ou non d'utiliser le modèle associatedStreet. J'ai glané les idées que c'était un modèle qui évitait les redondances, facilitait les corrections, mais plus délicat à réutiliser, que la maintenance des relations était délicate. Y a-t-il d'autres points qui m'ont échappé ? Zigeuner Le Lundi 19 mai 2014 10h58, Pieren pier...@gmail.com a écrit : 2014-05-19 10:22 GMT+02:00 Christian Quest cqu...@openstreetmap.fr: De toute façon, le plus simple c'est de tester ! Et de toute façon, comme il y a des applications qui ne reconnaissent pas les associatedStreet (et pour longtemps encore, semble-t-il, vu la position des allemands sur cette relation), le minimum est de conserver le tag sur le highway. 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 -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tag lotissement
J'ergoterais avec plaisir sur l'emploi du mot quartier en français, mais ça ne fera pas avancer la question de l'étiquetage sur OSM. Que l'on considère que quartier ne s'emploie que pour des grandes zones aux limites floues, ou qu'il peut s'employer aussi pour des petites zones aux frontières définies, cela ne remet pas en cause qu'il s'agit bien de deux espaces différents. L'emploi de place=neighbourhood sur le wiki est assez large : une aire géographique portant un nom, incluse dans une plus grande zone (place=suburb/village/town/city). Jusqu'ici, je l'ai utilisé surtout pour des grands ensembles, cités, considérant que ces aires ne pouvaient pas être étiquetés place=suburb. J'espère que ce n'est pas un emploi erroné de l'étiquette. Donc à mon sens, les lotissements rentrent parfaitement dans le cadre de palce=neighbourhood. Mais tu as raison, pourquoi ne pas utiliser une étiquette plus précise, avec le terme exact de place=subdivision ? Le terme de ressortir voulait seulement évoquer le fait que l'emploi de place=subdivision pour les lotissements n'était pas très répandu jusqu'à aujourd'hui (c'est un euphémisme). Par ailleurs, je me dis que quitte à raffiner la description des petites aires urbaines, on pourrait aussi raffiner le place=village : il me semble y avoir plus de différences entre un petit bourg de 150 âmes et une (sous-)préfecture de 8000 habitants, qu'entre un lotissement et un autre voisinage. Mais, comme les résidences, c'est un autre sujet ! Cordialement, Zigeuner___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tag lotissement
Dans cette situation, j'aurais utilisé place=neighbourhood. Personne ne l'a cité dans la discussion : ai-je mal compris le sens de cette étiquette ? Cordialement, Zigeuner Le Dimanche 4 mai 2014 16h12, Vincent de Château-Thierry v...@laposte.net a écrit : Bonjour, Le 04/05/2014 15:49, Francis Ganteaume a écrit : Sachant que une résidence couvre un nombre d'habitations supérieur à un lotissement, comment est ce qu'on l’intègre? de la même façon que le lotissement? Il serait souhaitable que la notion de résidence ne soit pas résumée à un landuse nommé. Landuse=residential est pour moi très générique et s'applique à l'échelle d'une agglomération. Une résidence, par comparaison, est d'une superficie réduite, souvent inscrite dans quelques pâtés de maisons / immeubles, avec éventuellement une notion de copropriété, des voies de desserte, une enceinte matérialisée, des espaces verts. Si landuse=residential est utilisé, comme beaucoup le suggèrent déjà pour les lotissements, il faudrait a minima le spécialiser par un second tag, pourquoi pas un residential=* (je n'ai pas idée de la valeur, à trouver). Une raison supplémentaire de sortir cette notion du simple landuse=residential est qu'elle a potentiellement une utilisation pour l'adressage, comme le rappelle cette page : http://www.laposte.fr/Entreprise/Outils-Indispensables/Outils/Testez-vos-adresses où la notion de résidence est présente en toutes lettres. 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] Tag lotissement
Cependant pour revenir à l'idée de lotissement, en regardant les pages anglaise et française de place=neighbourhood [1], je ne fais pas le lien avec le lotissement. Pourtant sur la page neihbourhood du wiki [1], il est indiqué que les housing subdivisions sont des cas particuliers de neighbourhoods, à étiqueter place=neighbourhood. Et comme tu le cites, wikipedia traduit housing subdivision par lotissement (ce qui correspond également à la définition donnée dans le wiki). Donc le lien me semble au contraire évident, les lotissements étant un cas particulier de place=neighbourhood. Quant à place=subdivision, la même page du wiki indique qu'il n'a quasiment été utilisé que par une personne aux Philippines (et aujourd'hui il n'y en a plus que 622 occurences, encore moins qu'en 2011). Je ne vois donc pas pourquoi ressortir cette étiquette. La traduction française parle de quartier, et pour moi c'est bien distinct Pour moi, les lotissements ne sont qu'un cas particulier de quartier. L'article quartier de wikipedia [2] semble d'ailleurs bien correspondre à un lotissement : physionomie propre, bâti particulier, etc. Cordialement, Zigeuner [1] http://wiki.openstreetmap.org/wiki/Neighbourhood [2] http://fr.wikipedia.org/wiki/Quartier_%28ville%29 La traduction française parle de quartier, et pour moi c'est bien distinct. En regardant comment on est arrivé à instaurer ce tag, je vois qu'on parle de place=subdivision, et là ça me semble bien coller à la notion de lotissement. Il y a une passerelle directe entre : http://en.wikipedia.org/wiki/Subdivision_(land) et http://fr.wikipedia.org/wiki/Lotissement notamment. Dans ce contexte je n'aurais pas d'états d'âme à utiliser un tracé surfacique avec place=subdivision voire name=* dans le cas d'un lotissement. Et vu que le sujet des résidences n'a jamais inspiré grand monde ici, je proposerais volontiers qu'on utilise le même tag pour les résidences, faute de mieux. Quitte à préciser avec un subdivision:FR=residence. Je trouve ça en tout cas bien plus pertinent que le squat de landuse=residential : on aurait un tag différent pour décrire une notion différente. vincent [1] : http://wiki.openstreetmap.org/wiki/Tag:place%3Dneighbourhood ___ 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] Relations cassées par un groupe de modification : que faire ?
Merci pour ces échanges de pratiques. Encore une question : si une vaste relation issue de Corine Land Cover est ainsi entièrement remplacée par plusieurs polygones (dûment sourcés et renseignés), y a-t-il un inconvénient à ce que les balises CLC:code/id/year et source=Union européenne - SOeS, CORINE Land Cover disparaissent avec elle ? Zigeuner Le Samedi 22 mars 2014 18h07, Brice MALLET brice...@free.fr a écrit : Bonjour, ...http://osm.org/go/eruLaoPIl-- Où la présence d'un chemin, d'une route ou d'un cours d'eau interrompt la surface. Pour ma part, j'ai choisi ce type de traitement pour les landuse sur ma commune en délimitant les surfaces le long des routes mais pas pour les routes en cul de sac, chemins ou petit cours d'eau. Cela m'a semblé un bon rapport entre détails / facilité de maintenance. http://tile.openstreetmap.fr/?zoom=18⪫=47.11887lon=-1.8394layers=B000FF Le 21/03/14 10:34, david.croc...@online.fr a écrit : Bonjour - Mail original - De: Copro Grammes coprogram...@yahoo.fr À propos de la taille de ces multipolygones landuse=meadow : je préfère également limiter leur taille, mais ai-je raison de trouver inutile de les remplacer par une mutltitude des chemins fermés délimitant chaque pré ? C'est ce qu'a fait le même utilisateur, par exemple : http://www.openstreetmap.org/way/263474495 (je passe sur les autres problèmes : superposition des landuses, barrier=hedge s'appliquant à toute la surface, recouvrement de la surface de la rivière). - Mail original - C'est ce que je faisait au départ : http://osm.org/go/ersjiibXg- La fin de la nature du terrain était lié à la présence d'une haie ou d'une clôture. mais j'ai constaté par la suite que cela devenait compliqué pour l'édition la superposition des chemins C'est pour cela que maintenant je travaille autrement http://osm.org/go/eruLaoPIl-- Où la présence d'un chemin, d'une route ou d'un cours d'eau interrompt la surface. Sauf qu'a des endroits http://osm.org/go/eruL~Jk2_ j'ai un peu abusé quand même Cordialement ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Relations cassées par un groupe de modification : que faire ?
Merci de ta réponse. Effectivement, j'ai testé une annulation, on obtient 6 conflits, que je ne préfère pas essayer de résoudre dans JOSM, de crainte de faire pire qu'avant... Je corrigerai à la main les multipolygones. À propos de la taille de ces multipolygones landuse=meadow : je préfère également limiter leur taille, mais ai-je raison de trouver inutile de les remplacer par une mutltitude des chemins fermés délimitant chaque pré ? C'est ce qu'a fait le même utilisateur, par exemple : http://www.openstreetmap.org/way/263474495 (je passe sur les autres problèmes : superposition des landuses, barrier=hedge s'appliquant à toute la surface, recouvrement de la surface de la rivière). Il me semble préférable de conserver uniquement des chemins (ouverts) barrier=hedge au niveau des haies, et un multipolygone landuse=meadow sur une plus vaste surface, non ? Zigeuner Le Jeudi 20 mars 2014 10h25, Pieren pier...@gmail.com a écrit : 2014-03-19 22:36 GMT+01:00 Copro Grammes coprogram...@yahoo.fr: Dans cette situation, que vaut-il mieux faire ? Annuler le groupe de modifications, ou tout corriger à la main ? Et s'il vaut mieux annuler, puis-je m'en charger, ou est-il préférable de laisser un utilisateur plus expérimenté le faire ? En regardant le profile du contributeur, on voit qu'il est peu actif sur le projet (104 edits) et ne fait plus rien depuis 22 jours. Le changeset dont on parle date lui de 2 mois. Il est probable que cette personne ne réagisse pas à ton message, soit parce que le projet ne l'intéresse plus, soit parce que cela dépasse ses compétences actuelles. Dans ce cas, j'essaierais d'aller au plus simple et d'annuler le changeset avec JOSM. Mais comme il est déjà assez vieux, il est possible que cela ne fonctionne pas (si des éléments ont encore été modifiés depuis). Si c'est le cas, il faudra alors corriger à la main les multipolygons et peut-être en profiter pour limiter leur taille (en les divisant là où c'est possible, le long d'une route importante, une rivière, un canal ou une voie de chemin de fer par exemple). 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
[OSM-talk-fr] Relations cassées par un groupe de modification : que faire ?
Bonsoir, Le groupe de modifications http://www.openstreetmap.org/changeset/19950859#map=12/46.4511/4.2716 a conduit à casser de nombreuses relations : * http://www.openstreetmap.org/relation/281439 * http://www.openstreetmap.org/relation/530 * http://www.openstreetmap.org/relation/529 * http://www.openstreetmap.org/relation/2624659 Il semble que, pour une forêt, l'utilisateur Azerty6 a voulu remplacer par un chemin fermé la relation multipolygone 281439, sans prendre garde qu'il cassait d'autres relations. Je lui ai envoyé un message, sans réponse. Dans cette situation, que vaut-il mieux faire ? Annuler le groupe de modifications, ou tout corriger à la main ? Et s'il vaut mieux annuler, puis-je m'en charger, ou est-il préférable de laisser un utilisateur plus expérimenté le faire ? Zigeuner___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[Talk-transit] Close stations having the same name
Hi, Close to a main railway station, there are often other stations (underground, bus, tram, etc.) which have the same name (e.g. Somewhere Station). I wonder what is the best value for the key 'name' of these stations? There are examples where the transport type is added in the name: e.g. Gare de Lyon (métro 14) in Paris [1], or Hauptbahnhof (U-Bahn) in Frankfurt [2]. Don't you think it is better to tag all these stations with their real name (Somewhere Station)? It isn't ambiguous since other tags than name allow to distinguish these stations [3]. And it gives to users/applications the real name, not a name for renderer. Cheers, Zigeuner [1] http://www.openstreetmap.org/export#map=18/48.84385/2.37467 [2] http://www.openstreetmap.org/export#map=18/50.10769/8.66386 [3] E.g. Gare de l'Est railway and underground stations can be distinguish by some renderers even though they are both tagged railway=station and name=Gare de l'Est: http://tile.openstreetmap.fr/?zoom=16lat=48.87451lon=2.359layers=B000FF ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Tagging of railway station
Thank you for your answers. I was also inclined to add railway=station tag to a node rather than to an area. But some French mappers advocate for the 'area' solution, contrary to the former version of the wiki, and I've begun to hesitate between both the approaches. So I was hoping this debate could be settled, but currently this is clearly not the case... Doesn't this matter interest anybody else ? Or doesn't anybody else have an opinion about this question ? This problem is not know (see place=*). We even already have an solution: role label. The role label could be interesting, but how can we use it ? Did you mean we could create a label relation [1] ? Or did you mean we should add a node with the role label to the stop_area relation which would be tagged railway=station (but the stop_area could also contain a bus station, a subway station, etc.) ? For new created objects I only use the new scheme but I do not delete the older tags if already tagged but only add the new ones. So I think it means you add the public_transport=station tag to the same node/area which was already tagged railway=station (as Roland did), doesn'it ? Cheers, Zigeuner [1] http://wiki.openstreetmap.org/wiki/Relations/Proposed/Label___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [OSM-talk-fr] Création d'un projet réseau ferré
J'ai posé sur talk-transit les problèmes de la position de railway=station, et de l'usage de public_transport=station [1]. J'espère que cela permettra de dégager un consensus sur ces points. Concernant la fusion des stations de métro/RER : Il me paraît plus judicieux de laisser les stations de métro séparées des stations de RER, car elles ont chacune des balises spécifiques. En revanche, Christian avait précisé précédemment qu'une station de métro desservie par plusieurs lignes n'était représentée que par un point car tout est souterrain et difficile à positionner. Par simplification on n'a mis qu'un noeud railway=station commun pour avoir la notion de correspondances. La seule exception présentée comme acceptable était la Gare de Lyon, à cause de l'éloignement des deux stations. Il paraît donc cohérent de regrouper sous un seul nœud les nœuds Concorde et ceux Bastille (pour cette dernière, en conservant le nœud au niveau de la gare aérienne). Mais la question posée dernièrement n'était pas de savoir si on regroupait les différentes stations, mais de savoir si on ajoutait au nom les mentions (RER), (métro), etc. Zigeuner PS Je crois vraiment que le schéma public_transport a été pensé comme doublonnant les balises classiques, et pas comme une alternative. Pour les platforms, c'est explicitement dit dans le wiki [2], et pratiqué sur plus de 100 000 highway=bus_stop qui sont balisés public_transport=platform. Et Roland Olbricht, dans sa réponse sur talk-transit, le voit comme ça lui aussi. Quant à l'allusion à la télépathie, c'était pour signifier que dans les discussions sur la position de railway=station, trois voix avaient défendu un nœud, trois autres une surface. Je ne voyais donc pas en quoi c'était un drôle de choix que celui de placer la Gare du Nord sur un nœud. À moins d'avoir lu dans mes pensées que je risquais de changer d'avis... [1] http://www.mail-archive.com/talk-transit@openstreetmap.org/msg01604.html [2] http://wiki.openstreetmap.org/wiki/Tag:highway%3Dbus_stop#Bus_stop Le Vendredi 6 décembre 2013 20h10, Christian Quest cqu...@openstreetmap.fr a écrit : Le 5 décembre 2013 22:50, Copro Grammes coprogram...@yahoo.fr a écrit : Effectivement, l'essentiel de ces discussions n'est pas restreint au cadre franco-français, et doit avoir lieu sur la liste dédiée. Je vais essayer de m'y atteler. Quelques remarques tout de même : Concernant public_transport=station : N'ajoutons pas de la confusion là où il n'y en avait pas encore : actuellement, le schéma public_transport est clairement et largement présenté comme un ensemble tags qui peuvent venir en complément des tags classiques [1], et donc généralement en doublon pour les platforms et les stations. Ca coince un peu là... soit on considère que public_transport est un complément et dans ce cas aucun tag ne devrait être un doublon de ceux pré-existant, soit on doublonne (et c'est le bazar constaté). Son usage n'est nulle part restreint aux cas où les tags classiques seraient insuffisants. On peut – avec force arguments rationnels – relancer le débat ; proposer que les tags public_transports soient limités à pallier d'éventuelles insuffisances des tags classiques ; les supprimer de toutes les stations / bus_stations /bus_stops / platforms /... où ils font doublon. Mais ce n'était pas l'objet du débat. Il s'agissait de savoir si (lorsque l'on utilisait le schéma public_transport tel qu'il est présenté aujourd'hui) on définissait un seul public_transport=station sur l'ensemble du pôle de transport, ou un pour chaque élément (gare ferroviaire, gare routière, etc.). La seconde solution a été préconisée dans les discussions. Je l'ai mise en œuvre sur la Gare du Nord. Point. Encore une fois, je me contrefous de ce schéma, je ne cherche aucunement à le promouvoir. Chacun de nous peut décider de ne l'utiliser que dans certains cas particuliers, puisqu'il n'est (encore heureux !) pas obligatoire. Mais, pour ceux qui inévitablement voudront utiliser plus largement ce schéma, autant présenter sur un exemple comment l'utiliser au mieux. Nœud ou surface pour railway=station ? Noeud pour une gare simple, polygone si nécessaire pour les gares complexes. On ne devrait pas imposer l'un plus que l'autre mais s'adapter à chaque cas. Christian m'a permis de passer outre à mes réticences envers les approximations de tracé, je déplacerai donc les tags sur une surface autour de la gare. C'est que j'aurai tendance à faire sur la Gare du Nord, ailleurs faut voir ;) Mais je m'interroge sur les dons de télépathie de Christian... Le débat n'avait pas permis de dégager un consensus clair pour l'une ou l'autre des solutions. J'en déduis que Christian a réussi à lire dans mes pensées que je commençai à me laisser convaincre par la solution « surface », privilégiant la rigueur cartographique plutôt que l'intérêt supposé des utilisateurs. Pas compris. Zigeuner
Re: [OSM-talk-fr] Création d'un projet réseau ferré
Effectivement, l'essentiel de ces discussions n'est pas restreint au cadre franco-français, et doit avoir lieu sur la liste dédiée. Je vais essayer de m'y atteler. Quelques remarques tout de même : Concernant public_transport=station : N'ajoutons pas de la confusion là où il n'y en avait pas encore : actuellement, le schéma public_transport est clairement et largement présenté comme un ensemble tags qui peuvent venir en complément des tags classiques [1], et donc généralement en doublon pour les platforms et les stations. Son usage n'est nulle part restreint aux cas où les tags classiques seraient insuffisants. On peut – avec force arguments rationnels – relancer le débat ; proposer que les tags public_transports soient limités à pallier d'éventuelles insuffisances des tags classiques ; les supprimer de toutes les stations / bus_stations /bus_stops / platforms /... où ils font doublon. Mais ce n'était pas l'objet du débat. Il s'agissait de savoir si (lorsque l'on utilisait le schéma public_transport tel qu'il est présenté aujourd'hui) on définissait un seul public_transport=station sur l'ensemble du pôle de transport, ou un pour chaque élément (gare ferroviaire, gare routière, etc.). La seconde solution a été préconisée dans les discussions. Je l'ai mise en œuvre sur la Gare du Nord. Point. Encore une fois, je me contrefous de ce schéma, je ne cherche aucunement à le promouvoir. Chacun de nous peut décider de ne l'utiliser que dans certains cas particuliers, puisqu'il n'est (encore heureux !) pas obligatoire. Mais, pour ceux qui inévitablement voudront utiliser plus largement ce schéma, autant présenter sur un exemple comment l'utiliser au mieux. Concernant les mentions (métro) (RER) (gare routière) rajoutées au nom « Gare du Nord »: Même si c'est moi qui les ai rajoutées, je ne les apprécie pas plus que Christian ! Mais j'avais posé la question de l'opportunité de ce changement, sans obtenir de réponse. Alors j'ai suivi l'exemple de la Gare de Lyon (qu'on avait évoqué, sans soulever ce point : j'en ai conclu bien hâtivement que c'était un exemple à suivre). Donc, on enlève toutes ces mentions superfétatoires aussi bien sur les stations « Gare du Nord » que sur les stations « Gare de Lyon » ? ↑ là il y a une question ; j'attendrai sagement les réponses avant toute modification Nœud ou surface pour railway=station ? Christian m'a permis de passer outre à mes réticences envers les approximations de tracé, je déplacerai donc les tags sur une surface autour de la gare. Mais je m'interroge sur les dons de télépathie de Christian... Le débat n'avait pas permis de dégager un consensus clair pour l'une ou l'autre des solutions. J'en déduis que Christian a réussi à lire dans mes pensées que je commençai à me laisser convaincre par la solution « surface », privilégiant la rigueur cartographique plutôt que l'intérêt supposé des utilisateurs. Zigeuner [1] notamment dans le lien envoyé par Christian ( http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Compatibility_with_well_known_tags ) : The proposed tags can and do coexist with the well known tags. The usage of the new tags is recommended but not mandatory. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Création d'un projet réseau ferré
De par mon expérience récente, ce qui est en effet le plus déroutant pour le béotien, c'est la disparité de l'utilisation de ces différents schémas. Pour le contributeur lambda+ (qui est prêt à faire l'effort de bien déchiffrer la doc), voir que pas une gare n'est balisée de la même manière laisse perplexe. Ce qui m'a surtout manqué (et me manque toujours), ce sont quelques exemples de référence. Plutôt que de se torturer les méninges sur Une station peut faire partie de plusieurs stop_area, mais aussi une stop_area peut contenir plusieurs stations, des exemples concrets seraient plus clairs ! Puisque la Gare du Nord (de Paris) est citée sur le wiki (page railway=station), on pourrait essayer de la clarifier pour qu'elle puisse servir d'exemple, non ? Elle a l'avantage de présenter un panel intéressant de situations, sans présenter trop d'originalités. Dans ce but, je viens de commencer quelques ajouts, issus des discussions précédentes. J'espère vraiment ne pas avoir engendré de perturbations, comme l'utilisateur qui avait modifié le métro parisien. - j'ai ajouté public_transport=station sur chacune des railway=station / amenity=bus_station de la relation (gare ferroviaire, gare RER, station de métro, gare routière, Magenta RER) - j'y ai rajouté train=yes / bus= yes. Le wiki ne l'évoque pas pour les stations, mais j'ai pensé que ça ne pouvait pas nuire de préciser (cf. réflexion précédente de Pieren) - j'ai précisé les noms de trois stations : Gare du Nord (gare routière), Gare du Nord (RER), Gare du Nord (métro). Je l'avais proposé suite à la remarque de verdy_p, sans que cela suscite de réponse. J'ai déplacé l'appellation Gare du Nord dans short_name - pour la gare ferroviaire, railway=station était situé sur une relation ne regroupant que les bâtiments. J'ai sincèrementvoulu le déplacer sur un polygone englobant toute la gare. Mais comme la partie est de la gare est couverte, j'aurais été contraint de tracer les limites approximativement. Je me suis donc rabattu sur la solution 'nœud central'... Je me sens peu crédible, là :-p Si quelqu'un se sent de tracer la surface, qu'il y aille. Du coup, public_transport=station est sur ce même nœud - remarque : pour la station de métro, j'ai en fait laissé public_transport=stop_position au lieu de station, car toutes les stations de la ligne sont balisées comme ça. OK, je me rends compte à l'instant que c'est le même problème pour les gares de RER : le nœud est aussi bien station, que stop, que platform. J'étais en mode railway=station = public_transport=station J'espère que ces modifications conviennent, et qu'on pourra passer à la question suivante : on laisse les quais désunis, ou on montre que deux quais forment une seule entité ? Zigeuner ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Création d'un projet réseau ferré
En fait, pour la gare du Nord, il n'y a pas trois nœuds, mais deux : - celui des lignes de banlieue est en fait la gare RER souterraine. Peut-être serait-il judicieux de la renommer name=Gare du Nord (RER) et official_name=Gare du Nord (à vérifier par ailleurs), à l'instar de ce qui est fait Gare de Lyon ? À ce moment-là, il faudrait également renommer le nœud correspondant à la station de métro. - celui au centre des plateformes des lignes longue distance, celui pour le point d'entrée du TGV transmanche correspond en fait à une unique balise railway=station apposée sur la relation multipolygone reliant les deux bâtiments de la gare. Si deux nœuds apparaissent, c'est uniquement un défaut du rendu (d'ailleurs un seul nœud apparaît sur le rendu FR) Certes, nous avons été d'accord sur le fait que railway=station ne devait pas être porté par les seuls bâtiments. Mais avant de le corriger, on peut peut-être attendre de voir si un consensus se dégage en faveur du nœud ou de la surface ? Je profite de cet exemple pour poser deux nouvelles questions : - si l'on utilise public_transport=station, on l'utilise sur une surface autour de la gare ferroviaire, et sur une autre surface autour de la gare routière ; ou sur une unique surface englobant toute la Gare du Nord en tant que pôle d'échange multimodal - même chose pour la(les) relation(s) stop_area : une pour le train, une pour le métro, une pour le RER, une pour les bus (rassemblées elles-même dans une relation-mère stop_area : j'ai vu quelques fois cette proposition, mais je ne l'ai pas vu appliquée) ? Ou une seule sur tous les éléments de la Gare du Nord. Je serais plutôt tenté par définir plusieurs relations stop_area pour chaque mode de transport/opérateur (regroupées dans une seul stop_area Gare du Nord), et peut-être une seule surface public_transport=station (vue plutôt comme une sorte de landuse = là il y a un pôle de transports public). Mais là, je n'ai pas d'avis bien tranché (ouf !). Zigeuner___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Usage de landuse=village_green
J'ai cru comprendre sur le wiki que cette balise désignait quelque chose de purement britannique. Or cela fait de nombreuses fois que je la rencontre sur des espaces verts urbains français, que j'ai corrigés en landuse=grass (quand c'était le cas, bien entendu). Mon interprétation est-elle correcte ? Dans ce cas, il faudrait peut-être insister sur le wiki, et corriger JOSM qui traduit village_green par espace vert. Zigeuner ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Usage de landuse=village_green
Merci de ta réponse, que j'ai plagiée sans vergogne pour créer la page francophone village green sur le Wiki [1]. J'espère y avoir été clair (peut-être trop péremptoire ?). Zigeuner [1] http://wiki.openstreetmap.org/wiki/FR:Tag:landuse%3Dvillage_green___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Création d'un projet réseau ferré
public_transport=station = railway=station c'est ce que dit le wiki.Est-ce que c'est vraiment explicitement dit quelque part ? Vu qu'on met le second pour la compatibilité, le premier n'a aucun intérêt (tout le problème de ce schéma). Moi qui suis arrivé après la bataille, j'ai surtout l'impression qu'on reste dans un entre-deux bâtard : il semblerait plus logique de remplacer une fois pour toutes les railway=station par public_transport=station+train=yes ; highway=bus_stop par p_t=platform+bus=yes et ainsi de suite... ou de ne pas introduire du tout le schéma public_transport. (encore une fois, je ne défends pas ce schéma, je trouve juste que la situation actuelle manque de logique) La relation public_transport=stop_area est justement destinée à regrouper les différents modes de transport dans une unique relation (ou alors j'ai rien compris au schéma ce qui n'est pas impossible) Pour le coup, sur les relations stop_area, je ne trouve pas ça la description claire pour un sou... Si ça devient récursif (hiérarchique comme l'envisage le wiki à ma grande surprise), c'est une complication de plus à gérer par les logiciels réutilisateurs et donc une raison de plus pour que ces données (trop complexes) ne soient pas exploitées. En tout cas pour un simple rendu c'est actuellement très difficile à gérer sans écrire un paquet de code rien que pour ça. Entendu !___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Création d'un projet réseau ferré
J'ai synthétisé les discussions précédentes sur la page de discussion du projet [1]. Bien qu'essayant de le faire objectivement, j'ai sans doute plus synthétisé certains arguments que d'autres... :-) Je vous laisse compléter. En espérant que d'autres participeront à la discussion. J'ai légèrement modifié la page Tag:railway=station [2], en rajoutant une petite touche en faveur de la solution polygone. J'en ai profité pour remettre à jour la page francophone [3]. Par ailleurs, j'ai appliqué la solution polygone à la gare de Nancy (j'ai aussi remis les balises addr sur ce polygone, comme elles y étaient auparavant). Zigeuner [1] http://wiki.openstreetmap.org/wiki/Talk:WikiProject_France/R%C3%A9seau_ferr%C3%A9#Tags_public_transport.3Dstation_et_railway.3Dstation [2] http://wiki.openstreetmap.org/wiki/Tag:railway%3Dstation [3] http://wiki.openstreetmap.org/wiki/FR:Tag:railway%3Dstation ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Création d'un projet réseau ferré
Merci Pieren, je ne connaissais pas la liste de diffusion talk-transit. Je n'y ai pas trouvé trace d'une discussion sur la position de railway=station. Mais c'est l'un de ses administrateurs, PeterIto, qui a précisé sur le wiki anglophone (rubrique comment utiliser la balise railway=station http://wiki.openstreetmap.org/wiki/Tag:railway%3Dstation#How_to_map ) : Either: * For simple modeling of simple stations with a single track (or one in each direction) just add a node with railway=stationand name=*at an appropriate point on the railway (tagged railway=rail, railway=subwayetc). * For complex or larger stations it is often best to create a node within the main concourse area and use a public_transport=stop_areato associate this with the rest of the elements of the station. * It is also valid to create an area encompassing the land used for passenger services (including any concourse, platforms and associated tracks) and tag this as a station. Currently two disadvantages with this approach. Firstly, without further refinement the name will be positioned in the centroid for the area which is often within the platform area for a terminus station which is not the place people using the station will find most helpful. Secondly, route relations require to be linked to nodes rather than areas and cannot be used with this approach.Note: This is now done with a node tagged as public_transport=stop_positionand/or railway=stop Ça vaudrait peut-être le coup d'actualiser la version française de la page ? Ce qui pourrait permettre de transférer le débat sur le wiki, comme le suggérait Florian. Finalement, ce sont les deux mêmes solutions qui semblent ressortir : nœud central ou emprise de la gare. On pourrait donc écarter les autres solutions (par exemple à Nancy, c'était le bâtiment qui portait la balise ; quant à la relation stop_area, Christian a raison de préciser qu'elle peut englober d'autres éléments que la gare ferroviaire). Même si la position de ce nœud est bien sûr utilisée par les rendus pour placer symbole et nom, il ne faut pas dériver vers le fameux tagguer pour le rendu. C'est-à-dire qu'il ne faut pas trahir la réalité, ou l'inventer, pour le rendu. Mais on peut quand même avoir des bonnes données et un bon rendu :-) Exactement comme pour les nœuds place= D'ailleurs, mettre la balise railway=station sur un nœud permet d'affiner les données, puisque l'emprise de la gare peut déjà être représentée par public_transport=station. On a deux informations différentes, au lieu d'utiliser deux balises redondantes pour un même objet. Pour le routage, tout dépend du mode de transport et de l'échelle. Un routage routier ne nous fera jamais aller sur ce nœud, mais au parking le plus proche. Un routage piéton devrait nous amener à l'entrée de la gare, puis (rêvons un peu) sur le bon quai devant la bonne voiture ;) Dans les deux cas, la position du nœud n'a pas vraiment été utile. C'est sûr que si on ne cherche pas à aller à la 'gare', mais au 'parking de la gare' ou au 'quai 2', le nœud 'gare' ne sert à rien !... ;-) Mais si on veut aller à la gare ? À Nancy ( http://tile.openstreetmap.fr/?zoom=17lat=48.68907lon=6.17465layers=B000FF ) si on balise le polygone, le lecteur lambda de la carte, ou l'utilisateur d'une solution de routage, v risque de se retrouver sur le pont de l'Avenue Foch, Gros Jean comme devant. Zigeuner Le Jeudi 28 novembre 2013 11h01, Pieren pier...@gmail.com a écrit : 2013/11/28 Christian Quest cqu...@openstreetmap.fr: Je crois que la discussion sur l'utilisation du schéma public_transport pour le train mériterait d'être incluse dans le plus vaste problème de la cartographie des lignes commerciales de train (relations route=train) : il y aurait beaucoup de choses à fixer ; je pense ouvrir une discussion là-dessus un de ces quatre. Surtout, cette thématique va bien au delà de nos frontières. Une telle discussion n'a de sens que si elle se fait au niveau international (il y a une liste de diffusion dédiée aux transports publics: talk-transit@). Ca serait pas idiot, mais vu l'usage non négligeable, un changement va avoir des impacts pour les ré-utilisation difficile à mesure, donc pas d'initiative non concertée (internationalement) là dessus. Tag trop largement utilisé et depuis trop longtemps sans que le changement apporte un réel plus = aucune chance que ça soit accepté. Un changement de tag doit réellement lever une ambiguité (comme le fameux power=station) ou se justifier par la création d'une nouvelle catégorie (comme les barrier=* ou office=*) Donc railway_station sur un polygone englobant la gare me semblerait la meilleure approche et au delà des quais accessibles aux voyageurs, un landuse=railway pour faire la continuité. D'accord avec ça (sauf pour le landuse qui, à mes yeux, est plus qu'optionnel ici). Il ne faut pas oublier qu'OSM a démarrer sans le bâti et donc que de nombreuses gares ont été
Re: [OSM-talk-fr] Création d'un projet réseau ferré
Par lieu d'attente je pense qu'il faut comprendre non pas une salle d'attente, mais le lieu où on doit attendre juste avant de monter dans un transport en commun. D'accord, autant s'en tenir à la définition univoque de public_transport=platform. L'étendre au hall de la gare est une interprétation qui pourrait sans doute apporter de la confusion. Je crois que la discussion sur l'utilisation du schéma public_transport pour le train mériterait d'être incluse dans le plus vaste problème de la cartographie des lignes commerciales de train (relations route=train) : il y aurait beaucoup de choses à fixer ; je pense ouvrir une discussion là-dessus un de ces quatre. Remarque : puisque tu évoquais les stations de métro, représentées par un nœud pour montrer les correspondances : faudrait-il donc corriger la station Gare de Lyon, séparée en deux GdL Métro 1, GdL métro 14. Ça me turlupine depuis longtemps. Et de même regrouper les deux stations du RER ? Pour le logo SNCF sur les haltes, je ne le mettrais pas en noir et blanc. Pour l'utilisateur de la carte, cela enverrait plutôt le message gare fermée au trafic voyageur (d'ailleurs, il pourrait aller sur les gares balisées usage=freight), voire abandonnée. Une différence de police (petite, pas en gras, comme actuellement) indique plus clairement qu'il s'agit d'une halte et pas d'une gare. Éventuellement, le logo SNCF pourrait être un peu plus petit. Tant que j'y suis, ne serait-il pas plus logique de baliser les haltes railway=station en ajoutant station=halt ? Enfin, je reviens sur un point qui ne m'a pas semblé résolu : peut-on élaborer un consensus sur le placement de la balise railway=station (ou halt) ? Plusieurs possibilités rencontrées : - un nœud au point central de la gare (Paris-Est par exemple) Cela me paraît correspondre le mieux à la perception sur le terrain, et à ce qu'attend l'utilisateur. Des chemins peuvent mener jusqu'à ce point pour le routage. C'est là que les plans classiques, les cartes IGN apposent la mention gare. Pour les haltes, le nœud peut être situé du côté de l'accès au quai, comme le propose Benjamin sur la page de discussion de projet Réseau ferré ( http://wiki.openstreetmap.org/wiki/Talk:WikiProject_France/R%C3%A9seau_ferr%C3%A9 ) - un nœud au milieu des voies N'attribue de l'importance qu'au faisceau de voies. Ignore l'aspect multimodal de la gare. Le routage conduit (dans le meilleur des cas) au milieu du souterrain/de la passerelle. - un nœud sur les voies Ce que défend Denis sur la page de discussion du wiki. Si j'ai bien compris, cette méthode n'a d'intérêt que si aucun stop_position n'est défini sur la voie, ni aucune relation entre les éléments de la gare. - sur le bâtiment Problème : des gares sont formées de plusieurs bâtiments. Mettre la balise sur un mutlipolygone regroupant les bâtiments peut être interprété comme si chacun des objets était une station (Paris-Gare du Nord par exemple). Problème inverse : parfois un seul grand bâtiment, de forme biscornue, qui n'est ouvert au public que dans une petite partie pas forcément centrale (ex. Dijon-Ville) - sur une surface tracée autour de l'ensemble de la gare (bâtiments, quais, voies, etc.) En doublon avec public_transport=station. Logique, mais à l'affichage, et au routage, la gare est alors située au centroïde de cette surface, point qui souvent ne correspond à rien de concret. - sur la relation stop_area Logique, mais le même défaut que la solution précédente. Zigeuner___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Création d'un projet réseau ferré
Bonsoir, Je suis l'auteur de la modification de la gare de Nancy, et du laïus qui s'en suivit (désolé, je ne m'étais pas rendu compte que c'était si long !). Contributeur depuis quelques mois, je n'avais pas encore eu l'occasion de participer à cette liste de diffusion. J'en profite pour vous féliciter pour te ce que vous faites et avez fait ! Deux points différents ont été soulevés : sur quel objet place-t-on la balise railway=station ? Comment utilise-t-on le schéma public_transport ? Christian a bien rappelé les fondamentaux (pas d'information changeante, plutôt pas d'info qu'une inexacte). C'est justement pour cela que le plus pertinent me paraît d'indiquer aux voyageurs d'attendre dans le hall de gare : c'est une information sûre et stable. public_transport=platform désigne un lieu où attendent les passagers, ce qui me semble assez cohérent avec un hall de gare (pas comme railway=platform qui désigne exclusivement un quai). Il n'est donc peut-être pas utile de créer une nouvelle balise. Je me suis contenté d'un point pour ce hall devant la difficulté de cartographier précisemment une zone à l'intérieur d'un bâtiment. C'est bien entendu à améliorer, comme le tracé des chemins intra-muros évoqués par Denis. Quant au point que suggérait Francescu, portant le nom de la gare et visé par les systèmes de routage, le point railway=station n'est-il pas adapté ? Effectivement, cela peut poser les mêmes problèmes que les nœuds place=, encore que les cas problématiques me semblent très rares : - Lyon Part-Dieu : c'est un grand espace, on peut mettre le nœud au milieu, ou sur l'ensemble de la zone (comme c'est le cas actuellement) - Paris-Gare de Lyon : j'avais justement déplacé ce nœud sur le Hall1, qui me paraît le cœur de la gare, plutôt qu'au milieu des voies où il était auparavant (pour les cheminements intra-muros, je les ai tracés Gare de l'Est, pour satisfaire Denis). J'espère que l'on arrivera à élaborer un schéma cohérent. Si l'on ne considère que les gares parisiennes, elles présentent toutes des schémas différents aujourd'hui ! Coridalement, Zigeuner Le Lundi 25 novembre 2013 21h10, DH dhel...@free.fr a écrit : Le 25/11/2013 10:43, Romain MEHUT a écrit : Bonjour, Ceci un appel aux contributeurs spécialistes du rail. Un contributeur a modifié le schéma de la gare de Nancy avec l'ajout en particulier du nœud http://www.openstreetmap.org/browse/node/2524858356. Je lui ai fait remarquer qu'il me semble que ce nœud vient en doublon de ce qui existait c'est à dire la relation http://www.openstreetmap.org/browse/relation/2828546 Vos avis sont les bienvenus... Il m'a donné son accord pour publier le sens de sa démarche (attention c'est un peu long): ... Il y a un truc qui me gêne dans cette histoire : le bâtiment de la gare ne fait pas partie de la relation http://www.openstreetmap.org/browse/relation/2828546. C'est vraiment dommage de créer un noeud supplémentaire, fictif alors que sémantiquement, c'est bien le bâtiment (http://www.openstreetmap.org/browse/way/40493423) de la gare qui est, euh comment dire, ben la gare !! Pas bien compris tous les arguments quais, arrêts. Si vraiment son argumentaire est de servir les logiciels de routage, c'est vers l'entrée principale de la gare qu'il faut les diriger (http://www.openstreetmap.org/browse/node/1666956055). Il aura en plus l'info si c'est accessible PMR jusqu'à ce point là. S'il veut vraiment être utile, il reste les cheminements intra-muros à tracer : bandes podotactiles, portes automatiques, etc. Il est vrai que ce schéma public_transport est bien complexe, riche et mériterait une traduction. Je veux bien m'y atteler et faire un premier jet mais pas avant les vacances de Noël. Denis PS : modéliser les circulations sur une gare comme celle de Nancy est hors de portée d'un projet comme OSM (ou de ses avatars) tant qu'on aura pas accès aux données de la Direction des Circulations Ferroviaires (DCF). Ce n'est pas le cas aujourd'hui et ne risque pas d'arriver avant un temps certain. ___ 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] Création d'un projet réseau ferré
Certes, nous pouvons paraître diverger, mais je tiens à préciser que je ne suis partisan d'aucun schéma particulier, ou conception d'OSM. Jusqu'à maintenant, j'ai juste essayé de comprendre au mieux ce qui avait été fait par d'autres, et ce qui est présenté sur le wiki, sans le remettre en cause. Entre autres, j'ai essayé de comprendre et d'appliquer le schéma public_transport, croyant qu'il faisait consensus. Effectivement, tu me fais prendre conscience qu'il ne décrit pas directement le terrain, mais en est une interprétation. On peut d'ailleurs dire la même chose des relations route=bus/train, non ? Je ne tiens pas à défendre l'idée que public_transport=platform désigne le lieu d'attente des voyageurs, je me suis contenté de tirer ça de la description du schéma sur le wiki ( http://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dplatform , http://wiki.openstreetmap.org/wiki/FR:Key:public_transport ), et du fait que des arrêts de bus portent cette balise (sans qu'il n'y ait physiquement de quai !). Maintenant que je pense avoir clairement montré que n'étais pas un partisan du schéma public_transport, que j'avais juste essayé de le comprendre et de l'utiliser, j'apporte quand même un avis personnel : Si l'on considère légitime de définir dans OSM des relations route=bus/train/..., il me paraît intéressant d'ajouter à ces relations des objets avec le rôle platform, plutôt que de se contenter des objets avec le rôle stop. Et je trouvais cohérent de leur ajouter la balise public_transport=platform. Le seul point où je ne t'ai pas compris, c'est quand tu parles de fluctuations ? Quelles sont les différentes interprétations qu'il y aurait ? Cordialement, Zigeuner PS En plus, j'ai oublié operator=SNCF à Nancy ; j'ai vraiment fait n'importe quoi !! PPS J'en profite, même si ce n'est pas le lieu : ce serait possible d'avoir le beau logo SNCF aussi sur les railway=halt ? (laissons pour plus tard le débat sur l'utilisation de halt/station...)___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
