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

[Gad Jo]

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

Re: [OSM-talk-fr] [SDIS/SAMU] Projet du mois défibrillateurs

[Philippe Verdy]

Le jeu. 3 sept. 2020 à 20:35, Yves P.  a écrit :

>
> aucune donnée publique. pourtant ils invitent à déclarer les DAE par eux
>
>
> Comme Staying alive / AED-Map ;)
>
> A la différence près que ces données sont publiées dans data.gouv.fr
> 
>
>
> SauvLife ne traite que les agences publiques, il n'a forcément pas tous
> les DAE concernés par ces déclarations).
>
> D'où tiens-tu cette information ?
>

Leur page d'accueil qui ne mentionne que des structures
médico-hospitalières publiques. Les autres sont juste des "partenaires".
Rien n'est indiqué sur les procédures de controle, et leur formulaire en
ligne n'est pas fait pour tout le monde avec ce qui est demandé et il
manque de pas mal de précisions: en gros juste le nom de l'organisme,
l'adresse de l'établissement (adresse fiscale ou de gestion) et les noms,
numéros ou adresses de contacts, le reste c'est du champ libre facultatif.
Rien n'est demandé vraiment sur la localisation exacte, l'accessibilité
réelle n'est pas demandée, rien non plus sur l'entretien. Même pas la
possibilité de se géolocaliser précisément sur une carte. Rien non plus
pour identifier le matériel (et éviter les doublons possibles selon qui va
utilsier le formulaire, et pas grand chose pour justifier l'identité du
déclarant: pas de quoi justifier plus tard ses obligations légales, et rien
pour que les autres employés puissent contrôler que cela a bien été déclaré
et si les restrictions d'accès imposées ou les limites d'entretien sont
respectées ou valides).
En gros cela ne crée ni plus ni moins qu'un agenda privé (mais pas grand
chose n'est dit sur ce qu'ils vont faire réllement de ces données et quel
droit d'accès ou de rectification sera possible, visiblement ce n'est pas
au point pour le RGPD avec les professions libérales).
Efin SAUV met une licence exclusive par défaut à tout son site et se
réserve le droit d'utiliser comme il veut les données collectées. Il n'est
pas conforme au RGPD concernant les visiteurs du site. Que dire aussi de
leur appli mobile: j'ai plus confiance en celle de la Croix-Rouge française
(bien plus connue aussi et plus complète, téléchargée par près de 5
millions de français, et c'est déjà pas si mal même si cette appli peut
être améliorée en terme d'accessibilité).

Que dire aussi de l'appli mobile Sop-Coviv du gouvernement: c'est déjà dur
à trouver, elle est franchement pas simple à installer (quoi qu'en disent
Googgle et Apple sur leurs stores), elle bouffe énormément de batterie (il
faut la désactiver si on veut recharger son téléphone) et elle n'apporte
presque aucun service: quitte à la laisser allumée, autant que ce soit
intégré dans l'appli de la Croix-Rouge (avec les mêmes APIs développées en
commun par Google et Apple, une API sensée être ouverte et que ces OS
devraient optimiser un peu mieux: l'appli ou l'API commune bouffe plus
qu'une connexion Bluetooth à son autoradio ou à une oreillette sans fil)

>
> N'importe qui peut déclarer un DAE :
> https://sauvlife.fr/declarer-un-defibrillateur/
>
> Après, qui vérifie et comment, mystère ?
>
>
> Philips fabrique aussi des DAE et vend une prestation pour référencer des
> DAE à la place des exploitants :
> https://dae.philips.fr/services-philips/localisation-defibrillateur
>
> "La prestation de « Géolocalisation d’un DAE » de Philips permet de
> collecter et d’enregistrer les données d’un défibrillateur dans 1 ou 2
> bases de données que vous choisissez, pour votre compte."
>
> Ils parlent de GeoDAE, de AEDMAP, de Sauv life ?
>
>
> En quoi aussi l'asso SauvLife aurait plus d'habilitations qu'OSM
>
>
>
>- Elle est dirigée par des médecins urgentistes ;)
>- Elle a un partenariat avec des SAMU.
>- N'importe qui peut modifier les données OSM, ça ne doit pas rassurer
>:D
>
>
>
> GeoDAE peut-il alors accepter les contributions d'OSM si on arrive à les
> qualifier
>
>
> Bonne question.
>
>
> Même s'ils remontent des infos à GeoDAE;
>
>
> Est-ce que c'est bien le cas ?
>
>
> __
> 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] La gestion des poteaux

[Philippe Verdy]

Le jeu. 3 sept. 2020 à 20:48, Francois Gouget  a écrit :

> On Thu, 3 Sep 2020, Philippe Verdy wrote:
>
> > la puissance transportée,
>
> La puissance transportée dépend de si le sèche-cheveux est allumé ou
> éteint.
>

