Re: [OSM-talk-fr] Cestdejaferme

[Yves P.]

> Dans un autre style, la banque d'à côté pendant le confinement:
> - sur rendez-vous le matin
> - par téléphone l'après-midi
> On code comment?


A minima
"Sur rendez-vous le matin - Par téléphone l'après-midi" 


Mieux si tu as les jour d'ouvertures :
Mo-Fr "Sur rendez-vous le matin - Par téléphone l'après-midi" 


Au pif : (pas de tag matin ni après-midi)
Mo-Fr 08:00-12:00 "Sur rendez-vous le matin" || Mo-Fr 14:00-18:00 "Par 
téléphone l'après-midi" 


etc…

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

Re: [OSM-talk-fr] #caresteouvert Intégration données dokomaps en opendata

[Philippe Verdy]

La cas des tags "*:covid19=*" devrait être une exception globale
acceptée du fait de la situation d'urgence et son caractère
"temporaire" (sans date de fin précise mais pas destiné à durer plus
que nécessaire).
Faire un revert massif ne posera aucun problème en fin de crise
officielle, zone par zone, mais on peut admettre que ces tags sont là
et valables pendant un an sans intervenir; ces tags ne gèneront pas
s'ils restent plus longtemps et que les restrictions sont pourtant
levées : au fur et à mesure des réouvertures générales (si le commerce
existe encore) on pourra remettre les tags classiques (mis à jour avec
les nouveaux horaires et conditions) On est déjà dans un régime légal
d'exception pour l'intérêt général.

En revanche pour tout le reste, on peut exiger les règles normales
d'attribution et licence (donc aussi pour l'ajout des POI manquants
qui passe par les "contributor terms" usuels, ce qu'on ne peut pas
faire directement dans l'appli "caresteouvert"). Je ne vois donc aucun
problème réel.


Le sam. 11 avr. 2020 à 14:17, Pierre-Olivier GREGOIRE
 a écrit :
