Re: [OSM-talk-fr] Sur quel objet mettre les tags des passages piétons ?

2023-05-04 Par sujet Bernard Lefrançois via Talk-fr 

Bonjour,

Une solution, lorsque les attributs sont placés sur le chemin 
highway=footway, serait d'utiliser xxx:separate sur le nœud 
highway=crossing (crossing:markings=separate par exemple).

Ça permettrait:
1- D'éviter les doublons
2- D'indiquer, à qui veut bien chercher, que l'info existe à proximité.


Le 25/04/2023 à 16:36, Noémie Lehuby via Talk-fr a écrit :

Bonjour,

Dites, quand vous cartographiez un passage piéton en chemin (way), les 
attributs du passage piéton (zébra, ilôt de refuge, feux sonores, 
bande podotactile, etc), vous les mettez plutôt :

1) sur le noeud higwhay=crossing
2) sur le chemin highway=footway + footway=crossing
3) sur les deux
?

Exemple illustré pour que ça soit plus clair : 
https://i.imgur.com/4IsT37m.png


J'ai tendance à faire plutôt le deuxième.
En effet, ça me semble plus cohérent (après tout, c'est utile pour les 
piétons, pas pour les voitures) et plus précis.


Mais l'inconvénient est que la donnée n'est pas uniforme, il faut 
parfois chercher l'info sur un noeud, parfois sur un chemin, et tous 
les éditeurs / réutilisateurs ne feront pas cet effort.
StreetComplete par exemple n'est pas de cet avis : les quêtes semblent 
porter toujours sur le noeud, et même lorsque les infos sont déjà 
renseignées sur le chemin, on a une quête qui re-pose la question sur 
le noeud.


Qu'en pensez-vous ?


___
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] Sur quel objet mettre les tags des passages piétons ?

2023-05-04 Par sujet Bernard Lefrançois via Talk-fr 



je signale juste que crossing_ref=zebra n'est pas égal à 
crossing:markins=zebra

parce que cette dernière valeur ne représente qu'un des cas
possible de marquage zebré (cfr les autres cas dans taginfo fr)


Bonjour,

Je ne comprends pas ta logique.

Il me semble que crossing_ref, du point de vue du marquage, globalise 
toutes les formes possibles du zébré: on sait que c'est zébré, c'est tout.
Au contraire, crossing:markings peut indiquer tous les cas possibles de 
marquage zébré: simple (valeur par défaut de zebra), double, pairé, 
bicolore etc.
Et pour ceux qui ne sont pas (encore) listé sur le wiki, comme je l'ai 
cité précédemment: "More values may be documented as they are discovered".
J'avais d'ailleurs soulevé la question sur le forum 
 
pour un marquage en damier (je ne suis pas encore allé au bout de la 
démarche en modifiant la traversée concernée, oubli, flemme?).


Pour ajouter au dossier cogitations, voir aussi notre discussion sur un 
de mes changesets 


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

Re: [OSM-talk-fr] Sur quel objet mettre les tags des passages piétons ?

2023-05-03 Par sujet Bernard Lefrançois via Talk-fr 
A l'origine crossing_ref 
 avec toutes ses 
valeurs zebra, toucan, tiger, puffin etc. décrit un système de 
références en vigueur au Royaume-Uni ou chaque "ref" définit bien plus 
que le simple marquage (présence d'un feu, conditions d'accès, priorités 
...).


En France, on s'est approprié ce tag pour indiquer, faute de mieux, 
uniquement le marquage.


Plus récemment, le tag crossing:markings 
 a été 
proposé, voté et approuvé 
 et 
permet de décrire le marquage, et rien d'autre, mais plus finement.
Et comme précisé sur le wiki, la liste des valeurs n'est pas exhaustive 
/"//More values may be documented as they are discovered or invented by 
governments."/


Dans ce cas je ne vois plus l'utilité de conserver ce crossing_ref qui 
ne correspond à aucune "ref" en vigueur chez nous.
Du moins dans mes nouvelles contributions, je ne mentionne plus que le 
crossing:markings.



Le 03/05/2023 à 09:39, Marc_marc a écrit :

Le 03.05.23 à 09:23, Philippe Verdy a écrit :

À ce sujet il semble que "crossing_ref=zebra" (et  plus généralement
"crossing_ref=*" ) soit maintenant déprécié et à remplacer par
"crossing:marking=zebra"


malheureusement ce n'est pas le cas (ni voté ni en pratique)
crossing_ref=zebra dit qu'il y a un zebra, peu importe
la sorte ce qui peux être selon les cas (tous existant
dans osm en France)