Je voulait dire en capacité maximale (donc "transportable" plus que
"transportée" à un instant T: ca dépend des câbles, des isolateurs, du
champ électrique (tension/écartement et un facteur dépendant du nombre de
phases ou du différentiel avec la terre ou des écarts de puissance acceptés
entre les phases, et les tolérances sur le déphasage dépendant de la
puissance sur de chaque circuit et des points de consommation), de la
capacité aussi des transformateurs (et leur refroidissement) et ce qui est
toléré par les coupe-circuits près des postes de transformation et de
distribution ou des transfos relais (même sans changement de tension).
C'est à cause de ça que les porteurs sont aussi différents en taille et en
hauteur.

>
> > le nombre de câbles,
>
> 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. Ca dépend beaucoup du fond (y compris la
saison), et de la précision et l'éclairage des photos. On peut parfois
devenir sur certains poteaux ou segments, mais ça se complique vite
quand il y a des ramifications (et on ne voit pas bien toutes les
ramifications du réseau mineur). Et de toute façon pas moyen de deviner les
tensions transportées et le mode (nombre de phases ou continu à certains
endroits)

Les transfos sont également pas faciles à voir (et pas toujours montés en
haut des poteaux, j'en ai vu à plusieurs centaines de mètres du dernier
poteau quand la ligne passe sous-terre et ce transfo est souvent caché dans
la végétation ou dans des constructions agricoles ou industrielles ou
parfois enterré sous une trappe difficile à voir (ou dans une armoire
difficile à distinguer d'une armoire télécoms; ces transfos de distribution
ne sont souvent pas bien grands et sur l'imagerie aérienne on ne peut même
pas savoir que c'en est ou si c'est un engin agricole, un puits.)

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.

Sinon si j'ai des doutes, tant pis je ne relie pas: ces segments
déconnectés seront détectés et joints plus tard quand on aura plus de
données, mais ça indique justement le lieu où on a un manque d'information
et ça guide ensuite l'exploration au sol pus tard en fixant des objectifs à
voir auxquels on ne penserait pas.


> > la hauteur des poteaux ou leur nature (bois ou métallique)
>
> Ou béton. Ça on peut le voir sur les photos Mapillary / OpenStreetCam
> quand il y en a. Je me demande si c'est une caractéristique régionale ou
> si c'est une question d'époque.
>

 Oui aussi. Les poteaux en bois sont sans doute plus courants dans les
régions forestières. L'alu coûte cher et pas forcément non plus plus
résistant dans les régions venteuses ou pas accepté dans certains
secteurs protégés (en plus les poteaux en alu doivent être "chapeautés"
mais les chapeaux en plastique ne résistent souvent pas longtemp).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Francois Gouget]

On Thu, 3 Sep 2020, Philippe Verdy wrote:

> Note: avec l'imagerie haute résolution on commence à bien voir les poteaux
> et lignes électriques mineures (notamment en milieu rural ou périurbain à
> travers les champs pour relier les hameaux ou certaines zones
> industrielles).

Je confirme. En campagne on les voit très bien et on peut cartographier 
au moins 80% des lignes. Là où il y a des difficultés les photos 
Mapillary / OpenStreetCam peuvent dépanner.

https://www.openstreetmap.org/edit?node=1676592637#map=19/45.88764/-0.00136

En ville les lignes sont enterrées alors forcément c'est plus difficile 
de les repérer sur les vues aériennes.


> Que fait-on de ces lignes mineures ? on continue à les cartographier (comme
> on peut) ou on attend des données ouvertes d'un exploitant pour avoir
> d'autres infos comme les tensions, 

La plupart du temps on trouve un transformateur Enedis à un bout de la 
ligne ce qui permet par continuité de qualifier tout ce qui y est 
connecté.

D'ailleurs Osmose constitue un bon point de départ. Il sufit de choisir 
un transformateur manquant en rase campagne. 
https://osmose.openstreetmap.fr/fr/map/?#zoom=16&lat=45.77269&lon=-0.54326&item=8280

Il se trouvera en haut d'un poteau qu'on pourra ajouter. Ensuite si 
l'image est bonne et que le fond s'y prête on sait tout de suite dans 
quelle direction chercher le suivant. Sinon il faut chercher un peu, 
s'aider des trouées dans les forêt, etc. Ensuite il n'y a plus qu'à 
dérouler la pelote de laine. Quand elle s'éfiloche on recommence avec un 
autre transformateur pas loin. Et à la fin, miracle, on se retrouve avec 
un plat de spaghetti !

https://openinframap.org/#11.46/45.9534/0.7541


> la puissance transportée,

La puissance transportée dépend de si le sèche-cheveux est allumé ou 
éteint.

> le nombre de câbles,

Le nombre de cables se voit sur les photos aériennes.

> la hauteur des poteaux ou leur nature (bois ou métallique)

Ou béton. Ça on peut le voir sur les photos Mapillary / OpenStreetCam 
quand il y en a. Je me demande si c'est une caractéristique régionale ou 
si c'est une question d'époque.

Sur les photos aériennes on repèrera aussi les power=portal.


-- 
Francois Gouget   http://fgouget.free.fr/
question = ( to ) ? be : ! be;
  -- Wm. Shakespeare___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [SDIS/SAMU] Projet du mois défibrillateurs

[Yves P.]

> aucune donnée publique. pourtant ils invitent à déclarer les DAE par eux

Comme Staying alive / AED-Map ;)

A la différence près que ces données sont publiées dans data.gouv.fr 



> SauvLife ne traite que les agences publiques, il n'a forcément pas tous les 
> DAE concernés par ces déclarations).

D'où tiens-tu cette information ?

N'importe qui peut déclarer un DAE : 
https://sauvlife.fr/declarer-un-defibrillateur/

Après, qui vérifie et comment, mystère ?


Philips fabrique aussi des DAE et vend une prestation pour référencer des DAE à 
la place des exploitants :
https://dae.philips.fr/services-philips/localisation-defibrillateur

"La prestation de « Géolocalisation d’un DAE » de Philips permet de collecter 
et d’enregistrer les données d’un défibrillateur dans 1 ou 2 bases de données 
que vous choisissez, pour votre compte."

Ils parlent de GeoDAE, de AEDMAP, de Sauv life ?


> En quoi aussi l'asso SauvLife aurait plus d'habilitations qu'OSM

Elle est dirigée par des médecins urgentistes ;)
Elle a un partenariat avec des SAMU.
N'importe qui peut modifier les données OSM, ça ne doit pas rassurer :D


> GeoDAE peut-il alors accepter les contributions d'OSM si on arrive à les 
> qualifier

Bonne question.


> Même s'ils remontent des infos à GeoDAE;

Est-ce que c'est bien le cas ?


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

Re: [OSM-talk-fr] [SDIS/SAMU] Projet du mois défibrillateurs

[Philippe Verdy]