>
> Bonjour,
>
> Étant donné que
> * les données d'ouverture sont bien en provenance des utilisateurs et non de 
> google,
> * qu'une décision assez équilibrée de compléter seulement les établissements 
> ayant déjà existé dans openstreetmap
> * qu'en plus la donnée a une portée temporaire durant le temps du confinement 
> avec un intérêt sanitaire
> * qu'on a bien l'accord du propriétaire de la base de donnée ("la personne 
> qui prend l'initiative et le risque des investissements correspondants")
> je trouve exagéré de supprimer ces données
>
> Pierre-Olivier
>
>
> Le sam. 11 avr. 2020 à 13:17, Marc M.  a écrit :
>>
>> Le 11.04.20 à 12:06, althio a écrit :
>> > Je lance donc un dernier appel sur cette liste, si quelqu'un :
>> > - veut exprimer son opinion en faveur ou défaveur de la validité de ces
>> > données dans OSM, et pour ou contre des reverts
>>
>> il y a hélas pas le choix :(
>>
>> si je met à disposition la base d'osm, mon accord pour le choix
>> d'une autre licence ne vaux rien, le choix ne m'appartient pas.
>>
>> Donc on ne peux pas intégrer des données sans licence ouverte dans osm,
>> même si le gars qui fait l’intermédiaire dit qu'il est d'accord
>>
>> la question se limite à est-ce l'auteur fait son revert lui-même
>> proprement ou il joue la montre, ce qui ne ferra qu'au
>> final un revert plus douleureux (parce que risque de perdre
>> toutes les modifs suivantes sur les objets concernés) ?
>>
>> C'est vraiement domage cette non prise en compte ce qui est
>> pourtant une des bases du projet :(
>>
>> ___
>> 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] Rue trop étroite pour que 2 voitures se croisent ?

[Erwan]

J’utilise également oneway=no + lanes=1
Souvent pour les chossidoux (chaussidoux ?)
Je ne retrouve pas s’il y a un wiki pour les chossidoux pour vérifier si cet 
usage est préconisé 

Erwan

> Le 11 avr. 2020 à 17:05, Florimond Berthoux  a 
> écrit :
> 
> 
> J'allais mettre +1 mais visiblement non :
> lanes=* « Note that it is valid to tag lanes count also in case where lanes 
> are not marked with paint on the surface »
> 
> Et pour narrow je ne suis pas d'accord, parce que :
> «Sometimes, highways or waterways get narrower for a brief period of time, 
> such as "under" a long-removed bridge.»
> «Add narrow=yes to the part of the way that gets narrower. »
> Narrow c'est lorsque la voie se rétrécie sur une courte distance, pas sur 
> toute sa distance, en français on parlerait d'un rétrécissement.
> 
> donc +1 à
> lanes=1
> oneway=no (inutile, mais utile pour affirmer que ce n'est pas une erreur de 
> tag)
> width si disponible.
> 
> et pour compléter les idées des autres :
> https://wiki.openstreetmap.org/wiki/Key:priority si un sens à la priorité
> https://wiki.openstreetmap.org/wiki/Tag:oneway%3Dalternating s'il y a un 
> alternat de type feu
> 
>> Le sam. 11 avr. 2020 à 13:21, Eric SIBERT  a écrit :
>> Pour moi, lanes=* doit être réservé aux chaussées où des voies sont 
>> matérialisés par traçage. Ce n'est pas le cas de la rue en question.
>> 
>> +1 pour :
>> 
>> narrow=yes
>> width=*
>> 
>> https://lists.openstreetmap.org/pipermail/talk-fr/2010-June/023564.html
>> 
>> Eric
>> 
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> -- 
> Florimond Berthoux
> ___
> 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] Application smartphone pour mettre simplement et rapidement une note avec photo(s) ?

[Yves P.]

Bonjour,

Je vois des notes rédigées avec StreetComplete contenant des photos :
https://matrix-client.matrix.org/_matrix/media/r0/download/matrix.org/tJlGICYtryYxyLYCXbYIJEDL
https://ent8r.github.io/NotesReview/?query=hairdresser=true=updated_at=18%2F48.6201%2F1.5644

Quels sont les outils qui permettent de faire ça simplement ?
(avec une éventuelle correction de la position GPS avec la carte)

Si possible avec des mots clés (au hasard #covid19 #caresteouvert #FR) ?

Par exemple pour ajouter un commerce qui n'existe pas encore.

__
Yves

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

Re: [OSM-talk-fr] #caresteouvert Intégration données dokomaps en opendata

[Pierre-Olivier GREGOIRE]

Bonjour,

Étant donné que
* les données d'ouverture sont bien en provenance des utilisateurs et non
de google,
* qu'une décision assez équilibrée de compléter seulement les
établissements ayant déjà existé dans openstreetmap
* qu'en plus la donnée a une portée temporaire durant le temps du
confinement avec un intérêt sanitaire
* qu'on a bien l'accord du propriétaire de la base de donnée ("la personne
qui prend l'initiative et le risque des investissements correspondants")
je trouve exagéré de supprimer ces données

Pierre-Olivier


Le sam. 11 avr. 2020 à 13:17, Marc M.  a écrit :

> Le 11.04.20 à 12:06, althio a écrit :
> > Je lance donc un dernier appel sur cette liste, si quelqu'un :
> > - veut exprimer son opinion en faveur ou défaveur de la validité de ces
> > données dans OSM, et pour ou contre des reverts
>
> il y a hélas pas le choix :(
>
> si je met à disposition la base d'osm, mon accord pour le choix
> d'une autre licence ne vaux rien, le choix ne m'appartient pas.
>
> Donc on ne peux pas intégrer des données sans licence ouverte dans osm,
> même si le gars qui fait l’intermédiaire dit qu'il est d'accord
>
> la question se limite à est-ce l'auteur fait son revert lui-même
> proprement ou il joue la montre, ce qui ne ferra qu'au
> final un revert plus douleureux (parce que risque de perdre
> toutes les modifs suivantes sur les objets concernés) ?
>
> C'est vraiement domage cette non prise en compte ce qui est
> pourtant une des bases du projet :(
>
> ___
> 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] Y-a-t'il mieux que mappeur(se) ; Était La Poste - fichier covid19 des bureaux

[Christian Rogel]

> Le 11 avr. 2020 à 01:14, Philippe Verdy  a écrit :
> 
> "twittos" et "twittas" sont des emprunts au néologismes espagnols. Si
> on avait voulu un néologisme français, on aurait dit "twitteur" et
> "twitteuse" (et on aurait confondu "twitteur" et "Twitter").
> 
> "cartographe(s)" en français reste approprié, pas la peine de faire un
> pseudo-emprunt à l'espagnol et au pluriel forcé. Et pire encore
> "cocarto(s)" qu'on va confondre avec "carto(s)" comme abréviation
> ambiguë (le préfixe ajouté "co-" ne change pas la sémantique du terme
> de base (est-ce que "carto-" désigne "carte", ou "cartographie", ou
> "cartopartie", etc? avec "cocarto(s)" on ne répond pas mieux, cela
> reste une abréviation)
> 
> Si on veut plus court que "cocartographe" (pour ne pas dire
> "cartographe" car on veut ajouter le sens "en coopération"), on peut
> utiliser "cocarteur(s)"/"cocarteuse(s)"
> Mais là on tombe en français sur la ressemblance homophonique avec le
> terme "cocarde" et ses dérivés (cocardier). En espagnol cela donnerait
> "commappor(a)(s)", en anglais "comapper(s) ».

Cocarteur ne sonne pas très bien. Les suffixes hispano-italiens sont de plus
en plus dans l’oreille (barista, fashionista).
Carteur n’existe pas parce que cela résonne avec les métiers de main d’oeuvre,
alors que les premiers cartographes se voyaient comme artistes de haute volée.

> On peut noter quand même que "mappeur(s)"/"mappeuse(s)" a une racine
> laine correcte en français, qu'on retrouve aussi en espagnol et
> italien, et serait tout à fait correct aussi en français comme
> substitut plus court à "cartographe(s)" (réservée à la spécialité
> professionnelle reconnue comme faisant autorité et attribuable).
> 
> Tout compte fait, si on ne veut pas le terme long "cocartographe(s)"
> (trop long?) et qu'on veut éviter "cocarteur(s)"/"cocarteuse(s)" ou
> "cocartier(s)"/"cocartières" (confusion quasi homophonique avec
> "cocardier"), on peut utiliser "comappeur(s)"/comappeuse(s)" (qui
> correspond aussi au breton "kengartenner", avec "ken-" comme préfixe
> traduisant "co(n)-" issu de la préposition latine "cum" signifiant
> "avec" et utilisée aussi comme préfixe en italien, espagnol,
> portugais, catalan, occitan, corse, sarde, roumain et à peine dérivé
> en breton...).
> 
> Mais en français je resterais plus simple avec
> "mappeur(s)"/"mappeuse(s)" qui est tout à fait correct. Et en anglais
> on dirait aussi "mapper(s)" qui serait correct aussi, tout comme
> "mappor(a)(s)" en espagnol (mais surtout pas l'horrible "mappos",
> "mappas" calqué sur l'emprunt abusif par Twitter)
> 

Mappeur ne sonne pas pleinement français. Comappeur nn plus.
Il serait bien de souligner le « avec », qui est, je ne l’ai pas précisé, est
aussi dans commun.


Christian R.




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

Re: [OSM-talk-fr] #caresteouvert Intégration données dokomaps en opendata

[Marc M.]

Le 11.04.20 à 12:06, althio a écrit :
> Je lance donc un dernier appel sur cette liste, si quelqu'un :
> - veut exprimer son opinion en faveur ou défaveur de la validité de ces
> données dans OSM, et pour ou contre des reverts

il y a hélas pas le choix :(

si je met à disposition la base d'osm, mon accord pour le choix
d'une autre licence ne vaux rien, le choix ne m'appartient pas.

Donc on ne peux pas intégrer des données sans licence ouverte dans osm,
même si le gars qui fait l’intermédiaire dit qu'il est d'accord

la question se limite à est-ce l'auteur fait son revert lui-même
proprement ou il joue la montre, ce qui ne ferra qu'au
final un revert plus douleureux (parce que risque de perdre
toutes les modifs suivantes sur les objets concernés) ?

C'est vraiement domage cette non prise en compte ce qui est
pourtant une des bases du projet :(

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

[OSM-talk-fr] Une borne de téléconsultation médicale

[Vincent Bergeot]

Bonjour,

cela se trouve dans une pharmacie, cela a une certaine importance en 
milieu rurale par exemple.


En voici un exemple (je ne fais pas de pub) 
https://www.medadom.com/pharmacie


Cela fait penser aux bornes de réparations pour les vélo mais je ne suis 
pas sur que cela soit approprié :D


healthcare_station ?

à votre bon coeur, voire à vos bonnes idées

à plus

--
Vincent Bergeot


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

Re: [OSM-talk-fr] [DAE] fonctionnement de la base de données nationale des,défibrillateurs automatisés externes

[PanierAvide]

Bonjour,

En tout cas le site est bien lancé et normalement a déjà reçu des 
informations de la part des structures concernées : 
https://geodae.sante.gouv.fr/


Peut-être leur envoyer un petit courriel pour savoir où ils en sont ?

Cordialement,

Adrien P.

Le 11/04/2020 à 17:50, deuzeffe a écrit :

Hello,

C'est moi ou la base nationale n'est toujours pas sur data.gouv sur 
lequel on ne trouve que 
https://www.data.gouv.fr/fr/datasets/defibrillateurs-publics/ ?


Le 24/01/2020 à 14:37, PanierAvide a écrit :

Bonjour,

J'ai assisté à la présentation du jour sur le sujet de la base des 
défibrilateurs (DAE). Quelques points clés à retenir :


- L'outil de saisie et la base entreront en service durant le mois de 
février
- La diffusion des données est prévue par plusieurs méthodes : API 
temps réel pour les applications citoyennes et services de secours, 
export brute des données publiques sur data.gouv.fr (mise à jour 
quotidienne ou hebdomadaire)
- Le système est pensé pour que ce soit les exploitants des 
défibrillateurs qui assurent la saisie et mise à jour. Ce sont eux 
qui ont le dernier mot pour valider ou non l'information. Les 
entreprises qui sont chargées de la maintenance ont également un rôle 
important dans le système. Les citoyens via les applis pourront 
"mettre en doute" les infos renseignées, qui seront vérifiées par 
l'exploitant
- Une équipe d'animation et vérification des données est mise en 
place, basée à Nantes
- Pour amorcer le peuplement de la base, les données issues des 
applis citoyennes seront utilisées.
- Concernant OSM, l'équipe pense utiliser les localisations de DAE 
dans les zones où les exploitants tarderaient à renseigner la base, 
et qui sont peu équipées (ex en zone rurale). La difficulté est de 
retrouver qui est l'exploitant d'un DAE à partir d'OSM, ce qui 
empêche une intégration plus précoce dans le projet
- Les DAE disposeront d'un identifiant unique national. Une recherche 
des doublons sera mise en place, avec la logique suivante : recherche 
dans un rayon de 50m, et validation par l'exploitant de s'il s'agit 
d'un doublon ou de deux équipements distincts
- Une alerte sera envoyée aux exploitants si un DAE n'est pas mis à 
jour pendant 2 ans, et automatiquement "mis en doute"
- La base n'a pas vocation à prendre en compte les DAE mobiles 
(trains, véhicules). Dans le cas d'un DAE qui est déplacé peu 
fréquemment (placé dans une salle quelques mois puis déplacé), ce 
sera à l'exploitant de changer sa localisation
- Pour toutes questions, il reste une démo la semaine prochaine, ou 
il est possible de contacter cont...@geodae.sante.gouv.fr


À minima, on peut donc mettre en place une analyse Osmose pour 
identifier les DAE qui seront dans la base nationale et absents 
d'OSM, une fois que les données seront disponibles. Dans le futur, on 
peut imaginer mettre en place une boucle vertueuse et identifier les 
changements côté OSM pour les soumettre automatiquement à l'API de 
"mise en doute" d'un DAE.


Cordialement,

Adrien P.

Le 16/01/2020 à 13:51, Laurent Magréault a écrit :

Bonjour,

Ci-dessous, les dates des 3 "webdémos" pour en savoir plus sur la 
base nationale des DAE.


___)```)___

Laurent Magréault

     Courriel original 
    Objet: Base nationale des DAE - faire suivre
    Date: 15/01/2020 18:16
    De: ATLASANTE >

    À:


    Bonjour,



    Ce message s’adresse aux collectivités locales ou opérateurs 
privés propriétaires de défibrillateurs, aux membres des plateformes 
régionales d’échanges de données, aux mainteneurs de 
défibrillateurs, aux professionnels du secours, aux gestionnaires 
des applications citoyennes qui assurent le service aujourd’hui.




    La base de données nationale de collecte des défibrillateurs 
automatisés externes ouvrira prochainement afin de permettre aux 
exploitants de déclarer leur DAE en ligne, conformément à la Loi du 
28 juin 2018.


    Afin de comprendre et voir comment cela va se mettre en place 
nous vous proposons 3 web démos d’une durée d’une heure. 
L’inauguration officielle aura lieu mi-février, mais nous ouvrirons 
le service avant pour permettre les déclarations des premiers DAE.




    La Direction Générale de la Santé (DGS) a mandaté les équipes 
d’Atlasanté pour assurer les aspects techniques de ce recueil et du 
partage de la donnée.


    Atlasanté est le Système d’Information Géographique mutualisé 
des ARS et du ministère de la santé.




    Le projet n’a pas vocation à remplacer les applications 
citoyennes existantes. Elles assurent un rôle indispensable 
d’animation de communautés de secouristes. La base nationale 
permettra à toutes les applications qui le souhaiteront de disposer 
des mêmes données via des API gratuites. Les données publiques de ce 
projet seront également disponibles en Open Data.






    3 webdémos  en janvier

    le 21 à 10h55            le 24 à 13h25            le 27 à 13h55



    1h pour découvrir le projet 

Re: [OSM-talk-fr] #caresteouvert Intégration données dokomaps en opendata

[althio]

En l'absence de clarification complète ou d'autres éléments convaincants
sur le statut des données Doko Maps, leur propriété et leur licence, je
considère que ces données ne sont pas valables pour un ajout dans OSM.

La discussion avec les différents auteurs de cet ajout de données et le
reste de la communauté n'a pas eu lieu (en tout, pas aussi détaillée et
conclusive qu'on aurait pu espérer), ni ici sur talk-fr, ni sur
https://github.com/osmontrouge/caresteouvert/issues/81

J'ai fait une demande aux auteurs de cet ajout de données de reverter leurs
contributions, ce qui a été ignoré pour l'instant.
cf.
https://github.com/osmontrouge/caresteouvert/issues/81#issuecomment-611299417

Je lance donc un dernier appel sur cette liste, si quelqu'un :
- veut exprimer son opinion en faveur ou défaveur de la validité de ces
données dans OSM, et pour ou contre des reverts
- voire un appel à volontaires pour effectuer les reverts si les auteurs
initiaux ne s'en chargent pas

On Sat, 4 Apr 2020 at 21:52, althio  wrote:

> Bonjour,
>
> Merci pour le suivi, les renseignements complémentaires et la mise à jour
> des informations.
>
> > Alors, en regardant plus en détails, sur les deux catégories de données :
>> >
>> > - données des contributeurs (commentaire) : je n'ai pas trouvé non plus
>> de
>> >   Terms of Services ou équivalent, donc c'est effectivement une zone
>> >   grise.  Je vais demander.
>>
>> Ils n'en ont effectivement pas.  Du point de vue d'OSM, on peut considérer
>> qu'ils nous ont accordé une licence et que la base juridique de cet accord
>> vis-à-vis de leurs utilisateurs les regarde, mais c'est sûr que c'est
>> problématique.  Dans ce cas particulier, vu la situation et le caractère
>> d'utilité publique de ces données, je ne pense pas qu'il faille bloquer /
>> reverter le travail d'import pour autant.
>>
>
> Tu ne le penses pas, certes, mais il faudrait demander à la communauté,
> voire demander des conseils de manière plus large (liste
> impo...@openstreetmap.org, Data WG, Legal WG...).
>
> "Du point de vue d'OSM, on peut considérer qu'ils nous ont accordé une
> licence et que la base juridique de cet accord vis-à-vis de leurs
> utilisateurs les regarde"
> C'est un peu cavalier, ça ressemble à du recel : la donnée n'a pas de
> licence valable, on le sait, mais on la garde quand même.
> D'autre part, si on veut intégrer dans OSM, la licence et la base
> juridique nous regarde aussi, beaucoup.
> OpenStreetMap est un projet collaboratif international avec des valeurs,
> un partage des données, un partage des méthodes, et un certain partage des
> risques.
> Ce n'est pas une start-up qui bidouille dans son coin pour son propre
> compte.
>
> Pour ma part, je pense que cette source de données est un bien faible
> gain, au regard des conditions problématiques.
> Pour ce qui est de bloquer ou d'annuler les contributions déjà
> effectuée... c'est sûr que c'est maintenant compliqué, il aurait été plus
> facile de prendre son temps et de tirer les choses au clair avant
> d'intégrer les données.
>
> "vu la situation et le caractère d'utilité publique de ces données" n'est
> pas un argument recevable pour justifier d'un ajout de données
> problématique.
>
> La conflation des données s'appuie toujours - je suppose - sur les données
> initiales (nom, localisation, ...).
> Il y a une tolérance du côté d'OSM pour permettre cela à d'autres
> utilisateurs vers d'autres bases.
> Je ne pense pas que cela soit autorisé aussi clairement par Google pour
> ses services et données.
>
> Franchement, avec ou sans conflation, la problématique est peut-être la
> même. Ces données sont teintées Google Maps, nous ne devrions pas y toucher
> - à mon avis - pour compléter OSM.
>
> Et vous devriez arrêter cette contribution, avec ou sans conflation, pour
> étudier proprement la question, arriver à un consensus sur la démarche à
> suivre, et l'appliquer.
>
> - althio
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rue trop étroite pour que 2 voitures se croisent ?

[PanierAvide]

Bonjour,

J'ai un vague souvenir d'une discussion (probablement sur cette liste) 
qui proposait oneway=no + lanes=1, ça a du sens : largeur pour une seule 
file de véhicule, mais rue accessible dans les deux sens.


Cordialement,

Adrien P.

Le 11/04/2020 à 13:03, Lionel Allorge via Talk-fr a écrit :

Bonjour,

Le passage Perron à Saint-Rémy-lès-Chevreuse
 est une ruelle étroite qui
est autorisée à la circulation des véhicules dans les deux sens mais il
est en pratique impossible de s'y croiser. Il faut donc attendre que la
voiture engagée en sorte pour y passer.

J'ai cherché dans le wiki mais je n'ai rien trouvé pour signaler ce cas
de figure.

Merci d'avance pour vos propositions.

Bon confinement.



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

[OSM-talk-fr] Fwd: Re: #caresteouvert Intégration données dokomaps en opendata

[Georges Dutreix via Talk-fr]

Pardon, j'ai répondu en privé au lieu de la liste ... je transfère


 Message transféré 
Sujet : 	Re: [OSM-talk-fr] #caresteouvert Intégration données dokomaps 
en opendata

Date :  Sat, 11 Apr 2020 12:44:16 +0200
De :Georges Dutreix 
Pour :  althio 



Bonjour,

Je n'ai pas les compétences pour entrer dans une discussion juridique. 
Et il est sans doute sage d'arrêter d'utiliser les données dokomaps.


Mais j'ai beaucoup de mal à voir comment le fait d'avoir ajouté un 
horaire covid19 sur une boutique déjà présente sur OSM, pourrait entrer 
en conflit avec une licence google.
Vu dans un autre sens, si je vois qu'une boulangerie est ouverte durant 
le confinement, puis-je en conclure "ah, ils ont pompé des données chez 
google" ?


Donc, je trouve vraiment dommage (et exagéré) de supprimer toutes ces infos.
Cordialement,
Georges


Le 11/04/2020 à 12:06, althio a écrit :
En l'absence de clarification complète ou d'autres éléments 
convaincants sur le statut des données Doko Maps, leur propriété et 
leur licence, je considère que ces données ne sont pas valables pour 
un ajout dans OSM.


La discussion avec les différents auteurs de cet ajout de données et 
le reste de la communauté n'a pas eu lieu (en tout, pas aussi 
détaillée et conclusive qu'on aurait pu espérer), ni ici sur talk-fr, 
ni sur https://github.com/osmontrouge/caresteouvert/issues/81


J'ai fait une demande aux auteurs de cet ajout de données de reverter 
leurs contributions, ce qui a été ignoré pour l'instant.
cf. 
https://github.com/osmontrouge/caresteouvert/issues/81#issuecomment-611299417


Je lance donc un dernier appel sur cette liste, si quelqu'un :
- veut exprimer son opinion en faveur ou défaveur de la validité de 
ces données dans OSM, et pour ou contre des reverts
- voire un appel à volontaires pour effectuer les reverts si les 
auteurs initiaux ne s'en chargent pas


On Sat, 4 Apr 2020 at 21:52, althio > wrote:


Bonjour,

Merci pour le suivi, les renseignements complémentaires et la mise
à jour des informations.

> Alors, en regardant plus en détails, sur les deux catégories
de données :
>
> - données des contributeurs (commentaire) : je n'ai pas
trouvé non plus de
>   Terms of Services ou équivalent, donc c'est effectivement
une zone
>   grise.  Je vais demander.

Ils n'en ont effectivement pas.  Du point de vue d'OSM, on
peut considérer
qu'ils nous ont accordé une licence et que la base juridique
de cet accord
vis-à-vis de leurs utilisateurs les regarde, mais c'est sûr
que c'est
problématique.  Dans ce cas particulier, vu la situation et le
caractère
d'utilité publique de ces données, je ne pense pas qu'il
faille bloquer /
reverter le travail d'import pour autant.


Tu ne le penses pas, certes, mais il faudrait demander à la
communauté, voire demander des conseils de manière plus large
(liste impo...@openstreetmap.org
, Data WG, Legal WG...).

"Du point de vue d'OSM, on peut considérer qu'ils nous ont accordé
une licence et que la base juridique de cet accord vis-à-vis de
leurs utilisateurs les regarde"
C'est un peu cavalier, ça ressemble à du recel : la donnée n'a pas
de licence valable, on le sait, mais on la garde quand même.
D'autre part, si on veut intégrer dans OSM, la licence et la base
juridique nous regarde aussi, beaucoup.
OpenStreetMap est un projet collaboratif international avec des
valeurs, un partage des données, un partage des méthodes, et un
certain partage des risques.
Ce n'est pas une start-up qui bidouille dans son coin pour son
propre compte.

Pour ma part, je pense que cette source de données est un bien
faible gain, au regard des conditions problématiques.
Pour ce qui est de bloquer ou d'annuler les contributions déjà
effectuée... c'est sûr que c'est maintenant compliqué, il aurait
été plus facile de prendre son temps et de tirer les choses au
clair avant d'intégrer les données.

"vu la situation et le caractère d'utilité publique de ces
données" n'est pas un argument recevable pour justifier d'un ajout
de données problématique.

La conflation des données s'appuie toujours - je suppose - sur les
données initiales (nom, localisation, ...).
Il y a une tolérance du côté d'OSM pour permettre cela à d'autres
utilisateurs vers d'autres bases.
Je ne pense pas que cela soit autorisé aussi clairement par Google
pour ses services et données.

Franchement, avec ou sans conflation, la problématique est
peut-être la même. Ces données sont teintées Google Maps, nous ne
devrions pas y toucher - à mon avis - pour compléter OSM.

Et vous devriez arrêter cette contribution, avec ou sans
conflation, pour étudier proprement la question, 

Re: [OSM-talk-fr] copyright erroné

[Philippe Verdy]

Ce copyright APEC est affectivement et honteusement abusif. Cette
carte (zoomable avec tous les détails est bel et bien produite avec
les données OSM. Son rendu CC-BY-SA convient masi avec la mention du
copyright ça laisse uniquement un repartage à l'identique avec ce
copyright abusif.

Et peu importe si son rendu a été calculé avec une base un peu
ancienne (bien que pas si vielle que ça, on voit bien des données qui
ont été dessinées dans OSM il y a quelques semaines ou moins sur les
niveaux de zoom avancés: ce rendu est donc bel et bien alimenté encore
avec les données OSM, même si c'est irrégulier).

Je ne sais pas quel prestataire a conseillé ça à l'APEC, mais même si
il lui a mis un place un serveur dédié, cela n'autorise pas l'APEC à
s'attribuer la totalité des données affichées, quelles qu'en soit la
date. En allant au niveau de zoom élevé on voit beaucoup trop de
données (détail des batiments, noms de rues, y compris avec certaines
fautes d'orthographe ou l'absence/présence de certains accents ou
majuscules ou trait d'union, qui ont été commises dans OSM,
cheminement des voies ferroviaires, etc., géométrie fine des rues,
classification fine des rues jusqu'aux limites "estimées" des aires de
service, typologie des surfaces, noms de grandes entreprises et
grandes surfaces commerciales) pour que cela soit un détail:
l'attribution d'OSM n'est donc pas une option, elle s'impose par la
loi et le dispositif particulier de la protection des bases de
données.

Ces tuiles sont servies par le site www.apec.fr (mais en interne c'est
un proxy cache qui va chercher ça chez un prestataire ("Mogobiz Paris"
si on en croit le cooky fourni par le server web "APEC server" dans
ces tuiles).

Ce prestataire fait héberger le site web chez InterXion France, ou
bien c'est InterXion France qui a vendu cette solution pour l'APEC, et
ce prestataire abuse aussi sans doute ailleurs pour d'autres sites à
qui il propose une carto toute faite.

D'ailleurs c'est le métier d'InterXion de proposer des services
d'hébergement avec gestion des flux, réplication, proxies, CDN (ils
peuvent alors répliquer de façon transparent des bases venant de
divers autres services en ligne, les sociétés de webdesign n'ont plus
qu'à faire leur marché, Interxion mettra tout visible sur le domaine
cible des sites hébergés). Je pense que InterXion n'est pas assez
fiable sur le fait qu'il facilite le détournement de données via ses
plateformes et je ne le vois pas trop imposer beaucoup de règles à ses
clients concernant la protection des données, il semble se dégager
toute responsabilité.

Donc ici la responsabilité en revient directement à l'APEC. C'est
clair qu'elle s'est attribuée abusivement tous les droits sur des
données dont elle n'est de toute évidence pas la source, elle a juste
acheté une "solution" toute faite à un prestataire qui lui a promis
abusivement que ce site serait totalement à l'APEC. Ou alors un
webdesigner interne de l'APEC a jugé "bon" d'unifier le copyright APEC
sur toutes les pages et contenus (on se demande alors pourquoi il
laisse encore la mention de Leaflet et un CC-BY-SA sur le fond de
carte...).

Le jeu. 9 avr. 2020 à 14:57,  a écrit :
>
> Bonjour, j'ai regardé certains traits de côtes sableux et donc variant
> avec le temps et je vous disons de très fortes similarités avec une
> carte connue :
>
> https://www.apec.fr/mon-centre.html#/recherche
>
> Ils hébergent leurs tuiles, très bien.
>
> Imagerie ©Apec me semble cependant déplacé.
>
> Vous êtes d'accord sur la source des données ?
>
> 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] [Phramacies][Licence] Intégration Osmose des professionnels de santé (infirmières, kinésithérapeutes…)

[althio]

La licence, sur http://sante.fr et http://annuairesante.ameli.fr
ça joue pas (ce qui est assez désespérant, je trouve).

Mais, comme indiqué dans le premier message par Yves, le jeu de données qui
semble intéressant est disponible sur data.gouv.fr avec une licence ouverte.

"Il existe en données ouvertes : Infos pratiques professionnels de sante
 avec sa
description

"

Ou alors j'ai loupé un épisode ?


Je relance sur la licence de :
>
> https://sante.fr/conditions-generales-dutilisation
>
> Ca joue ou ça joue pas ?
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Rue trop étroite pour que 2 voitures se croisent ?

[Lionel Allorge via Talk-fr]

Bonjour,

Le passage Perron à Saint-Rémy-lès-Chevreuse
 est une ruelle étroite qui
est autorisée à la circulation des véhicules dans les deux sens mais il
est en pratique impossible de s'y croiser. Il faut donc attendre que la
voiture engagée en sorte pour y passer.

J'ai cherché dans le wiki mais je n'ai rien trouvé pour signaler ce cas
de figure.

Merci d'avance pour vos propositions.

Bon confinement.

-- 
Lionel Allorge

« Ne craignez jamais de vous faire des ennemis; si vous n'en avez pas,
c'est que vous n'avez rien fait »
Clemenceau

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

Re: [OSM-talk-fr] [DAE] fonctionnement de la base de données nationale des,défibrillateurs automatisés externes

[deuzeffe]

Hello,

C'est moi ou la base nationale n'est toujours pas sur data.gouv sur 
lequel on ne trouve que 
https://www.data.gouv.fr/fr/datasets/defibrillateurs-publics/ ?


Le 24/01/2020 à 14:37, PanierAvide a écrit :

Bonjour,

J'ai assisté à la présentation du jour sur le sujet de la base des 
défibrilateurs (DAE). Quelques points clés à retenir :


- L'outil de saisie et la base entreront en service durant le mois de 
février
- La diffusion des données est prévue par plusieurs méthodes : API temps 
réel pour les applications citoyennes et services de secours, export 
brute des données publiques sur data.gouv.fr (mise à jour quotidienne ou 
hebdomadaire)
- Le système est pensé pour que ce soit les exploitants des 
défibrillateurs qui assurent la saisie et mise à jour. Ce sont eux qui 
ont le dernier mot pour valider ou non l'information. Les entreprises 
qui sont chargées de la maintenance ont également un rôle important dans 
le système. Les citoyens via les applis pourront "mettre en doute" les 
infos renseignées, qui seront vérifiées par l'exploitant
- Une équipe d'animation et vérification des données est mise en place, 
basée à Nantes
- Pour amorcer le peuplement de la base, les données issues des applis 
citoyennes seront utilisées.
- Concernant OSM, l'équipe pense utiliser les localisations de DAE dans 
les zones où les exploitants tarderaient à renseigner la base, et qui 
sont peu équipées (ex en zone rurale). La difficulté est de retrouver 
qui est l'exploitant d'un DAE à partir d'OSM, ce qui empêche une 
intégration plus précoce dans le projet
- Les DAE disposeront d'un identifiant unique national. Une recherche 
des doublons sera mise en place, avec la logique suivante : recherche 
dans un rayon de 50m, et validation par l'exploitant de s'il s'agit d'un 
doublon ou de deux équipements distincts
- Une alerte sera envoyée aux exploitants si un DAE n'est pas mis à jour 
pendant 2 ans, et automatiquement "mis en doute"
- La base n'a pas vocation à prendre en compte les DAE mobiles (trains, 
véhicules). Dans le cas d'un DAE qui est déplacé peu fréquemment (placé 
dans une salle quelques mois puis déplacé), ce sera à l'exploitant de 
changer sa localisation
- Pour toutes questions, il reste une démo la semaine prochaine, ou il 
est possible de contacter cont...@geodae.sante.gouv.fr


À minima, on peut donc mettre en place une analyse Osmose pour 
identifier les DAE qui seront dans la base nationale et absents d'OSM, 
une fois que les données seront disponibles. Dans le futur, on peut 
imaginer mettre en place une boucle vertueuse et identifier les 
changements côté OSM pour les soumettre automatiquement à l'API de "mise 
en doute" d'un DAE.


Cordialement,

Adrien P.

Le 16/01/2020 à 13:51, Laurent Magréault a écrit :

Bonjour,

Ci-dessous, les dates des 3 "webdémos" pour en savoir plus sur la base 
nationale des DAE.


___)```)___

Laurent Magréault

     Courriel original 
    Objet: Base nationale des DAE - faire suivre
    Date: 15/01/2020 18:16
    De: ATLASANTE mailto:atlasa...@ars.sante.fr>>
    À:


    Bonjour,



    Ce message s’adresse aux collectivités locales ou opérateurs 
privés propriétaires de défibrillateurs, aux membres des plateformes 
régionales d’échanges de données, aux mainteneurs de défibrillateurs, 
aux professionnels du secours, aux gestionnaires des applications 
citoyennes qui assurent le service aujourd’hui.




    La base de données nationale de collecte des défibrillateurs 
automatisés externes ouvrira prochainement afin de permettre aux 
exploitants de déclarer leur DAE en ligne, conformément à la Loi du 28 
juin 2018.


    Afin de comprendre et voir comment cela va se mettre en place nous 
vous proposons 3 web démos d’une durée d’une heure. L’inauguration 
officielle aura lieu mi-février, mais nous ouvrirons le service avant 
pour permettre les déclarations des premiers DAE.




    La Direction Générale de la Santé (DGS) a mandaté les équipes 
d’Atlasanté pour assurer les aspects techniques de ce recueil et du 
partage de la donnée.


    Atlasanté est le Système d’Information Géographique mutualisé des 
ARS et du ministère de la santé.




    Le projet n’a pas vocation à remplacer les applications citoyennes 
existantes. Elles assurent un rôle indispensable d’animation de 
communautés de secouristes. La base nationale permettra à toutes les 
applications qui le souhaiteront de disposer des mêmes données via des 
API gratuites. Les données publiques de ce projet seront également 
disponibles en Open Data.






    3 webdémos  en janvier

    le 21 à 10h55            le 24 à 13h25            le 27 à 13h55



    1h pour découvrir le projet et poser vos questions



    ·         Audio : 01 70 75 07 40

    ·         Ecran : 
https://ars-auvergne-rhonealpes.anywhereconference.com/


    Web login


    Code PIN Participant

    418836232


    92796633




    Pour le confort de tous, nous vous demanderons de couper vos 
micros et poser vos 

[OSM-talk-fr] Cestdejaferme

[Eric SIBERT]

Bonjour,

J'ai un petit problème avec ma banque. L'agence a été fermée (le DAB 
aussi) pour travaux un peu avant le confinement. Les travaux...


Alors, j'ai mis un access=no le temps des travaux et je n'ai rien ajouté 
pour le covid. Je vois que ça apparaît en vert dans caresteouvert.


https://www.caresteouvert.fr/@45.186494,5.744184,18.40

Une autre proposition pour coder la fermeture temporaire pour travaux?


Dans un autre style, la banque d'à côté pendant le confinement:
- sur rendez-vous le matin
- par téléphone l'après-midi
On code comment?

A+

Eric

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

Re: [OSM-talk-fr] Cestdejaferme

[Marc M.]

Bonjour,

Le 11.04.20 à 11:48, Eric SIBERT a écrit :
> L'agence a été fermée (le DAB aussi) pour travaux un peu 
> avant le confinement. 
> Alors, j'ai mis un access=no

cela dépend des travaux, si c'est lourd, j'aurais altéré
le tag principal genre was:amenity=bank et was:amenity=atm

PS: pour les horaires multi-activié, voir email précédent.

Cordialement,
Marc

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

Re: [OSM-talk-fr] Rue trop étroite pour que 2 voitures se croisent ?

[Philippe Verdy]

J'aurais bien vu un "oneway=alternated" pour indiquer le passage par
alternance (il doit y avoir une zone d'attente à taguer ne plus pour
le croisement.

Ce cas se présente de plus en plus souvent en ville pour pas mal de
rues qui ont été réduites volontairement avec de telles zones
(cependant avec un passage prioritaire dans un sens, pas toujours par
un panneau mais avec une alternance des côtés et donc la nécessité de
zigzaguer. La réduction s'est faite en mettant des places de
stationnement ou limitées et des obstacles tous les ~50 mètres (au
passage la nombre totale de places de stationnement est
considérablement réduit aussi).

Et pourtant la rue n'est pas réellement étroite, il n'y a aucun
problème pour les trottoirs de chaque côté. (donc width=narrow" ne
s'applique pas non plus). Dans certains cas même il n'y a aucun
obstacle autre qu'un marquage au sol, et pas de stationnement
autorisé, la rue reste large (et les services d'urgence ou bus ne sont
pas gênés).

Le cas existe aussi dans des rues avec plusieurs voies, dont une ou
plusieurs réservées aux bus ou aux cycles. Là encore c'est un cas pour
que la voie qui reste (pour tous dans les deux sens) soit en
alternance "oneway=alternated".

Pour le rendu on ne peut pas mettre de flèche simple, il faudrait deux
flèches en opposition. Dans le cas des voies à 1 seul sens priotiaire
aussi, mais comment rendre le sens prioritaire: une flèche épaisse
dans la moiité dans un sens et fine dans l'autre ? ou une double
pointe pour le sens prioritaire ?)



Le sam. 11 avr. 2020 à 14:01, Francescu GAROBY  a écrit :
>
> Bonjour,
> N'y aurait-il pas aussi des panneaux B15 et C18 à cartographier ?
> Leurs présences, si les calculateurs d'itinéraires savent en tenir compte, 
> peuvent aussi être une indication de la faible largeur de la rue.
>
> Francescu
>
> Le sam. 11 avr. 2020 à 13:21, Eric SIBERT  a écrit :
>>
>> Pour moi, lanes=* doit être réservé aux chaussées où des voies sont
>> matérialisés par traçage. Ce n'est pas le cas de la rue en question.
>>
>> +1 pour :
>>
>> narrow=yes
>> width=*
>>
>> https://lists.openstreetmap.org/pipermail/talk-fr/2010-June/023564.html
>>
>> Eric
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> --
> Francescu
> ___
> 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] copyright erroné

[Philippe Verdy]

A ce sujet, Mogobiz est une des activités de "l'entreprise E Biznext",
dont le siège est à Levallois, dirigée par Hayssam SALEH. Il s'en
déclare seul dirigeant, avec aucun salarié et un capital de seulement
5000€ pour Mogobiz (et 37000€ pour E Biznext )! Pas de quoi donc créer
une telle carte. c'est un intermédiaire qui se contente de revendre
des prestations toutes faites. Une entreprise avec au moins une
douzaine de salariés aurait un capital bien plus élevé (de l'ordre de
plusieurs centaines de milliers d'euros), sinon elle n'aurait pas les
crédits et garanties nécessaires pour fonctionner et assurer salaires,
loyers, frais récurrents pour les serveurs selon les variations
saisonnières de prestations vendues.

On se demande ce qui a pris l'APEC de faite appel à ce genre de
margoulin pour lui revendre ce truc tout fait, et où se situe son rôle
de "conseil" (un rôle que l'APEC devrait bien connaitre puisqu'elle
l'explique à ses membres). Certes ça devait pas être bien cher. Mais
ne pas payer grand chose ne signifie pas qu'on peut se passer de
l'obligation de créditer les sources correctement, surtout si on veut
endosser un copyright complet sur le site, ce n'est pas autorisé sur
les parties du site qui ne lui appartiennent pas.

Les mentions légales du site de l'APEC ne contiennent aucune clause de
limitation d'attribution pour les contenus venant de tiers (cette page
est doinc aussi abusive, j'ai trouvé divers autres contenus sur ce
site qui n'appartiennent pas du tout à l'APEC, y compris des données
personnelles publiées, ainsi que les annonces d'offres de ses
partenaires... via un "kit" d'agrégation tout aussi abusif!).

L'APEC ne peut prétendre ignorer la loi alors qu'elle diffuse tout un
paquet de guides pratiques et se veut clairement experte pour
conseiller en matière légale (pas que le droit du travail, mais le
droit d'auteur et les droits voisins entrent dans le champ du droit du
travail, y compris les "nouvelles formes d'emploi" comme le
télétravail ou l'autoentreprenariat).

Le sam. 11 avr. 2020 à 15:17, Philippe Verdy  a écrit :
>
> Ce copyright APEC est affectivement et honteusement abusif. Cette
> carte (zoomable avec tous les détails est bel et bien produite avec
> les données OSM. Son rendu CC-BY-SA convient masi avec la mention du
> copyright ça laisse uniquement un repartage à l'identique avec ce
> copyright abusif.
>
> Et peu importe si son rendu a été calculé avec une base un peu
> ancienne (bien que pas si vielle que ça, on voit bien des données qui
> ont été dessinées dans OSM il y a quelques semaines ou moins sur les
> niveaux de zoom avancés: ce rendu est donc bel et bien alimenté encore
> avec les données OSM, même si c'est irrégulier).
>
> Je ne sais pas quel prestataire a conseillé ça à l'APEC, mais même si
> il lui a mis un place un serveur dédié, cela n'autorise pas l'APEC à
> s'attribuer la totalité des données affichées, quelles qu'en soit la
> date. En allant au niveau de zoom élevé on voit beaucoup trop de
> données (détail des batiments, noms de rues, y compris avec certaines
> fautes d'orthographe ou l'absence/présence de certains accents ou
> majuscules ou trait d'union, qui ont été commises dans OSM,
> cheminement des voies ferroviaires, etc., géométrie fine des rues,
> classification fine des rues jusqu'aux limites "estimées" des aires de
> service, typologie des surfaces, noms de grandes entreprises et
> grandes surfaces commerciales) pour que cela soit un détail:
> l'attribution d'OSM n'est donc pas une option, elle s'impose par la
> loi et le dispositif particulier de la protection des bases de
> données.
>
> Ces tuiles sont servies par le site www.apec.fr (mais en interne c'est
> un proxy cache qui va chercher ça chez un prestataire ("Mogobiz Paris"
> si on en croit le cooky fourni par le server web "APEC server" dans
> ces tuiles).
>
> Ce prestataire fait héberger le site web chez InterXion France, ou
> bien c'est InterXion France qui a vendu cette solution pour l'APEC, et
> ce prestataire abuse aussi sans doute ailleurs pour d'autres sites à
> qui il propose une carto toute faite.
>
> D'ailleurs c'est le métier d'InterXion de proposer des services
> d'hébergement avec gestion des flux, réplication, proxies, CDN (ils
> peuvent alors répliquer de façon transparent des bases venant de
> divers autres services en ligne, les sociétés de webdesign n'ont plus
> qu'à faire leur marché, Interxion mettra tout visible sur le domaine
> cible des sites hébergés). Je pense que InterXion n'est pas assez
> fiable sur le fait qu'il facilite le détournement de données via ses
> plateformes et je ne le vois pas trop imposer beaucoup de règles à ses
> clients concernant la protection des données, il semble se dégager
> toute responsabilité.
>
> Donc ici la responsabilité en revient directement à l'APEC. C'est
> clair qu'elle s'est attribuée abusivement tous les droits sur des
> données dont elle n'est de toute évidence pas la source, elle a juste
> acheté une "solution" toute 

Re: [OSM-talk-fr] Rue trop étroite pour que 2 voitures se croisent ?

[Marc M.]

Bonjour,

Le 11.04.20 à 13:03, Lionel Allorge via Talk-fr a écrit :
> il est en pratique impossible de s'y croiser

lane=1 oneway=no

Cordialement,
Marc

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

Re: [OSM-talk-fr] Rue trop étroite pour que 2 voitures se croisent ?

[Francescu GAROBY]

Bonjour,
N'y aurait-il pas aussi des panneaux B15

et C18

à cartographier ?
Leurs présences, si les calculateurs d'itinéraires savent en tenir compte,
peuvent aussi être une indication de la faible largeur de la rue.

Francescu

Le sam. 11 avr. 2020 à 13:21, Eric SIBERT  a
écrit :

> Pour moi, lanes=* doit être réservé aux chaussées où des voies sont
> matérialisés par traçage. Ce n'est pas le cas de la rue en question.
>
> +1 pour :
>
> narrow=yes
> width=*
>
> https://lists.openstreetmap.org/pipermail/talk-fr/2010-June/023564.html
>
> Eric
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

Re: [OSM-talk-fr] Rue trop étroite pour que 2 voitures se croisent ?

[Florimond Berthoux]

J'allais mettre +1 mais visiblement non :
lanes=* « Note that it is valid to tag lanes count also in case where lanes
are not marked with paint on the surface »

Et pour narrow je ne suis pas d'accord, parce que :
«Sometimes, highways or waterways get narrower for a brief period of time,
such as "under" a long-removed bridge.»
«Add narrow=yes to the part of the way that gets narrower. »
Narrow c'est lorsque la voie se rétrécie sur une courte distance, pas sur
toute sa distance, en français on parlerait d'un rétrécissement.

donc +1 à
lanes=1
oneway=no (inutile, mais utile pour affirmer que ce n'est pas une erreur de
tag)
width si disponible.

et pour compléter les idées des autres :
https://wiki.openstreetmap.org/wiki/Key:priority si un sens à la priorité
https://wiki.openstreetmap.org/wiki/Tag:oneway%3Dalternating s'il y a un
alternat de type feu

Le sam. 11 avr. 2020 à 13:21, Eric SIBERT  a
écrit :

> Pour moi, lanes=* doit être réservé aux chaussées où des voies sont
> matérialisés par traçage. Ce n'est pas le cas de la rue en question.
>
> +1 pour :
>
> narrow=yes
> width=*
>
> https://lists.openstreetmap.org/pipermail/talk-fr/2010-June/023564.html
>
> Eric
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

Re: [OSM-talk-fr] Rue trop étroite pour que 2 voitures se croisent ?

[Eric SIBERT]

Le 11/04/2020 à 17:03, Florimond Berthoux a écrit :

J'allais mettre +1 mais visiblement non :
lanes=* « Note that it is valid to tag lanes count also in case where 
lanes are not marked with paint on the surface »


Je vois qu'il s'agit d'une modification récente (juin 2019) suite à une 
discussion sur la liste tagging dont on ne peut pas dire qu'elle ait 
abouti à un consensus.


https://lists.openstreetmap.org/pipermail/tagging/2019-June/046002.html

Il y a aussi discussion sur la page du wiki:
https://wiki.openstreetmap.org/wiki/Talk:Key:lanes#Marked_or_unmarked_lanes

Pour revenir au point de départ :

Le fait qu'il n'y ait qu'une voie n'indique pas que c'est étroit. C'est 
un détournement de ce pourquoi le tag est fait. Il y a des tas de routes 
de campagne sans marquage où on peut se croiser sans difficulté.


Eric

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

Re: [OSM-talk-fr] Rue trop étroite pour que 2 voitures se croisent ?

[Eric SIBERT]

Pour moi, lanes=* doit être réservé aux chaussées où des voies sont 
matérialisés par traçage. Ce n'est pas le cas de la rue en question.


+1 pour :

narrow=yes
width=*

https://lists.openstreetmap.org/pipermail/talk-fr/2010-June/023564.html

Eric

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

Re: [OSM-talk-fr] école primaire

[deuzeffe]

Hello,

Est-ce qu'à part changer la première ligne dernière colonne du tableau 
ici 
https://wiki.openstreetmap.org/wiki/FR:Tag:amenity%3Dschool#Type_d.27.C3.A9cole 
pour amenity=school, il y a autre chose à faire pour que les choses 
avancent ?


Avertir sur tagging ? Demander une amélioration de l'analyse osmose ? 
Autre ?


--
deuzeffe, qui nettoie sa BàL, donc.

Le 14/01/2020 à 15:32, ma pomme a écrit :

Le 14/01/2020 à 10:33, marc marc a écrit :

Le 13/01/2020 à 19:49, deuzeffe a écrit :

établir que, pour la France, quand c'est
une « école », c'est amenity=school ; amenity=kindergarten étant 
utilisé

pour les établissements d'accueil pré-scolaire.
( pour les autres pays francophones, je ne connais pas du tout leur
fonctionnement )


Une décision a-t-elle été prise ?


ton idée m'a l'air bien.
tu fais une courte comparaison avant/après pour ceux qui ne sont pas
dans le bain ? :)


Chef ! Oui, chef !

Le but est de virer amenity=kindergarten attribués aux écoles 
maternelles (cf 
https://wiki.openstreetmap.org/wiki/FR:Tag:amenity%3Dschool#Type_d.27.C3.A9cole 
La page n'est^W n'était pas à jour pour les âges extrêmes d'instruction 
obligatoire). À conserver uniquement pour le pré-scolaire (crèches) (et 
garderies ?). Donc, tagguer tout établissement, quel qu'il soit, 
d'enseignement primaire et secondaire en amenity=school. Premier point.


Second point : préciser le type d’établissement 
(maternelle/élémentaire/primaire regroupant les deux 
précédents/collège/lycée/secondaire regroupant les 2 précédents) avec le 
school:FR=



Outre le fait qu'il semble que cette manie (d'abuser du namespace) soit 
vaguement franco-française #OuPas, ça peut casser pas mal d'analyses OD 
d'Osmose (pas d'exemple sous la souris où c'est une maternelle sur le 
terrain et une primaire dans la base en OD, vous en avez sûrement).



C'est ça ?


Le 14.01.20 à 07:23, Arnaud Champollion a écrit :

Et y a school:FR=maternelle pour le préciser.


je trouve ce tag historique compréhensible à titre temporaire
lors de la création du monde ou presque.
mais pitié, la proposition d'éducation 2.0


Et on peut la lire où, cette propal ? ^^


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

Re: [OSM-talk-fr] Rue trop étroite pour que 2 voitures se croisent ?

[althio]

lanes=1
width=*

voir aussi
narrow=yes
https://wiki.openstreetmap.org/wiki/Key:narrow

On Sat, 11 Apr 2020 at 15:06, Lionel Allorge via Talk-fr <
talk-fr@openstreetmap.org> wrote:

> Bonjour,
>
> Le passage Perron à Saint-Rémy-lès-Chevreuse
>  est une ruelle étroite qui
> est autorisée à la circulation des véhicules dans les deux sens mais il
> est en pratique impossible de s'y croiser. Il faut donc attendre que la
> voiture engagée en sorte pour y passer.
>
> J'ai cherché dans le wiki mais je n'ai rien trouvé pour signaler ce cas
> de figure.
>
> Merci d'avance pour vos propositions.
>
> Bon confinement.
>
> --
> Lionel Allorge
> 
> « Ne craignez jamais de vous faire des ennemis; si vous n'en avez pas,
> c'est que vous n'avez rien fait »
> Clemenceau
>
> ___
> 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] #caresteouvert Intégration données dokomaps en opendata

[Baptiste Jonglez]

Bonjour,

Tout d'abord, je n'ai pas l'impression d'avoir fermé la discussion.  Il y
a eu une première discussion sur
https://github.com/osmontrouge/caresteouvert/issues/81 avec des retours
positifs (je tiens à noter que je ne suis pas l'initiateur de cette
discussion).

Puis une seconde discussion ici, où tu as très justement pointé du doigt
certains problèmes avec l'origine des données.  Quelques personnes ont
participé à la discussion.  Après je suis d'accord que le début de
l'intégration a été précipité vis-à-vis de l'annonce sur talk-fr (j'ai
considéré à tord que les principales personnes concernées avaient déjà eu
vent de la discussion via le ticket github, ouvert depuis plusieurs jours
et avec de nombreux retours).

Maintenant sur les données elles-mêmes, il y a deux cas :

- les données provenant de Google (nom des POI et localisation) :
  clairement, il n'y a pas lieu de les intégrer, ça semble faire
  consensus.  Merci d'avoir remonté ce problème.  Aucune intégration n'a
  été faite sur ces données.

- les données d'ouverture en temps de confinement, venant des
  contributeurs de Dokomaps : il y a effectivement un flou sur la relation
  entre Dokomaps et ses utilisateurs, Dokomaps aurait dû chercher de façon
  plus explicite la permission de ses utilisateurs.  Ceci dit, il ne me
  semble pas y avoir de consensus dans la discussion sur l'intégration de
  ces données, ni dans un sens ni dans l'autre.  Ça ne me semble pas
  justifié de reverter l'intégration de ces données (surtout qu'elles sont
  généralement croisées avec des informations apportées par ailleurs par
  des contributeurs sur çaresteouvert)

En tout cas, vu ces oppositions, j'ai désactivé les données restantes à
intégrer sur umap (ce que j'aurais effectivement dû faire avant).

Si un consensus émerge sur la nécessité de reverter les données déjà
intégrées, ce sera à contre-coeur mais je m'en chargerais, il n'est pas
question que ça demande du travail à d'autres contributeurs...

Baptiste

On 11-04-20, althio wrote:
> En l'absence de clarification complète ou d'autres éléments convaincants
> sur le statut des données Doko Maps, leur propriété et leur licence, je
> considère que ces données ne sont pas valables pour un ajout dans OSM.
> 
> La discussion avec les différents auteurs de cet ajout de données et le
> reste de la communauté n'a pas eu lieu (en tout, pas aussi détaillée et
> conclusive qu'on aurait pu espérer), ni ici sur talk-fr, ni sur
> https://github.com/osmontrouge/caresteouvert/issues/81
> 
> J'ai fait une demande aux auteurs de cet ajout de données de reverter leurs
> contributions, ce qui a été ignoré pour l'instant.
> cf.
> https://github.com/osmontrouge/caresteouvert/issues/81#issuecomment-611299417
> 
> Je lance donc un dernier appel sur cette liste, si quelqu'un :
> - veut exprimer son opinion en faveur ou défaveur de la validité de ces
> données dans OSM, et pour ou contre des reverts
> - voire un appel à volontaires pour effectuer les reverts si les auteurs
> initiaux ne s'en chargent pas
> 
> On Sat, 4 Apr 2020 at 21:52, althio  wrote:
> 
> > Bonjour,
> >
> > Merci pour le suivi, les renseignements complémentaires et la mise à jour
> > des informations.
> >
> > > Alors, en regardant plus en détails, sur les deux catégories de données :
> >> >
> >> > - données des contributeurs (commentaire) : je n'ai pas trouvé non plus
> >> de
> >> >   Terms of Services ou équivalent, donc c'est effectivement une zone
> >> >   grise.  Je vais demander.
> >>
> >> Ils n'en ont effectivement pas.  Du point de vue d'OSM, on peut considérer
> >> qu'ils nous ont accordé une licence et que la base juridique de cet accord
> >> vis-à-vis de leurs utilisateurs les regarde, mais c'est sûr que c'est
> >> problématique.  Dans ce cas particulier, vu la situation et le caractère
> >> d'utilité publique de ces données, je ne pense pas qu'il faille bloquer /
> >> reverter le travail d'import pour autant.
> >>
> >
> > Tu ne le penses pas, certes, mais il faudrait demander à la communauté,
> > voire demander des conseils de manière plus large (liste
> > impo...@openstreetmap.org, Data WG, Legal WG...).
> >
> > "Du point de vue d'OSM, on peut considérer qu'ils nous ont accordé une
> > licence et que la base juridique de cet accord vis-à-vis de leurs
> > utilisateurs les regarde"
> > C'est un peu cavalier, ça ressemble à du recel : la donnée n'a pas de
> > licence valable, on le sait, mais on la garde quand même.
> > D'autre part, si on veut intégrer dans OSM, la licence et la base
> > juridique nous regarde aussi, beaucoup.
> > OpenStreetMap est un projet collaboratif international avec des valeurs,
> > un partage des données, un partage des méthodes, et un certain partage des
> > risques.
> > Ce n'est pas une start-up qui bidouille dans son coin pour son propre
> > compte.
> >
> > Pour ma part, je pense que cette source de données est un bien faible
> > gain, au regard des conditions problématiques.
> > Pour ce qui est de bloquer ou d'annuler les 

Re: [OSM-talk-fr] Cestdejaferme

[Philippe Verdy]

Le sam. 11 avr. 2020 à 13:32, Yves P.  a écrit :
> Dans un autre style, la banque d'à côté pendant le confinement:
> - sur rendez-vous le matin
> - par téléphone l'après-midi

C'est comme ça que fonctionne ma banque maintenant depuis plus d'un
an... Le COVID19 n'a pas changé ça, sauf que maintenant il est très
difficile d'avoir un rendez-vous et que les appels au téléphone
renvoient vers un centre d'appel régional (surchargé). Les anciens
numéros directs vers l'agence ne sont plus accessibles. L'agence a
aussi réduit son personnel. Il ne reste ouvert que la salle d'entrée
(agrandie) avec les GAB (seul changement depuis le COVID: suppression
du mobilier et toute décoration inutile, plus aucun document à
disposition, les remise de chèques ou liquide se font sur écran ou
application mobile).

D'ici peu on ne pourra plus toucher le distributeur (il n'y aura plus
de clavier ou d'écran tactile) il faudra utiliser son propre mobile
avec l'appli dédiée pour télécommander l'ouverture du GAB et donner
les renseignements nécessaires (tant pis pour ceux qui n'ont pas de
carte de paiement "sans contact", qui déjà ne fonctionne plus dans les
commerces, car impossible de recharger la carte, le commerce ayant
supprimé le clavier pour composer le PIN, il faudra utiliser l'appli
mobile; ceux qui n'ont pas de smartphone avec internet mobile ni de
carte de avec puce RFID pour le sans-contact, sont dans la m...e!)

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

Re: [OSM-talk-fr] Rue trop étroite pour que 2 voitures se croisent ?

[Marc M.]

Le 11.04.20 à 17:39, Eric SIBERT a écrit :
> une voie n'indique pas que c'est étroit

non une voie n'est pas nécessairement étroit.
mais par définition d'une voie, cela indique qu'on ne peux pas
se croiser

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

Re: [OSM-talk-fr] Une borne de téléconsultation médicale

[Jacques Lavignotte]

Le 11/04/2020 à 21:22, Marc M. a écrit :


alors j'ose : amenity/healtcare=doctos


Je mettrai bien un « remote » quelque part pour « à distance »

J.
--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

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

Re: [OSM-talk-fr] Une borne de téléconsultation médicale

[Marc M.]

Le 11.04.20 à 18:06, Vincent Bergeot a écrit :
> Bonjour,
> 
> cela se trouve dans une pharmacie, cela a une certaine importance en
> milieu rurale par exemple.
> 
> En voici un exemple (je ne fais pas de pub)
> https://www.medadom.com/pharmacie

quel service ? un médecin ?
alors j'ose : amenity/healtcare=doctos
avec un sous-tag pour ceux que cela importe si
le docteur est de l'autre côté de son bureau ou d'un écran

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

Re: [OSM-talk-fr] Rue trop étroite pour que 2 voitures se croisent ?

[osm . sanspourriel]

> N'y aurait-il pas aussi des panneaux B15

et C18

à cartographier ?
C'est facultatif.

J'ai un  exemple où les
panneaux sont des B11

indiquant que la largeur maxi est de 3,2 m.

C'est la largeur de la voirie, pas de la voie (bon il y a des camions
qui en plus de respectent pas le 3,5 T et qui élargissent au niveau des
toitures...).

D'où l'utilisation de width (bon on peut ajouter maxwidth).

Le B15/C18 n'est pas obligatoire : dans un cas le véhicule ne doit pas
s'engager car un autre est déjà dans la voie.

À propos de lane, il y avait aussi lane=1,5. ÀMHA à proscrire.

Comme déjà dit narrow=yes si là c'est plus étroit, pas si c'est étroit
partout.

width= c'est le plus objectif et c'est ce qui est conseillé dans le wiki
.

> Non il n'y a aucun panneau aux entrées du passage. Côté sortie par
contre il y a deux panneaux de "céder le passage".
Donc entrée prioritaire et on y reste ? On aura tout vu.

Jean-Yvon

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

Re: [OSM-talk-fr] Une borne de téléconsultation médicale

[osm . sanspourriel]

Tu as remarqué le télé-stétoscope du médecin ? MdR

ça me semble relever d'amenity=doctors puisque c'est un vrai médecin que
tu as en visioconférence.

doctor_station ? bof

Et il faudrait dire que c'est limité.

amenity=doctors
healtcare=telehealth  (à
créer, télémédecine)

Jean-Yvon

Le 11/04/2020 à 18:06, Vincent Bergeot - vinc...@bergeot.org a écrit :

Bonjour,

cela se trouve dans une pharmacie, cela a une certaine importance en
milieu rurale par exemple.

En voici un exemple (je ne fais pas de pub)
https://www.medadom.com/pharmacie

Cela fait penser aux bornes de réparations pour les vélo mais je ne
suis pas sur que cela soit approprié :D

healthcare_station ?

à votre bon coeur, voire à vos bonnes idées

à plus

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

Re: [OSM-talk-fr] Une borne de téléconsultation médicale

[Donat ROBAUX]

Effectivement, il va falloir trouver un tag rapidement.

Pour la clé, ce serait healthcare=*
Pour la valeur, j'ai fais quelques recherches, et c'est pas fameux mais à
mon avis, il faudra plutôt poser la question au niveau mondial pour avoir
une valeur pas trop dégueu, maladroitement traduite.

Mais jetons nous dans la fosse aux lions, je propose:
healthcare=telehealth_station
healthcare=telehealth_cabinet

Donat



--
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

[OSM-talk-fr] site utilisant survey:date et la date metadata

[Marc M.]

Bonjour,

Quel site montrait les objets en fonction de
survey:date et/ou date de dernier modif ?

Cordialement,
Marc

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

Re: [OSM-talk-fr] Rue trop étroite pour que 2 voitures se croisent ?

[Florimond Berthoux]

Merveilleux on a une image
https://www.mapillary.com/app/?lat=48.70657111071199=2.071755502185397=18.2080345940791=7aJzk-PQW4MJ8bw4A_vM_A=0.2830141895413684=0.5381063618623757=1.2625482625482622=photo

Je mettrais aussi
highway=service
service=alley
https://wiki.openstreetmap.org/wiki/Tag:service%3Dalley

Et grâce à l'imagerie et des calculs hautement scientifique (50cm le
carreau de peinture de cédez le passage) je calcul 2,6m à l'entrée,
probablement 3m ensuite :)

Le sam. 11 avr. 2020 à 21:40,  a écrit :

> > N'y aurait-il pas aussi des panneaux B15
> 
> et C18
> 
> à cartographier ?
> C'est facultatif.
>
> J'ai un  exemple où les
> panneaux sont des B11
> 
> indiquant que la largeur maxi est de 3,2 m.
>
> C'est la largeur de la voirie, pas de la voie (bon il y a des camions qui
> en plus de respectent pas le 3,5 T et qui élargissent au niveau des
> toitures...).
>
> D'où l'utilisation de width (bon on peut ajouter maxwidth).
>
> Le B15/C18 n'est pas obligatoire : dans un cas le véhicule ne doit pas
> s'engager car un autre est déjà dans la voie.
>
> À propos de lane, il y avait aussi lane=1,5. ÀMHA à proscrire.
>
> Comme déjà dit narrow=yes si là c'est plus étroit, pas si c'est étroit
> partout.
>
> width= c'est le plus objectif et c'est ce qui est conseillé dans le wiki
> .
>
> > Non il n'y a aucun panneau aux entrées du passage. Côté sortie par
> contre il y a deux panneaux de "céder le passage".
> Donc entrée prioritaire et on y reste ? On aura tout vu.
>
> Jean-Yvon
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

Re: [OSM-talk-fr] Rue trop étroite pour que 2 voitures se croisent ?

[Lionel Allorge]

Bonsoir,

> N'y aurait-il pas aussi des panneaux B15
> 
> et C18
> 
> à cartographier ?
> Leurs présences, si les calculateurs d'itinéraires savent en tenir
> compte, peuvent aussi être une indication de la faible largeur de la rue.

Non il n'y a aucun panneau aux entrées du passage. Côté sortie par
contre il y a deux panneaux de "céder le passage".

Bon confinement.

-- 
Lionel Allorge

« Alésia ? Connais pas Alésia ! Je ne sais pas où se trouve Alésia !
Personne ne sait où se trouve Alésia ! »
Abraracourcix dans Le Bouclier Arverne

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

Re: [OSM-talk-fr] Rue trop étroite pour que 2 voitures se croisent ?

[Marc Mongenet]

Bonjour,

Le sam. 11 avr. 2020 à 14:13, Philippe Verdy  a écrit :

> J'aurais bien vu un "oneway=alternated" pour indiquer le passage par
> alternance (il doit y avoir une zone d'attente à taguer ne plus pour
> le croisement.
>
> Ce cas se présente de plus en plus souvent en ville pour pas mal de
> rues qui ont été réduites volontairement avec de telles zones
> (cependant avec un passage prioritaire dans un sens, pas toujours par
> un panneau mais avec une alternance des côtés et donc la nécessité de
> zigzaguer. La réduction s'est faite en mettant des places de
> stationnement ou limitées et des obstacles tous les ~50 mètres (au
> passage la nombre totale de places de stationnement est
> considérablement réduit aussi).
>
>
A noter que ce cas peut  être tagué sémantiquement
https://wiki.openstreetmap.org/wiki/FR:Key:traffic_calming chicane


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

Re: [OSM-talk-fr] Une borne de téléconsultation médicale

[Georges Dutreix via Talk-fr]

et pourquoi ne pas proposer simple :
healthcare=tele_health (ou même "healthcare=tele")



Le 11/04/2020 à 19:59, Donat ROBAUX a écrit :

Effectivement, il va falloir trouver un tag rapidement.

Pour la clé, ce serait healthcare=*
Pour la valeur, j'ai fais quelques recherches, et c'est pas fameux mais à
mon avis, il faudra plutôt poser la question au niveau mondial pour avoir
une valeur pas trop dégueu, maladroitement traduite.

Mais jetons nous dans la fosse aux lions, je propose:
healthcare=telehealth_station
healthcare=telehealth_cabinet

Donat



--
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

[OSM-talk-fr] réplication ko sur osm13 osm25 osm165 (tous les rendus géré par osm-fr) osm105 (bano v1), osmosis version avant 0.47.2

[Marc M.]

Bonjour,

pour info :
start osmosis
Apr 11, 2020 10:21:36 PM org.openstreetmap.osmosis.core.Osmosis run
INFO: Osmosis Version 0.44.1

SEVERE: Thread for task 1-rri failed
org.openstreetmap.osmosis.core.OsmosisRuntimeException: Unable to parse
xml file /tmp/change3603586700282958333.tmp.  publicId=(null),
systemId=(null), lineNumber=1775, columnN
umber=22.

Caused by: org.apache.xerces.impl.io.MalformedByteSequenceException:
Invalid byte 2 of 4-byte UTF-8 sequence.

https://github.com/openstreetmap/osmosis/pull/51

en cours...

Cordialement,
Marc

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

Re: [OSM-talk-fr] site utilisant survey:date et la date metadata

[althio]

Geocropping ?
https://geocropping.xsalto.com/
https://play.google.com/store/apps/details?id=geocropping.com.geocroppingapp


On Sun, Apr 12, 2020, 00:32 Marc M.  wrote:

> Bonjour,
>
> Quel site montrait les objets en fonction de
> survey:date et/ou date de dernier modif ?
>
> Cordialement,
> Marc
>
> ___
> 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] Application smartphone pour mettre simplement et rapidement une note avec photo(s) ?

[Benoit Fournier]

Je ne connais que StreetComplete, qui fait ça très bien, avec
positionnement ajusté à la main.
On y ajoute le texte de la note, avec contenu libre.

On Sat, Apr 11, 2020, 13:35 Yves P.  wrote:

> Bonjour,
>
> Je vois des notes rédigées avec *StreetComplete* contenant des *photos* :
>
> https://matrix-client.matrix.org/_matrix/media/r0/download/matrix.org/tJlGICYtryYxyLYCXbYIJEDL
>
> https://ent8r.github.io/NotesReview/?query=hairdresser=true=updated_at=18%2F48.6201%2F1.5644
>
> Quels sont les outils qui permettent de faire ça simplement ?
> (avec une éventuelle correction de la position GPS avec la carte)
>
> Si possible avec des *mots clés* (au hasard #covid19 #caresteouvert #FR) ?
>
> Par exemple pour ajouter un commerce qui n'existe pas encore.
>
> __
> Yves
>
> ___
> 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] [Phramacies][Licence] Intégration Osmose des professionnels de santé (infirmières, kinésithérapeutes…)

[Jacques Lavignotte]

Le 09/04/2020 à 19:09, deuzeffe a écrit :

Le 09/04/2020 à 08:53, Yves P. a écrit :

Dans le fichier on trouve beaucoup de profession, mais avec quelques 
doublons / interrogations :


[...]


  * Pharmacien (62 à 63)


Je relance sur la licence de :

https://sante.fr/conditions-generales-dutilisation

Ca joue ou ça joue pas ?

J.


--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

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