crossing:marking=zebra un zebra mono ligne mono couleur,
de loin le plus courant.
il aurait suffit d'inventer crossing:markings=zebra:simple
pour ce cas afin de garder crossing:markings=zebra
comme valeur générique, hélas cela n'a pas été le cas.

crossing:markings=zebra:double un zebra double rangée,
ce qui arrive occcasionalement sur les passages très large

crossing:markings=zebra:bicolour bicouleur (et sa variante
oubliée d'un zebra blanc "enrobé" dans un fond d'un autre couleur
(ce que j'ai vu était sur un revetement peint en rouge),
certainsn semblent utiliser surface;zebra pour cela

du coup les 2 vont coexister pendant longtemps ou
crossing:marking=zebra va perdre le sens voté
pour devenir une valeur générique.

perso je détail de la peinture m'interesse moins
c'est pourquoi je renseigne crossing_ref=zebra
et non crossing:markings=*
mais chacun son envie bien évidement.



___
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] Sur quel objet mettre les tags des passages piétons ?

2023-04-25 Par sujet Bernard Lefrançois via Talk-fr 
A partir du moment où je cartographie la traversée avec highway=footway 
+ footway=crossing, je place les attributs qui concernent ce chemin sur 
celui-ci (proposition 2) et je place les éléments tels que les kerb (1), 
tactile paving (2) sur un nœud à leur place réelle.
Par rapport à ton exemple, je laisse sur le nœud commun highway=crossing 
les attributs:

crossing=uncontroled/traffic_signals (je n'aime pas ce marked!)
crossing_island=yes
crossing_ref éventuellement s'il existe déjà (bien que j'estime, d'après 
la description, que ces zebra, toucan etc. signifient davantage que le 
simple marquage)

Ces attributs sont utiles aussi aux voitures il me semble.

Par contre sur le chemin highway=footway + footway=crossing, je décris 
le marquage avec crossing_markings.


Effectivement, les éditeurs / réutilisateurs ont du mal à traiter ces 
infos, mais ne serait-ce pas à eux de s'adapter.
La difficulté vient peut-être du fait que le wiki ne décrit pas cette 
méthode 2.


(1) A propos de kerb, je m'interroge sur la nécessité du barrier=kerb. 
D'après la page wiki sur kerb, kerb=lowered/flush.. suffit)


(2) tactile_paving sur le nœud highway=crossing est à mon sens ambigu: 
on voit maintenant des passages piétons avec un pavé podotactile 
transversal au bord de la chaussée, mais aussi une bande tactile 
longitudinale qui traverse toute la chaussée au milieu du marquage. La 
méthode 2 permet d'indiquer les deux.



Le 25/04/2023 à 16:36, Noémie Lehuby via Talk-fr a écrit :

Bonjour,

Dites, quand vous cartographiez un passage piéton en chemin (way), les 
attributs du passage piéton (zébra, ilôt de refuge, feux sonores, 
bande podotactile, etc), vous les mettez plutôt :

1) sur le noeud higwhay=crossing
2) sur le chemin highway=footway + footway=crossing
3) sur les deux
?

Exemple illustré pour que ça soit plus clair : 
https://i.imgur.com/4IsT37m.png


J'ai tendance à faire plutôt le deuxième.
En effet, ça me semble plus cohérent (après tout, c'est utile pour les 
piétons, pas pour les voitures) et plus précis.


Mais l'inconvénient est que la donnée n'est pas uniforme, il faut 
parfois chercher l'info sur un noeud, parfois sur un chemin, et tous 
les éditeurs / réutilisateurs ne feront pas cet effort.
StreetComplete par exemple n'est pas de cet avis : les quêtes semblent 
porter toujours sur le noeud, et même lorsque les infos sont déjà 
renseignées sur le chemin, on a une quête qui re-pose la question sur 
le noeud.


Qu'en pensez-vous ?


___
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] présentation

2023-04-25 Par sujet Bernard Lefrançois via Talk-fr 

Le 24/04/2023 à 22:48, Christian Rogel a écrit :
C’est comme qu’on peut voir qu’ « associated_street » ne fait « 
l’unanimité » qu’en France (c’est un gimmick Fr de se précipiter sur 
ce qui semble plus malin). 


L'unanimité, c'est pas un peu vite dit?
Bon, c'était entre guillemet. Ironique?


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

Re: [OSM-talk-fr] Prendre les escaliers à vélo

2020-08-28 Par sujet Bernard Lefrançois 

Un exemple parmi d'autre:
https://www.openstreetmap.org/directions?engine=graphhopper_bicycle=43.09118%2C-0.04734%3B43.09215%2C-0.04781#map=19/43.09186/-0.04693
https://www.openstreetmap.org/directions?engine=fossgis_osrm_bike=43.09118%2C-0.04734%3B43.09215%2C-0.04781#map=19/43.09167/-0.04763