Oui on a une carte avec juste les départements des SAMU concernés pour
l'instant (et les quelques autres assos partenaires). Ils annoncent que
cela concernera bientôt tous les départements, mais aucune donnée publique.
pourtant ils invitent à déclarer les DAE par eux (en espérant que ça
remonte plus tard dans le geoDAE publié, mais comme SauvLife ne traite que
les agences publiques, il n'a forcément pas tous les DAE concernés par ces
déclarations).

Donc cela fait un tiers de plus (un autre asso qui agit comme
intermédiaire), mais ça ajoute aussi du retard (et de possibles erreurs
d'intégration). En quoi aussi l'asso SauvLife aurait plus d'habilitations
qu'OSM, le fait que ses membres ne sont que des organisations publiques ou
reconnues ? GeoDAE peut-il alors accepter les contributions d'OSM si on
arrive à les qualifier mieux que ces déclarations approximatives qu'on voit
dans le GeoDAE (et qui sans doute sont passées dans les mains de
SauvLife qui na pas du faire grand chose de plus pour les qualifier si ce
n'est fournir la plateforme technique et un espace d'échange) ?

Même s'ils remontent des infos à GeoDAE; je ne vois pas ce qui les empêche
de publier les données de déclarations obligatoires qu'ils collectent, ces
données étant normalement destinées à être publiques.


Le jeu. 3 sept. 2020 à 20:03, Yves P.  a écrit :

> Et ça n'a pas manqué : mon SAMU contacté au téléphone aujourd'hui m'a
> *immédiatement* renvoyé à Sav'Life :(
>
> https://sauvlife.fr/carte-du-deploiement/
>
> J'ai tout de même envoyé un mail de prise de contact.
>
> Merci de nous éclairer si tu as une réponse :)
>
> __
> 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] [SDIS/SAMU] Projet du mois défibrillateurs

[Yves P.]

> Et ça n'a pas manqué : mon SAMU contacté au téléphone aujourd'hui m'a 
> *immédiatement* renvoyé à Sav'Life :(
https://sauvlife.fr/carte-du-deploiement/

> J'ai tout de même envoyé un mail de prise de contact.
Merci de nous éclairer si tu as une réponse :)

__
Yves



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

Re: [OSM-talk-fr] uMap, SILL et Wikidata

[Philippe Verdy]

Note: je n'ai pas indiqué la compatibilité avec les OS supportés (OK il y a
Linux, mais pour le détail des distribs ou formats de package, il vaut
mieux que ce soit les auteurs et mainteneurs qui précisent ça; je ne sais
pas si ça a été testé/utilisé/adapté à d'autres OS car c'est un logiciel
serveur, indépendant des OS des clients web; il peut aussi y avoir des
clients spécifiques pour certains OS mobiles, développés séparément ou
maintenus par les installateurs d'autres instances que l'instance française
"par défaut")

Le jeu. 3 sept. 2020 à 19:40, Philippe Verdy  a écrit :

> Pour Wikidata, j'ai ajouté quelques propriétés (y compris  en français et
> anglais) avec les liens les plus utiles.
>
> https://www.wikidata.org/wiki/Q28502462
>
> Il n'y a pas de page Wikipédia en français je pense, je n'ai vu que
> l'espagnol. Mais les liens sur le wiki OSM (français et anglais) y sont (en
> tant que "documentation"). J'ai ajouté les langages de programmation, les
> autres outils essentiels dont uMap dépend, les infos de licence et d'auteur
> plus complètes
>
> Le mar. 1 sept. 2020 à 08:55, Cédric Frayssinet  a
> écrit :
>
>> Bonjour à tous,
>>
>> Cet été, j'ai découvert que uMap avait été introduit au SILL qui est une
>> référence pour les collectivités (mais pas que) :
>> https://fr.wikipedia.org/wiki/Socle_interminist%C3%A9riel_de_logiciels_libres
>>
>> Et j'ai fait remarqué à Bastien Gerry que la fiche était très
>> approximative : https://sill.etalab.gouv.fr/fr/software?id=150
>>
>> Il m'a donc répondu qu'il fallait compléter la fiche wikidata comme celle
>> de Gimp : https://www.wikidata.org/wiki/Q8038. Cela tombe bien car il
>> semblerait qu'elle ait été amorcée en espagnol :
>> https://www.wikidata.org/wiki/Q28502462
>>
>> Le code source du SILL est également ici :
>> https://github.com/DISIC/sill/blob/master/2020/sill-2020.csv
>>
>> J'appelle donc à l'aide. Si certains d'entre vous sont à l'aise avec
>> GitHub et WikiData, je pense que ce serait bienvenue d'améliorer cette
>> fiche :)
>>
>> Merci à la communauté,
>>
>> Cédric
>> --
>>
>> Sur Mastodon : @bristow...@framapiaf.org
>> 
>>
>> [image: Promouvoir et soutenir le logiciel libre] 
>> ___
>> 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] uMap, SILL et Wikidata

[Philippe Verdy]

Pour Wikidata, j'ai ajouté quelques propriétés (y compris  en français et
anglais) avec les liens les plus utiles.

https://www.wikidata.org/wiki/Q28502462

Il n'y a pas de page Wikipédia en français je pense, je n'ai vu que
l'espagnol. Mais les liens sur le wiki OSM (français et anglais) y sont (en
tant que "documentation"). J'ai ajouté les langages de programmation, les
autres outils essentiels dont uMap dépend, les infos de licence et d'auteur
plus complètes

Le mar. 1 sept. 2020 à 08:55, Cédric Frayssinet  a
écrit :

