Wow, ça fuse sur la liste, avec ce projet génial de Sylvain ! Comme ils disent : "On n'a peut-être pas de pétrole, mais on a des idées" ;-) Du rendu en live, avec cache pondéré, ça devient presque de l'intelligence artificielle...
Toutefois je veux "rebondir" sur les gares, aux questions de Christian, Jonathan et Pieren : Christian, sur la carte s'affichera ce qu'on a mis dans les tags. Ce sont les contenus des tags, qui disent aux moteurs de rendu, quoi et comment afficher sur la carte. On pourrait traduire "tags" par "propriétés de l'objet". Même si les renderers actuels exploitent seulement une partie des tags présents dans un objet, avec le temps, le rendu de la carte deviendra de plus en plus complet. Les renderers à venir se serviront des tags qu'aujourd'hui nous mettons dans les objets de la bdd. D'où l'intérêt qu'on les organise de façon logique, cohérente. Je fais confiance à capacité d'auto-régulation des milliers de participants d'osm qu'ils veillent à la cohérence des tags et de la bdd ;-) Pour les arrêts de train qui ne sont pas de vraies gares et où le train ne s'arrête que sur demande, facultatifs, il existe le tag "railway : halt". http://wiki.openstreetmap.org/index.php/Tag:railway%3Dhalt. Je pense qu'il ne soit pas utile de marquer sur osm les "arrêts inexistants" desquels je parlais, où des automotrices ramassent les cheminots tôt le matin - Même si parfois les particuliers peuvent en profiter ;-) La question de fond est, quel nom donner aux gares ( = "station"). Je comprends bien ton idée, de mettre le mot (Gare) derrière le nom(_de_Lieu) : Sur la bdd des points d'intérêt de mon vieux gps (et son logiciel PC) je suis embêté pour trouver une gare : Les gares de France y sont nommées "gare de xyz", "gare xyz", "xyz gare", ou autre (et met dans la même liste aussi les gares routières...) celles d'Allemagne comme "Bahnhof Xyz, mais certaines comme "Hauptbahnhof Xyz, ou encore "Xyz Hauptbahnhof" ou Xyz Hbf", et ainsi de suite. Bref, on n'y trouve rien :-( S'ils avaient mis le mot "Gare" après le nom, cela aurait facilité la recherche par nom_de_ville. Depuis, ça a avancé, on ne fait quasiment plus de recherches sur seulement un critère. (Quoique la recherche des POI sur mon nouvel IGN Ushuaïa Evadéo Primo Europe ne soit guère plus évoluée, que celle de mon vieux SporTrak, de Mathusalem... :-( ) Maintenant, concrètement pour osm, je ne suis pas convaincu qu'il faille mettre le mot "Gare" après le nom, suis plutôt contraire, car les tags (propriétés) présents dans le node d'une gare déterminent qu'il s'agit d'une gare ferroviaire : le tag "railway : station" le dit déjà. D'accord, pour permettre un bon ciblage pour des requêtes sur la bdd, il faudrait systématiquement ajouter le tag "is in (nom_de_la_ville)", sinon une recherche comme 'gare de lyon' pourrait confondre Paris Gare de Lyon avec Lyon Perrache, Part-Dieu, ou St-Ex TGV. Tous moteurs de rendu, du fait du tag "railway : station", devraient afficher un tel node par un logo correspondant. Les "tags" ou "attributs de propriété" justement sont là, pour cela. Ça viendra, un jour... Sur osm c'est la propriété "railway : station" qui informe toute la planète que c'est une gare peu importe la langue/écriture locale. Rassurez-vous, c'est de l'anglophone européen, pas américanophone : L'origine d'osm vient de GB ;-) -- Le principe des "propriétés" ou "tags" sur osm me semble être, que chaque tag ait sa fonction bien distincte, à son nievau hiérarchique : Le tag principal du way dit, de quel réseau il s'agit (highway, railway, bus, bicycle...), l'attribut désigne les particularités (station, halt, parking...), et le "name", bhen, c'est purement le nom propre - sans la fonction (amha, on devrait spécifier la fonction du lieu, dans le nom, uniquement dans le cas où n'existe pas de tag pour telle ou telle propriété spécifique comme pour une piste de ski d'été, un acrobranches, une station-service avec huile de colza ou huile de frites pour diesel...). -- Je comprends que dans certains cas, écrire '(Gare de)' pourrait être utile, mais je crains que cela crée des confusions par la suite. Dans des grandes villes la question pourrait se poser, car les noms propres peuvent comprendre les mots 'Gare de...' selon le quartier où elle se trouve, ou selon la destination qu'elle sert, ou d'après la société qui exploite la ligne, ou d'après l'architecte ou le politicien qui l'a fait construire. là où ailleurs on appelle une gare d'après le nom de la ville où elle se trouve. Y a comme une sorte de confusion sémantique... Je pense que la Sencefe nomme les gares d'abord par le nom de ville, et si la gare a vraiment un nom propre, l'ajoute à la suite, comme Paris Montparnasse, Montpellier Saint-Roch, Lyon TGV St-Exupéry, mais aussi Paris Gare du Nord (ou le mot "gare" fait partie intégrante du nom propre). Et, par fonction, ces serait plutôt une "ref :" (!), qu'un "name :" Quid est ? -- Le tag/propriété "railway : station" d'abord est une propriété fonctionnelle qui intéresse le réseau de voies ferrées, donc pour rester cohérent en soi ça s'applique sur un node faisant partie de la voie ferrée elle-même. Aussi, pour rester cohérent (dans le sens du mot) ce node devrait être relié au réseau routier devant, et aux parkings, par des voies piétonnes (et quand ils s'agit d'embarquement de véhicules sur des trains, comme on en a dans les Alpes, par des "highway :" carrossables. On a déjà parlés de ces interconnexions pour les métros, ways nécessaires aux logiciels futurs pour qu'ils puissent proposer des parcours mixtes). Aussi est-il nécessaire, de lier les areas de la gare à ce node du railway, d'une façon logique et exploitable pour les logiciels : bâtiments transport public d'abord, et leurs accès, puis transport des marchandises et leurs bâtiments, puis la surface ferroviaire d'une gare en entier (ça peut faire quelques kilomètres carrés). mais de quelle façon le faire, au mieux, de façon sytémique ? Peut-être que les "relations" pourraient être une réponse, mais pour ma chtite cervelle de bâtisseur constructif, la démarche booléenne de ces "relations", qui se veut partir d'un fonctionnement finalisé quand la plupart des données nécessaires n'est pas encore acquise..., est un peu trop hard à piger, trop loin de la démarche de base (française ?) qui voudrait de d'abord acquérir les infos et données, puis monter thèse, antithèses, puis synthèse... Ça me rappelle les années 1990, 2000, ou les chercheurs scientifiques tentaient à imposer à tout prix (sur le dos du contribuable) que leur théorie était la seule valable, et qu'ils ignoraient tant d'autres pistes lesquelles ces essais coûteux avaient mis au jour, pistes qu'ils ignoraient, car moins rémunératoires... Hélas cela continue et persiste. Pourtant, ni scientifique, ni administrateur, ni nous sur osm ne compresserons la réalité dans une concept lequel nous nous faisons d'elle - peu importe l'effort et l'agent qu'on puisse y investir. (Wow, philosophie ! ;-) Dixit Gerhard aka trop long Ce n'est *pas* un jeu vidéo. Malgré toutes précautions, il n'y a pas de "bouton reset" ni "pause" ni de "vies supplémentaires", comme y aurait dans un jeu vidéo. Ni possibilité de refourguer au fonctionnaire suivant. --- Pas trop confusionner signification et taches de géographe, cartographe, topographe, géomètre, arpenteur, dessinateur, graveur, et imprimeur... Ok, aujourd'hui on est tous un peu interdisciplinaires, informatique oblige, mais n'empêche que pour faire du boulot cohérent, aucun n'est cap', de connaître toutes les facettes de chacun de ces métiers. C'est une collaboration entre personnes de capacités complémentaires, du "montage multimédia" avant l'ère, avec en sus le souci de l'exactitude, et la responsabilité pour de vies humaines. On retrouve un "découpage" semblable des fonctions dans la création des jeux et dans la création cinoche... Avec la différence, que la responsabilité pour les vies humaines soit escamotée par l'objectif de produire de la quantité, et/ou de la flouze. Les cartographes aussi sont soumis à la pression de fournir, pour des raisons commerciales, économiques et/ou militaires, mais pour la plupart ils sont conscients, que leur travail comporte une responsabilité pour des vies, pas seulement commerciale. D'acc, c'est philo-déonto, je jette l'éponge. --- Une inconséquence structurelle qui à mon avis pèse encore sur osm, serait la question, quoi est prioritaire dans la structuration des tags. Pour l'instant, plusieurs principes s'y mélangent de façon peu ordonnée ; L'objet (fonction, ref, name) qui se trouve à un endroit ("node"), le type de réseau duquel il fait partie (voirie véhicules, vélo, train, tram, touristique, religieux, naturel...) ou encore les ways (tracés) qui forment les réseaux et les zones eux- mêmes. La structure des tags n'est pas encore au point de façon conséquente : Une fois c'est le réseau qu'est en haut de l'hiérarchie des tags, une autre fois c'est la fonction, une autre fois c'est son type gis. Les niveaux d'arborescence ne sont pas encore homogènes. Le fait que pour le contributeur, osm ait "un peu" changé de logique, y est pour quelque chose (Souvenez-vous : Avant, on plaçait d'abord les nodes, pour ensuite les relier en des ways : c'était plus clair, mais ça surchargeait la bdd). Tout cela trouvera solution, avec le temps, à force qu'on en parle... j'en suis convaincu :-) --- Merci d'éclairer ma lanterne, si je fais erreur. Décidément trop long, j'espère que mes pensées puissent aider à ceux qui les lisent, de résoudre les questions afin qu'on garde la bougie droite. :-) ------ Le 9 nov. 08 à 17:49, Christian Rogel a écrit : .../... > il vaudrait peut-être mieux écrire Saint-Etienne-Châteaucreux > (gare) que de > s'embarasser avec "de" ou "du". Avantage : Ermont-Halte serait allégé. > > > Christian > > g.d a écrit : >> Si, >> _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