En fait, suivant le cas: autre chemin disponible à côté ou pas, on 
prend, ou pas, l'escalier.


Le 28/08/2020 à 21:40, blef a écrit :


 Message transféré 
Sujet : Re: [MP] Prendre les escaliers à vélo
Date :  Fri, 28 Aug 2020 20:25:53 +0200
De :osm.sanspourr...@spamgourmet.com





Bonjour, MP car je ne suis pas spécialiste du domaine.

Je dirais aussi que c'est une erreur, au moins à fortement pénaliser 
(descendre du vélo, descendre ou pire montre à pied les escalier et 
reprendre le vélo).


Tu peux donner un exemple, chez moi ça semble bon sur OSRM :

https://www.openstreetmap.org/directions?engine=fossgis_osrm_bike=48.38923%2C-4.49998%3B48.38891%2C-4.50025#map=19/48.38933/-4.50088

KO sur GraphHopper :

https://www.openstreetmap.org/directions?engine=graphhopper_bicycle=48.38923%2C-4.49998%3B48.38891%2C-4.50025#map=19/48.38903/-4.49997

(si tu veux, tu peux publier ma réponse sur la liste pour y répondre).

Jean-Yvon



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


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



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

Re: [OSM-talk-fr] parking

2020-03-09 Par sujet Bernard Lefrançois 

Bonjour,
Je partage plutôt la vision de Jean-Yvon.
Sur ta dernière version:
- tu laisses un espace vide qui n'existe pas entre le parking et la route.
- tu crées à un emplacement aléatoire une voie qui n'existe pas non plus.