> Bonjour à tous,
>
> Cet été, j'ai découvert que uMap avait été introduit au SILL qui est une
> référence pour les collectivités (mais pas que) :
> https://fr.wikipedia.org/wiki/Socle_interminist%C3%A9riel_de_logiciels_libres
>
> Et j'ai fait remarqué à Bastien Gerry que la fiche était très
> approximative : https://sill.etalab.gouv.fr/fr/software?id=150
>
> Il m'a donc répondu qu'il fallait compléter la fiche wikidata comme celle
> de Gimp : https://www.wikidata.org/wiki/Q8038. Cela tombe bien car il
> semblerait qu'elle ait été amorcée en espagnol :
> https://www.wikidata.org/wiki/Q28502462
>
> Le code source du SILL est également ici :
> https://github.com/DISIC/sill/blob/master/2020/sill-2020.csv
>
> J'appelle donc à l'aide. Si certains d'entre vous sont à l'aise avec
> GitHub et WikiData, je pense que ce serait bienvenue d'améliorer cette
> fiche :)
>
> Merci à la communauté,
>
> Cédric
> --
>
> Sur Mastodon : @bristow...@framapiaf.org
> 
>
> [image: Promouvoir et soutenir le logiciel libre] 
> ___
> 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] [SDIS/SAMU] Projet du mois défibrillateurs

[Jacques Lavignotte]

Le 03/09/2020 à 18:08, Philippe Verdy a écrit :



Le mer. 2 sept. 2020 à 18:19, Jacques Lavignotte 



   (c'est le SAMU qui a et ça n'a pas été ouvert). 



Le SAMU n'étant pas forcément l'exploitant


Ce n'est pas tant qu'exploitant que mentionnais le SAMU mais comme 
partenaire de programmes utilisant les DAE.


Et ça n'a pas manqué : mon SAMU contacté au téléphone aujourd'hui m'a 
*immédiatement* renvoyé à Sav'Life :(

J'ai tout de même envoyé un mail de prise de contact.

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] La gestion des poteaux

[Philippe Verdy]

Note: avec l'imagerie haute résolution on commence à bien voir les poteaux
et lignes électriques mineures (notamment en milieu rural ou périurbain à
travers les champs pour relier les hameaux ou certaines zones
industrielles).

Cependant beaucoup sont partielles et si on peut tracer ce qu'on voit il
est difficile de les qualifier et les relier au reste du réseau (d'autant
plus que souvent il y a des sections enterrées, et autour des
transformateurs pas facile à localiser et pas toujours très près du dernier
poteau). On ne voit pas ce réseau enterré (qui se développe surtout près
des habitations ou zones d'activités).

Il y a des kilomètres de ces lignes mineures un peu partout (et souvent en
milieu rural en plaine, où a eu lieu un très fort remembrement, c'est
presque le seul élément facilement repérable pour distinguer les champs et
chemins quand il n'y a pas de rivière ni de bois visibles et quand les
champs ou chemins agricoles ou petites routes se ressemblent tous)

Que fait-on de ces lignes mineures ? on continue à les cartographier (comme
on peut) ou on attend des données ouvertes d'un exploitant pour avoir
d'autres infos comme les tensions, la puissance transportée, le nombre
de câbles, la hauteur des poteaux ou leur nature (bois ou métallique) et
d'autres équipements annexes (par exemple pour éviter de laisser un sommet
ouvert sans chapeau où les oiseaux qui y tombent ou s'y réfugient ne
peuvent plus ressortir, ou encore si ces poteaux sont également porteurs
d'antennes ou portent aussi le transformateur ou le coupe-circuit) ou
encore s'ils sont toujours en service: ( on voit facilement les poteaux
mais mois facilement les câbles, car il reste des poteaux qui ne portent
plus rien mais sont restés en place et peuvent servir à autre chose, comme
support de clôtures par exemple) ?


Le jeu. 3 sept. 2020 à 18:04, François Lacombe 
a écrit :

> Salut à tous
>
> L'été a permis d'avancer certains projets pour pas mal de monde à ce que
> j'ai vu, y compris les projets du mois :p
>
> Suite aux développements de ces deux derniers mois, j'ai mis à disposition
> aujourd'hui un rendu pour montrer tous les poteaux électriques et telecom
> qu'on pouvait avoir dans OSM en France.
> www.gespot.fr
>
> Le sujet passionne en ce moment pour le déploiement de la fibre et
> plusieurs exploitants sont intéressés par ce que la contribution OSM a déjà
> produit.
> Exemple : http://gespot.fr/#14.84/46.04506/6.13543
>
> Un peu de documentation sur le sujet :
> https://common.infos-reseaux.com/files/telco/gespot.pdf
> @Zimmy : je vais essayer d'en reverser une partie dans les thématiques de
> GéOSM.
>
> Une proposition est en cours d'écriture pour finaliser l'approbation de
> man_made=utility_pole (tous les poteaux sauf électriques qui sont avec
> power=pole)
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Utility_poles_proposal
> (pas encore traduite)
>
> C'est dores et déjà utile de compléter les power=pole du réseau de
> distribution avec operator=Enedis (dans les communes appropriées
> https://dataviz.agenceore.fr/distributeurs-energie-france/) ou d'ajouter
> les poteaux Orange de vos environs avec man_made=utility_pole +
> utility=telecom + operator=Orange
>
> A suivre pour la suite des événements, bonne soirée
>
> François
> ___
> 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] [SDIS/SAMU] Projet du mois défibrillateurs

[Philippe Verdy]

Le mer. 2 sept. 2020 à 18:19, Jacques Lavignotte  a
écrit :

>
>
> Le 02/09/2020 à 15:05, PanierAvide a écrit :
> > Bonjour,
> >
> > C'est à tenter, de préférence par les contacts locaux.
>
> C'est le S(D)IS (D comme département) 86 Je sais qu'ils ont une liste et
> un système de cartographie.
>
>   De mon côté j'ai
> > fait les 4 SDIS de Bretagne, deux toujours en attente et les deux autres
> > n'avaient pas
>
> Pas de recencement des DAE ?
>
>   (c'est le SAMU qui a et ça n'a pas été ouvert).


