Re: [OSM-talk-fr] La gestion des poteaux

2020-09-04 Par sujet Francois Gouget 
On Thu, 3 Sep 2020, Philippe Verdy wrote:
[...]
> > Le nombre de cables se voit sur les photos aériennes.
>
> Pas toujours il y a plein de petites lignes même si on est capable de le 
> dire. Difficile de dire souvent s'il y a 3 ou 5 câbles ou plus. ou même 
> s'il y en a plus d'un seul.

On parle bien du 20kV, pas du 400V en aval des transformateurs de 
distribution ? Les lignes 400V sont effectivement ingérables. Pareil pour 
les lignes téléphoniques.


> Ca dépend beaucoup du fond (y compris la saison),

Ils sont effectivement beaucoup plus visibles sur les fonds sombres que 
les fonds clairs. C'est pas très pratique dans les vignobles, plus simple 
là où il y a des prairies. Mais même si on ne voit pas le nombre de cables 
à un endroit donné, on peut souvent les compter dans un autre champ un peu 
plus loin.

> Et de toute façon pas moyen de deviner les tensions transportées et le 
> mode (nombre de phases ou continu à certains endroits)

Comme dit précédemment la tension se déduit des transformateurs qu'on 
trouve sur la ligne.


> Les transfos sont également pas faciles à voir (et pas toujours montés en
> haut des poteaux,

Les transformateurs au sol sont au sol sont généralement en bordure des 
villes. Pour eux il faut compté sur les photos de rue.

Mais en campagne c'est huit voir neuf transformateurs sur 10 qui se 
trouvent en haut du poteau. Ceux-là font une généralement une verrue bien 
repérable sur l'ombre du poteau.

https://www.openstreetmap.org/edit#map=21/45.77978/-0.09650

Du coup ça fait un bon faisceau d'indices : verrue sur l'ombre + ligne 3 
cables qui arrive + proche d'un transformateur manquant sur Osmose + à 
coté d'un hameau => il y a un transformateur.


> et ce transfo est souvent caché dans la végétation

D'accord avec toi mais en remplaçant 'souvent' par 'parfois'. La verrue 
est aussi parfois moins visible quand le poteau est dans l'axe du soleil.


> parfois enterré sous une trappe difficile à voir (ou dans une armoire
> difficile à distinguer d'une armoire télécoms;

Tout ça ne concerne que les villes. Et dans ce cas c'est clair qu'i faut 
des photos de rue.


> Pour le gaz c'est plus facile car le chemin est marqué par des gros points
> jaunes ou chapiteaux jaunes sur un poteau très visibles presque partout et
> presque toujours en bordure de chemin ou en limite de parcelle sur une aire
> dégagée.

Oui. Et il y a moins de marqueurs que de poteaux électriques. Mais les 
marqueurs faits pour être vus d'hélicoptère sont assez rares et quand on 
n'a qu'eux je ne suis pas sûr que le tracé du pipeline soit bien précis. 
Pour bien faire il faut aussi avoir les marqueurs triangulaires (pedestal) 
mais ils sont très durs à repérer 'en grous il faut identifier 4 pixels un 
peu clairs en losange de part et d'autre d'une route proche du tracé 
supposé du pipeline).


> Sinon si j'ai des doutes, tant pis je ne relie pas:

Oui. Pareil.


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

Re: [OSM-talk-fr] anomalie du serveur OSM sur iD (données partielles/incomplètes)

2020-09-04 Par sujet Philippe Verdy 
Note que le gros des tests et déploiement de SoH en ce moment dépend de
serveurs mis en place par CloudFlare.
Hors CloudFlare c'est jsutement une des grosses victimes de la méga-panne
de Level3 (au moins en Europe).

ce qui marche plutôt pour l'instant (mais pas encore massivement déployé)
c'est DoT (DNS over TLS, plutôt TLS 1.3), IPSEC.

Il manque encore des composants essentiels: SNI, et surtout le déploiement
d'IPv6 qui est encore largement insuffisant pour servir le monde (et
notamment les IoT qui se développent à grande vitesse dans l'anarchie la
plus complète et sans grand contrôle et même en dépit des règles légales
concernant leur sécurité, la confidentialité, l'absense totale de contrôle
par l'utilsiateur tant ils sont opaques, jamais maintenus, et pas
désactivables).

DoH pour moi n'a aucune chance de marcher sans IPv6 partout (Note:
Microsoft est en train de supprimer de Windows le support des tunnels IPv6
pour la transition: 6to4, Teredo, etc. sont officielement listés comme
n'étant plus maintenus, et les serveurs de Microsoft qui les
supporte encore sont en forte déduction de capacité). Microsoft semble
faire ça pour forcer les FAI a enfin mettre à jour leurs box ou les
remplacer (mais dans de nombreux pays, les box ne sont pas fournis ni gérés
par les FAI, ils sont achetés et ceux qui les vendent ne les
maintiennent pas non plus, il y a beaucoup de produits défectueux et non
conformes dans ce qu'on trouve en ligne dont nombre de vendeurs chinois, et
même chez de nombreux importateurs qui achète juste sur catalogue et
livrent tels quels)

De fait aussi, nombre de'utilisateurs désactivent le support d'IPv6 sur
leur matériel parce qu'ils jugent qu'ils n'en ont pas besoin, ou parce
qu'un vendeur de VPN leur a dit que c'était nécessaire et qu'ils
"s'occupaient de tout" à leur place. Les VPN sont une arnaque commerciale
presque partout, avec de fausses promesses de sécurité, de confidentialité
ou d'optimisation des performances.

