Re: [OSM-talk-fr] Undelivered Mail Returned to Sender
Bonjour, la réponse est dans la question : Si le réseau s'appelle Réseau MAT, alors network = Réseau MAT, le tag network correspond au nom commercial du réseau. -- Noémie Lehuby Jungle Bus - http://junglebus.io Le 10/07/2018 à 13:42, mga_geo a écrit : Bonjour à tous, L'agglomération de Saint-Malo change le nom de son réseau de transport public. KSMA devient le "Réseau MAT". Quelle valeur doit-on mettre dans le tag network ? network=FR:Réseau MAT Marc -- Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html ___ 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] Gros travail pour mettre à jour les mobilités régionales en France
> Le 10 juil. 2018 à 13:49, Philippe Verdy a écrit :
>
> "transport collectif" c'est du jargon politiquement correct. Tout le monde
> dit et comprend "transports en commun" (pas forcément des transports
> "publics" comme le suggère le terme anglophone utilisé).
>
> Note: les transports ne sont pas forcément en groupe ("collectif") et on
> inclut dedans des transports individuels organisés par la collectivité
> (exemple: transport des handicapés à la demande, ou service public de
> vélo-partage...): la notion de groupe ou "collectif" dit que c'est utilisable
> par plus qu'un seul individu pour son usage privé, même si c'est un seul à la
> fois: la ressource de transport est bien mise "en commun" mais nécessite une
> réservation individuelle et se fait sous condition non exclusive hors des
> périodes de réservation et limitations d'usage (en durée ou distance).
>
> Franchement je préfère "transports en commun" qui est plus approprié que
> "collectif" qui est trop restrictif, "commun" se rapprochant mieux du sens de
> "public" en anglais qui n'est pas nécessairement celui d'une collectivité et
> peut répondre à des intérêts et une organisation privée; exemple, les offres
> "publiques" en bourse, qui veut dire "ouvertes au public général" sous des
> conditions d'accès relativement ouvertes non nominatives, mais pas
> nécessairement appartenant au public).
>
>
> Le 9 juillet 2018 à 12:28, Christian Rogel > a écrit :
> Je ne me suis pas vraiment occupé du réaménagement des pages transports FR du
> wiki, mais je crois utile de conseiller 3 choses :
>
> utiliser le terme de transport collectif au lieu de transport en commun
> introduire les nouveaux mots (mobilités, pôle d’échanges) et noter les
> liaisons intermodales
> mettre les pages des réseaux sous autorité régionale (= transports régionaux)
> en WikiProject France, ce qui n’est pas nécessaire pour les transports
> urbains qui doivent être dans les pages de leurs agglomérations respectives
On peut préfèrer l’expression transport en commun, mais, ce n’est pas celui du
21ème siècle. Les deux ont evidemment le même sens.
Depuis peu, et c’est logique que nous nous y conformons, on emploie le terme
plus englobant de mobilité(s)., précisément pour inclure les types de
déplacements de personnes que tu cites (TAD, taxis, cycles, handis, VTC,
gyropodes, …).
Transport public est à écarter, puisque cela amène de la confusion, alors que
les opérateurs majeurs ne sont pas toujours de droit public.
Pour répondre à deuzeffe, l’arborescence du wiki doit déployée sur 2 approches :
L’une fonctionnelle et orientée technique de taggage OSM (la page «FR:Transport
public » est trop verbeuse et semble contrefaire Wikipedia)
transport (hommes et marchandises)
> transport de fret (décrire les gares de triage et les centres pour les
> véhicules de transport routier)
> mobilté
>> transport collectif
>> trains, bus, trams, aéroports, téléphériques
>> déplacements non collectifs
>>> Itinéraires cyclables
>>> Itinéraires pédestres
>>>…
L’autre approche est territoriale et consiste à répertorier les réseaux et à
organiser le travail de cartographie, c’est pourquoi les plus importants
doivent aller dans un WikiProject France.
L’arborescence est du type :
> Transport par région
>> Régions
>>> Réseaux régionaux
Chemin de fer (réseau régional de)
Cars (réseau régional de)
Itinéraires par catégorie
> Transport urbain et interurbain
>> Villes et leurs agglomérations (utiliser leur page dédiée)
Par ailleurs, Philippe a renommé la catégorie « Public transport in Brittany »
en Public transport in Bretagne ». Il n’y a aucune raison de passer à la trappe
une appelation familière aux anglophones. A la rigueur, on peut les accoler.
Chaque catégorie en anglais devrait être doublée par son équivalent en
français, pour l’utilisabilité du plus grand nombre.
Christian R.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Undelivered Mail Returned to Sender
Une précision : le nom du réseau est "Réseau MAT" cf https://www.reseau-mat.fr/ Il ne me semble pas judicieux d'enlever le mot "Réseau". Inclure le numéro de département serait une première pour un réseau de transport ? -- Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Undelivered Mail Returned to Sender
je suggère d'éviter "Réseau", juste mettre "FR:35:MAT" (car "MAT" est trop court pour être identifiable, même en France, avec 35 on sait que c'est en Ille-et-Vilaine et que c'est un sous-réseau dans le département et pas le réseau départemental; chercher MAT en Ille-et-Vilaine ne sera donc pas difficile à trouver). === Note: il y a maintenant un problème de livraison des mails de Yahoo via la liste OSM vers Gmail (problème de sécurité DKIM/DMARC) : une erreur se produit "550 5.7.1 DMARC initiative. m129-v6si1689864wmb.101 - gsmtp", ce qui empêche de faire un "forward". Il semble que Gmail a renforcé les règles concernant les renvois de listes de diffusion, et la mailing list OSM ne semble pas prendre en charge une clé de suivi nécessaire opur que Google évite de rejeter les mails entrants comme venant d'une source non authentique; il semble que le mailing list manager d'OSM oublie une signature, la chaine de vérification des sources est rompue; je pense que c'est lié au niveau de sécurité demandé, Google ayant désapprouvé d'anciens algos de signature numérique comme SHA1 et impose maintenant SHA256 avec une longueur de clé supérieure; Google a également désapprouvé tout un tas d'anciennes clés PKI utilisant une signature SHA1 dont la mort avait été prévue pourtant depuis plus de 10 ans et annoncée comme définitive au 1er juillet: plein de services ont changé leur certificats depuis de début de l'année, Google l'a fait depuis au moins 3 ans. En France Orange n'a encore rien fait et est **encore** à la traine en terme de sécurité !). Je reçois encore ces messages correctement chez Orange qui n'impose pas encore la nouvelle version de DKIM/DMARC pour les listes de diffusion. Je pense que je ne dois pas être le seul à qui il manque des messages non arrivés depuis cette liste. Ce qui est particulier aux listes de diffusion est que le message envoyé à la liste doit nécessairement être modifié par la liste (au moins les entêtes, mais la liste OSM modifie aussi le corps du message en adjoignant un pied de page (le message perd donc sa signature valide, la liste OSM ne recalcule pas une clé sur le fragment initial, et ne met pas son pied de page dans une section MIME séparée avec sa propre signature numérique OSM, il laisse les autres entêtes DKIM inchangés et le texte ne correspond plus, Google est incapable de valider l'authenticité, et prend donc les messages venant des listes OSM comme du spam abusant l'identité d'un tiers). Philippe Le 10 juillet 2018 à 13:43, mga_geo a écrit : > > Subject: [OSM-talk-fr] Changement de nom d'un réseau de transport > Bonjour à tous, > L'agglomération de Saint-Malo change le nom de son réseau de transport > public. > KSMA devient le "Réseau MAT". > Quelle valeur doit-on mettre dans le tag network ? > network=FR:Réseau MAT > > Marc ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] panne des rendu HOT OpenRiverBoatMap Route500/BDCarthage/QA/FrAdm
Le 9 juillet 2018 à 09:20, Christian Quest a écrit : > Le rendu Route500 et Hydro (Carthage + BDTopo Hydro) sont de retour. > > Manque encore le rendu QA et FRadm + les analyses osmose. > > Le 7 juillet 2018 à 16:14, Christian Quest a > écrit : > >> La semaine dernière un des SSD d'osm13 a rendu l'âme après presque 6 ans >> d'usage intensif. >> >> Voilà ce que j'appelle "usage intensif": >> - plus de 47000 heures de vol >> > Les SSD actuels sont en centaines de milliers d'heure. > - plus de 100To écrits (soit 200 fois la capacité du SSD de 480Go) >> > 200 fois c'est peu, les SSD actuels promettent plusieurs milliers de réécriture par secteur. De plus ils compensent des pannes éventuelles sur certains secteurs avec une réserve supplémentaire en faisant cycler (cela évite les cas pathologiques lors que le SSD est presque plein, où quelques secteurs seulement sont constamment réécrits et les autres beaucoup moins souvent. La ressource critique est la mémoire de "tags" qui permet de mapper les secteurs logiques en secteurs physiques (dont la position change constamment à chaque écriture en les réallouant parmi les secteurs trimmés, qui eux aussi doivent avoir une réserve suffisante pour ne pas tourner sur le même petit nombre: au besoin le firmware SSD devrait aussi recycler les secteurs logiques non réécrits mais sur des secteurs beaucoup moins souvent écrits afin de les mettre sur des secteurs trimmés trop fréquemment réécrits mais encore fiables; chaque trim d'un secteur devrait tenir un compteur pour déterminer ce qu'il faudrait déplacer afin de préserver le reste en distribuant la charge sur la totalité du disque; la réserve libre non allouable devrait être de l'ordre de 10% de la capacité physique pour avoir 90% de capacité logique; la petite mémoire de tags devrait être constituée de mémoire nettement plus fiable et plus rapide, sa capacité réduite permet de la maintenir en RAM volatile synchronisée prioritairement vers la mémoire flash, avec une réserve d'énergie suffisante et pour cela le firmware devrait maintenir un pool minimum de pages prétrimmés libres pour sauvegarder très facilement et rapidement la mémoire de tags sans avoir besoin de beaucoup d'énergie). Cependant des lecteurs SSD bon marché n'ont même pas de réserve d'énergie suffisante ou c'est un simple condensateur électrolytique dont la duré de vie est limitée et trop utilisé en pleine capacité de charge avec une "mémoire de charge" qui se dégrade comme les batteries de smartphones avec un hystérésis important. Certains qui n'ont aucune réserve d'énergie ont simplement alloué la mémoire de tags dans un petit journal cyclique sur des pages qui s'usent prématurément plus vites que le reste de la capacité de stockage logique et physique, et avec un trop petit pool de pages trimmées libre pour ce journal: ils sont faits comme les clés USB, qui peuvent se bloquer en lecture seul très vite (j'ai eu une clé USB3, pourtant de marque Philips, qui n'a pas tenu son premier formatage pour y installer une image ISO bootable de Windows, la copie s'est bloquée au milieu, la clé est passée en lecture seule définitive avec moins de 300 méga écrits dessus sur une clé de 32 Go!). OCZ (comme les fabricants de clés de stockage USB) n'est pas réputé pour la fiabilité de ses SSD et notamment de son firmware trop simpliste assurant un recyclage statistiquement correct des pages de stockage. Sur un SSD c'est toujours la mémoire de tags qui est la plus sollicitée, elle doit avoir des tampons maintenant sa durabilité et le meilleur moyen reste d'y inclure un cache en registres CMOS et un cache de second niveau en DRAM, une réserve d'énergie, avant la couche finale flash, et une bonne gestion des priorités internes dans les bus internes. - plus de 11100 To de lus, 1.1 Po Là oui c'est intensif, mais normalement pas un problème pour les SSD, la lecture ne touchant ni à la mémoire de tags, ni ne nécessitant aucune opération de trim et recyclage. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Gros travail pour mettre à jour les mobilités régionales en France
"transport collectif" c'est du jargon politiquement correct. Tout le monde
dit et comprend "transports en commun" (pas forcément des transports
"publics" comme le suggère le terme anglophone utilisé).
Note: les transports ne sont pas forcément en groupe ("collectif") et on
inclut dedans des transports individuels organisés par la collectivité
(exemple: transport des handicapés à la demande, ou service public de
vélo-partage...): la notion de groupe ou "collectif" dit que c'est
utilisable par plus qu'un seul individu pour son usage privé, même si c'est
un seul à la fois: la ressource de transport est bien mise "en commun" mais
nécessite une réservation individuelle et se fait sous condition non
exclusive hors des périodes de réservation et limitations d'usage (en durée
ou distance).
Franchement je préfère "transports en commun" qui est plus approprié que
"collectif" qui est trop restrictif, "commun" se rapprochant mieux du sens
de "public" en anglais qui n'est pas nécessairement celui d'une
collectivité et peut répondre à des intérêts et une organisation privée;
exemple, les offres "publiques" en bourse, qui veut dire "ouvertes au
public général" sous des conditions d'accès relativement ouvertes non
nominatives, mais pas nécessairement appartenant au public).
Le 9 juillet 2018 à 12:28, Christian Rogel a écrit :
> Je ne me suis pas vraiment occupé du réaménagement des pages transports FR
> du wiki, mais je crois utile de conseiller 3 choses :
>
>
>- utiliser le terme de transport collectif au lieu de transport en
>commun
>- introduire les nouveaux mots (mobilités, pôle d’échanges) et noter
>les liaisons intermodales
>- mettre les pages des réseaux sous autorité régionale (= transports
>régionaux) en WikiProject France, ce qui n’est pas nécessaire pour les
>transports urbains qui doivent être dans les pages de leurs agglomérations
>respectives
>
>
> Il ne faut pas prendre la prudence des politiques pour l’indice de vouloir
> laisser les transports par autocar sous responsabilité départementale, car,
> si les services sont restés sur place, les personnels ont pu déjà être
> régionalisés (80 en Bretagne).
>
> Ce n’est qu’une question de temps pour que les façades départementales
> disparaissent. De nouvelles marques et de nouvelles lignes sont en
> préparation et cela bougera beaucoup à la rentrée 2019.
>
> Note : La Région Bretagne a renommé son calculateur d’itinéraires,
> MobiBreizh (basé sur Navitia), et utilise des cartes OSM au lieu de G Maps
> pour les trajets. Ce calculateur semble devoir être celui des gros réseaux
> urbains, car il a été adopté par mon agglo.
>
>
>
> Christian R.
>
> ___
> 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] Changement de nom d'un réseau de transport
Bonjour à tous, L'agglomération de Saint-Malo change le nom de son réseau de transport public. KSMA devient le "Réseau MAT". Quelle valeur doit-on mettre dans le tag network ? network=FR:Réseau MAT Marc -- Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition de projet du mois de Juillet (ce que vous allez découvrir va vous surprendre)
On Mon, 9 Jul 2018, François Lacombe wrote: > Bonjour à vous, > > Le 9 juillet 2018 à 11:36, Francois Gouget a écrit : > > > Ca serait sympa d'avoir un module Osmose pour faire l'intégration, un > > peut comme pour les panneaux Mapillary : une ligne haute tension est > > signalée à proximité mais aucun objet OSM correspondant n'a été trouvé. > > > > Aux dernières nouvelles ce n'est pas possible pour les objets linéaires. > Osmose ne fait de la conflation que sur les points. > Nous ne pourrions dans tous les cas pas proposer de correction via Osmose : > il manque les poteaux dans les données Enedis, et ce sont pourtant les > seuls sommets qui doivent composer les lignes OSM. L'absence des poteaux dans les données Enedis ne me paraît pas rédihibitoire. Pour chaque portion de ligne qui va tout droit leur fichier contient un segment décrit par les coordonnées de ses extrémités. D'après ce que j'ai pu en voir leurs coordonnées sont assez précises. Donc à proximité de chaque extrémité on devrait retrouver un poteau dans OSM. Je ne sais pas si on peut aussi vérifier que le poteau de départ est bien connecté au poteau d'arrivée mais la détection des poteaux isolés et des lignes incomplètes devrait déjà inciter les contributeurs à ajouter les lignes manquantes. Bien sûr cela ne permettra pas non plus de vérifier que le contributeur OSM n'a pas raté des poteaux intermédiaires. Mais cela permettra d'identifier les morceaux de ligne manquants et c'est déjà beaucoup. En particulier cela permettra de s'assurer que le réseau est correctement connecté et complet. Parce que lorsque le réseau a trois au quatre bifurcations de suite il est facile de continuer sur la branche 'principale' et d'oublier de revenir en arrière pour ajouter celles qu'on a sauté. > Ca se décrit comme ca : > power=line OU power=minor_line (faut choisir, perso c'est line) > voltage=2 > operator=Enedis > cables=3 J'ai une question là-dessus : comme j'ai travaillé à partir des photos j'ai renseigné ce que je voyais, c'est à dire cables=3. Par contre le voltage ne se voyant pas sur les photos je ne l'ai pas positionné. Par contre maintenant je voie que mes lignes correspondent à celles du fichier Enedis. Sait-on si ce fichier ne contient que des lignes à 2 V ? (j'ai pas réussi à le voir d'après leur doc) Déjà dessus je ne voie pas les lignes à 9 V qui passent dans la région donc c'est bon signe. Bref, serait-il présomptueux d'ajouter voltage=2 sur les lignes que j'ai ajouté même si je ne suis pas allé vérifier avec mon voltmètre ? ;-) Et pour les transformateurs il faut transformer=distribution, pas transformer=minor_distribution ? Ça semble incohérent avec les power=substation. https://wiki.openstreetmap.org/wiki/Tag:power=substation#Substation_values https://wiki.openstreetmap.org/wiki/Tag:power=transformer#Transformer_values -- Francois Gouget http://fgouget.free.fr/ It really galls me that most of the computer power in the world is wasted on screen savers. Chris Caldwell from the GIMPS project http://www.mersenne.org/prime.htm___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