Le SAMU n'étant pas forcément l'exploitant à qui on impose l'installation
et la déclaration, je ne pense pas que la loi prévois l'obligation des SAMU
à déclarer leurs propres données qui ne sont éventuellement que des
constatations sur le terrain, mais pas nécessairement suivies (par exemple
en cas de changement d'exploitant ou d'usage des lieux, il peut ne plus y
en avoir puisq'uil n'y a plus d'obligation et que l'obligation entraine un
coût de gestion, notamment signer un nouveau contrat d'entretien)

Dans ce cas, le SAMU est dans la même situation qu'OSM lui-même: c'est une
base indicative, pas soumise aux mêmes contraintes légales (notamment en
terme de délai de publication, ou de remise à jour imposée).

Je me demande d'ailleurs quel est le régime légal des mises à jour (quand
elles sont demandées et avec quels délais, ou s'il y a aussi obligation de
déclaration rapide des appareils hors services et des délais imposés pour
les remises en état et les garanties que les exploitants doivent pouvoir
attendre des sociétés de maintenance, et à quel rythme ce sera contrôlé)

Je suppose que ça peut se limiter à une déclaration au mieux tous les ans
masi que GeoDAE a des infos qui déjà date de plusieurs années et plus du
tout à jour, ou partielles: un seule DAE déclaré par l'exploitant même s'il
y en a plusieurs sur des sites un peu importants ou des exploitants sur
plusieurs sites d'une même ville qui peuvent être éloignés de
plusieurs kilomètres en tenant compte aussi des accès publics s'il faut
faire un grand détour autour du site, mais avec un seul siège: pour ceux
qui sont habilités à entrer à l'intérieur, ces sites peuvent sembler très
proches et n'être déclarés qu'une seule fois, leur accès ne se faisant pas
par ces grands détours).

Les textes à ce sujet sont encore récents, le système commence à peine à se
déployer, il y a encore plein d'expérimetnation, on est juste ne phase de
montée en charge et la réglementation va s'affiner en fonction des
résultats ou expérimentations ou en cas d'abus trop faciles ou trop de
défaillances dans le fonctionnemetn ou d'inefficacité (si au final cela ne
dépend toujours que de l'équipement des véhicules et personnels de secours
d'urgence et de leurs délais d'intervention).

D'ailleurs on voit les limites des déclarations actuelles: elles sont peu
précises et ce n'est pas évident que cela aide réellement le public visé,
c'est à dire presque tout le monde (même un grand nombre de mineurs et
aussi les touristes et migrants qui n'ont pas forcément à comprendre notre
langue et notre réglementation) et pas juste des spécialistes ou des
professionnels de la sécurité ou des cartographes expérimentés.

En France quand même ce public a trois types de contacts :
- (1) la police/gendarmerie (et maintenant aussi les agents de sécurité
privés depuis la loi récente de "sécurité globale" votée cette année
transférant pas mal de fonction de la police publique vers le
secteur privé, notamment les sociétés de vigiles ou les agents internes ou
externes missionnés par les sociétés de transport),
- (2) la sécurité civile/les pompiers/les SDIS,
- (3) le SAMU/15 et les services hospitaliers (qui sont les plus sollicités)