Que dire encore des FAI et fournisseurs de services français qui tardent
encore à déployer IPv6 (à peine 35% d'entre eux ont une allocation et un
bloc routable, mais au final ils ne les utilisent même pas pour leurs
clients et préfèrent déployer IPv6 à travers de tunnels IPv4 propriétaires,
bien plus lent donc que l'IPv4 natif). Orange en particulier ne fait pas
grand chose. Pas plus SFR. Seul Free semble avoir une offre native
dual-stack par défaut pour tout le monde (libre ensuite à chacun de le
désactiver s'il le veut). Et rien du tout concernant l'Internet mobile.

En fait tout ce monde là préfère vendre ses services en fournissant un
service DNS dont ils contrôlent et filtrent le contenu, et ils en supprime
la sécurité (aucune authentification, ils en profitent pour détourner du
trafic: Orange et SFR notamment). Et que dire des offres des FAI français
qui imposent l'usage (location ou achat) de leur modèle de box supporté
uniquement chez eux et dont ils controlent totalement le firmware (même sur
les box achetées et non louées). L'internet transparent et égalitaire n'est
pas une réalité, il est même de plus menacé, filtré, comme autant de
réseaux propriétaires où on voit ce que le fournisseur veut bien laisser
passer.

Dans ces conditions, IPv6 ne décolle pas. Et tout le monde continue de
dépendre sur des services IPv4 dont on peine à les maintenir en vie et à
les sécuriser: Internet est de plus en plus grévé d'erreurs de securité et
de défauts de maintenance, mais tout le monde "tolère" ça car en plus ces
problèmes servent à booster des ventes d'autres produits dits "de
sécurisation" (les VPN sont la dernière invention inutile, alors qu'ils
n'étaient au départ qu'une solution transitoire d'interconnexion, pas
destinée à optimiser les performances ni réellement apporter une vraie
sécurité auditable).

Bref j'ai de gros doute sur le fait de déployer DoH pour l'instant.
L'Internet n'est pas prêt (en tout cas même pas en France, il l'est
juste dans certains petits pays comme le Luxembourg, mais ces même pays
dépendent très largement de contenus et services qui ne sont pas
accessibles en IPv6, même en vitesse lente pour seulement envisager d'y
héberger DNS sur HTTPS ou TLS: meêm sans TLS, le DNS non sécurisé sur TCP
est tout aussi lent et sous-dimensionné, il n'y a pas assez de serveurs,
même en IPv4, et encore moins en IPv6 où pourtant ce serait plus facile
avec plein de ports et des milliards d'IP uniques pour multiplier les ports
sans nécessiter d'installer une multitude d'interfaces réseau et leur
allouer de très couteuses IPv4).

Si je reviens aux VPN, ils sont presque tous conçus pourtant pour héberger
leur tunnel en IPv4 (il n'y a pas assez de serveurs de tunnels en IPv6).

Il y a bien une parade: faire du TLS avec une encapsulation de TCP sur UDP
(solution déjà utilisée pour le streaming sur certains services).

Mais les gros sites fournisseurs ou hébergeurs de vidéos eux préfèrent
encore l'HTTP(S) sur IPv4 via des serveurs miroirs négociés chez les
fournisseurs

Re: [OSM-talk-fr] Affichage d'un name suivant le rendu

2020-09-04 Par sujet Philippe Verdy 
Ca c'est jsute le point de vue théorique. Rien à voir avec le pragmatisme
qui consiste à s'adapter à ce qu'on peut et sait faire en attendant de
développer mieux.

Ton problème de comptage est un point de vue théorique uniquement qui
oublie de prendre en compte le fait que tu peux parfaitement (et
facilement en plus!) identifier les doublons. C'est une réponse de celui
qui a juste pas envie, pas le courage de le faire. Pourtant c'est facile à
documenter, et utile dans un *long* processus de transition où on n'aura
jamais tout en même temps et tout de suite: c'est illusoire de croire
qu'OSM sera complet, sinon c'est que le monde entier est mort (et n'a donc
plus besoin d'OSM et n'a plus non plus aucun contributeur)!

On en reparlera quand le monde ne sera plus peuplé que de robots et que
l'espèce humaine aura disparu. Personne ne le souhaite ici et en fait on ne
le verra jamais sur OSM, OSM sera mort bien avant ça.

Être pragmatique c'est juste savoir minimiser l'impact en terme de
conséquences, et ici les conséquences sont théoriques (pour un esprit trop
borné à ne pas vouloir voir le reste et qui voudrait se comporter comme un
robot). Mais un humain n'est pas induit en erreur, et on peut parfaitement
apprendre à un robot à se comporter correctement, il faut juste lui dire et
le faire travailler un peu plus, à peine plus en fait car c'est facile à
trouver dans la base).


Le ven. 4 sept. 2020 à 18:20, Vincent de Château-Thierry 
a écrit :

>
> > De: "Philippe Verdy" 
>
> > Ben non justement, ce n'est pas "taguer" pour le rendu car les deux
> > méthodes sont indiquées comme valides et approuvées. Certes il y a
> > des bogues dans le rendu puisque suivant les cas c'est l'une ou
> > l'autre méthode qui est visible; mais si on voit les deux c'est
> > moins grave que ne rien voir du tout.
>
> Les 2 méthodes sont valides et approuvées, je suis d'accord. Mais elles
> sont mutuellement exclusives : si on en choisit une pour un objet du
> terrain, alors il ne faut pas utiliser l'autre pour le même objet. Toujours
> le "one feature, one element".
>
> > Et même hors du rendu (par exemple pour les recherches) cela n'a pas
> > de conséquence: on trouve deux objets pratiquement au même endroit.
>
> Il y a au moins une conséquence : 2 objets pour la même réalité terrain,
> ça fausse les statistiques. Avec un polygone "parking" incluant un point
> "parking" la réponse à la simple question "combien y a t-il de parkings
> dans la commune ?" devient compliquée, alors qu'elle devrait être
> simplement la somme des noeuds "parking" et des polygones "parking" si on
> respecte le principe du "one feature, one element".
>
> 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] Rond point et relations routes

2020-09-04 Par sujet Philippe Verdy 
A mon avis je ne pense pas qu'on ait besoin de l'avis international (peut
importe dans quelle langue) pour décrire ce qu'on a en France et nos
besoins (bien que la solution française est pratiquement similaire chez nos
voisins, européens, ou nos outremers qui sont assez isolés de leurs
voisins, sauf en Angleterre et même pas tout le Royaume-Uni).