Lorsque je cartographie un parking, j'applique la règle suivante:
- le parking est séparé réellement de la route (par un fossé, une bande 
d'herbe, un trottoir etc.), je le trace en surfacique avec ses limites 
réelles. Et dans ce cas, il y a forcément une voie pour y accéder et je 
la représente à sa place.
- ou bien:  le parking borde la route sans séparation et dans ce cas une 
partie du polygone représentant le parking est commune avec le linéaire 
de la route. Inutile de rajouter ici une voie d'accès puisque cet accès 
est possible sur toute la longueur.


Le 08/03/2020 à 21:38, Romain MEHUT a écrit :

J'ai proposé une autre version toute simple.
Romain

Le dim. 8 mars 2020 à 11:53, > a écrit :


Oui voir : http://osmose.openstreetmap.fr/en/byuser/ririahp

L'erreur c'est d'avoir fait coller le parking au dessin de la route au
lieu de le faire coller au fil de la route : mélange représentation
filaire/représentation surfacique. J'ai corrigé.

Jean-Yvon

Le 08/03/2020 à 08:36, Arnaud Champollion -
arnaud.champoll...@linux-alpes.org
 a écrit :
> Bonjour,
>
> Question suite aux contributions du groupe OSMDigne réuni hier
> après-midi.
>
> Quand on trace un parking comme surface, faut-il nécessairement
> ajouter une voie de type highway pour le connecter à la route ?
>
> Le cas se trouve ici :
> https://www.openstreetmap.org/#map=19/43.81467/6.24606
>
> Sur la vue aérienne il est visible qu'il n'y a pas réellement de
voies
> pour entrer / sortir, ni de voies de parking, seulement une aire en
> terre battue qui borde la route.
>
> Merci de vos avis,
>
> Bonne journée,
>
> Arnaud
>
>
>
>
> ___
> 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



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

[OSM-talk-fr] Des projets de construction pas sorti de terre !

2019-03-21 Par sujet Bernard Lefrançois 

   n’est ce pas plus sage cartographier ce paquet d’arbre comme un
   landuse ?
   je n’aurais pas rentré le détail de chaque arbre mais si quelqu’un
   le fait, je vois pas le soucis.


Si j'ai émis des doutes, c'est parce que je ne pense pas que c'est dans 
l'esprit du wiki: "Marquage d'un arbre unique, parfois isolé ou 
significatif", mais je reconnais que le mot "parfois" laisse ouverte la 
discussion.


Si on accepte l'utilisation du tag, il n'en reste pas moins que chaque 
natural=tree doit correspondre a un arbre réel, localisé à son 
emplacement réel.


Or, les imageries utilisables (BD Ortho IGN, Bing) ne permettent pas 
d'arriver à ce niveau de précision.
Pire, si on superpose les nœuds en question sur une image Ortho IGN, ça 
saute au yeux, il n'y a aucune relation.


On pourrait envisager que le contributeur a utilisé une base de donnée 
d'un organisme disposant de moyens technologiques avancés (ONF ...).
Mais pas de source citée, pas d'info sur la licence de ces éventuelles 
données.


Quant à l'utilisation d'un landuse, on s'aperçoit que cette zone 
appartient déjà à un landuse=grass.
Ce qui révèle peut-être une lacune d'OSM: comment décrire à la fois le 
couvert et le niveau du sol.


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

[OSM-talk-fr] Des projets de construction pas sorti de terre !

2019-03-21 Par sujet Bernard Lefrançois 

//>/> Le 20.03.19 à 14:58, Vincent Bergeot a écrit : />/>> https://www.openstreetmap.org/user/L3mp1ck4 
/>>//>//>/>> https://www.openstreetmap.org/user/Dupuiche />//>//>/je penche pour une agence 
d'archi, le fait que les 2 se retrouve sur une />/même zone ! /On peut rajouter à la liste:
https://www.openstreetmap.org/user/Y43l//En plus d'introduire des éléments encore à l'état de 
projet, ils ont une tendance à cartographier "pour faire joli"/. /Avec, en 
particulier, un usage abusif du tag natural=tree par exemple comme 
ici://https://www.openstreetmap.org/#map=18/43.73203/7.27437=N//J'ai peine à 
croire que le contributeur a une source fiable pour la position et la hauteur de chaque arbre!
//

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

Re: [OSM-talk-fr] améliorer les panneaux entrée et sortie de ville

2019-03-19 Par sujet Bernard Lefrançois 

Le 18/03/2019 à 23:02, deuzeffe a écrit :

Aucun avis sur la proposition (pas assez aguerrie, je suis).

En revanche, j'abonde avec le fait qu'on ne peut pas mettre 2x2 
panneaux sur le même nœud, et pourtant sur le terrain, de nombreux 
panneaux doubles sont pile face à face sur le bas-côté droit de chaque 
voie. Et comme je ne sais pas faire, je n'y ai pas touché dans ma zone.


Ben, pourquoi pas?

Dans ton cas, je suppose que tu places le nœud sur le highway.

Cas d'un panneau à 2 indications orienté dans un sens, et un autre 
panneau à 2 indications de l'autre côté de la route, orienté dans 
l'autre sens, tagués sur un seul nœud:


traffic_sign:forward=panneau1;panneau2
traffic_sign:backward=panneau3;panneau4


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

Re: [OSM-talk-fr] améliorer les panneaux entrée et sortie de ville

2019-03-19 Par sujet Bernard Lefrançois 



Le 19/03/2019 à 10:02, Jérôme Seigneuret a écrit :
Ou avec Mapillary : 
https://www.mapillary.com/app/?focus=photo=47.79721754166424=-3.4809542=17=RxO4q1ZookumCATmH2Ct3g=0.5334449075931347=0.3798607750491876=3. 

Je suis tombé sur le même cas mais avec sur le même poteau les entrées 
et sortie inverse.
Est-ce que quelqu'un a un avis sur ma proposition d'utiliser le champs 
[value] décrit dans le wiki/Key:traffic_sign
"Where the traffic sign requires a value, you can supply it after the ID 
using brackets |[value]|."


Je me suis posé la question si [value] pouvait être de type "string" 
mais je me dis pourquoi pas?

Dans la sémantique OSM on décrit bien un attribut par key=value
(value n'ayant pas un sens strict de Valeur numérique).

Car, en une seule ligne on dirait tout:

traffic_sign=FR:EB20[Ville1];EB10[Ville2]

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

[OSM-talk-fr] améliorer les panneaux entrée et sortie de ville

2019-03-18 Par sujet Bernard Lefrançois 
N'oubliez pas que même si le panneau de sortie et celui d'entrée de la 
commune suivante sont sur le même support, il s'agit de deux panneaux 
distincts.

Si l'on ajoute des attributs il faut savoir de quel panneau on parle.

Même s'il sont sur le même poteau, je placerais deux nœuds rapprochés avec:

pour la sortie
traffic_sign=city_limit
traffic_sign=FR:EB20

et pour l'entrée
traffic_sign=city_limit
traffic_sign=FR:EB10

Quant au tag name, est-ce vraiment le tag approprié?
Le nom écrit sur la plaque, c'est celui de la commune, pas celui de la 
plaque.


Je verrais plutôt le tag inscription=Nomdeville
le wiki est assez large pour l'utilisation de ce tag /(//text of 
inscriptions on buildings, memorials, advertising signs and other objects)/.


Il y aurait bien aussi le champ [value] à placer après l'ID du panneau, 
ce qui donnerait:

traffic_sign=FR:EB10[Nomdeville]
mais je ne sait pas si ce champ accepte des valeurs alphabétiques.



*direction* c'est en effet la direction du panneau tel que l'on peut
l'observer. Ce détail existe déjà et est renseigné sur pas mal de panneaux
de type trafic_sign. le fait de modéliser les panneaux sur un point hors du
réseau et aussi un autre modèle de saisie (valide) à condition de
renseigner la direction.

Qui plus est le problème reste le même que pour les intersections de
tronçon. sachant que l'on qualifie la vitesse de toute façon en entrée de
ville en sortie de ville on a forcément un découpage au niveau du nœud
entrée sortie. D'où l'exploitation de cette modélisation.

Du côté left and right, c'est en effet des cas qui existe. dans mon mode de
saisie left and right n'a aucun intérêt. Et du coup c'est la même
problématique avec forward-backward.

le panneau peut être placé à gauche ou à droite de la voirie généralement à
droite pour l'entrée. Mais dans certains cas comme toujours en France il y
a des exceptions. Le panneau peut être a l'opposé.

l'objectif de mettre le panneau d'entrée et de sortie et double étant donné
que ça permet aux collectivités de savoir où est-ce qu'il pourrait manquer
des panneaux de sortie ou des panneaux d'entrée le cas échéant.

les panneaux d'entrée et de sortie sont normalisées donc normalement on
pourrait utiliser la même procédure que pour les trafic_ sign. Garder name
par défaut pour l'entrée


Le lun. 18 mars 2019 à 18:01, https://lists.openstreetmap.org/listinfo/talk-fr>> a écrit :

>/J'aurais aussi laissé l'entrée dans name tout simplement. />//>/name:entrance et name:exit, sachant que entrance et exit ne sont pas des />/codes de langue n'est pas vraiment ambigu mais peut entraîner des 
problèmes />/pour les outils d'importation. />//>/name:fr:exit serait le nom en français de la commune de sortie. />//>/N. B. : contrairement à ce qu'indique Marc ce n'est pas le nom de la />/commune mais aussi le nom de l'agglomération suivi de "commune de XXX". />//>/Exemple : https://www.openstreetmap.org/node/3347836570, Guidel-Plages />/alors qu'il s'agit de la commune de Guidel. />/Ou avec Mapillary : />/https://www.mapillary.com/app/?focus=photo=47.79721754166424=-3.4809542=17=RxO4q1ZookumCATmH2Ct3g=0.5334449075931347=0.3798607750491876=3 
/>/. />/Oui un panneau de lieu-dit suffit mais le maire devait avoir un tarif 
sur />/les panneaux ;-). />//>/Remarquez qu'on entre en français et breton mais on ne sort qu'en 
français />/! />//>/D'ailleurs comment entreriez-vous : />//>/Guidel-Plages />/Commune de Guidel />/? />//>/Vous laissez tomber "Cne de Guidel" ? />//>/Note : si on ne connait la direction du panneau, on ne sait si c'est une />/entrée ou une sortie. Sur le Wiki on n'entre que le nom de 
l'agglomération />/dans laquelle on entre. />/> on a donc croisé un panneau qui a donné son nom />/Et non, ça c'est seulement dans le cas droit où toute route menant à X a />/son panneau d'entrée. />/Typiquement avec des panneaux indiquant des sous-parties de la 
commune il />/n'est pas évitent que toutes les limites internes soient indiquées, par />/exemple dans des culs-de-sac. Mais dans ce cas on n'a pas le panneau />/d'entrée dans l'autre zone. />/Ceci dit je suis à peu-près sûr d'arriver à entrer via "Les Cinq 
Chemins - />/Cne de Guidel" et à ressortir par "Guidel", il suffit de passer par des />/petites rues. />//>/Le 18/03/2019 à 16:59, marc marc - marc_marc_irc at hotmail.com 
 a écrit : />//>/Le 18.03.19 à 16:05, Charles MILLET a écrit : />//>/il me semble qu'il n'y a pas d’ambiguïté donc des name:* devraient 
être bon. />//>/Pourtant name:abc est "name" dans la langue "abc" (ex name:fr name:de) />/Dans les zones multilingue, un panneau est parfois multilingue dont />/multiple name. et un name:abc qui ne se rapport pas à un langue entre en />/conflit avec cette logique bien établie. />/Je n'ai tjs pas saisis l'intérêt, mais si on veux vraiment renseigner />/le nom de la ville qu'on quitte lorsqu'on rentre dans une autre, />/*:name me semble préférable pour éviter cet ambiguïté. />//>/Et si