Et une unification surtout autour du 112 (conformément aux règles
européennes): peut-être qu'il faut coordonner aussi ces 3 secteurs autour
de ceux qui s'occupe en France de la gestion du 112 européen.
GeoDAE restera un test à intégrer dans une politique plus large et la
législation devra revoir les obligations propres à chacun des 3 secteurs
(plus le dernier secteur autres exploitants soumis à exploitation, dont les
grosses entreprises au delà d'un seuil d'employés, ou celles installées sur
des sites privés de taille importante, celles déjà déclarées comme
dangereuses comme les sites industriels, les installations de production
électrique, les grand chantiers de construction ou de démolition, la
restauration, les hôtels, les parcs de loisir, les écoles, universités,
salles de sport publiques et privées, gares et hubs de transport, les
salles de spectacle, les événements temporaires comme les foires ou les
autres rassemblements, et pourquoi pas même les organisateurs de grandes
manifestations à déclaration obligatoire, qu'elles soient festives,
culturelles, sportives, syndicales, politiques, hors des murs
habituellement dédiés à ces usages et qui sont déjà soumises à des
obligations de sécurité et d'assistance aux personnes).

Et puis il y a l'équipement mobile en plus des emplaceme

[OSM-talk-fr] La gestion des poteaux

[François Lacombe]

Salut à tous

L'été a permis d'avancer certains projets pour pas mal de monde à ce que
j'ai vu, y compris les projets du mois :p

Suite aux développements de ces deux derniers mois, j'ai mis à disposition
aujourd'hui un rendu pour montrer tous les poteaux électriques et telecom
qu'on pouvait avoir dans OSM en France.
www.gespot.fr

Le sujet passionne en ce moment pour le déploiement de la fibre et
plusieurs exploitants sont intéressés par ce que la contribution OSM a déjà
produit.
Exemple : http://gespot.fr/#14.84/46.04506/6.13543

Un peu de documentation sur le sujet :
https://common.infos-reseaux.com/files/telco/gespot.pdf
@Zimmy : je vais essayer d'en reverser une partie dans les thématiques de
GéOSM.

Une proposition est en cours d'écriture pour finaliser l'approbation de
man_made=utility_pole (tous les poteaux sauf électriques qui sont avec
power=pole)
https://wiki.openstreetmap.org/wiki/Proposed_features/Utility_poles_proposal
(pas encore traduite)

C'est dores et déjà utile de compléter les power=pole du réseau de
distribution avec operator=Enedis (dans les communes appropriées
https://dataviz.agenceore.fr/distributeurs-energie-france/) ou d'ajouter
les poteaux Orange de vos environs avec man_made=utility_pole +
utility=telecom + operator=Orange

A suivre pour la suite des événements, bonne soirée

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

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

[Rpnpif via Talk-fr]

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

Quel intérêt de rappeler un doublon désuet ?

Sauf à rappeler que c'est doublon désuet.


maxspeed:type désuet ? La page de wiki de source:maxspeed a été créée en 
2009, celle de maxspeed:type en 2011.


C'est vrai que source:maxspeed est le plus utilisé avec 1,6 millions de 
valeurs alors que maxspeed:type en a 378000 ce qui n'est pas ridicule.


Je connais la discussion sur ce sujet mais pour être exhaustif, il 
fallait citer les deux. D'ailleurs c'est ce que fait la page en anglais 
du wiki sans prendre parti.


Personnellement, j'ai un léger faible pour maxspeed:type car ce n'est 
pas véritablement une source mais plutôt une référence remplaçable par 
une valeur. Les applications qui utilisent la carte, n'utilisent que 
rarement les attributs source:* alors que la valeur FR:urban peut être 
remplacée par une vitesse.

Cela n'a rien a voir avec source=cadastre ou autre.

Mais je ne suis pas intégriste de cet attribut mais je pense qu'il faut 
laisser le choix vu le nombre d'utilisation.


--
Rpnpif

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

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

[osm . sanspourriel]

Quel intérêt de rappeler un doublon désuet ?

Sauf à rappeler que c'est doublon désuet.

Jean-Yvon

Le 03/09/2020 à 16:30, Rpnpif via Talk-fr - talk-fr@openstreetmap.org a
écrit :

Bonjour,

Le 03/09/2020 à 03:38, Marc Mongenet a écrit :

Le mer. 2 sept. 2020 à 01:16, Yannick  a écrit :

L'implicite est désormais quasi impossible à deviner.
Je suis donc partisan de mettre systématiquement le maxspeed=* au
moins c'est clairement renseigné sans équivoque possible.

Oui l'implicite est difficile à maîtriser. Mais le problème que j'ai
rencontré, et je pense qu'il est répandu, c'est que les mappeurs ne
connaissent pas suffisamment bien le code de la route pour expliciter
correctement l'implicite! D'ailleurs, en relisant les textes
réglementaires avant de poster, je me suis rendu compte que je ne suis
pas tout à fait au clair moi-même.

Ainsi, je pense que
https://wiki.openstreetmap.org/wiki/FR:Key:maxspeed#Limitation_de_vitesse

se trompe en écrivant:


Et comme ce serait trop simple, je rappelle qu'il existe aussi
maxspeed:type comme synonyme de source:maxspeed. Le premier est oublié
sur le wiki en français.




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

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

[Rpnpif via Talk-fr]

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
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Rpnpif via Talk-fr]

Bonjour,

Le 03/09/2020 à 03:38, Marc Mongenet a écrit :

Le mer. 2 sept. 2020 à 01:16, Yannick  a écrit :

L'implicite est désormais quasi impossible à deviner.
Je suis donc partisan de mettre systématiquement le maxspeed=* au
moins c'est clairement renseigné sans équivoque possible.

Oui l'implicite est difficile à maîtriser. Mais le problème que j'ai
rencontré, et je pense qu'il est répandu, c'est que les mappeurs ne
connaissent pas suffisamment bien le code de la route pour expliciter
correctement l'implicite! D'ailleurs, en relisant les textes
réglementaires avant de poster, je me suis rendu compte que je ne suis
pas tout à fait au clair moi-même.

Ainsi, je pense que
https://wiki.openstreetmap.org/wiki/FR:Key:maxspeed#Limitation_de_vitesse
se trompe en écrivant:


Et comme ce serait trop simple, je rappelle qu'il existe aussi 
maxspeed:type comme synonyme de source:maxspeed. Le premier est oublié 
sur le wiki en français.


--
Rpnpif

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

Re: [OSM-talk-fr] Zaclys

[Jacques Lavignotte]

Le 03/09/2020 à 15:17, Vincent Bergeot a écrit :

Le 03/09/2020 à 15:09, pepilepi...@ovh.fr a écrit :

Et juste pour ma culture : c'est qui, Zacklys ?


un chaton, fournisseur de services web https://www.zaclys.com/ (un bel 
exemple autour de nextcloud avec nombreux serveurs et du mail)


+111


Vincent Bergeot


Jacques

--
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] Rond point et relations routes

[Philippe Verdy]