On peut décider ici pour la France (et pour d'autres pays francophones qui
nous suivent, même si par exemple les belges devraient en discuter aussi
avec les néerlandophones, les suisses avec les germanophones).

Donc aucune opposition à fixer ça dans la page française (en laissant toute
fois la place à d'autres pays francophones, notamment le Canada, la
Belgique en marquant clairement ce qui s'applique en France dans sa
section, et permettant des sections spécifiques pour d'autres pays, avec
d'autres exigences locales).

OSM applique une politique de respect des conditions locales: partout en
géographie, il ne faut pas toujours généraliser ce qui ne doit pas l'être
et laisser la place à des extensions ou exceptions et essayer de borner ce
qui est applicable (et le minimum applicable c'est la juridiction
applicable, nationale ou d'état, même si dans l'UE beaucoup de principes
réglementaires sont basés sur des règles européennes qui s'imposent du fait
du marché unique et de très nombreuses normes obligatoires assorties de
sanctions si elles ne sont pas appliquées dans une juridiction donnée avant
un temps imparti, une fois les temps de négociation, amendements ou recours
passés et portés dans les instruments de ratification et acceptés par les
autres pays ou négociés par échange d'autres exceptions pour eux).
Cependant au final, même si l'UE a plein de directives, elles ne sont pas
immédiatement applicables et au final c'est toujours la juridiction locale
qui fait loi et règles les litiges (même s'il y a encore ensuite des
recours européens en dernier ressort, qui peuvent alors imposer des
changements réglementaires ou des sanctions à une juridiction locale qui
devra modifier ses instruments de ratification et en notifier l'UE; de même
la France, comme les autres pays de l'UE, est tenue de publier les
décisions faisant jurisprudence, afin que les autres pays aussi puisse les
connaitre et éventuellement commencer des recours contre leur application
trop stricte ou trop large; en pratique ce sont les grands groupes de
cabinets juridiques qui se chargent de faire le tri et ensuite presser l'UE
de modifier les directives pour obliger les gouvernements à renégocier
certains accords ou les faire réviser dans leurs parlements pour les lois
ou par de nouveaux arrêtés d'application).

Bref, on peut décider ici ce qui vaut pour la France, mais rien n'interdit
d'en aviser les autres listes (d'autant que tout le monde n'est pas non
plus francophone, même en France au sens légal, et nombreux sont ceux qui
se sentent plus à l'aise avec une autre langue de travail, ou simplement
ils préfèrent passer plus de temps à coopérer à l'international et ne pas
se disperser sur plein de listes). Donc leur faire savoir qu'une modif a eu
lieu dans la page de doc francophone du wiki suite à un échange ici (ou sur
la petite partie francophone du forum en ligne d'OSM si certains le
suivent).

Unetelle décision peut aussi se faire savoir par le bulletin d'actus OSM
(lui aussi à la base hébergé sur le wiki mais très résumé et qui au moins
aura une traduction dans plus de langues : à charge ensuite pour les autres
de nous lire ou se faire aider pour comprendre les traductions. De toute
façon sur notre wiki, on peut aussi créer une sous-page qui sera traduite
en français et anglais (néerlandais, allemand, italien, catalan ou espagnol
pour les motivés, et même portugais pour ce qui concerne la Guyane et nos
voisins brésiliens bien que la Guyane soit très pauvre en rond-points et
que la communication c'est d'abord par voie fluviale ou maritime) et
référencée depuis la page anglophone sans avoir besoin de trop la
restructurer: la doc du wiki est d'abord centrée sur des aspects génériques
(tous pays) mais a vocation à avoir des sous-pages appropriées s'il le fait
pour certains pays (indépendamment des langues utilisées pour l'original ou
ses traductions complètes ou partielles).





Le ven. 4 sept. 2020 à 19:01, Georges Dutreix via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> C'est la question que je me pose aussi.
> On a les pages route=bus
>  et FR:Bus
> .
> Puis d'autres comme relation route
>  pour les  Itinéraires
> cyclables et randonnées
> ,
>
> Si notre souci est franco-français, et pas juste francophone, quelle est
> la bonne pratique ? Met-on un paragraphe "Rond point" dans ces pages en
> précisant "bonne pratique en France" ? Doit-on d'abord s'assurer

Re: [OSM-talk-fr] Rond point et relations routes

2020-09-04 Par sujet Georges Dutreix via Talk-fr 

C'est la question que je me pose aussi.
On a les pages route=bus 
 et FR:Bus 
.
Puis d'autres comme relation route 
 pour les 
Itinéraires cyclables et randonnées 
, 

Si notre souci est franco-français, et pas juste francophone, quelle est 
la bonne pratique ? Met-on un paragraphe "Rond point" dans ces pages en 
précisant "bonne pratique en France" ? Doit-on d'abord s'assurer de 
l'accord sur la page EN ?




Le 04/09/2020 à 05:52, Gad Jo a écrit :
Pour faire les modifications sur les pages EN faut il faire une 
demande de consensus via une page de discussions ? Quitte a passer sur 
l'hebdo osm pour stimuler les réponses

Il me faut juste quelques conseils et je me lance


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

Re: [OSM-talk-fr] Affichage d'un name suivant le rendu

2020-09-04 Par sujet Vincent de Château-Thierry 

> De: "Philippe Verdy" 

> Ben non justement, ce n'est pas "taguer" pour le rendu car les deux
> méthodes sont indiquées comme valides et approuvées. Certes il y a
> des bogues dans le rendu puisque suivant les cas c'est l'une ou
> l'autre méthode qui est visible; mais si on voit les deux c'est
> moins grave que ne rien voir du tout.
 
Les 2 méthodes sont valides et approuvées, je suis d'accord. Mais elles sont 
mutuellement exclusives : si on en choisit une pour un objet du terrain, alors 
il ne faut pas utiliser l'autre pour le même objet. Toujours le "one feature, 
one element".
 
> Et même hors du rendu (par exemple pour les recherches) cela n'a pas
> de conséquence: on trouve deux objets pratiquement au même endroit.

Il y a au moins une conséquence : 2 objets pour la même réalité terrain, ça 
fausse les statistiques. Avec un polygone "parking" incluant un point "parking" 
la réponse à la simple question "combien y a t-il de parkings dans la commune 
?" devient compliquée, alors qu'elle devrait être simplement la somme des 
noeuds "parking" et des polygones "parking" si on respecte le principe du "one 
feature, one element".

vincent

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

Re: [OSM-talk-fr] anomalie du serveur OSM sur iD (données partielles/incomplètes)

2020-09-04 Par sujet Denis Chenu via Talk-fr 
Je gère des serveurs dont des serveurs DNS,

Cependant : je ne me permettrais ni d'évaluer la qualité technique de DOH.
Je laisse cela à des personnes compétentes.

Denis
Le 04/09/2020 à 15:18, Philippe Verdy a écrit :
> Ce n'est toujours pas complètement réglé. Notamment des fournisseurs
> de DNS sécurisés (dont bon nombre de services DNS over HTTPS qui
> perdent leurs sessions et on beaucoup de mal à les reconencter) sont
> toujours impactés.
>
> Le DNS over HTTPS (DOH) est proposé en ce moment en test par Google ou
> par Microsoft sous Windows 10, mais visiblement il n'a pas encore la
> capcité nécessaire de supporter le traffic nécessaire: les serveurs
> DOH "tombent" les uns après les autres par surcharge (plus assez de
> ports TCP). A mon avis le DOH est une mauvaise solution (à cause de
> l'utilisation de TCP) et le plus fiable reste encore le DNS sur UDP
> qu'on peut authentifier malgré tout avec les signatures numériques et
> les certificats PKI.
>
> J'avais ausi repéré l'incident pas que chez Level3 mais aussi chez
> Cogent (et sur certaines passerelles de Cogent vers
> l'Afrique transitant par OpenTransit/Orange). Là encore il y a
> toujours un problème (et certains pays africains sont encore quasi
> coupés du monde (il y a aussi des problèmes ailleurs comme en Syrie ou
> Corée du Nord, mais là c'est beaucoup plus lié aux mesures politiques,
> ou des mesures d'urgence dans la cyberguerre qui se déroule en ce
> moment, que ce soit entre US et Chine, ou Chine et Taiwan, et en fait
> pas tellement pour ce qui concerne la situation politique locale,
> puisque même les groupes violents ou extrémistes ont besoin de ces
> réseaux et ne les sabottent pas, bien au contraire, même s'ils veulent
> en prendre le contrôle pour pouvoir les utiliser encore davantage: les
> mesures prises le sont par leurs voisins).
>
>
> Le ven. 4 sept. 2020 à 09:39, Christian Quest  > a écrit :
>
> Le 01/09/2020 à 13:33, Philippe Verdy a écrit :
> > oui ça remarche ce midi, hier soir l'internet était un enfer à
> > naviguer. (sauf les sites Google, et le reste était
> extrèmmeent lent,
> > surtout le DNS et presque tout ce qui transitait par les gros
> > datacenters d'Amsterdam)
>
>
> Tout ceci semble lié à une grosse panne chez Level3/CenturyLink,
> un gros
> fournisseur de tuyaux.
>
> 
> https://www.nextinpact.com/lebrief/43434/une-panne-plusieurs-heures-chez-level3centurylink-fait-planter-partie-services-sur-internet
>
>
> La concentration d'internet dans toute sa splendeur :(
>
> -- 
> 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

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

Re: [OSM-talk-fr] Affichage d'un name suivant le rendu

2020-09-04 Par sujet Arnaud Champollion 

Le 30/08/2020 à 21:20, osm.sanspourr...@spamgourmet.com a écrit :
Si par contre tu parles d'objets de nature surfacique telles qu'un 
parking ou un jardin, on est d'accord.


Pour une école je ne sais : tu mets ça sur le landuse ?



Pour une école, je fais un polygone avec amenity=school sur l'emprise de 
l'établissement avec ses bâtiments et surfaces extérieures, par exemple 
https://www.openstreetmap.org/way/483979733







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

[OSM-talk-fr] Caméras - Contributions de Sous-surveillance.net

2020-09-04 Par sujet Vucod via Talk-fr 
Bonjour,

Le site sous-surveillance.net a récemment accepté que les données que ces 
contributeurs ont récolté soient importées dans OpenStreetMap.
Il s'agit de 10 000 caméras et caméras ALPR localisés essentiellement en France 
et récoltés par des contributeurs locaux.
C'est-à-dire que les caméras ont été ajoutées manuellement par les 
contributeurs. Notez également, que les données récoltées correspondent déjà 
aux tags de OpenStreetMap.

Je souhaite donc importer ces données. Je l'ai déjà fait il y a quelques mois 
pour la ville de Bruxelles. 
La qualité des données a été vérifiée, les doublons ont été exclus et cet 
import-là n'a pas reçu de retour négatif après l'import.

Vous pouvez trouver plus d'information ici: 
https://wiki.openstreetmap.org/wiki/Import/Catalogue/sous-surveillance.net et 
n'hésitez pas à commenter la page.

Vucod

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

Re: [OSM-talk-fr] Affichage d'un name suivant le rendu

2020-09-04 Par sujet Philippe Verdy 
Et noter que le "POI" ne désignent pas la cartographie physique, ils sont
juste des points au centre d'une aire (de taille non spécifiée) qui n'est
pas délimitée nécessairement par un objet physique (un seul batiment,
plusieurs, des services annexes rattachés, y compris leurs boites aux
lettres qui peuvent être ailleurs, et qui ne couvrent pas non plus leur
aire d'influence ou de chalandise et ne dit souvent rien de leur importance
relative vis à vis de leur environnement économique ou social)

Hors on ne peut pas taguer comme un POI tous les objets physiques et les
découper ou regroupe ne fait souvent pas de sens non plus car on n'est pas
capable de faire une réelle délimitation: c'est pour ça qu'on les réduit à
un seule noeud assez souvent. Pourtant ils peuvent être bien plus grands et
avoir eux-même une structure interne plus fine (exemple: une école ou une
zone hospitalière avec divers services, et même pas mal de zones
commerciales: l'usage des lieux n'est pas forcément unique non plus et on
ne peut pas séparer géographiquement ces services qui pourtant y sont
situés et se recouvrent partiellement, que ce soit territorialement ou dans
le temps).

On ne peut donc pas déprécier une méthode plutôt qu'une autre.
Malheureusement, traiter les points et les polygones/surfaces, c'est très
différent dans les rendus. Et pour créer des filtres efficaces, ce n'est
pas facile car on ne les verra pas toujours simultanément dans toute
sélection d'objets depuis la base (au plan purement géométrique, les points
sont trop petits ils peuvent être oubliés, les surfaces sinon ne sont
qu'indicatives le plus souvent et parfois trop grande relativement à
l'importance d'autres objets voisins ou qui y sont inclus: on ne peut pas
figer ces règles de filtrage dans les rendus, donc autant permettre cette
flexibilité: c'est aux rendus qui voient les deux types d'objets de mieux
gérer les filtres au cas où il voient des doublons, et ils n'en voient pas
toujours puisqu'ils ne sélectionnent pas tous la même chose).

Enfin les POI tagués comme simple noeud n'ont toujours indication d'une
taille relative (au moins un rayon), et leur "importance" relative par
rapport au reste ne peut pas non plus être décrétée par le système de
tagging, sinon on aurait partout le même carte unique dans tous les rendus,
les mêmes filtres appliqués à tous les niveaux de zopom, et trop de détail
visibles pour tous les usages qui n'en ont pourtant pas besoin: ce qu'on
ferait serit de recréer une carte "à la Google" avec ses critères imposés
ou téléguidés par des choix externes (ou des politiques commerciales selon
les intérêts des autres et pas du visiteur réutilisateur; OSM serait
beauoup moins riche).

Le ven. 4 sept. 2020 à 17:25, Philippe Verdy  a écrit :

> Ben non justement, ce n'est pas "taguer" pour le rendu car les deux
> méthodes sont indiquées comme valides et approuvées. Certes il y a des
> bogues dans le rendu puisque suivant les cas c'est l'une ou l'autre méthode
> qui est visible; mais si on voit les deux c'est moins grave que ne rien
> voir du tout.
>
> Et même hors du rendu (par exemple pour les recherches) cela n'a pas de
> conséquence: on trouve deux objets pratiquement au même endroit.
>
> C'est similaire à d'autres objets où on tague les deux (y compris les
> "labels" qui ont été utilisés et sont encore approuvés dans les relations
> boundary même si on n'en a plus besoin pour les rendus les plus courants ni
> pour les recherches pour les outils classiques comme Nominatim. Ce qui doit
> être changé (ou corrigé) c'est ce que doivent faire les rendus au cas où
> ils trouvent les deux objets (de type différents) au même endroit et la
> façon dont ils gèrent les priorités d'affichage (car de toute façon ils
> font toujours des choix, ils ont tous des filtres et ce sont ces filtres
> qui sont à régler pour eux-mêmes, même si les autres rendus en ont encore
> besoin puisqu'ils ne "voient" qu'une partie des objets).
>
> Rien à voir donc avec "taguer pour le rendu", qui ne désigne que la façon
> de **détourner** des tags prévus pour désigner tout autre chose a fin de
> forcer un affichage. Ce n'est pas du tout le cas ici: les deux
> méthodes sont approuvées. Et il n'a pas été décidé d'en déprécier l'une
> pour l'autre.
>
>
> Le ven. 4 sept. 2020 à 17:01, Vincent de Château-Thierry 
> a écrit :
>
>> Bonjour,
>>
>> > De: "Philippe Verdy" 
>>
>> > Ce rappel était inutile. Ce sont deux objets de nature différente
>> > même s'ils ont le même nom mais pas la même fonction. Et ce
>> > "doublon" n'est pas gênant: si on crée une surface délimitée par un
>> > polygone, ce n'est pas un noeud de plus qui change la donne en terme
>> > de volumétrie et il n'y a pas d'ambiguité réelle.
>>
>> Dans ton précédent mail tu dis : "un point parking trouvé dans une
>> surface parking" donc on parle bien de 2 objets décrivant la même réalité
>> sur le terrain. Leur nature géométrique est différente mais ce sont bien
>> des doublons sémantiques, chose qu'on cherche à

Re: [OSM-talk-fr] Affichage d'un name suivant le rendu

2020-09-04 Par sujet Philippe Verdy 
Ben non justement, ce n'est pas "taguer" pour le rendu car les deux
méthodes sont indiquées comme valides et approuvées. Certes il y a des
bogues dans le rendu puisque suivant les cas c'est l'une ou l'autre méthode
qui est visible; mais si on voit les deux c'est moins grave que ne rien
voir du tout.

Et même hors du rendu (par exemple pour les recherches) cela n'a pas de
conséquence: on trouve deux objets pratiquement au même endroit.

C'est similaire à d'autres objets où on tague les deux (y compris les
"labels" qui ont été utilisés et sont encore approuvés dans les relations
boundary même si on n'en a plus besoin pour les rendus les plus courants ni
pour les recherches pour les outils classiques comme Nominatim. Ce qui doit
être changé (ou corrigé) c'est ce que doivent faire les rendus au cas où
ils trouvent les deux objets (de type différents) au même endroit et la
façon dont ils gèrent les priorités d'affichage (car de toute façon ils
font toujours des choix, ils ont tous des filtres et ce sont ces filtres
qui sont à régler pour eux-mêmes, même si les autres rendus en ont encore
besoin puisqu'ils ne "voient" qu'une partie des objets).

Rien à voir donc avec "taguer pour le rendu", qui ne désigne que la façon
de **détourner** des tags prévus pour désigner tout autre chose a fin de
forcer un affichage. Ce n'est pas du tout le cas ici: les deux
méthodes sont approuvées. Et il n'a pas été décidé d'en déprécier l'une
pour l'autre.


Le ven. 4 sept. 2020 à 17:01, Vincent de Château-Thierry 
a écrit :

> Bonjour,
>
> > De: "Philippe Verdy" 
>
> > Ce rappel était inutile. Ce sont deux objets de nature différente
> > même s'ils ont le même nom mais pas la même fonction. Et ce
> > "doublon" n'est pas gênant: si on crée une surface délimitée par un
> > polygone, ce n'est pas un noeud de plus qui change la donne en terme
> > de volumétrie et il n'y a pas d'ambiguité réelle.
>
> Dans ton précédent mail tu dis : "un point parking trouvé dans une surface
> parking" donc on parle bien de 2 objets décrivant la même réalité sur le
> terrain. Leur nature géométrique est différente mais ce sont bien des
> doublons sémantiques, chose qu'on cherche à éviter, cf le lien indiqué par
> Christian.
>
> > Et j'avais indiqué "de façon pragmatique". On sait qu'on a des
> > limites et qu'elles ne vont pas se régler tout de suite. Je préfère
> > nettement avoir deux objets (de nature différents mais positionnés
> > presque au même endroit, cela n'induit personne en erreur) que de
> > n'en voir aucun de façon aléatoire ou ne pas le trouver si on
> > cherche avec les outils qu'on a actuellement (en attendant qu'ils
> > soient corrigés).
>
> Le fait de "voir ou pas" les objets est de la responsabilité du logiciel
> qui les affiche, ça n'est pas au contenu lui-même de palier les limites des
> chartes graphiques. Sinon ça revient à tagguer pour le rendu.
>
> 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] Affichage d'un name suivant le rendu

2020-09-04 Par sujet Vincent de Château-Thierry 
Bonjour,

> De: "Philippe Verdy" 
 
> Ce rappel était inutile. Ce sont deux objets de nature différente
> même s'ils ont le même nom mais pas la même fonction. Et ce
> "doublon" n'est pas gênant: si on crée une surface délimitée par un
> polygone, ce n'est pas un noeud de plus qui change la donne en terme
> de volumétrie et il n'y a pas d'ambiguité réelle.

Dans ton précédent mail tu dis : "un point parking trouvé dans une surface 
parking" donc on parle bien de 2 objets décrivant la même réalité sur le 
terrain. Leur nature géométrique est différente mais ce sont bien des doublons 
sémantiques, chose qu'on cherche à éviter, cf le lien indiqué par Christian.

> Et j'avais indiqué "de façon pragmatique". On sait qu'on a des
> limites et qu'elles ne vont pas se régler tout de suite. Je préfère
> nettement avoir deux objets (de nature différents mais positionnés
> presque au même endroit, cela n'induit personne en erreur) que de
> n'en voir aucun de façon aléatoire ou ne pas le trouver si on
> cherche avec les outils qu'on a actuellement (en attendant qu'ils
> soient corrigés).

Le fait de "voir ou pas" les objets est de la responsabilité du logiciel qui 
les affiche, ça n'est pas au contenu lui-même de palier les limites des chartes 
graphiques. Sinon ça revient à tagguer pour le rendu.

vincent

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

Re: [OSM-talk-fr] anomalie du serveur OSM sur iD (données partielles/incomplètes)

2020-09-04 Par sujet Philippe Verdy 
Ce n'est toujours pas complètement réglé. Notamment des fournisseurs de DNS
sécurisés (dont bon nombre de services DNS over HTTPS qui perdent leurs
sessions et on beaucoup de mal à les reconencter) sont toujours impactés.

Le DNS over HTTPS (DOH) est proposé en ce moment en test par Google ou par
Microsoft sous Windows 10, mais visiblement il n'a pas encore la
capcité nécessaire de supporter le traffic nécessaire: les serveurs DOH
"tombent" les uns après les autres par surcharge (plus assez de ports TCP).
A mon avis le DOH est une mauvaise solution (à cause de l'utilisation de
TCP) et le plus fiable reste encore le DNS sur UDP qu'on peut authentifier
malgré tout avec les signatures numériques et les certificats PKI.

J'avais ausi repéré l'incident pas que chez Level3 mais aussi chez Cogent
(et sur certaines passerelles de Cogent vers l'Afrique transitant par
OpenTransit/Orange). Là encore il y a toujours un problème (et certains
pays africains sont encore quasi coupés du monde (il y a aussi des
problèmes ailleurs comme en Syrie ou Corée du Nord, mais là c'est beaucoup
plus lié aux mesures politiques, ou des mesures d'urgence dans la
cyberguerre qui se déroule en ce moment, que ce soit entre US et Chine, ou
Chine et Taiwan, et en fait pas tellement pour ce qui concerne la situation
politique locale, puisque même les groupes violents ou extrémistes ont
besoin de ces réseaux et ne les sabottent pas, bien au contraire, même
s'ils veulent en prendre le contrôle pour pouvoir les utiliser encore
davantage: les mesures prises le sont par leurs voisins).


Le ven. 4 sept. 2020 à 09:39, Christian Quest  a
écrit :

> Le 01/09/2020 à 13:33, Philippe Verdy a écrit :
> > oui ça remarche ce midi, hier soir l'internet était un enfer à
> > naviguer. (sauf les sites Google, et le reste était extrèmmeent lent,
> > surtout le DNS et presque tout ce qui transitait par les gros
> > datacenters d'Amsterdam)
>
>
> Tout ceci semble lié à une grosse panne chez Level3/CenturyLink, un gros
> fournisseur de tuyaux.
>
>
> https://www.nextinpact.com/lebrief/43434/une-panne-plusieurs-heures-chez-level3centurylink-fait-planter-partie-services-sur-internet
>
>
> La concentration d'internet dans toute sa splendeur :(
>
> --
> 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] Affichage d'un name suivant le rendu

2020-09-04 Par sujet Philippe Verdy 
Le ven. 4 sept. 2020 à 09:38, Christian Quest  a
écrit :

> Le 01/09/2020 à 22:50, Philippe Verdy a écrit :
> > De façon pragmatique on peut admettre d'avoir simplement les deux (un
> > noeud et une surface)
>
> C'est une très mauvaise pratique, car cela crée 2 objets dans la base
> pour un seul sur le terrain.
>
> Petit rappel :
> https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element


Ce rappel était inutile. Ce sont deux objets de nature différente même
s'ils ont le même nom mais pas la même fonction. Et ce "doublon" n'est pas
gênant: si on crée une surface délimitée par un polygone, ce n'est pas un
noeud de plus qui change la donne en terme de volumétrie et il n'y a pas
d'ambiguité réelle.

Et j'avais indiqué "de façon pragmatique". On sait qu'on a des limites et
qu'elles ne vont pas se régler tout de suite. Je préfère nettement avoir
deux objets (de nature différents mais positionnés presque au même endroit,
cela n'induit personne en erreur) que de n'en voir aucun de façon aléatoire
ou ne pas le trouver si on cherche avec les outils qu'on a actuellement (en
attendant qu'ils soient corrigés).

Si la correction a lieu il sera toujours très facile plus tard de nettoyer
ces quelques "doublons", faciles à trouver en plus.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rond point et relations routes

2020-09-04 Par sujet Philippe Verdy 
Notez quand même que nos giratoires à cédez le passage pour l'entrée ne
sont pas la règle partout. Le premier pays à avoir introduit des
giratoires, le Royaume-Uni, a la plupart de ses ronds-points avec
cédez-le-passage en sortie (la priorité à gauche classique, puisqu'ils
roulent à gauche, s'applique) Et dans de nombreux pays les giratoires (ils
en ont moins) sont souvent plus grands qu'en France et comportent des feux
(une minorité en France sauf aménagément particuliers pour voies de bus
centrale, ou dans les très grands ronds-points comme L'Etoile à Paris, où
les giratoires sont très peu nombreux).

D'une façon générale malgré tout (en Europe du moins) les mêmes règles
qu'en France s'appliquent le plus souvent. Il reste quelques pays
anglophones (GB et US notamment) qui ont un système à part. Aux US les rues
sont démesuréement larges, multivoies même avec peu de circulation,
rectilignes, et ils aiment les feux (suspendus sur câbles). Ils ne sentent
pas le besoin de développer des giratoires (qui sont mal compris ou qui
souvent ont des dispositions encore plus spéciales (comme les
"Turbo-roundabount" qu'on trouve dans les interconnexions de voies
majeures, masi qui donnent une plus grande priorité à certains sens de
circulation et certaines voies d'entrée ou de sortie au détriment des
autres où la traversée est plus compliquée).

Nos giratoires à la française sont relatiment simples dans leurs règles et
ne diffèrent en fait que la présence ou l'absence d'ilots séparateurs entre
voies d'entrée et de sortie, et le cas des connexion unidirectionnelles,
mais la même règle de cédez-le-passage à l'entrée et priorité aux véhicules
sur l'anneau (qui devraient avoir un clignotant à gauche pour indiquer
qu'ils ne sortent pas, mais là c'est peu appliqué en France et jamais
sanctionné non plus, pas plus que ceux qui grillent la priorité et ne
cèdent pas le passage en forçant leur entrée et faisant mine de n'avoir
rien vu).


Le ven. 4 sept. 2020 à 05:52, Gad Jo  a écrit :

> Si vous voulez je peu m'en occuper à minima pour les bonnes pratique en
> France.
>
> Le cas des giratoires à ne pas découper on le comprend mieux chez nous, le
> pays des rond point... On en a un nombre très important sans commune mesure
> avec celui qui est en deuxième position (info entendu sur le journal TV).
> Il est probable que dans les autres pays que le cas se présente rarement
> et que personne ne s'y est intéressé.
>
> Pour faire les modifications sur les pages EN faut il faire une demande de
> consensus via une page de discussions ? Quitte a passer sur l'hebdo osm
> pour stimuler les réponses
> Il me faut juste quelques conseils et je me lance
>
> Le September 3, 2020 2:38:45 PM UTC, Rpnpif via Talk-fr <
> talk-fr@openstreetmap.org> a écrit :
>>
>> Le 01/09/2020 à 19:13, Georges Dutreix via Talk-fr a écrit :
>>
>> Bonjour,
>>
>> J'ai souvent découpé des giratoires pour des lignes de bus : honte sur
>> moi !
>> Promis, je ne le ferai plus ;-)
>>
>> Peut-être faudrait-il décrire les bonnes pratiques, pour les naïfs comme
>> moi, dans des pages comme https://wiki.openstreetmap.org/wiki/FR:Bus
>> ou
>> https://wiki.openstreetmap.org/wiki/FR:Relation:route#Les_itin.C3.A9raires_de_bus_et_les_ronds-points
>> ?
>>
>> Je ne maîtrise pas assez celles-ci pour m'amuser à modifier le wiki
>> moi-même. Et il semblerait qu'il n'y ait pas consensus...
>> Peut-on écrire par ci par là que la bonne pratique en France est de, si
>> possible, ne pas casser les rond points en plusieurs segments ?
>>
>>
>> +1 ! Tout à fait d'accord.
>> --
>> Rpnpif
>>
>
> --
> Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.
> ___
> 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] bâtiments composites / fusion de polygones ?

2020-09-04 Par sujet draenog 

>> SC a des requêtes pourrissant pas mal la base comme demander plusieurs
>> adresses à un bâtiment.

Ok, c'est vrai que j'évite de donner plusieurs adresses pour un même 
lieu, d'où ma question initiale :)


>> Je ne dis pas que SC ne peut pas être utile mais qu'il est utilisé de
>> manière sous optimale. A cause des quêtes pas des utilisateurs^^.

Il est possible de réordonner les quêtes pour les prioriser, qu'est-ce 
qu'il serait le plus utile ?

https://wiki.openstreetmap.org/wiki/StreetComplete/Quests


Le 03/09/2020 à 14:20, osm.sanspourr...@spamgourmet.com a écrit :

Le 03/09/2020 à 13:56, draenog - drae...@harinezumi.fr a écrit :


Je contribue quasi exclusivement depuis mon téléphone, StreetComplete
/ Vespucci (un peu, je découvre), et cela me semblait curieux de
demander (StreetComplete) des numéros de rue plusieurs fois pour le
même lieu (mais est-ce gênant pour OSM ?)


SC a des requêtes pourrissant pas mal la base comme demander plusieurs
adresses à un bâtiment.

Au moins en France on veut ne voir qu'une adresse et plutôt au droit de
l'accès principal.

Et qu'elle soit dans une associatedStreet si c'est une adresse de rue.

Avec plusieurs adresses il y a du travail pour afficher une carte
propre. J'ai déjà vu des coins ou les adresses 12 pullulaient mais peu
d'autres d'adresses dans le coin.

Et tu imagines que si tu demandes d'aller au "13 rue de la Mairie" on
demande si tu veux aller :
- au toit "13 rue de la Mairie"
- au bâtiment de plain-pied "13 rue de la Mairie"
- au bâtiment de deux étages "13 rue de la Mairie"

etc...

De plus avec les possibilités d'intégrer les adresses depuis le
cadastre, il serait raisonnable de déactiver cette quête sur SC. Et
d'inciter à utiliser dev.cadastre.openstreetmap.fr à la place.

C'est un peu comme demander le revêtement de la route sur une
départementale en France : dans 99 % des cas c'est surface=asphalt. Je
pense qu'on a mieux à faire que demander le revêtement de la route.

Je ne dis pas que surface est sans intérêt mais seulement quand la
surface est étonnante ou que vu le type de voirie ça n'a rien d'évident.

 > Je contribue quasi exclusivement depuis mon téléphone,

C'est un peu le problème : en contribuant via SC tu n'a pas forcément
les bons outils.

Je ne dis pas que SC ne peut pas être utile mais qu'il est utilisé de
manière sous optimale. A cause des quêtes pas des utilisateurs^^.


Le bon type pour l'exemple au-dessus serait "toit" ?


oui (roof=no en termes d'attributs).

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

Re: [OSM-talk-fr] maxspeed par défaut

2020-09-04 Par sujet osm . sanspourriel 

Le 03/09/2020 à 16:05, Percherie OnDaNet - perche...@toutenkamion.net a
écrit


Attention pour le nombre de voies. C'est le nombre de voies par sens
de circulation. Je m'en suis rendu compte quand mes applications de
routage m'indiquez 4 voies (2 + 2 par sens) sur une route de
campagne. C'était une découverte sur un cas pratique.


Non, c'est bien le nombre *total* de voies :

FR:Key:lanes /
/

/La clé //lanes=*//doit être utilisée pour indiquer le nombre total
marquées de voies. /


Vérifié et confirmé.

Jean-Yvon

P. S.  : FR:Key:lanes#Présupposés

indique bien quand on peut se contenter du nombre de voies par défaut.

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

Re: [OSM-talk-fr] Rond point et relations routes

2020-09-04 Par sujet Christian Quest 

Le 01/09/2020 à 13:34, osm.sanspourr...@spamgourmet.com a écrit :

Tu veux parler de giratoires ? ;-)

Je crois que le problème est plus général avec les routes : on n'arrête
pas de les couper pour des limites de vitesse, stationnement, files...



Oui, le problème est plus général que l'effet des relation route=*

Cela pose problème côté rendu... car à force ces petits segments 
deviennent trop petits pour y placer les noms.


J'ai dû les recoller ensemble quand ils ont le même name=* / highway=* 
pour avoir plus de chance de placer le nom.


Il est probable de devoir un de ces jours avoir des relations pour 
conserver un objet logique composé de multiples éléments de plus en plus 
petits à mesure qu'on rentre dans les détails.


C'est un comble, car historiquement il n'y avait pas de "way" dans OSM, 
mais des segments qui ne reliaient que deux nœuds, et à force de 
découper, on retombe presque par endroits dans cette segmentation.





C'est qu'il manque un niveau d'information : la rue, le giratoire, à
distinguer du segment de route.

Pour la rue on a associatedStreet. Mais pour le rendu on utilise le nom
de chaque segment avec n fois Rue Tartempion sur la carte.



Les associatedStreet servent à lier les adresses à la voirie, pas à lier 
la voirie elle même.




Et le découpage des giratoires est fait en fonction des trajets de bus,
pas des segments (si deux routes se croise et que le bus route, on va
avoir un segment d'un côté et trois de l'autre).

On pourrait ici avoir 4 segments dans une relation round-about.

Ce serait propre et utilisable si les outils le supportaient.

Je crains qu'il vaille mieux s'en tenir à l'existant.

Usuellement je ne découpe que si le reste du trajet de bus les
giratoires sont découpés.


Je ne découpe pas pour les route=*


--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] anomalie du serveur OSM sur iD (données partielles/incomplètes)

2020-09-04 Par sujet Christian Quest 

Le 01/09/2020 à 13:33, Philippe Verdy a écrit :
oui ça remarche ce midi, hier soir l'internet était un enfer à 
naviguer. (sauf les sites Google, et le reste était extrèmmeent lent, 
surtout le DNS et presque tout ce qui transitait par les gros 
datacenters d'Amsterdam)



Tout ceci semble lié à une grosse panne chez Level3/CenturyLink, un gros 
fournisseur de tuyaux.


https://www.nextinpact.com/lebrief/43434/une-panne-plusieurs-heures-chez-level3centurylink-fait-planter-partie-services-sur-internet


La concentration d'internet dans toute sa splendeur :(

--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Affichage d'un name suivant le rendu

2020-09-04 Par sujet Christian Quest 

Le 01/09/2020 à 22:50, Philippe Verdy a écrit :
De façon pragmatique on peut admettre d'avoir simplement les deux (un 
noeud et une surface)


C'est une très mauvaise pratique, car cela crée 2 objets dans la base 
pour un seul sur le terrain.


Petit rappel : 
https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element



En revanche il peut être utile de conserver certains tags spécifiques 
(pas tous) comme la délimitation des places réservées aux handicapés, 
ou les parkings 2 roues sans avoir besoin d'afficher leur nom en 
doublon visible.


amenity=parking_space pour indiquer les places (en ponctuel ou 
surfacique), à ne pas confondre avec amenity=parking qui décrit 
l'ensemble du parking.



--
Christian Quest - OpenStreetMap France


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