Seulement les arrêts c'est ingérable, on obtient un nuage de points, et
l'ordre en plus n'est pas garanti (pas moyen de le manipuler dans iD par
exemple, un point défusionné et recréé à côté sera systémqtiquement mis en
fin de liste. Donc à moins de numéroter les arrêts dans l'ordre... On se
retrouve dans la même situation qu'un nuage de points pour les services à
la demande (sans aucun itinéraire ni aucun temps de parcours calculable ou
prévisible, même avec une marge d'erreur).

Les itinéraires sont utiles (même s'il passent par des ronds-points non
découpés, ce qui ne change que quelques secondes au cas où un
itinéraire voudrait faire la boule entière et un peu plus, ce qui est
rarement le cas sauf pour faire demi-tour sur une branche: là aussi le
nuage de point ne détecte pas ce cas, et va minorer le temps de trajet ou
calculer n'importe quoi) ou du cas de l'arrêt sur le rond-point lui-même
nécessitant d'en faire le tour complet ou un peu plus pour le desservir).

De toute façon tous les itinéraires ont une petite marge de variation de
trajet (travaux avec déviations) ou de temps de parcours (pour les bus cela
peut monter à quelques minutes en service normal). On a souvent des arrêts
déplacés (le plus souvent signalés car prévus à l'avance, sauf cas spécial
comme un accident, une manif ou une affluence inhabituelle, les causes
festives étant cependant souvent organisées à l'avance par l'autorité
publique et signalées): un rond-point gardé entier ne change rien de façon
significative par rapport aux aléas de conditions de circulation et
d'affluence variable dans les bus. Et ça vaut aussi pour les trajets en
véhicule particulier ou en taxi ou auto-partage (là aussi une variabilité
de l'ordre du quart d'heure pour nombre de trajets, sauf desserte
très locale pour quelques kilomètres au plus où ça descend un peu, et les
trajets très longs passant par les grandes infrastructures routières, mais
il peut arriver sur ces trajets de plus de 200 km des retards atteignant
facilement l'heure sur des points de congestion urbains: là encore les
ronds-points sont insignifiants et en cas de congestion il y a des
itinéraires "bis" qui éventuellement peuvent faire gagner un peu de temps
ou en perdre mais là souvent les conducteurs n'ont pas trop le choix).

Pour les trajets à pied c'est très indicatif, chacun marche comme il veut à
la vitesse qu'il veut, et fait autant d'arrêt qu'il veut selon ses envies
ou sa condition. Même chose pour les trajets cyclistes.

En pratique, quand on prend un bus ou un car, on a besoin de ces
itinéraires ordonnés pour savoir quand descendre et demander les arrêts
suivants (bouton de signalement au chauffeur) et se repérer sur le parcours
(sauf cas des lignes directes où on n'a pas besoin de surveiller) et savoir
que l'arrêt suivant du parcours habituel est desservi ou pas (de nombreuses
lignes ont des variante de parcours: il faut savoir quel bus prendre et
repérer s'il vaut mieux attendre le suivant, en s'aidant des fiches
horaires).

Mettre les itinéraires permet de reconstituer l'ordre des arrêts, faire les
diagrammes, construire des fiches horaires et les rendre lisibles et à
chacun de pouvoir avoir une bonne idée de la variabilité du temps de
parcours. Et pour certaines lignes il est même possible de demander des
arrêts à la demande le long du parcours sur des arrêts facultatifs mais
disposant d'emplacements adéquats (ce cas est courant en milieu très rural
où les arrêts signalés sont très distants entre eux) ; ça dépend des règles
de chaque réseau et ce que le chauffeur a le droit de faire selon sa
compagnie, mais aussi de la politesse et de la conduite pour cette demande,
ainsi que de l'affluence dans les bus: si le bus est déjà en trop en retard
et a du monde, les autres passagers ont aussi un avis important : c'est un
règlement social implicite (et on ne peut pas obliger un chauffeur à sortir
non plus des règles du code de la route et accélérer ou faire une
manœuvre dangereuse selon son jugement où il a l'autorité et une
responsabilité pénale et civile vis à vis de ses passagers, sa compagnie,
et les autres usagers de la voie publique).

Si on commence à ne plus mettre les trajets et juste les arrêts, alors
autant ne plus rien mettre dans OSM et laisser ça aux cartes et
applications des sociétés de transport et leurs fiches horaires (pas
toujours très lisibles).

Le mer. 2 sept. 2020 à 20:26, Gad.Jo  a écrit :

> Dans un monde parfait mettre uniquement les arrêts serait nickel mais cela
> prive les usagers du tracé.
>
> Dans l'agglo où je vie à part des pdf inexploitable sur un smartphone il
> n'y a aucun plan du réseau. En sus la majorité des plans pdf ne sont pas
> orienté dans le sens nord sud. Cela rend complexe la compréhension de leur
> plan.
>
> Peut être que dans les années à venir seul les arrêts seront suffisant +
> les nœuds où passe la ligne pour lever toute ambiguïté quand le bus
> emprunte non pas la route la plus logique mais celle décidé par la régie de
> transpor

Re: [OSM-talk-fr] test n° 3 depuis Thunderbird

[Vincent Bergeot]

Le 03/09/2020 à 15:09, pepilepi...@ovh.fr a écrit :

Et juste pour ma culture : c'est qui, Zacklys ?


un chaton, fournisseur de services web https://www.zaclys.com/ (un bel 
exemple autour de nextcloud avec nombreux serveurs et du mail)


à plus

--
Vincent Bergeot

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

Re: [OSM-talk-fr] test n° 3 depuis Thunderbird

[roptat]

Idem, pas de n°2 ici. Pourtant j'ai mon propre serveur et il est plutôt laxiste 
sur ce qu'il laisse entrer (je bloque seulement une poigné d'expéditeurs, pas 
de filtrage pour les spam, …).

Le 3 septembre 2020 09:09:59 GMT-04:00, "pepilepi...@ovh.fr" 
 a écrit :
>Le 02/09/2020 à 21:54, Georges Dutreix via Talk-fr a écrit :
>> Dernier test depuis mon ordinateur.
>> Merci de me signaler si vous avez eu ce mail en indésirable. Sinon
>> vous pouvez le jeter :-)
>>
>> C'est fini, je ne vous embête plus.
>
>
>Bonjour (re),
>
>Comme d'autres je n'ai pas reçu de N° 2.
>
>Et juste pour ma culture : c'est qui, Zacklys ?
>
>Bonne journée,
>
>JP
>
>
>>
>> Merci beaucoup.
>> Georges
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
>-- 
>
>
>Si ma réponse n'a pas résolu ton problème, c'est que tu n'as pas posé
>la
>bonne question.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] test n° 3 depuis Thunderbird

[pepilepi...@ovh.fr]

Le 02/09/2020 à 21:54, Georges Dutreix via Talk-fr a écrit :
> Dernier test depuis mon ordinateur.
> Merci de me signaler si vous avez eu ce mail en indésirable. Sinon
> vous pouvez le jeter :-)
>
> C'est fini, je ne vous embête plus.


Bonjour (re),

Comme d'autres je n'ai pas reçu de N° 2.

Et juste pour ma culture : c'est qui, Zacklys ?

Bonne journée,

JP


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


-- 


Si ma réponse n'a pas résolu ton problème, c'est que tu n'as pas posé la
bonne question.

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

[osm . sanspourriel]

Correction de ma réponse.


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


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


En fait c'est building=roof.

Sinon la réponse reste la même.

Jean-Yvon


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

[Julien Lepiller]

Le Thu, 3 Sep 2020 14:20:36 +0200,
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...

C'est pour ça qu'il faudrait regrouper les bouts sous un seul bâtiment
: un `building=*` qui fait le tour de tous les bouts, et passer chaque
bout en building:part, au lieu de building. D'un côté on a un bâtiment
logique, et chaque bout peut coder un nombre d'étage différent, un type
différent, 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).

non, ça ça veut dire qu'il n'y a *pas* de toit :)

C'est plutôt `building=roof`, non ?

> 
> 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] bâtiments composites / fusion de polygones ?

[osm . sanspourriel]

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

Re: [OSM-talk-fr] bâtiments composites / fusion de polygones ?

[draenog]

Merci de vos réponses,

Effectivement sur la photo correspondant à l'exemple que j'avais mis en 
lien, l'avant semble être un porche d'accès à l'entrée et le côté un 
abri (à bois ?). Je n'avais pas non plus pensé aux différences de niveaux.


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


Le bon type pour l'exemple au-dessus serait "toit" ?
code de la quête SC "type de bâtiment" : 
https://github.com/westnordost/StreetComplete/blob/master/app/src/main/java/de/westnordost/streetcomplete/quests/building_type/AddBuildingType.kt#L13
code inventaire/tag SC des bâtiments : 
https://github.com/westnordost/StreetComplete/blob/master/app/src/main/java/de/westnordost/streetcomplete/quests/building_type/BuildingTypes.kt#L56




Le 28/08/2020 à 16:28, Philippe Verdy a écrit :
Les zones claires sont effectivement des parties non complètement 
fermées: on ne les identifie pas forcément sur l'imagerie aérienne quand 
il y a un même toit. Mais c'est considéré comme "à l'extérieur". 
Souvent des porches d'entrée couverts, ou un bout de terrasse couverte 
le long de la maison, parfois avec une véranda partiellement fermée par 
un vitrage ou une grille légère, et en tout cas pas isolé. Cela 
approte juste de l'ombrage ou la protection contre la pluie, de quoi 
rester au sec le temp de s'essuyer les pieds, trouver ses clés, poser un 
sac...


Il n'y a pas forcément de diférence de hauteur. Pour le voir il faut une 
photographie au niveau du sol ou à 45 degrés, mais l'orthophoto 
verticale ne fait pas la distinction.


Ce serait bien d'avoir aussi des images à 45 degrés, mais il y en a peu 
(cela demande une couverture aérienne couteuse, par avion/hélico ou par 
drone, et la surface couverte est forcément plus petite: il faut 
multiplier les jeux d'images sources, la couverture territoriale n'est 
pas aussi bonne qu'en orthophoto verticale.


Si c'est en milieu urbain dense on peut voir les façades de la voie 
publique mais pas les arrières, et on ne voit pas non plus à travers 
murs et haies.


Bref en attendant faire confiance au cadastre "a priori". La seule chose 
à faire concerne plutôt les coupures abitraires qui ne sont visiblement 
pas des porches ou galeries extérieures, tronçonnant des restangle en 
triangles de taille inappropriée pour quoi que ce soit et qu'on ne voit 
même pas dans le cadastre lui-même, je me demande d'où viennet ces 
coupures, qui pourraient venir d'un artefact de l'outil d'improt qui a 
procédé par zones de sélection arbitraire), et sinon réorienter (il y a 
parfois des batiments mal orientés, certains n'existent visiblement plus 
et ont été démolis et voire remplacés par d'autres de taille et position 
très différente).



Le mer. 26 août 2020 à 13:59, roptat > a écrit :


De ce que je vois les trois autres parties n'ont pas les mêmes
attributs : ce sont de bouts "sans murs" (correspond à une zone plus
claire sur le cadastre). En général c'est un balcon, une véranda, un
porche, …

Ce que tu peux peut-être faire c'est créer un bâtiment global, et
passer chaque partie en building:part.

Le 26 août 2020 02:12:30 GMT-04:00, draenog mailto:drae...@harinezumi.fr>> a écrit :

Bonjour,

J'ai commencé à contribuer avec StreetComplete, et pour les quêtes "type
de bâtiment" je tombe assez souvent sur des bâtiments composites suite à
l'import cadastre (ex :https://www.openstreetmap.org/way/64141846  
maison en 4 morceaux). Mais la maison me semble un tout cohérent :

https://wtf.roflcopter.fr/pics/Mb6sQLC6/C9cBjJVm.jpg

Ça ne relève pas de StreetComplete, avec quel outil est-il possible de
fusionner les chemins ?
Et surtout, est-ce que c'est la bonne chose à faire ?


draenog

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] test n° 3 depuis Thunderbird

[pepilepi...@ovh.fr]

Le 02/09/2020 à 21:54, Georges Dutreix via Talk-fr a écrit :
> Dernier test depuis mon ordinateur.
> Merci de me signaler si vous avez eu ce mail en indésirable. Sinon
> vous pouvez le jeter :-)


Bien reçu

JP

>
> C'est fini, je ne vous embête plus.
>
> Merci beaucoup.
> Georges
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr


-- 


Si ma réponse n'a pas résolu ton problème, c'est que tu n'as pas posé la
bonne question.

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

Re: [OSM-talk-fr] Test n°1 compte zaclys

[pepilepi...@ovh.fr]

Le 02/09/2020 à 21:48, Georges Dutreix via Talk-fr a écrit :
> Bonjour à tous,
>
> Je vais être un peu hors sujet et vous prie de me pardonner.
> Plusieurs d'entre vous m'ont signalé que mes mails arrivaient en
> indésirables. Avant d'accuser Zaclys, je voudrais faire quelques
> tests. Trois tests dont celui ci est le premier.
> Mail envoyé depuis FairEmail en changeant l'expéditeur.
>
> Merci beaucoup de me dire si vous avez ce message en indésirable. 

Bonjour,

Bien reçu normalement.

Bonne journée,

JP

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


-- 


Si ma réponse n'a pas résolu ton problème, c'est que tu n'as pas posé la
bonne question.

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