Re: [Talk-at] Gefahr durch Internet-Bergrouten

2020-08-29 Diskussionsfäden Stefan Kopetzky
Grob fahrlässig im juristischen Sinne handelt von Deinen Beispielen nur
einer: Der Nutzer. Niemand ist davon befreit sich "auf Sicht"
fortzubewegen, in den Bergen oder sonstwo.

On 30.08.20 00:05, Robert Grübler wrote:
> Nur Bergwege – markierte und gewartete Steige mit Schwierigkeitsangabe vom 
> Wegeerhalter – sollten in OSM aufgenommen werden. 
> Ungewartete Steige sollten nicht in OSM aufgenommen werden. Vorhandene 
> sollten gelöscht werden. Oder zumindest solange als „Nicht-Wege“ maskiert 
> werden, bis ein etabliertes Tagging dafür existiert.

Das widerspricht fundamental dem Grundsatz zu Mappen "was ist" aka
"ground truth". Gemappt werden sollen Wege, die existieren! Unabhängig
davon, wie sie entstehen oder erhalten werden oder wie offiziell sie
sind. Ich gebe Dir recht, dass man beim Mappen, gerade im Gebirge, den
Schwierigkeitsgrad mit angeben sollte, aber das trifft auch auf viele
andere Informationen zu und es ist bei OSM halt so, dass die Sachen
iterativ gewartet wurden und werden und daher jede Information mit
Vorsicht zu geniessen ist.

LG,
Stefan

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


Re: [Talk-it] [talk:it] Bicycle road all'italiana?

2020-08-29 Diskussionsfäden Andrea Musuruane
Ciao,

On Sat, Aug 29, 2020 at 12:17 AM Volker Schmidt  wrote:

>
> On Fri, 28 Aug 2020 at 15:27, Martin Koppenhoefer 
> wrote:
>
>> penso l’accordo generale prevede di non mappare “lanes” quando le corsie
>> non sono indicate, invece si può usare “width”.
>> Lanes=1 in questo senso sarebbe giusto mettere soltanto quando si tratta
>> di un senso unico, perché altrimenti non ci sarebbero corsie segnate.
>>
>
> Questa affermazione mi sembra essere in conflitto con la prassi e con le
> pagine wiki che ho citato.
> Ammetto che è un po' un casino, ma da nessuna parte ho trovato che lanes=1
> implica senso unico.
>

Se c'è solo una corsia in tutto, come fa a non essere un senso unico?

Ho guardato qualche esempio che riporti e, se sono strade a doppio senso di
circolazione, dovrebbero essere mappate come lanes=2 + lane_markings=no se
hanno i delimitatori di carreggiata, oppure solo con lane_markings=no se
non sono presenti, come tra l'altro riporta la wiki:
https://wiki.openstreetmap.org/wiki/Key:lanes#Examples

Ciao,

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


[Talk-it] Osmf

2020-08-29 Diskussionsfäden Lorenzo Pesci
Iscritto anche io, poi mi spiegate meglio come potrò essere utile, grazie.Ciao Lorenzo Pesci Dear Lorenzo,your active contributor membership for becoming an OSMF member has been approved and processed.___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [Talk-it] [talk:it] Bicycle road all'italiana?

2020-08-29 Diskussionsfäden Volker Schmidt
On Sat, 29 Aug 2020 at 13:25, Martin Koppenhoefer 
wrote:

> sono d‘accordo che ci siano strade che non sono abbastanza larghe per
> avere traffico continuo in due versi, però non sono nemmeno sensi unici. In
> questi casi non ci sono corsie, infatti il nome inglese è single tracked,
> non single-lane.
> Si omette “lanes” (diceva la maggioranza sulla lista tagging).
>
Martin, non è così. Una "single-track road" (UK) o "one-lane road"  (USA),
termini equivalenti secondo Wikipedia, sono spesso vere e proprie strade a
una corsia, utilizzati con due sensi di traffico. Sono comuni nel Regno
Uniti, e ci sono tante anche in Italia, in particolare in montagna. In
Inghilterra normalmente, su queste strade, sono previsti dei con passing
places (scritta "passing place" su quadrato o rombo bianco).

Quello che è descritto sulla wiki OSM attuale, cioè che strade a corsia
unica senza bordo bianco dipinto non vanno taggate con lanes=1 è
contra-intuitivo, è un cambiamento di un tagging in uso massiccio, e il
quale era, inoltre, descritto sulla pagina wiki "lanes" fino al 2017.

Vorrei sollevare la questione sulla lista tagging.
Martin, ti ricordi del dove (quale lista) e quando della discussione alla
quale ti riferivi? La mia memoria è debole e non la trovo con una semplice
ricerca. Grazie.

Volker




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


Re: [Talk-it] [talk:it] Bicycle road all'italiana?

2020-08-29 Diskussionsfäden Volker Schmidt
Ciao

> Se c'è solo una corsia in tutto, come fa a non essere un senso unico?
>
In caso di una single-track road
, anche chiamata one-lane
road.

Ho guardato qualche esempio che riporti e, se sono strade a doppio senso di
> circolazione, dovrebbero essere mappate come lanes=2 + lane_markings=no se
> hanno i delimitatori di carreggiata, oppure solo con lane_markings=no se
> non sono presenti, come tra l'altro riporta la wiki:
> https://wiki.openstreetmap.org/wiki/Key:lanes#Examples
>
Conosco la pagina e la mia conclusione è che è stat scritta da una che non
ha guardato come il tagging è versamante nel database. Non affronta il caso
della single-track road
Se guardi gli esempi (e ci sono migliaia di altri dello stesso tipo) vedi
che la pratica.
Da notre che il tag lane_markings è stato documentato nel wiki per la prima
volta nel ottobre 2019. Poi la pagina wiki è stata recentemente ( 20:30, 5
March 2017

) modificata cambiando il titolo della foto della single-track road da
"lanes=1" a " highway =
passing_place
 (on the
node)"
Questa modifica non ha preso in considerazione l'uso preesistente. Non ho
capito se si tratta di wiki-fiddling o se c'è una discussione al proposito.

Sono d'accordo che c'è confusione.
Ho cercato dove si definisce la larghezza di una single-lane road ed ho
trovato solo questo cenno in wikipedia :
"Some roads and bridges that carry very low volumes of traffic are less
than 4.6 metres (15 ft) wide, and are only a single lane wide"  e poi nel
articolo wikipedia citato sopra ( single-track road
,). Interessante che in
Wkipedia i due articoli mancano i cross-link.

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


Re: [Talk-it] Osmf

2020-08-29 Diskussionsfäden Martin Koppenhoefer


sent from a phone

> On 29. Aug 2020, at 10:02, Lorenzo Pesci  wrote:
> 
> Iscritto anche io, poi mi spiegate meglio come potrò essere utile, grazie.
> Ciao Lorenzo Pesci 


più tardi nell’anno ci saranno elezioni per il board (consiglio 
d’amministrazione), e spero che vinceranno persone della comunità dei mappatori 
piuttosto che rappresentanti delle grandi aziende.

Ciao Martin ___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [Talk-it] [talk:it] Bicycle road all'italiana?

2020-08-29 Diskussionsfäden Martin Koppenhoefer


sent from a phone

> On 29. Aug 2020, at 14:51, Volker Schmidt  wrote:
> 
> Martin, non è così. Una "single-track road" (UK) o "one-lane road"  (USA), 
> termini equivalenti secondo Wikipedia, sono spesso vere e proprie strade a 
> una corsia, utilizzati con due sensi di traffico


la corsia serve per una fila di macchine di andare, una strada con spazio per 
una sola corsia non ne ha più quando è a doppio senso 

Ciao Martin 
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [Talk-it] [talk:it] Bicycle road all'italiana?

2020-08-29 Diskussionsfäden Martin Koppenhoefer


sent from a phone

> On 29. Aug 2020, at 11:29, Volker Schmidt  wrote:
> 
> Sono d'accordo che c'è confusione. 
> Ho cercato dove si definisce la larghezza di una single-lane road ed ho 
> trovato solo questo cenno in wikipedia:
> "Some roads and bridges that carry very low volumes of traffic are less than 
> 4.6 metres (15 ft) wide, and are only a single lane wide"  e poi nel articolo 
> wikipedia citato sopra ( single-track road,). Interessante che in Wkipedia i 
> due articoli mancano i cross-link.



sono d‘accordo che ci siano strade che non sono abbastanza larghe per avere 
traffico continuo in due versi, però non sono nemmeno sensi unici. In questi 
casi non ci sono corsie, infatti il nome inglese è single tracked, non 
single-lane.
Si omette “lanes” (diceva la maggioranza sulla lista tagging).

 Io ero a favore di taggare lanes=2 le strade sufficientemente larghe per 2 
corsie ma non marcate (per esempio strade provinciali in campagna). Talvolta (o 
forse sempre) è solo effetto di mancata manutenzione, e dopo anni senza ci 
mettono finalmente di nuovo le linee. Succede addirittura su strade grandi 
(statali), a 2+2 corsie, e anche a tratti su autostrade (per esempio sul GRA) 
che ci mettono anni a marcare le corsie (dopo aver fatto lavori).
In quest’ultimi casi ci metto comunque lanes come se ci fossero, ma volendo 
lane_markings=no sarebbe un tag da aggiungere se si volesse mappare con questo 
livello di dettaglio.

Mappiamo anche i limiti, a prescindere del senso (strada in zone balneare con 
residenze adiacenti, bar e ristoranti, e tanti pedoni: 70, invece strada a 
scorrimento fuori centro abitato, 2+2 corsie, 60km/h (per decine di chilometri 
e motivi sempre diversi: dossi, banchina strada non fermo, rischio incidenti, 
strade immergenti, di nuovo dossi, ecc. sempre 60.

https://www.google.com/maps/@41.4952726,12.8272644,3a,75y,295.94h,88.5t/data=!3m4!1e1!3m2!1sgTs_Myz5mZBnnWZgGu9TCA!2e0

Ciao Martin 

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


Re: [Talk-it] Osmf

2020-08-29 Diskussionsfäden Damjan Gerl

  
  
Martin Koppenhoefer je 29.8.2020 ob
  13:28 napisal:


  
  
  
  sent from a phone
  
On 29. Aug 2020, at 10:02, Lorenzo Pesci
   wrote:
  

  
  
Iscritto anche io,
poi mi spiegate meglio come potrò essere utile, grazie.
  Ciao Lorenzo
  Pesci 

  
  
  
  
  più tardi nell’anno ci saranno elezioni per il board
(consiglio d’amministrazione), e spero che vinceranno persone
della comunità dei mappatori piuttosto che rappresentanti delle
grandi aziende.
  
  
  Ciao Martin 
  


Ci sono anche io :-)

Saluti
Damjan Gerl
  


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


Re: [Talk-at] Gefahr durch Internet-Bergrouten

2020-08-29 Diskussionsfäden Friedrich Volkmann

On 29.08.20 18:34, Stefan Kopetzky wrote:

einfach vor kurzem wild
reingelöscht, was er(?) für keine offiziellen Wege hält
https://www.openstreetmap.org/changeset/88569171), was ich persönlich
so, ganz ohne Diskussion für eine grobe Missachtung der Arbeit der
Vormapper und wg. dem Sockenpupperlaccount, eigentlich für eine Sauerei
halte.

Ich wär hier für einen Revert. Nicht dass die Wege vorher unstrittig
wären (access=private, width=0 etc.), aber so ists "keine Art", wie man
hier sagt.


Das ist nicht nur keine Art, sondern klarer Vandalismus, und da braucht ein 
Revert keine vorherige Diskussion. Machst du?


--
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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


Re: [Talk-at] Gefahr durch Internet-Bergrouten

2020-08-29 Diskussionsfäden Stefan Kopetzky
On 29.08.20 18:41, Friedrich Volkmann wrote:
>> Ich wär hier für einen Revert. Nicht dass die Wege vorher unstrittig
>> wären (access=private, width=0 etc.), aber so ists "keine Art", wie man
>> hier sagt.
> 
> Das ist nicht nur keine Art, sondern klarer Vandalismus, und da braucht
> ein Revert keine vorherige Diskussion. Machst du?

Schon passiert.
Vielleicht könnte ja noch jemand mit mehr Ortskenntnis in dem Eck vom
Höllengebirge (Marcus?) mal über das Tagging drübergehen. Ich hab nur
einen offensichtlich doppelt gemappten Steig vereint.

LG,
Stefan

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


Re: [Talk-at] Gefahr durch Internet-Bergrouten

2020-08-29 Diskussionsfäden Robert Grübler
Am Donnerstag, 27. August 2020 22:05 schrieb Friedrich Volkmann 
[mailto:b...@volki.at]

> Darum kann ich euch nur eindringlich ersuchen, alle highway=via_ferrata, 
> denen ihr begegnet, auf highway=path zurückzuändern.

Alle? Wohl nicht.
Ein klassischer Klettersteig – das mit durchgehenden Stahlseil gesicherte, 
primäre Ziel einer Tour – ist mit highway=via_ferrata korrekt getaggt (s. 
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dvia_ferrata ). 


Meine Gedanken zum Ausgangsthema selbst:
Ein Mapper, der einen alpinen Pfad ohne Schwierigkeitsgrad aufnimmt, handelt 
grob fahrlässig. Keine Karte, kein Router kann wissen, dass es kein normaler 
Wanderweg ist.

Ein Mapper, der einen alpinen Pfad mit einem selbstbestimmten 
Schwierigkeitsgrad aufnimmt, nimmt eine große Verantwortung auf sich. Er muss 
ev. für die Richtigkeit geradestehen. Nicht nur jetzt, sondern auch zukünftig. 
D.h. er sollte den Schwierigkeitsgrad periodisch überprüfen.
Sicherheitshalber den höchsten Schwierigkeitsgrad zu vergeben ist keine 
besonders gute Idee, das untergräbt das Vertrauen in die Schwierigkeitsangabe.

Ein Kartenhersteller, eine Router, der die Schwierigkeitsangabe alpiner Pfade 
ignoriert, handelt grob fahrlässig. Das kann lebensbedrohlich sein.

Mein Resümee daraus:
Nur Bergwege – markierte und gewartete Steige mit Schwierigkeitsangabe vom 
Wegeerhalter – sollten in OSM aufgenommen werden. 
Ungewartete Steige sollten nicht in OSM aufgenommen werden. Vorhandene sollten 
gelöscht werden. Oder zumindest solange als „Nicht-Wege“ maskiert werden, bis 
ein etabliertes Tagging dafür existiert.

LG Robert

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


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


[Talk-us] Large fire perimeter tagging?

2020-08-29 Diskussionsfäden stevea
Not sure if crossposting to talk-us is correct, but it is a "home list" for me.

I've created a large fire perimeter in OSM from public sources, 
http://www.osm.org/way/842280873 .  This is a huge fire (sadly, there are 
larger ones right now, too), over 130 square miles, and caused the evacuation 
of every third person in my county (yes).  There are hundreds, perhaps 
thousands of structures, mostly residential homes, which have burned down and 
the event has "completely changed" giant redwoods in and the character of 
California's oldest state park (Big Basin).

This perimeter significantly affects landuse, landcover and human patterns of 
movement and activity in this part of the world for a significant time to come. 
 It is a "major disaster."  I'm curious how HOT teams might delineate such a 
thing (and I've participated in a HOT fire team, mapping barns, water sources 
for helicopter dips and other human structures during a large fire near me), 
I've simply made a polygon tagged fire=perimeter, a name=* tag and a 
start_date.  I don't expect rendering, it's meant to be an "up to right about 
here" (inside the polygon is/was a burning fire, outside was no fire).  I 
wouldn't say it is more accurate than 20 to 50 meters on any edge, an "across a 
wide street" distance to be "off" is OK with me, considering this fire's size, 
but if a slight skew jiggles the whole thing into place better, feel free to 
nudge.  It's the tagging I'm interested in getting right, and perhaps wondering 
if or even that people enter gigantic fires that will significantly change 
landscape for some time into OSM, as I have done.  This will affect my local 
mapping, as a great much has burned.  Even after starting almost two weeks ago, 
as of 20 minutes ago this fire is 33% contained, with good, steady progress.  
These men and women are heroes.

To me, this is a significant polygon in my local mapping:  it is a "huge thing" 
that is a major feature on a map, especially right now.  I firmly believe it 
belongs in OSM for many reasons and want it tagged "correctly."  Yes, there are 
other maps that show this, I believe OSM should have these data, too, as this 
perimeter will affect much (in the real world) and much newer, updated mapping 
in OSM going forward.

Thank you for your suggestions,
SteveA
California
(safer now thanks to truly heroic efforts by firefighters, law enforcement and 
many others)
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us


Re: [OSM-talk-fr] BANO est-il mort?

2020-08-29 Diskussionsfäden Philippe Verdy
Et bravo encore pour ta "bienveillance", qui démontre encore un haut niveau
de tolérance.

Le dim. 30 août 2020 à 02:23, Jérôme Amagat  a
écrit :

> Vous vous faite du mal à répondre à Philippe, ça ne sert à rien. Ça fait
> plusieurs années que je lis ce qui se dit sur cette liste et il est
> coutumier de ce genre d'intervention, il ne faut pas y faire attention et
> même ne pas le lire, vous vous en porterez que mieux :)
>

Maintenant tu donnes des ordres aux autres, monsieur le censeur bien
pensant qui veut se placer comme élite ? Et c'est moi qu'on traite de
"yakafaucon" ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


[talk-au] Suburbs & admin boundaries stopping streets being found?

2020-08-29 Diskussionsfäden Graeme Fitzpatrick
Having a problem with OSMAND that I think could be related back to the way
data has been entered, or later defined, in OSM?

Playing with OSMAND yesterday & searched for a local street but it came
back "not found". Tried a number of others with some found & others not.
Then tried changing the search town from "Gold Coast" to individual suburbs
& all the "missing" streets in that suburb were then found OK?

If you'd like to please try yourself, in OSMAND, please set your city /
town to Gold Coast, then search Dawn Parade, Honeyeater Drive & Rio Vista
Boulevard. There should be nothing found for the first two, but Rio Vista
should appear but with only two results - intersections with Furlong Street
& Cleland Crescent.

If you then set the city / town to Miami, Dawn Parade will show; Burleigh
Waters will find Honeyeater Drv & Broadbeach Waters will show all of the
Rio Vista Blvd results (~50 of them!)

BTW, they can all be found fine in OSM itself eg Dawn Parade Miami gives
https://www.openstreetmap.org/way/182163166#map=17/-28.06847/153.43806

I think there may be two things at play here?

Only a few Gold Coast suburbs, including these ones, have had their admin
boundaries mapped (incidentally, as an aside, they've been mapped as
admin_level=10 - should they be =9?) eg
https://www.openstreetmap.org/relation/973018.

In addition, the overall Gold Coast LGA boundary hasn't been mapped.

Does that sound feasible?

If so, what's the fix? It would appear that mapping an admin boundary has
convinced OSMAND that that area isn't part of the Gold Coast any more?
Would mapping the Gold Coast LGA as admin_level=8 resolve it?

Or is this just another OSMAND problem? :-(

Thanks

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


Re: [OSM-talk-fr] BANO est-il mort?

2020-08-29 Diskussionsfäden Philippe Verdy
En plus ce que tu viens d'écrire me donne raison car tu as fait les mêmes
constatations que moi ou n'importe qui.

J'ai juste demandé de la maintenance et toi aussi tu la demande. En quoi
ai-je eu tord ?

En revanche tu as eu tord sur ta façon de réagir. Et tu confirmes ce que je
décrivais de l'attitude malveillante de certains ici (dont tu confirmes on
ne peut plus explicitement faire partie). Ton intention c'est bien
d'exclure et diviser les gens. Cela n'a rien de coopératif ni constructif.
Je ne t'avais pourtant pas désigné ni émis aucune critique contre toi, mais
là tu viens de te le permettre honteusement (et ce n'est pas la première
fois).

Mais là tu n'as pas hésité à tenir ta rancoeur anti-personnelle persistante
et la rendre publique. T'inquiète pas, je suis résistant, je ne généralise
pas et ne met pas tout le monde dans le même panier. On peut exprimer des
déceptions, des avis, des suggestions de changement, interroger et demander
des avis, sans subit de telles attaques publiques personnelles comme ici.


Le dim. 30 août 2020 à 03:32, Philippe Verdy  a écrit :

> Et bravo encore pour ta "bienveillance", qui démontre encore un haut
> niveau de tolérance.
>
> Le dim. 30 août 2020 à 02:23, Jérôme Amagat  a
> écrit :
>
>> Vous vous faite du mal à répondre à Philippe, ça ne sert à rien. Ça fait
>> plusieurs années que je lis ce qui se dit sur cette liste et il est
>> coutumier de ce genre d'intervention, il ne faut pas y faire attention et
>> même ne pas le lire, vous vous en porterez que mieux :)
>>
>
> Maintenant tu donnes des ordres aux autres, monsieur le censeur bien
> pensant qui veut se placer comme élite ? Et c'est moi qu'on traite de
> "yakafaucon" ?
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Projet du mois défibrillateurs : c'est parti !

2020-08-29 Diskussionsfäden Yves P.
> - Soit le DAE a été importé dans la base nationale en utilisant les jeux de 
> données pré-existants (SDIS, SAMU, ARLOD...), et dans ce cas il est noté "en 
> attente de validation".
> 
C'est pour ça que j'ai trouvé deux entrées dans GéoDAE pour un même 
défibrillateur :)

Ça veut dire aussi que tous les DAE listés par ARLoD sont dans Géo DAE ?

> Quand le propriétaire se manifeste et confirme les informations, il devient 
> alors "validé".
> 
> - Soit le DAE est directement ajouté par le propriétaire (car pas listé au 
> préalable), et dans ce cas il est noté directement comme validé.
> 
Ok et merci pour les infos :)

> À noter également qu'une API existe pour intégration dans les applications 
> citoyennes (type Sauvlife et autres). 
> 
Est-ce que la doc de l'API est publiée ?

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


Re: [OSM-talk-fr] Projet du mois défibrillateurs : c'est parti !

2020-08-29 Diskussionsfäden Christian Quest

Le 29/08/2020 à 10:04, PanierAvide a écrit :

Le 29/08/2020 à 06:48, Yves P. a écrit :

Est-ce que quelqu'un en sait plus sur la *validation d'un DAE* ?
Je n'ai rien trouvé sur le site.

La validation d'un défibrillateur sur GéoDAE est réalisée 
systématiquement par son propriétaire. C'est au propriétaire du DAE de 
confirmer la localisation, les informations techniques et contacts. 
Avec ça en tête, deux cas existent actuellement :


- Soit le DAE a été importé dans la base nationale en utilisant les 
jeux de données pré-existants (SDIS, SAMU, ARLOD...), et dans ce cas 
il est noté "en attente de validation". Quand le propriétaire se 
manifeste et confirme les informations, il devient alors "validé".


- Soit le DAE est directement ajouté par le propriétaire (car pas 
listé au préalable), et dans ce cas il est noté directement comme validé.


À noter également qu'une API existe pour intégration dans les 
applications citoyennes (type Sauvlife et autres). Elle permet la 
"mise en doute" d'un défibrillateur : il vient d'être utilisé donc à 
remettre en état, il a été cassé/déplacé, est hors service... Tant que 
le propriétaire ne re-confirme pas qu'il fonctionne à nouveau, le DAE 
n'est plus proposé auprès des personnels qualifiés.


Cordialement,

Adrien.



Et malheureusement, ce n'est pas parce qu'il est validé par son 
exploitant, que la donnée est de qualité :(


GéoDAE ne fait pas contrôle particulier sur les données, pas de 
rapprochement avec d'autres bases. On a du coup un certain nombre de DAE 
sur Null Island.



--
Christian Quest - OpenStreetMap France

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


Re: [OSM-talk-fr] Besoin de conseils pour les diagrammes de transport public

2020-08-29 Diskussionsfäden Noémie Lehuby via Talk-fr

Bonjour,

Merci pour le feedback. Unroll n'est disponible qu'en anglais pour le 
moment.


Pour le wiki, c'est une bonne idée ! L'idéal serait de l'ajouter 
directement dans le template existant BrowseLine plutôt que de créer un 
nouveau template que personne ne va utiliser non ?
Par contre, ça va modifier toutes les pages qui l'utilisent et 
l'opération n'est pas sans risque apparement (cf les remarques sur cette 
page https://wiki.openstreetmap.org/wiki/Template:Relation)


--
Noémie Lehuby
Jungle Bus - http://junglebus.io

Le 28/08/2020 à 15:33, Percherie OnDaNet a écrit :
Fort sympa Unroll. Y a t'il une interface en français ? J'ai regardé 
sur le wiki et il ne semble pas y avoir de modèle permettant de 
générer de lien pointant vers Unroll (idéalement Unroll + 
sketch-line). Un peut comme les template "BrowseLine" ou "Relation" 
disponible quand on édite une page du wiki.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


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

2020-08-29 Diskussionsfäden blef
Les "bandes roulables à côté sans marches" sont (ou devraient être) 
taguées avec l'attribut ramp:bicycle=yes


Mais les routeurs en question ne se limitent pas à ces (rares) cas pour 
créer leurs itinéraires.


Le 28/08/2020 à 23:32, Philippe Verdy a écrit :
Sauf les escaliers à marches près  peu pentues et pas trop hautes (pas 
plus que les ralentisseurs sur les rues ou aires de parking) ou ceux 
qui disposent d'une bande roulable à côté sans marches et de zones 
planes d'arrêt. Assimilables aux voies (lanes) sur les rues/routes 
(highways=* aussi) s'il n'y a pas de réelle séparation physique entre 
l'escalier piéton et la bande roulante, et donc pas forcément 
détaillés par des "ways" OSM séparés.



Le ven. 28 août 2020 à 18:44, blef > a écrit :


Bonjour,

Je m'aperçois qu'en faisant une recherche d'itinéraire en mode
vélo, que ce soit avec GraphHopper ou OSRM, on m'envoie sans
vergogne sur des escaliers.
Pourtant, d'après le wiki
, le
tag highway=steps implique access=no + foot=yes, donc
implicitement bicycle=no, ce qui me semble normal, moi qui n'ai
pas pour habitude de descendre (ou monter) les escaliers à vélo!
Me confirmez vous que le tag highway=steps ne nécessite pas
d'ajouter bicycle=no et donc que les routeurs n'appliquent pas
correctement les conditions d'accès dans ce cas?

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


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



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


[OSM-talk-fr] Adhésion gratuite à l'OSMF

2020-08-29 Diskussionsfäden Jean-Claude Repetto
Je ne sais pas si c'est récent, mais les contributeurs actifs peuvent 
désormais adhérer gratuitement à l'OSMF:

https://join.osmfoundation.org/active-contributor-membership/

Je ne pense pas avoir vu passer l'info sur cette liste.

Jean-Claude

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


Re: [OSM-talk-fr] Projet du mois défibrillateurs : c'est parti !

2020-08-29 Diskussionsfäden PanierAvide

Le 29/08/2020 à 06:48, Yves P. a écrit :

Est-ce que quelqu'un en sait plus sur la *validation d'un DAE* ?
Je n'ai rien trouvé sur le site.

La validation d'un défibrillateur sur GéoDAE est réalisée 
systématiquement par son propriétaire. C'est au propriétaire du DAE de 
confirmer la localisation, les informations techniques et contacts. Avec 
ça en tête, deux cas existent actuellement :


- Soit le DAE a été importé dans la base nationale en utilisant les jeux 
de données pré-existants (SDIS, SAMU, ARLOD...), et dans ce cas il est 
noté "en attente de validation". Quand le propriétaire se manifeste et 
confirme les informations, il devient alors "validé".


- Soit le DAE est directement ajouté par le propriétaire (car pas listé 
au préalable), et dans ce cas il est noté directement comme validé.


À noter également qu'une API existe pour intégration dans les 
applications citoyennes (type Sauvlife et autres). Elle permet la "mise 
en doute" d'un défibrillateur : il vient d'être utilisé donc à remettre 
en état, il a été cassé/déplacé, est hors service... Tant que le 
propriétaire ne re-confirme pas qu'il fonctionne à nouveau, le DAE n'est 
plus proposé auprès des personnels qualifiés.


Cordialement,

Adrien.

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


Re: [OSM-talk-fr] BANO est-il mort?

2020-08-29 Diskussionsfäden Christian Quest

Le 28/08/2020 à 21:45, Philippe Verdy a écrit :



Le ven. 28 août 2020 à 18:45, Vincent de Château-Thierry 
mailto:osm.v...@free.fr>> a écrit :


Bonjour,

> De: "Philippe Verdy" mailto:ver...@gmail.com>>
>
> Pratiquement plus aucun lien concernant BANO ne fonctionne, plus un
> seul outil, plus aucune base de suivi, plus aucun rendu.

Tu ne donne aucune URL dans ton mail, or c'est bien pratique quand
on parle de service, d'indiquer son URL. Ca évite les
interprétations. Je vais répondre à ce que je peux, avec le risque
de répondre à côté de la plaque, puisque je vais devoir
interpréter. Tant pis.

> Je sais qu'il y a eu un bogue, mais là ça dure. Que faire en
> attendant ? On peut encore utiliser la couche cadastre pour
> compléter les numéros de rue manquants dans OSM et voir un rendu
> dans les couches OSM classiques (uniquement en fort niveau de zoom)
> mais il n'y a plus de suivi sur l'avancement et sur ce qu'on a pu
> oublier.

Je suppose que tu parle du rendu carto de BANO, les points colorés
et les zones rouges à dégommer. Si c'est ça, en effet c'est en
panne. La raison : la v1 a été coupée (elle n'était plus mise à
jour) et le v2 n'est pas encore développée. Elle a besoin du
contenu du produit Adresses [1] qui est pour l'instant absent de
BANO, c'est le prochain sujet pour moi [2]

> Voir la page "officielle" de BANO assi sur openstreemap.fr
 , hormis
> les articles de présentation et anciennes interviews sur d'autres
> sites, plus rien ne fonctionne ou les liens ne sont pas remis à
> jour. Si les services ont été migrés il faudrait revoir ces pages de
> base sinon BANO sortira aussi de la vue des mainteneur de la BAN, et
> les réutilisateurs se tourneront à nouveau vers des contrats aux
> licences propriétaires avec LaPoste ou l'IGN.

Je ne sais pas de quelle page officielle tu parles. Comme point
d'entrée au projet je vois avant tout le wiki [3] et la page
d'accès aux services et aux données [4]


Je n'ai pas parlé non plus du wiki mais bien du site openstreemap.fr 
 et des pages qui y sont, dont quasiment tous 
les liens sont morts (et ceux des références dans les sites liés avec 
les interviews etc.). Donc non pje ne peux rien y changer.



> La seule chose qui marche ce sont les exports (anciens et peu
> actualisés) de la BAN sur data.gouv.fr 
(EtaLab), où OSM est
> totalement oublié !

Les exports de BANO sont rejoués chaque nuit et publiés sous
http://bano.openstreetmap.fr/data/

Le wiki n'est pas forcément à jour, mais c'est un wiki, chacun.e
peut y mentionner ces infos.


Non. Le wiki est bloqué aussi, pas ouvert.


wiki.openstreetmap.org ? Merci d'être précis pour éviter de perdre du 
temps à comprendre, à chercher ce que tu veux dire et/ou un problème.





> BANO est-il mort ?

Mort, jamais. Morte, un jour peut-être. Le B de BANO c'est pour
"base" donc féminin :)


Je ne parle pas de la base de données (oui elle existe toujours... 
dans son ancien état) mais bien du projet (sa maintenance et ses 
évolutions), donc le masculin est correct dans ce contexte.


Même les exports BANO dans EtaLab sont vieux.


Tous les liens de téléchargement pointent sur les données actuelles et 
bien remises à jour quotidiennement.


Si tu fais référence à la date indiquée dans l'encadré "informations" 
sur 
https://www.data.gouv.fr/fr/datasets/base-d-adresses-nationale-ouverte-bano/ 
celui-ci n'est pas remis automatiquement à jour. Il faudrait pour cela 
un appel quotidien à l'API de data.gouv.



Et les pages et outils de suivi, et les pages des logiciels 
opensource (GitHub et autres): tout est vieux et date de 2016.


Vincent a répondu.


D'ailleurs les stats ne sont mieux, il y a environ 14 millions 
d'adresses dans BANO, le site annonce 20 millions d'adresses dans la 
BAN mais elle en a 24 millions


D'où sortent ces chiffres ? (histoire qu'on les mette à jour si besoin)


aujourd'hui la BAN évolue bien plus vite que la BANO (mais surtout 
grace aux exports des collectivités locales, et plus depuis la Poste 
qui a visiblement quitté le projet et ne veut plus s'y intéresser 
(elle semble vouloir que l'ARCEP s'en occupe pour forcer les autres 
services postaux à coopérer aussi à un projet commun qui visiblement 
ne décolle pas du tout à l'ARCEP).


Je ne vais pas revenir sur les saisons passées de la BAN... le 
feuilleton était mauvais, j'ai arrêté de regarder la série.



en attendant EtaLab n'a rien à fournir et ce projet adresses en France 
est au point mort, et rien n'est fait au plan qualité, les seules 
vraies contributions venant des principales métropoles et agglos 
(quand aux petites CC elles n'ont pas les moyens de gérer ça, elles 
ont déjà eu du mal à faire vectoriser le cadastre... mais sans les 
adresses en de nombreux endroits et sans non plus 

Re: [OSM-talk-fr] Projet du mois défibrillateurs : c'est parti !

2020-08-29 Diskussionsfäden Yves P.
> Tous les DAE ont des coordonnées. Seulement 227 avec lat/lon = 0,0

Pour info, Ils sont dans ces communes :
Cornil  216
COINCHES1
FRÉMIFONTAINE   1
HERPELMONT  1
LA GOUTELLE 1
LA PETITE-RAON  1
LE BARROUX  1
LE PERTRE   1
MARSAIS-SAINTE-RADÉGONDE1
OFFIGNIES   1
SAINT JEAN D ORMONT 1
SAINT RÉMY  1

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


Re: [OSM-talk-fr] Projet du mois défibrillateurs : c'est parti !

2020-08-29 Diskussionsfäden Gad Jo
Nickel, j'avais peur qu'une notion de licences m'interdisait d'exploiter ces 
informations.

Je vais faire un premier import suivant la localisation indiquée sur la fiche 
avec un fixme demandant de préciser la localisation exact dans le bâtiment. 
Autrement j'aurai fini de les importer dans 2 ans (je suis seul sur Narbonne).

Astuces : dans les journaux locaux on peut trouver des articles indiquant la 
création de DAE et souvent il y a les photos des appareils. Sans forcément 
réutiliser les photos (licence ?) on peut déjà faire un ajout assez précis.
Pratique pour les villages environnant pour éviter de brûler du carburant à 
tout vas...
D'ailleurs, a t'on le droit de réutiliser une photos postée dans un journal 
local ?

Le August 29, 2020 4:48:54 AM UTC, "Yves P."  a écrit :
>> Ils ne sont pas proposé sur Osmose. Ai-je le droit de les intégrer
>tel quel ?
>Tu as le devoir de le intégrer :D
>
>J'ai regardé celui de la Hall d'honneur Pech de Laclause
> : 
>Sans photo de terrain, difficile de faire quoi que ce soit avec si peu
>d'informations.
>
>Dans ce cas, je suggère de l'ajouter uniquement après une visite et 2
>publier 2 photos (autre qu'un pompier soufflant dans un truc en
>plastique
>
>:D)
>
>de Philippe :
>> Attention à l'intégration avec Osmose, notamment sur:
>
>Ce n'est pas osmose en soit le problème, mais la qualité des données.
>
>
>> - le placement: la position est approximative car souvent l'adresse
>n'est pas bien localisée et manque;
>> - si l'adresse est présente, le placement proposée dessus n'est pas
>réellement le bon placement car l'adresse est souvent un noeud en
>bordure de propriété
>
>
>Le placement est souvent approximatif car l'adresse est géocodée (et
>pas toujours très bien selon la base de données utilisée).
>La personne qui saisi la fiche n'est pas forcément allée sur le
>terrain.
>
>Hier j'ai rajouté un DAE dans une entreprise. Elle est dans une zone
>industrielle, "loin" du village.
>GéoDAE la situait au centre.
>
>
>> - regarder l'attribut indoor=yes proposé, pour ajuster le noeud dans
>le bâtiment à cet adresse, près de son entrée mais bien à l'intérieur
>
>Idem. Un DAE était à l'extérieur, mais la fiche GéoDAE indiquait le
>contraire.
>
>Si une photo utile est fournie par GeoDAE et/ou que le défibrillateur
>est visible sur une photo terrain, j'intègre.
>Sinon, je laisse…
>
>
>Seulement 2 294 DAE sont "validés", et 14 040 sont en "attente de
>validation".
>
>Est-ce que quelqu'un en sait plus sur la validation d'un DAE ?
>Je n'ai rien trouvé sur le site.
>
>
>Autre remarque sur les données GéoDAE : la saisie semble libre, du coup
>c'est un vrai bazar.
>On se retrouve avec des infos peu structurées (les horaires notamment),
>des infos dans le mauvais champ, des descriptions manquantes ou trop
>vagues, pas de photos de situation…
>
>Donc plein de travail d'intégration en perspective :)
>
>__
>Yves

-- 
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] Adhésion gratuite à l'OSMF

2020-08-29 Diskussionsfäden Yves P.
> Je ne sais pas si c'est récent, mais les contributeurs actifs peuvent 
> désormais adhérer gratuitement à l'OSMF:
> https://join.osmfoundation.org/active-contributor-membership/

Merci Jean-Claude :)

__
Yves

PS:
Les traductions du formulaire d'inscription sont marrantes : elles s'affichent 
sur une autre page que le formulaire
https://join.osmfoundation.org/active-contributor-membership/application-form-for-active-contributor-membership-mapping/



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


Re: [OSM-talk-fr] Projet du mois défibrillateurs : c'est parti !

2020-08-29 Diskussionsfäden Yves P.
> GéoDAE ne fait pas contrôle particulier sur les données, pas de rapprochement 
> avec d'autres bases. On a du coup un certain nombre de DAE sur Null Island.
> 
Tous les DAE ont des coordonnées. Seulement 227 avec lat/lon = 0,0

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


Re: [OSM-talk-fr] BANO est-il mort?

2020-08-29 Diskussionsfäden PanierAvide
Le point soulevé n'était pas sur le projet du mois, mais sur la 
nécessité d'une communication *bienveillante*.



Même si les intentions sont bonnes (c'est souvent le cas), les *demandes 
expéditives sont usantes* : une personne bénévole n'est pas un robot 
sans âme soumis à bons de commandes. De la même manière qu'on ne peut 
pas attendre d'OSM une qualité irréprochable des données sur l'ensemble 
de la planète, on ne peut pas attendre une garantie de service 100% ou 
une actualisation des briques logicielles en sprints agiles toutes les 4 
semaines. On souhaite tous faire avancer le bien commun, faisons-le dans 
une ambiance bienveillante et accueillante. À quoi ça sert de défendre 
un modèle d'ouverture sur les logiciels et données si c'est pour 
communiquer comme le N+1 d'une multinationale qui n'a aucun respect pour 
son équipe.


Une communication bienveillante ne veut pas dire qu'on ne peut pas 
améliorer la disponibilité ou la rapidité de mise à jour des logiciels, 
mais dans ce cas il faut :


- Soit *mettre la main à la pâte* (on n'est jamais mieux servi que par 
soi-même) et travailler à plusieurs sur les outils critiques (assurer 
une continuité de maintenance)


- Soit trouver un *budget* (donc émettre un _vrai_ bon de commande) pour 
que les personnes qui maintiennent actuellement les services y 
consacrent du temps salarié.


Et si on a ni le temps ni l'argent, *revoir ses priorités* ou comprendre 
qu'une personne bénévole ait des priorités différentes (travail, 
famille, besoin de s'aérer...). Même si c'est dommage que tel service 
soit indisponible, ça arrive, c'est la vie. On est tous bénévoles dans 
ce projet, n'infligeons pas à autrui ce que l'on n'aimerait pas qu'on 
nous fasse. Le sujet de l'accueil des nouveaux est récurrent, n'oublions 
pas que si la communauté doit se renouveler, c'est aussi à cause de*la 
fatigue des personnes présentes de longue date*. Alors évitons de leur 
rajouter une couche de fatigue inutile.



Quand je remonte un problème, soit j'ai la capacité d'aider donc j'aide, 
soit je n'ai pas la capacité et dans ce cas le problème est remonté en 
mode "*bouteille à la mer*". Un guide de bonnes pratiques :


- Commencer par du *positif* : merci pour cet outil/base/... qui est 
d'un grand service. Les français sont les champions du monde pour râler, 
mais très peu iront vous remercier d'un service utile.


- *Détailler* le problème : je rencontre tel problème, dans tel contexte 
technique, à telle adresse... Plus la demande est détaillée, plus le 
problème sera simple à identifier


- *Proposer* une ou des solutions si on peut les envisager, ne pas 
hésiter à illustrer avec maquettes, captures d'écran...


- Et enfin *remercier* pour le temps qui pourra être consacré à cette 
demande, tout en n'attendant pas une réponse immédiate ni une résolution 
rapide.


Du point de vue extérieur, ça semble idiot de faire des ronds de jambe. 
Pourtant à l'usage ça réduit largement la charge mentale des personnes 
qui maintiennent ces services. Chacun a suffisamment de stress dans sa 
vie pour ne pas vouloir s'en rajouter avec des projets bénévoles. Donc 
évitons de *dégoûter* à tout jamais les personnes suffisamment motivées 
pour consacrer du temps au bien commun en communiquant avec elles comme 
à des sous-traitants pour lesquels on aurait aucun respect. C'était une 
des tendances lors des présentations du Sotm monde en ligne : la vraie 
valeur d'OSM n'est pas dans ses données, mais dans sa *communauté*.



En résumé, ne disons pas à Vincent "/BANO est mort, c'est con quand 
même/", mais disons lui "/Merci pour avoir contribué toutes ces années à 
BANO et merci pour ton engagement régulier. Si nous pouvons t'aider, 
nous le ferons volontiers. Si nous ne pouvons pas, sache que ce service 
nous est bien utile dans notre contribution, et que nous serons contents 
de pouvoir le retrouver le moment venu./".


Cordialement,

Adrien P.

Le 28/08/2020 à 23:25, Philippe Verdy a écrit :



Allez, juste un peu de lecture pour finir sur des paroles sages et
bienveillantes :
https://github.com/vdct/ProjetDuMois/issues/22#issuecomment-678981742

Je ne vois pas le rapport: là tu reviens sur un autre projet du mois, 
les DAE (qui n'ont pourtant aucun rendu sauf le rendu OSM.FR 
 qui n' pas la capacité de supporter l'usage voulu par 
le grand public au sens large pour les DAE, et ne sont pas non plus 
pour l'instant dans les priorité internationales d'OSM).


Il n'y a rien concernant BANO pourtant fondamental (même pour 
faciliter l'intégration des DAE et de toutes sortes d'autres "projets 
du mois").


Le projet BANO mérite un peu plus d'attention, et il s'est endormi sur 
ses lauriers passés et n'évolue presque plus, alors que la BAN elle 
continue bien plus vite.


Avec la conséquence directe: l'IGN recommence à prendre du poids pour 
les usages via des licences privées (ou bien les solutions payantes 
comme Mapbox et même Google), et le "switch 2 OSM" semble un 

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

2020-08-29 Diskussionsfäden blef
Je ne connaissais pas (ou j'avais oublié) BRouter, effectivement plus 
paramétrable et réaliste que les deux autres qui ont l'avantage d'être 
intégrés à la carte standard OSM.org.


Le 28/08/2020 à 22:12, Yves P. a écrit :
En fait, suivant le cas: autre chemin disponible à côté ou pas, on 
prend, ou pas, l'escalier.


  * Calculateur d'itinéraires
  o BRouter


 (pas
d'escaliers)
  o GraphHopper


  o OSRM




BRouter fait bien le travail (même sans lui demander d'éviter les 
escaliers, le calcul vélo ne passe pas par l'escalier).


Tous ne passent pas par la boucle 
 car 
elle est… privée ;)


__
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] BANO est-il mort?

2020-08-29 Diskussionsfäden Vincent de Château-Thierry


Le 29/08/2020 à 10:56, PanierAvide a écrit :
Le point soulevé n'était pas sur le projet du mois, mais sur la 
nécessité d'une communication *bienveillante*.



Même si les intentions sont bonnes (c'est souvent le cas), les *demandes 
expéditives sont usantes* : une personne bénévole n'est pas un robot 
sans âme soumis à bons de commandes. De la même manière qu'on ne peut 
pas attendre d'OSM une qualité irréprochable des données sur l'ensemble 
de la planète, on ne peut pas attendre une garantie de service 100% ou 
une actualisation des briques logicielles en sprints agiles toutes les 4 
semaines. On souhaite tous faire avancer le bien commun, faisons-le dans 
une ambiance bienveillante et accueillante. À quoi ça sert de défendre 
un modèle d'ouverture sur les logiciels et données si c'est pour 
communiquer comme le N+1 d'une multinationale qui n'a aucun respect pour 
son équipe.


Une communication bienveillante ne veut pas dire qu'on ne peut pas 
améliorer la disponibilité ou la rapidité de mise à jour des logiciels, 
mais dans ce cas il faut :


- Soit *mettre la main à la pâte* (on n'est jamais mieux servi que par 
soi-même) et travailler à plusieurs sur les outils critiques (assurer 
une continuité de maintenance)


- Soit trouver un *budget* (donc émettre un _vrai_ bon de commande) pour 
que les personnes qui maintiennent actuellement les services y 
consacrent du temps salarié.


Et si on a ni le temps ni l'argent, *revoir ses priorités* ou comprendre 
qu'une personne bénévole ait des priorités différentes (travail, 
famille, besoin de s'aérer...). Même si c'est dommage que tel service 
soit indisponible, ça arrive, c'est la vie. On est tous bénévoles dans 
ce projet, n'infligeons pas à autrui ce que l'on n'aimerait pas qu'on 
nous fasse. Le sujet de l'accueil des nouveaux est récurrent, n'oublions 
pas que si la communauté doit se renouveler, c'est aussi à cause de*la 
fatigue des personnes présentes de longue date*. Alors évitons de leur 
rajouter une couche de fatigue inutile.



Quand je remonte un problème, soit j'ai la capacité d'aider donc j'aide, 
soit je n'ai pas la capacité et dans ce cas le problème est remonté en 
mode "*bouteille à la mer*". Un guide de bonnes pratiques :


- Commencer par du *positif* : merci pour cet outil/base/... qui est 
d'un grand service. Les français sont les champions du monde pour râler, 
mais très peu iront vous remercier d'un service utile.


- *Détailler* le problème : je rencontre tel problème, dans tel contexte 
technique, à telle adresse... Plus la demande est détaillée, plus le 
problème sera simple à identifier


- *Proposer* une ou des solutions si on peut les envisager, ne pas 
hésiter à illustrer avec maquettes, captures d'écran...


- Et enfin *remercier* pour le temps qui pourra être consacré à cette 
demande, tout en n'attendant pas une réponse immédiate ni une résolution 
rapide.


Du point de vue extérieur, ça semble idiot de faire des ronds de jambe. 
Pourtant à l'usage ça réduit largement la charge mentale des personnes 
qui maintiennent ces services. Chacun a suffisamment de stress dans sa 
vie pour ne pas vouloir s'en rajouter avec des projets bénévoles. Donc 
évitons de *dégoûter* à tout jamais les personnes suffisamment motivées 
pour consacrer du temps au bien commun en communiquant avec elles comme 
à des sous-traitants pour lesquels on aurait aucun respect. C'était une 
des tendances lors des présentations du Sotm monde en ligne : la vraie 
valeur d'OSM n'est pas dans ses données, mais dans sa *communauté*.



En résumé, ne disons pas à Vincent "/BANO est mort, c'est con quand 
même/", mais disons lui "/Merci pour avoir contribué toutes ces années à 
BANO et merci pour ton engagement régulier. Si nous pouvons t'aider, 
nous le ferons volontiers. Si nous ne pouvons pas, sache que ce service 
nous est bien utile dans notre contribution, et que nous serons contents 
de pouvoir le retrouver le moment venu./".


Cordialement,

Adrien P.


Rien à ajouter à part un *grand* merci à toi Adrien

vincent

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


Re: [OSM-talk-fr] No U-turn vs BRouter

2020-08-29 Diskussionsfäden Frédéric Rodrigo

C'est la relation dans OSM qui est problématique.

Le node via à mon avis devrait coté giratoire et pas au milieu de la 
ligne droite.


https://www.openstreetmap.org/relation/7488769#map=16/45.7905/-1.1526



Le 29/08/2020 à 14:42, Francois Gouget a écrit :

J'ai rencontré un problème de routage bizarre avec BRouter. C'est une
relation No U-turn sur un noeud qui semble être la source du problème.
Mais comme je ne connais pas le fonctionnement de ces relations je ne
sais pas si le problème se trouve dans les données OSM ou dans le code
de BRouter (je n'ai pas trouvé de bug BRouter qui semble lié).

Voici le noeud qui, je pense, pose problème :
https://www.openstreetmap.org/node/965521503#map=19/45.79175/-1.15111

Et voici le trajet voiture crée par BRouter. Ça fait quand même un sacré
détour ! En vélo ou à pied il n'y a pas de problème par contre.

http://brouter.de/brouter-web/#map=19/45.79194/-1.15119/standard=-1.151057,45.791798;-1.151201,45.791643=car-fast


GraphHopper n'a pas ce problème de routage mais je ne sais pas s'il
traite les No U-Turn.



___
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] BANO est-il mort?

2020-08-29 Diskussionsfäden Philippe Verdy
En plus ta réponse est typique ici d'un "privilégié" qui a des moyens et
son club autour de lui, et très parisiano-centrée (ou dans les quelques
grandes villes où se réunir à plusieurs ne coûte pas cher ou qui dispose de
moyens qu'on lui donne généreusement sans gros effort de sa part).

Je suis très isolé et n'ai pas du tout les moyens de faire des centaines de
kilomètres régulièrement pour trouver des contacts réguliers. Mes seuls
moyens sont le temps que je peux donner et parce que ça m'occupe et
m'intéresse, mais pour ce temps très important que je consacre, je ne suis
jamais remercié, juste critiqué et ce temps qui pourtant devrait avoir une
valeur monétaire (le temps c'est de l'argent) ne me rapporte strictement
rien et me coûte aussi de l'argent de temps en temps (pour le matériel
utilisé, ou à réparer/renouveler, mais moins que ce que coûterait les
loisirs de base qui vous semblent faciles à votre porté). Pourtant je fais
tous les efforts possibles.

Mais je reste isolé dans mon coin (dans un région où la socialisation est
très peu développée et très intolérante avec des fractures sociales
évidentes), comme beaucoup de contributeurs qui sont isolés dans leurs
campagne, et doivent subir ce qui se décide ailleurs.

J'ai eu des moyens dans le passé (mais j'avais moins de temps), je ne les
ai plus depuis polusieurs années. OSM c'est une occupation pour ne pas
m'ennuyer et qui ne me coûte pas trop cher, car hors de ça je ne suis aidé
par personne. Et à Niort, les quelques personnes intéressé dans le projet
se réunissent dans des lieux où je ne peux pas aller, ou ils demandent des
contributions, modiques pour eux, mais que je n'ai pas les moyens de faire.
Ils sont en "comités restreints" entre personnes du même milieu (étudiants,
ou administrations, ou certaines entreprises) et ils se réunissent dans des
salles de réunion louées ou des restaus/bars chics où il faut consommer et
ça je ne peux pas le faire.

Il n'y a aucune structure locale pour réunir des personnes sans grands
moyens, aucun soutien ou implication des collectivités locales pour
réellement ouvrir l'internet et les outils libres à disposition de tous, ou
les former, pas de lieu dédié ouvert à tous (je veux bien qu'il y ait des
contributions demandées à certains utilisateurs mais ceux qui ne les ont
pas ne peuvent bénéficier d'aucune aide). Le groupe "Niort Tech" existe
théoriquement mais ne fonctionne pas du tout, il existe sur le papier mais
le gros se fait entre personnes qui se connaissent travaillent dans leur
milieu dans des entreprises où ces échanges existent naturellement, c'est
assez facile pour eux. Je ne suis d'aucun de ces "clans".

Je n'ai jamais réussie à trouver des contact locaux (à moins de 20
kilomètres, ais même faire 20 kilomètres c'est difficile pour moi aux
horaires planifiés). La perception du projet OSM France est qu'il est très
fermé sur quelques personnes qui veulent tout piloter et pourtant n'ont pas
le temps de le faire.

Même payer une cotisation annuelle, je ne peux pas le faire, c'est trop
cher et j'ai des priorités **vitales** avant ça (par exemple un loyer, pas
plus d'un plein d'essence par mois, parfois moins et quelques euros par
jour pour juste manger, et il m'arrive souvent de ne pas manger du tout
quand il me tombe une tuile ou que je ne peux pas payer des médicaments ou
soins non remboursés pourtant obligatoires, ou encore quand on me taxe
d'office même au delà de mes revenus réels et que l'Etat tarde à me
rembourser les sommes indues prélevées d'office et les frais subis en plus
prélevés directement par ma banque).

De fait je suis forcément obligé de ne contribuer qu'en ligne, à distance.
Mais qui me dit merci à moi ? Je n'ai critiqué personne directement, mais
je suis fatigué d'être cité ad hominem avec des commentaires qui présument
totalement à tort de mes mauvaises intentions alors que j'ai mis les formes
et pris des précautions oratoires.

Et pourtant cet internet qui est mon principal contact social avec "le
monde" est très intolérant, et tout aussi élitiste que peut l'être les
petits groupes qui décident ici et me dénigrent régulièrement. Je dois
dire merci à qui ? Qui me dit merci, personne. Mon temps passé est
totalement dévalué. Porutant je continue car ça m'occupe. Mais
contrairement à ce que font beaucoup sur Internet quand ils s'ennuient je
ne passe pas mon temps à faire des attaques directes ad hominem comme
l'indique le ton TRES agressif avec lequel on m'a répondu ici, sur des
présomptions d'intention qui ne sont pas les miennes.

Merci donc de revoir vos messages. Je suis dans une situation bien plus
difficile que vous. Ne présumez pas de moyens ou de ce que je pourrais
faire. Je fais de mon mieux, comme je peux. Merci de valuer mes efforts.
Mais visiblement c'est lettre morte. L'élitisme règne et l'élite critique
qui elle veut sans conséquence car elle a tout son petit clan puissant
allié derrière elle.

OSM devrait être un projet pour tous destiné à servir tout le monde à
commencer 

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

2020-08-29 Diskussionsfäden Yves P.
> Calculateur d'itinéraires 
> BRouter 
> 
>  (pas d'escaliers)
> GraphHopper 
> 
> OSRM 
> 
Ce qui est bizarre avec GraphHopper, c'est qu'il différencie vélo de route et 
VTT.
Le VTT pourrait emprunter les escaliers :D

Autre escalier avec BRouter :
Cyclotourisme 

Cyclotourisme (pas d'escalier) 

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


Re: [OSM-talk-fr] Adhésion gratuite à l'OSMF

2020-08-29 Diskussionsfäden Eric SIBERT via Talk-fr

Le 29/08/2020 à 09:45, Jean-Claude Repetto a écrit :
Je ne sais pas si c'est récent, mais les contributeurs actifs peuvent 
désormais adhérer gratuitement à l'OSMF:

https://join.osmfoundation.org/active-contributor-membership/


Merci.

J'ai fait ma demande.

Eric

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


[OSM-talk-fr] No U-turn vs BRouter

2020-08-29 Diskussionsfäden Francois Gouget

J'ai rencontré un problème de routage bizarre avec BRouter. C'est une 
relation No U-turn sur un noeud qui semble être la source du problème. 
Mais comme je ne connais pas le fonctionnement de ces relations je ne 
sais pas si le problème se trouve dans les données OSM ou dans le code 
de BRouter (je n'ai pas trouvé de bug BRouter qui semble lié).

Voici le noeud qui, je pense, pose problème :
https://www.openstreetmap.org/node/965521503#map=19/45.79175/-1.15111

Et voici le trajet voiture crée par BRouter. Ça fait quand même un sacré 
détour ! En vélo ou à pied il n'y a pas de problème par contre.

http://brouter.de/brouter-web/#map=19/45.79194/-1.15119/standard=-1.151057,45.791798;-1.151201,45.791643=car-fast


GraphHopper n'a pas ce problème de routage mais je ne sais pas s'il 
traite les No U-Turn.


-- 
Francois Gouget   http://fgouget.free.fr/
   Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] BANO est-il mort?

2020-08-29 Diskussionsfäden Vincent de Château-Thierry

Bonjour,

Le 29/08/2020 à 10:15, Christian Quest a écrit :

Le 28/08/2020 à 21:45, Philippe Verdy a écrit :

Le ton de tes messages sur ce sujet est particulièrement peu 
bienveillant. J'ai hésité à répondre.


A part critiquer à tout va, que proposes-tu de concret (et réaliste, 
parce que repasser la bébé à la fondation il fallait oser) pour 
améliorer la visibilité de BANO, sa documentation, sa qualité ?


Merci Christian pour ces réponses et compléments factuels.

vincent

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


Re: [OSM-talk-fr] BANO est-il mort?

2020-08-29 Diskussionsfäden Philippe Verdy
Le sam. 29 août 2020 à 10:16, Christian Quest  a
écrit :

> Le ton de tes messages sur ce sujet est particulièrement peu bienveillant.
> J'ai hésité à répondre.
>

Mon ton était tout à fait correct et respectueux, je crois que tu en fais
une interprétation trop personnelle. Le fait est que trouver des liens qui
fonctionnent à partie d'une simple recherche de pages les plus visibles
dans un moterur de recherche n'aboutit à rien qui soit à jour et qui
fonctionne réellement.

Je dis simplement que ce sont ces mises à jour qui manquent et qui font
qu'utiliser ou contribuer à BANO est devenu difficile: on s'y perd
réellement, on passe son temps à chercher parmis les divers liens et outils
pour savoir où est le bon ou si les données sont réellement à jour. Même
sur GitHub aussi tout est hors d'age.

> A part critiquer à tout va, que proposes-tu de concret (et réaliste, parce
> que repasser la bébé à la fondation il fallait oser) pour améliorer la
> visibilité de BANO, sa documentation, sa qualité ?
>
Je constate simpelemtn que ce projet est sous-administré et qu'il manque de
ressources **habilitées** à en faire le suivi. Non on ne peut pas faire ça
soi-même ou alors il faut créer un fork séparé: du fait l'intégration est
encore plus difificile et on complexifie le problème: il n'y a pas de base
de référence stable qui fonctionne pour tout le monde.

Donc tu as pris ça beaucoup trop à coueur comme si c'était une attaque
personnelle alors que je ne t'ai pas cité du tout. J'ai demandé juste
l'avis de tout le monde. La perception que j'en ai est que le projet BANO
ne fonctionne pas (en tout cas pas certainement pas mieux que le projet BAN
qui, lui semble aller bien plus vite même s'il est, en principe, moins
ouvert.)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] BANO est-il mort?

2020-08-29 Diskussionsfäden Philippe Verdy
Le sam. 29 août 2020 à 10:57, PanierAvide  a écrit :

> Le point soulevé n'était pas sur le projet du mois, mais sur la nécessité
> d'une communication *bienveillante*.
>
>
> Même si les intentions sont bonnes (c'est souvent le cas), les *demandes
> expéditives sont usantes* : une personne bénévole n'est pas un robot sans
> âme soumis à bons de commandes. De la même manière qu'on ne peut pas
> attendre d'OSM une qualité irréprochable des données sur l'ensemble de la
> planète, on ne peut pas attendre une garantie de service 100% ou une
> actualisation des briques logicielles en sprints agiles toutes les 4
> semaines. On souhaite tous faire avancer le bien commun, faisons-le dans
> une ambiance bienveillante et accueillante. À quoi ça sert de défendre un
> modèle d'ouverture sur les logiciels et données si c'est pour communiquer
> comme le N+1 d'une multinationale qui n'a aucun respect pour son équipe.
>
> Une communication bienveillante ne veut pas dire qu'on ne peut pas
> améliorer la disponibilité ou la rapidité de mise à jour des logiciels,
> mais dans ce cas il faut :
>
> - Soit *mettre la main à la pâte* (on n'est jamais mieux servi que par
> soi-même) et travailler à plusieurs sur les outils critiques (assurer une
> continuité de maintenance)
>

Ce que je ne peux pas faire.

> - Soit trouver un *budget* (donc émettre un _vrai_ bon de commande) pour
> que les personnes qui maintiennent actuellement les services y consacrent
> du temps salarié.
>

Un budget que je n'ai pas.


> Et si on a ni le temps ni l'argent, *revoir ses priorités* ou comprendre
> qu'une personne bénévole ait des priorités différentes (travail, famille,
> besoin de s'aérer...). Même si c'est dommage que tel service soit
> indisponible, ça arrive, c'est la vie. On est tous bénévoles dans ce
> projet, n'infligeons pas à autrui ce que l'on n'aimerait pas qu'on nous
> fasse. Le sujet de l'accueil des nouveaux est récurrent, n'oublions pas que
> si la communauté doit se renouveler, c'est aussi à cause de* la fatigue
> des personnes présentes de longue date*. Alors évitons de leur rajouter
> une couche de fatigue inutile.
>
C'est exactement ce que j'ai déjà écrit ici. Tu reformules mon message.

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


Re: [OSM-talk-fr] BANO est-il mort?

2020-08-29 Diskussionsfäden osm . sanspourriel

Bonjour,

Oui Philippe c'est pour toi ad nominem mais pas que.

Je précise que je suis dans un hameau, que l'agglomération fait de
l'ordre de 200 000 habitants et que j'ai dû faire une réunion (une
bouffe) avec deux contributeurs local et de passage.

Que je suis moi aussi actuellement à la recherche d'un emploi (après
avoir fait de la cartographie notamment autour d'OSM en entreprise).
Voilà pour le contexte.

Le 29/08/2020 à 15:32, Philippe Verdy - ver...@gmail.com a écrit :

De fait je suis forcément obligé de ne contribuer qu'en ligne, à
distance. Mais qui me dit merci à moi ?


Pas plus mais pas moins qu'à des milliers de contributeurs.


Je n'ai critiqué personne directement, mais je suis fatigué
d'être cité ad hominem avec des commentaires qui présument totalement
à tort de mes mauvaises intentions alors que j'ai mis les formes et
pris des précautions oratoires.


Non  il est question de bienveillance, qui n'est pas l'opposé de la la
malveillance. Personne n'a dit que tu étais malveillant.

Tu as critiqué globalement la gestion des priorités d'OSM.

Mettant notamment en opposition BANO V2 et le projet du mois.

Il se trouve que sur BANO V2 vdct et Christian Quest sont a priori les
seuls à pouvoir contribuer (du fait de leurs connaissances et de leurs
temps disponible pour permettre à d'autres de raccrocher les wagons).

Les seuls ? Non pas vraiment. Tu dis que certains outils ne marchent pas
(plus), que certains liens de certaines pages sont morts.

Que fait de ça ? *Rien.*

Tu aggraves ton "cas" en précisant que tu ne peux faire mieux alors que
Christian t'a donné des pistes :

- quels outils ne marchent pas, en partant d'où en suivant quelle
recette ? Là il y a peut-être d'autres recettes qui marchent et certains
sur la liste peuvent te répondre.
- quels pages pointent sur quel liens qui ne marchent pas ? Par quels
nouveaux liens les remplacer ?

Sans cela tu es à classer parmi les yakafaukons. Et ça ce n'est pas
agréable à entendre mais pour ceux qui contribuent sur les outils et les
pages ce n'est pas agréable de recevoir des messages de yakafaukons
exprimant un mécontentement inexploitable.

Tu peux aussi demander récupérer la page en question sur ton espace
wiki, la modifier pour corriger les soucis et signaler que la page peut
être reprise sur OSM FR (car on comprend que c'est sur ces pages qu'il y
aurait des choses à modifier).

De même pour les outils, tu peux créer un ticket expliquant ce qui ne
marche pas.

Pour revenir sur l'opposition BANO V2/projet du mois elle était
entendable quand Adrien a proposé de travailler sur les DAE.

Protester après c'est juste à contre-temps.


Et pourtant cet internet qui est mon principal contact social avec "le
monde" est très intolérant, et tout aussi élitiste que peut l'être les
petits groupes qui décident ici et me dénigrent régulièrement.

Pour les locaux, je ne me prononce pas. Si tu te comportes comme ici ce
n'est pas étonnant : tu te places sur le message "BANO est-il mort?"
comme un pur demandeur.

Je dois dire merci à qui ? Qui me dit merci, personne. Mon temps passé
est totalement dévalué. Porutant je continue car ça m'occupe. Mais
contrairement à ce que font beaucoup sur Internet quand ils s'ennuient
je ne passe pas mon temps à faire des attaques directes ad hominem
comme l'indique le ton TRES agressif avec lequel on m'a répondu ici,
sur des présomptions d'intention qui ne sont pas les miennes.


Il n'est pas question d'intentions mais de fait : que faire de ton
message disant qu'il y a des trucs qui ne marchent pas sur BANO ?

Dois-je rappeler le titre du message "BANO est-il mort?" alors qu'il y a
eu des messages sur BANO V2 ici et que des outils V2 permettent
d'intégrer des adresses du cadastre :

http://dev.cadastre.openstreetmap.fr/fantoir/#insee==0
 (cliquer
sur Relation).

Donc non BANO n'est pas mort. Tu peux contribuer. Deux bonnes nouvelles.


Merci donc de revoir vos messages.

Toi aussi, y compris les tiens.

Je suis dans une situation bien plus difficile que vous.

Ce n'est pas un concours ! Ce n'est pas l'objet du grief.

Ne présumez pas de moyens ou de ce que je pourrais faire. Je fais de
mon mieux, comme je peux.

Non, tu peux faire mieux. Tu peux le prendre comme une claque ou au
contraire comme expliqué ci-dessus que tu peux participer de chez toi.
Et écoutant ce que disent les gens plutôt qu'en prenant ça pour des
attaques.

Merci de valuer mes efforts. Mais visiblement c'est lettre morte.
L'élitisme règne et l'élite critique qui elle veut sans conséquence
car elle a tout son petit clan puissant allié derrière elle.

Rassure-toi, le jour ou Adrien, Christian ou Vdct dit une connerie, ça
ne me gêne pas de la relever. Mais en mettant les formes, ça ne mange
pas de pain.

OSM devrait être un projet pour tous destiné à servir tout le monde à
commencer par ceux qui en ont le plus besoin. Je ne fais pas que
l'utiliser, j'essaye de me rendre utile, et c'est pour ça que je

[Talk-GB] London's COVID infrastructure and Low Traffic Neighbourhoods

2020-08-29 Diskussionsfäden Simon Still
A couple of blog posts on London Cycling Campaign that may be of interest 

finding-your-way-on-londons-cycle-infrastructure-1 


signage-and-wayfinding 

Low traffic neighbourhoods 
(https://lambethcyclists.org.uk/a-vision-for-lambeth/low-traffic-neighbourhoods/
 
)
 present an interesting challenge for OSM based routing algorithms. 

The generally offer a significant upgrade to the cycling experience within 
their boundaries by significantly reducing motor traffic volumes. The biggest 
change tends to be on the roads of most use to cyclists (ie the ones that 
provide a useful, direct, alternative to the surrounding main roads, or a short 
cut).  Before an LTN these are likely to be busy with rat running traffic. An 
LTN removes that. 

However, I’m not sure how these can be best represented in OSM so that routing 
algorithms can take account of them. As I understand it, in the absence of a 
signed cycle route algorithms won’t see any change in the experience of cycling 
on the roads within the zone.

What do people suggest?  Could we mark LTN boundaries (in the way that the 
congestion charging zone is marked)? Should cycle campaigners be pushing for 
routes through LTNs to be designated and signed?


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


[Talk-GB] Tagging of solar panels - number of modules

2020-08-29 Diskussionsfäden Donald Noble
Hi,

I have a query regarding tagging of solar panels, and specifically the
number of modules for (domestic) rooftops. I have been tagging these with
just generator:modules, but I see that generator:solar:modules is a lot
more popular on TagInfo [1], although I don't seem to find specific
documentation on the solar mapping page.

This issue came up as I was surprised by the low percentage for Edinburgh
with a number of modules on Gregory William's excellent Solar Mapping stats
page [2].

If there is a clear consensus, I will re-tag those I have added (which is
possibly a significant number of the 1161)

Cheers, Donald


[1] https://taginfo.openstreetmap.org.uk/search?q=modules
Count
Key
13 906
generator:solar:*modules*

1 161
generator:*modules*

2
plant:solar:*modules*

1
*modules* 

[2] http://osm.gregorywilliams.me.uk/solar/index.html
-- 
Donald Noble
http://drnoble.co.uk - http://flickr.com/photos/drnoble
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


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

2020-08-29 Diskussionsfäden osm . sanspourriel

Le 29/08/2020 à 19:24, deuzeffe - opensm@deuzeffe.org a écrit :

i un ou une wizard voulait bien m'expliquer ces différences de
comportement : ordre des couches, encombrement stérique des noms,
"cékomssa", explication toute bête, autres, je l'en remercie d'avance.


Dans le second cas il y a une fontaine, or les icônes font partie de
l'encombrement stérique, il n'y a pas que les noms.

Donc les rendus affichant les fontaines n'ont pas la place d'afficher le
nom (en fait à un certain niveau de zoom en ne centrant pas ce serait
possible). Les autres si.

Mandrake le Magicien



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


Re: [OSM-talk-fr] BANO est-il mort?

2020-08-29 Diskussionsfäden Philippe Verdy
Non je ne suis pas un yakafaucon.

Les "yakafaucons", on m'en ordonne s'en arrêt sans se préoccuper si j'ai
les moyens même de les appliquer.

Les solutions simplistes ce n'est pas moi qui les donne. Je n'ai fait qu'un
constat. Les "yakafaucons" viennent trop souvent ceux qui nient
l'évidence et ne sortent pas de leur bulle du haut de leur hiérarchie et ne
se retournent pas sur ce qu'ils ont fait pour demander l'avis et
l'impression laissée.

Mes remarques ne désobligent personne directement. Si vraiment OSM me
répulsait, je n'y contribuerais pas autant et je n'y passerais pas autant
de temps. Mais n'ayant pas les moyens et privilèges de ceux qui nous
dirigent, je suis bien obligé de subir leurs décisions, mais on a le droit
de faire des constats d'usage sur ce qui ne fonctionne plus ou est resté
délaissé par eux (qui ont choisi tous seuls d'autres priorités que celles
qui au départ avait été définies comme essentielles pour le plus grand
nombre).

S'ils ont moins de temps à s'occuper de ça, c'est à eux que revient la
responsabilité de déléguer et ouvrir le système en place, même si d'autres
qu'eux iront sur des choix et arbitrages différents. il n'y a pas assez de
délégation, "l'équipe dirigeante" est trop petite et constitue plus un
frein pour tout le monde si elle se disperse en changeant unilatéralement
les priorités sans le dire réellement et sans passer le relais.




Le sam. 29 août 2020 à 18:35,  a écrit :

> Bonjour,
>
> Oui Philippe c'est pour toi ad nominem mais pas que.
>
> Je précise que je suis dans un hameau, que l'agglomération fait de l'ordre
> de 200 000 habitants et que j'ai dû faire une réunion (une bouffe) avec
> deux contributeurs local et de passage.
>
> Que je suis moi aussi actuellement à la recherche d'un emploi (après avoir
> fait de la cartographie notamment autour d'OSM en entreprise). Voilà pour
> le contexte.
> Le 29/08/2020 à 15:32, Philippe Verdy - ver...@gmail.com a écrit :
>
> De fait je suis forcément obligé de ne contribuer qu'en ligne, à distance.
> Mais qui me dit merci à moi ?
>
> Pas plus mais pas moins qu'à des milliers de contributeurs.
>
> Je n'ai critiqué personne directement, mais je suis fatigué d'être cité ad
> hominem avec des commentaires qui présument totalement à tort de mes
> mauvaises intentions alors que j'ai mis les formes et pris des précautions
> oratoires.
>
> Non  il est question de bienveillance, qui n'est pas l'opposé de la la
> malveillance. Personne n'a dit que tu étais malveillant.
>
> Tu as critiqué globalement la gestion des priorités d'OSM.
>
> Mettant notamment en opposition BANO V2 et le projet du mois.
>
> Il se trouve que sur BANO V2 vdct et Christian Quest sont a priori les
> seuls à pouvoir contribuer (du fait de leurs connaissances et de leurs
> temps disponible pour permettre à d'autres de raccrocher les wagons).
>
> Les seuls ? Non pas vraiment. Tu dis que certains outils ne marchent pas
> (plus), que certains liens de certaines pages sont morts.
>
> Que fait de ça ? *Rien.*
>
> Tu aggraves ton "cas" en précisant que tu ne peux faire mieux alors que
> Christian t'a donné des pistes :
>
> - quels outils ne marchent pas, en partant d'où en suivant quelle recette
> ? Là il y a peut-être d'autres recettes qui marchent et certains sur la
> liste peuvent te répondre.
> - quels pages pointent sur quel liens qui ne marchent pas ? Par quels
> nouveaux liens les remplacer ?
>
> Sans cela tu es à classer parmi les yakafaukons. Et ça ce n'est pas
> agréable à entendre mais pour ceux qui contribuent sur les outils et les
> pages ce n'est pas agréable de recevoir des messages de yakafaukons
> exprimant un mécontentement inexploitable.
>
> Tu peux aussi demander récupérer la page en question sur ton espace wiki,
> la modifier pour corriger les soucis et signaler que la page peut être
> reprise sur OSM FR (car on comprend que c'est sur ces pages qu'il y aurait
> des choses à modifier).
>
> De même pour les outils, tu peux créer un ticket expliquant ce qui ne
> marche pas.
>
> Pour revenir sur l'opposition BANO V2/projet du mois elle était entendable
> quand Adrien a proposé de travailler sur les DAE.
>
> Protester après c'est juste à contre-temps.
>
> Et pourtant cet internet qui est mon principal contact social avec "le
> monde" est très intolérant, et tout aussi élitiste que peut l'être les
> petits groupes qui décident ici et me dénigrent régulièrement.
>
> Pour les locaux, je ne me prononce pas. Si tu te comportes comme ici ce
> n'est pas étonnant : tu te places sur le message "BANO est-il mort?" comme
> un pur demandeur.
>
> Je dois dire merci à qui ? Qui me dit merci, personne. Mon temps passé est
> totalement dévalué. Porutant je continue car ça m'occupe. Mais
> contrairement à ce que font beaucoup sur Internet quand ils s'ennuient je
> ne passe pas mon temps à faire des attaques directes ad hominem comme
> l'indique le ton TRES agressif avec lequel on m'a répondu ici, sur des
> présomptions d'intention qui ne sont pas les miennes.
>
> Il 

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

2020-08-29 Diskussionsfäden deuzeffe

Bonjour,

Suivant le rendu consulté, des noms de leisure=garden s'affichent ou pas.

Exemple :
- soient les deux polygones suivants : 1/ 
https://www.openstreetmap.org/way/67527 et 2/ 
https://www.openstreetmap.org/way/294951535

- au nom près, les attributs sont les mêmes (mêmes couples champ/valeur)
- le nom de 1/ s'affiche mais pas celui de 2/ sur le rendu standard 
https://www.openstreetmap.org/#map=19/45.79721/1.14039 ou le rendu 
osm-fr en dev 
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#19/45.79725/1.14056 
(osmfr-cartocss étant, vu son nom un fork de Mapnik-cartoCSS, ça parait 
logique ?) ;
- les deux noms s’affichent sur le rendu cyclable standard 
https://www.openstreetmap.org/#map=19/45.79721/1.14039=C et le 
rendu HOT (qui patine un peu, au passage) 
https://www.openstreetmap.org/#map=19/45.79731/1.14025=H



Si un ou une wizard voulait bien m'expliquer ces différences de 
comportement : ordre des couches, encombrement stérique des noms, 
"cékomssa", explication toute bête, autres, je l'en remercie d'avance.


--
deuzeffe, qui aime bien comprendre pourquoi ça pas marche.

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


Re: [Talk-GB] Tagging of solar panels - number of modules

2020-08-29 Diskussionsfäden Dan S
Hi Donald,

If I remember right, we started off last year tagging it as
"generator:modules" but then fairly early on changed to
"generator:solar:modules" to make the tag clearer. The latter's been the
recommendation on this wiki page, for a good while:
https://wiki.openstreetmap.org/wiki/Renewable_energy_in_the_United_Kingdom/Rooftop_Solar_PV

I don't know which tag(s) Gregory's page picks up, but in my (separate)
processing I've been handling both tag variants.

Cheers
Dan

Op za 29 aug. 2020 om 18:47 schreef Donald Noble :

> Hi,
>
> I have a query regarding tagging of solar panels, and specifically the
> number of modules for (domestic) rooftops. I have been tagging these with
> just generator:modules, but I see that generator:solar:modules is a lot
> more popular on TagInfo [1], although I don't seem to find specific
> documentation on the solar mapping page.
>
> This issue came up as I was surprised by the low percentage for Edinburgh
> with a number of modules on Gregory William's excellent Solar Mapping stats
> page [2].
>
> If there is a clear consensus, I will re-tag those I have added (which is
> possibly a significant number of the 1161)
>
> Cheers, Donald
>
>
> [1] https://taginfo.openstreetmap.org.uk/search?q=modules
> Count
> Key
> 13 906
> generator:solar:*modules*
> 
> 1 161
> generator:*modules*
> 
> 2
> plant:solar:*modules*
> 
> 1
> *modules* 
>
> [2] http://osm.gregorywilliams.me.uk/solar/index.html
> --
> Donald Noble
> http://drnoble.co.uk - http://flickr.com/photos/drnoble
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] Tagging of solar panels - number of modules

2020-08-29 Diskussionsfäden gregory
  
  
  
IIRC the code for my site only picks up "generator:solar:modules". It also 
picks up "generator:orientation" and "location".
  

  
Incidentally, I think that we've been a bit inconsistent with the latter of 
these. I think that the recommendation is for "roof" and "surface", but I know 
that I've managed to map many as "ground" too, when I've intended the same 
meaning as "surface". I've gradually changed the ones I've mapped over to 
"surface" as and when I've stumbled upon them.
  

  
  
  
  
  
>   
> On 29 Aug 2020 at 19:02, Dan Swrote:
>   
> 
>   
> Hi Donald,
>   
>
>   
> If I remember right, we started off last year tagging it as 
> "generator:modules" but then fairly early on changed to 
> "generator:solar:modules" to make the tag clearer. The latter's been the 
> recommendation on this wiki page, for a good while:
>   
>  
> https://wiki.openstreetmap.org/wiki/Renewable_energy_in_the_United_Kingdom/Rooftop_Solar_PV
>   
>
>   
> I don't know which tag(s) Gregory's page picks up, but in my (separate) 
> processing I've been handling both tag variants.
>   
>
>   
> Cheers
>   
> Dan
> 
>   
>   
> Op za 29 aug. 2020 om 18:47 schreef Donald Noble  :
>   
> >   
> > Hi,  
> >
> >   
> > I have a query regarding tagging of   solar panels, and specifically the 
> > number of modules for (domestic) rooftops. I have been tagging these with 
> > just generator:modules, but I see that generator:solar:modules is a lot 
> > more popular   on TagInfo [1], although I don't seem to find specific 
> > documentation on the   solar mapping page.   
> >   
> >
> >   
> > This issue came up as I was surprised   by the low percentage for Edinburgh 
> > with a number of modules on Gregory William's excellent   Solar Mapping 
> > stats page [2].
> >   
> >
> >   
> >   
> >
> >   
> > If there is a clear consensus, I will re-tag those I have added (which is 
> > possibly a significant number of the 1161)
> >   
> >
> >   
> > Cheers, Donald
> >   
> >
> >   
> >
> >   
> > [1]   https://taginfo.openstreetmap.org.uk/search?q=modules
> >   
> >   
> >   
> >   
> >   
> >   
> >   
> >   
> >  Count
> >   
> >   
> >   
> >  Key
> >   
> >   
> >   
> >   
> >   
> >   
> >   
> >   
> >   
> >   
> >   
> >   
> >   
> >   
> >   
> >   
> >   
> >   
> >  13 906
> >   
> >   
> >   
> >   generator:solar:modules
> >   
> >   
> >   
> >   
> >   
> >  1 161
> >   
> >   
> >   
> >   generator:modules
> >   
> >   
> >   
> >   
> >   
> >  2
> >   
> >   
> >   
> >   plant:solar:modules
> >   
> >   
> >   
> >   
> >   
> >  1
> >   
> >   
> >   
> >   modules
> >   
> >   
> >   
> >   
> >   
> >   
> >   
> >
> >   
> > [2]   http://osm.gregorywilliams.me.uk/solar/index.html
> >  --
> >   
> > Donald Noble
> >   http://drnoble.co.uk  -  http://flickr.com/photos/drnoble  
> > ___
> >  Talk-GB mailing list
> >   Talk-GB@openstreetmap.org
> >   https://lists.openstreetmap.org/listinfo/talk-gb
> 
>   
>  ___ Talk-GB mailing list 
> Talk-GB@openstreetmap.org   https://lists.openstreetmap.org/listinfo/talk-gb  
>  
>   
 ___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [OSM-talk-fr] Projet du mois défibrillateurs : c'est parti ! données foireuses de GéoDAE

2020-08-29 Diskussionsfäden osm . sanspourriel

Le 29/08/2020 à 10:18, Christian Quest - cqu...@openstreetmap.fr a écrit :


On a du coup un certain nombre de DAE sur Null Island.


Le 29/08/2020 à 10:27, Yves P. - yves.prat...@gmail.com a écrit :

Tous les DAE ont des coordonnées. Seulement 227 avec lat/lon = 0,0


Pour info, Ils sont dans ces communes :
Cornil216


Corps Nil, nom prédestiné pour la bouée Null Island ? ;-)

216 DAE pour 1340 habitants, je crois que c'est le territoire de la
République le mieux doté en DAE^^.

Une erreur dans la base ? Dans ta recherche ?

On a d'autres soucis avec reception_desk et security_desk

https://github.com/osm-fr/osmose-backend/blob/master/analysers/analyser_merge_defibrillators_FR.py#L81-91

On prend ce qui est dans GéoDAE. Mais cette information est "foireuse"
même si elle a été "validée".

Prenons
http://osmose.openstreetmap.fr/fr/error/c986fd47-f342-8ba3-0301-6419922f554d


 * gml_id : geodae_publique.15665
 * gid : 15665
 * *c_etat_valid :* *validées*
 * *c_nom :* *DAE ACCUEIL MANOIR DE KERNAULT*
 * c_lat_coor1 : 47.8884
 * c_long_coor1 : -3.59755
 * c_adr_num : 360
 * c_adr_voie : 360 Château de Kernault 29300 Mellac
 * c_com_cp : 29300
 * c_com_insee : 29147
 * c_com_nom : Mellac
 * *c_acc :* Intérieur
 * *c_acc_lib :* t
 * *c_acc_pcsec :* f
 * *c_acc_acc :* f
 * c_disp_j : {lundi,mardi,mercredi,jeudi,vendredi}
 * c_disp_h : {"heures ouvrables"}
 * c_etat_fonct : En fonctionnement
 * c_etat : Actif
 * c_doublon : f
 * timePosition : 2020-07-16T16:21:36Z
 * c_srid_origin : EPSG:4326

Osmose propose :

access  yes
emergency   defibrillator
indoor  yes
operatorChemins du Patrimoine En Finistère
operator:ref:FR:SIREN   282900463
*reception_desk*no
ref:FR:GeoDAE   15666
*security_desk* no
*source*Direction Générale de la Santé

On a déjà eu le cas où ces "informations" quoique "validées" sont fausses.

Comme le psuedo-nom est DAE *ACCUEIL* MANOIR DE KERNAULT, j'en déduis
qu'au moins reception_desk est faux.

Dans tous les cas ce sont des propriétés du bâtiment pas du DAE.

Je suis donc partisan de ne pas les intégrer. Ce n'est pas le premier
cas du genre signalé sur la liste.

De plus ça ne me semble pas apporter grand chose (parce que c'est une
donnée dans GéoDAE et que je ne vois pas trop à quoi ça sert : si les
pompiers arrivent sur place ils verront bien s'il y a un accueil ou une
sécurité).

Et si l'accueil ou la sécurité sont supprimés, pensez-vous que GéoDAE
sera mis à jour ?

Vous vous doutez de ma réponse ;-)

Source : ne faut-il pas millésimer ? Version Adrien : je suggère de
millésimer la source comme pour les autres données, peut-être ici plutôt
un check_date=2020-07-16 ;-).

Position : foireuse (proche mais à l'extérieur du bâti malgré
indoor=yes). On met un fixme=geometry ?

Via le site internet (absent initialement d'OSM) j'ai trouvé la position
assez précise de l'accueil parmi les différents bâtiments.

Jean-Yvon



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


Re: [OSM-talk-fr] BANO est-il mort?

2020-08-29 Diskussionsfäden PanierAvide
Merci Philippe d'avoir pris le temps d'apporter une réponse complète 
dans un exposé clair. Je me permets de répondre par points dans le message.


Adrien P.

Le 29/08/2020 à 15:32, Philippe Verdy a écrit :
En plus ta réponse est typique ici d'un "privilégié" qui a des moyens 
et son club autour de lui, et très parisiano-centrée (ou dans les 
quelques grandes villes où se réunir à plusieurs ne coûte pas cher ou 
qui dispose de moyens qu'on lui donne généreusement sans gros effort 
de sa part).


On devrait échanger de vive voix, on a peut-être plus de points communs 
que tu ne l'imagines. Le "club" en question est un groupe local sur 
Rennes qui propose des évènements toujours gratuits, toujours dans des 
lieux accessibles en transport en commun et autant que possible 
accessibles PMR. Ce groupe tourne avec un budget réduit (un double de 
clés d'une salle fait en 2019, un remboursement de covoiturage pour un 
atelier sur Vitré). On réserve le même accueil peu importe l'âge, 
l'origine, la religion, les moyens...


C'est sûr c'est en ville, pas accessible à tout le monde. J'en fais 
moi-même les frais : 1h aller-retour depuis la campagne pour assister 
aux réunions. Mais peu importe où on ferait ces activités, la mobilité 
sera excluante. Le mieux est donc de multiplier les activités et les 
lieux, mais pour ça on doit pouvoir mobiliser plus de contributeurs 
partout. Malheureusement les ressources de chacun sont limitées, cf le 
courriel précédent.



Je suis très isolé et n'ai pas du tout les moyens de faire des 
centaines de kilomètres régulièrement pour trouver des contacts 
réguliers. Mes seuls moyens sont le temps que je peux donner et parce 
que ça m'occupe et m'intéresse, mais pour ce temps très important que 
je consacre, je ne suis jamais remercié, juste critiqué et ce temps 
qui pourtant devrait avoir une valeur monétaire (le temps c'est de 
l'argent) ne me rapporte strictement rien et me coûte aussi de 
l'argent de temps en temps (pour le matériel utilisé, ou à 
réparer/renouveler, mais moins que ce que coûterait les loisirs de 
base qui vous semblent faciles à votre porté). Pourtant je fais tous 
les efforts possibles.


Ce constat que tu fais est aussi la réalité d'autres personnes qui 
contribuent à OSM. C'est pour cela que j'appuie la nécessité d'une 
communication bienveillante. D'où mon message pour d'abord annoncer du 
positif avant de proposer des améliorations. À noter que l'asso OSM 
France peut rembourser des frais liés aux activités autour d'OSM, il 
suffit de formuler une demande quelques jours avant.



Mais je reste isolé dans mon coin (dans un région où la socialisation 
est très peu développée et très intolérante avec des 
fractures sociales évidentes), comme beaucoup de contributeurs qui 
sont isolés dans leurs campagne, et doivent subir ce qui se décide 
ailleurs.


J'ai eu des moyens dans le passé (mais j'avais moins de temps), je ne 
les ai plus depuis polusieurs années. OSM c'est une occupation pour ne 
pas m'ennuyer et qui ne me coûte pas trop cher, car hors de ça je ne 
suis aidé par personne. Et à Niort, les quelques personnes intéressé 
dans le projet se réunissent dans des lieux où je ne peux pas aller, 
ou ils demandent des contributions, modiques pour eux, mais que je 
n'ai pas les moyens de faire. Ils sont en "comités restreints" entre 
personnes du même milieu (étudiants, ou administrations, ou certaines 
entreprises) et ils se réunissent dans des salles de réunion louées ou 
des restaus/bars chics où il faut consommer et ça je ne peux pas le faire.


Il n'y a aucune structure locale pour réunir des personnes sans grands 
moyens, aucun soutien ou implication des collectivités locales pour 
réellement ouvrir l'internet et les outils libres à disposition de 
tous, ou les former, pas de lieu dédié ouvert à tous (je veux bien 
qu'il y ait des contributions demandées à certains utilisateurs mais 
ceux qui ne les ont pas ne peuvent bénéficier d'aucune aide). Le 
groupe "Niort Tech" existe théoriquement mais ne fonctionne pas du 
tout, il existe sur le papier mais le gros se fait entre personnes qui 
se connaissent travaillent dans leur milieu dans des entreprises où 
ces échanges existent naturellement, c'est assez facile pour eux. Je 
ne suis d'aucun de ces "clans".


Je n'ai jamais réussie à trouver des contact locaux (à moins de 20 
kilomètres, ais même faire 20 kilomètres c'est difficile pour moi aux 
horaires planifiés). La perception du projet OSM France est qu'il est 
très fermé sur quelques personnes qui veulent tout piloter et pourtant 
n'ont pas le temps de le faire.


La gestion et l'animation d'un groupe local n'est pas simple, et c'est 
clair que on ne trouve pas des contributeurs dans toutes les communes. 
Je ne connais pas le groupe sur Niort et si l'exposé qui en est fait est 
authentique, peut-être rétablir une communication avec eux et voir 
comment rendre ces évènements plus ouverts serait intéressant. Malgré 
tout, des petits évènements dans ta 

Re: [OSM-talk-fr] BANO est-il mort?

2020-08-29 Diskussionsfäden Georges Dutreix via Talk-fr
29 août 2020 23:23:51 PanierAvide :

> je remercie les personnes autant que possible de leur contribution, en 
> espérant que ceux qui trouveront mon travail utile me remercieront un jour. 
> Donner avant de recevoir, même lorsque la seule chose à donner c'est du temps.
> 
Merci pour ces belles pensées. Merci à toi et à ceux qui donnent beaucoup plus 
que moi, et qui me permettent de me sentir participer à la construction de 
communs.

Et j'inclue Philippe dans ces remerciements pour toutes ses contributions, 
parfois un peu longues, certes, mais très riches. 

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


Re: [Talk-us] [Imports] Import WestCOG building footprints in south-west Connecticut

2020-08-29 Diskussionsfäden Yury Yatsynovich
Hi Julien,
Unfortunately, I have limited knowledge on the data quality as I wasn't
able to download it (the server returns error). I let the CT point of
contact (Scott) know about the problem -- he mentioned in our communication
that he forwarded the issue to the tech support team, but I haven't heard
from them since then and I'm still unable to download it.

On Sat, Aug 29, 2020, 4:57 PM Julien Lepiller  wrote:

> So, it's been a week since that last message. Do you think we should
> import addresses and buildings at the same time? Should we import the
> buildings first and care about addresses later?
>
> Yury, what are your thoughts about the data source quality? Do you
> think it's a good idea to import from WestCOG and maybe rely on CT data
> for the rest of CT? I tried playing with the data and I didn't see any
> difference between drawing the buildings from scratch and having to
> simplify and correct CT's data.
>
> Thanks!
>
> Le Sat, 22 Aug 2020 19:36:23 -0400,
> Martin Machyna  a écrit :
>
> > Thank Julien for pushing this forward!
> >
> > yeah, I tried to get addresses from here:
> >
> http://geodata-ctmaps.opendata.arcgis.com/datasets/bfa7da83da384c2aa809882179369dc4_0/features/305004
> > and add them on top of the westCOG buildings.
> >
> > The data is a big mess because it's a join_table of like 30 different
> > address databases. I lost a bit of motivation there, but I could have
> > a look at it again.
> >
> > Martin
> >
> > On Sat, Aug 22, 2020 at 2:19 PM Julien Lepiller 
> > wrote:
> >
> > > Le Sat, 22 Aug 2020 13:30:02 -0400,
> > > Yury Yatsynovich  a écrit :
> > >
> > > > Hi Julien,
> > > > The following communication that I've had recently with a CT
> > > > official might be of interest to you:
> > > >
> > > >
> > >
> > > Oh, great! I think we already saw this data (I tried to contact them
> > > too, but never got a reply :/). From what we saw (I think it was in
> > > February?) the footprints have simplification issues (see
> > > https://files.slack.com/files-pri/T029HV94T-FTDGDHXTM/image.png for
> > > instance) where they are too detailed, not square enough, etc. Some
> > > buildings also have holes in them, when there's none in the imagery.
> > >
> > > So I think it's too bad to be used directly, without a lot of manual
> > > effort to simplify, square and redraw the shapes. However, the
> > > address data is very interesting, so maybe we could extract from
> > > it? Or we could use a separate dataset if they have addresses
> > > separately.
> > >
> > > ___
> > > Imports mailing list
> > > impo...@openstreetmap.org
> > > https://lists.openstreetmap.org/listinfo/imports
> > >
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us


Re: [Talk-us] [Imports] Import WestCOG building footprints in south-west Connecticut

2020-08-29 Diskussionsfäden Julien Lepiller
So, it's been a week since that last message. Do you think we should
import addresses and buildings at the same time? Should we import the
buildings first and care about addresses later?

Yury, what are your thoughts about the data source quality? Do you
think it's a good idea to import from WestCOG and maybe rely on CT data
for the rest of CT? I tried playing with the data and I didn't see any
difference between drawing the buildings from scratch and having to
simplify and correct CT's data.

Thanks!

Le Sat, 22 Aug 2020 19:36:23 -0400,
Martin Machyna  a écrit :

> Thank Julien for pushing this forward!
> 
> yeah, I tried to get addresses from here:
> http://geodata-ctmaps.opendata.arcgis.com/datasets/bfa7da83da384c2aa809882179369dc4_0/features/305004
> and add them on top of the westCOG buildings.
> 
> The data is a big mess because it's a join_table of like 30 different
> address databases. I lost a bit of motivation there, but I could have
> a look at it again.
> 
> Martin
> 
> On Sat, Aug 22, 2020 at 2:19 PM Julien Lepiller 
> wrote:
> 
> > Le Sat, 22 Aug 2020 13:30:02 -0400,
> > Yury Yatsynovich  a écrit :
> >  
> > > Hi Julien,
> > > The following communication that I've had recently with a CT
> > > official might be of interest to you:
> > >
> > >  
> >
> > Oh, great! I think we already saw this data (I tried to contact them
> > too, but never got a reply :/). From what we saw (I think it was in
> > February?) the footprints have simplification issues (see
> > https://files.slack.com/files-pri/T029HV94T-FTDGDHXTM/image.png for
> > instance) where they are too detailed, not square enough, etc. Some
> > buildings also have holes in them, when there's none in the imagery.
> >
> > So I think it's too bad to be used directly, without a lot of manual
> > effort to simplify, square and redraw the shapes. However, the
> > address data is very interesting, so maybe we could extract from
> > it? Or we could use a separate dataset if they have addresses
> > separately.
> >
> > ___
> > Imports mailing list
> > impo...@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/imports
> >  


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


Re: [OSM-talk-fr] BANO est-il mort?

2020-08-29 Diskussionsfäden Philippe Verdy
J'ai essayé le projet DAE, mais franchement je trouve que ce projet est à
long terme et que labase n'est pas encore là pour le faire correctement en
un temps aussi limité (un mois?).
Ce qui est proposé par Osmose n'est pas du tout intégrable en l'état: i ly
a trop de boulot à faire avant autour pour savoir seulemetn où placer
correctement les éléments cités.
Bref j'en reviens à la problématique du projet BANO, sur lequel le projet
DAE dépend TRES fortement (sauf dans les grandes agglos où
quasiment toutes les adresses sont déjà correctement réglées).
Et même avant BANO, il y a la problématique FANTOIR pour référencer les
rues/routes correctement.

Ce qui est homogène en France c'est juste les communes et collectivités ou
groupements. En dessous on est encore loin du compte:

FANTOIR et BANOR restent des priorités à ne pas négliger et passer en
second plan.

Je n'ai rien contre le fait de mettre un mois sur les DAE (à l'essai pour
remonter ce qui cloche mai sinon de façon épisodiques dans certains lieux
qui interessent certaines personnes n'ayant plsuy grand chose à faire dans
leurs zone de travail où FANTOIR et BANO sont quasiment complets, ou bien
juste à titre de hobi ou pour "varier les plaisirs" et faire une pause en
cours d'un travail de plus longue haleine).

Mais ce que je vois c'est qu'intégrer les DAE est encore trop compliqué et
trop lourd (et qu'Osmose n'aide pas beaucoup ou peut conduire certains à
précipiter les choses, "faire du chiffre" sans tenir compte des
contraintes de placement). Hors vouloir aller trop vite, c'est bâcler, et
ensuite compliquer les corrections (nombreux doublons attendus, données
obsolètes non maintenues et difficiles à corriger ensuite): les corrections
demandent beaucoup plus de temps que le simple import, aller trop vite
c'est gâcher les efforts futurs.

Bref je ne pense pas qu'Osmose nous rende service à cette étape, les
données sont à requalifier complètement et ce n'est pas aussi facile que ce
que propose un simple lien "JOSM-fix" trop vite cliqué et expédié tel quel.
Je pense même que ce lien devrait être supprimé si la placement est
juste indicatif (adresse BANO non trouvée, identification de l'opérateur
trop ambigue pour trouver un SIREN/SIRET fiable), Osmoes ne devrait dans ce
cas là que mentionner des infos sans possibilité de les intégrer
directement d'un clic.

En attendant mes faibles moyens, mon isolement social, mes problèmes de
santé compliquent pas mal de choses. Je suis toujours à la recherche
d'alliés locaux mais pas moyen d'en trouver. Et sur Intenet en virtuel, on
prète trop vite de mauvaises intentions et des fausse interprétations. C'et
ce que je veux éviter, mais directe ici quelques élites le prennent pour
elles et surréagissent avant de savoir. On n'a pas cet écueil quand on peut
agir "de visu", une fois qu'on se connait un peu c'est tout de suite
plus facile.

Mais je ne comprend pas qu'u vu de la quantité de contributions que je fais
sur OSM ou dans les projets libres, on ne m'accorde qu'aussi peu
d'attention et qu'on présume encore de mauvaise intentions de ma part. Je
résiste à beaucoup de choses, je ne fais pas de griefs immédiats et
permanents. Mais on m'a bien traité de "yakafaucon" ici, alors que les
"yakas " ne venaient pas de moi mais s'adressaient uniquement et
directement à moi directement et nommément.

Ne vous étonnez pas du manque de participation ici: beaucoup n'osent pas
intervenir et subissent ça en silence. Ils ont trop peur de se faire
traiter comme je le suis jsute par ce que je fais quelques constats ou
donne des opinions qui ne sont pas dans le droit fil du petit groupe élite.
Beaucoup n'ont pas cette résistance et assez vite abandonnent (et il est
plus facile alors pour eux de dire tout ce qu'ils veulent sur Facebook ou
ailleurs, et ont le sentiment d'être mieux respectés quand ils
coopèrenet même avec des projets commerciaux/propriétaires, où exite une
charte sans doute restrictive mais qui est plus claire et face à laquelle
on sait à quoi s'attendre, le projet commercial ayant aussi intérêt à ne
pas s'opposer trop fortement à sa clientèle.

Dans ce que je vois, OSM est *moins* ouvert et a une politique de
communication bien plus floue que Google ou d'autres solutions
propriétaires/fermées. C'est bien dommage. C'est un beau gâchis.



Le sam. 29 août 2020 à 23:23, PanierAvide  a écrit :

> Merci Philippe d'avoir pris le temps d'apporter une réponse complète dans
> un exposé clair. Je me permets de répondre par points dans le message.
>
> Adrien P.
>
> Le 29/08/2020 à 15:32, Philippe Verdy a écrit :
>
> En plus ta réponse est typique ici d'un "privilégié" qui a des moyens et
> son club autour de lui, et très parisiano-centrée (ou dans les quelques
> grandes villes où se réunir à plusieurs ne coûte pas cher ou qui dispose de
> moyens qu'on lui donne généreusement sans gros effort de sa part).
>
> On devrait échanger de vive voix, on a peut-être plus de points communs
> que tu ne l'imagines. Le "club" en question est un 

Re: [Talk-us] [Imports] Import WestCOG building footprints in south-west Connecticut

2020-08-29 Diskussionsfäden joe.sapletal
I was going to look at the buildings too.  I’ve used a tool in ArcGIS to 
correct some pretty awful buildings, but I couldn’t download them either.If 
there is no hurry, I’d check in again with the contact on Monday.  It would be 
nice to have the buildings with addresses on them.

 

Joe

 

From: Yury Yatsynovich  
Sent: Saturday, August 29, 2020 5:05 PM
To: Julien Lepiller 
Cc: impo...@openstreetmap.org; talk-us@openstreetmap.org
Subject: Re: [Talk-us] [Imports] Import WestCOG building footprints in 
south-west Connecticut

 

Hi Julien,

Unfortunately, I have limited knowledge on the data quality as I wasn't able to 
download it (the server returns error). I let the CT point of contact (Scott) 
know about the problem -- he mentioned in our communication that he forwarded 
the issue to the tech support team, but I haven't heard from them since then 
and I'm still unable to download it. 

 

On Sat, Aug 29, 2020, 4:57 PM Julien Lepiller mailto:o...@lepiller.eu> > wrote:

So, it's been a week since that last message. Do you think we should
import addresses and buildings at the same time? Should we import the
buildings first and care about addresses later?

Yury, what are your thoughts about the data source quality? Do you
think it's a good idea to import from WestCOG and maybe rely on CT data
for the rest of CT? I tried playing with the data and I didn't see any
difference between drawing the buildings from scratch and having to
simplify and correct CT's data.

Thanks!

Le Sat, 22 Aug 2020 19:36:23 -0400,
Martin Machyna mailto:mach...@gmail.com> > a écrit :

> Thank Julien for pushing this forward!
> 
> yeah, I tried to get addresses from here:
> http://geodata-ctmaps.opendata.arcgis.com/datasets/bfa7da83da384c2aa809882179369dc4_0/features/305004
> and add them on top of the westCOG buildings.
> 
> The data is a big mess because it's a join_table of like 30 different
> address databases. I lost a bit of motivation there, but I could have
> a look at it again.
> 
> Martin
> 
> On Sat, Aug 22, 2020 at 2:19 PM Julien Lepiller   >
> wrote:
> 
> > Le Sat, 22 Aug 2020 13:30:02 -0400,
> > Yury Yatsynovich  >  > a écrit :
> >  
> > > Hi Julien,
> > > The following communication that I've had recently with a CT
> > > official might be of interest to you:
> > >
> > >  
> >
> > Oh, great! I think we already saw this data (I tried to contact them
> > too, but never got a reply :/). From what we saw (I think it was in
> > February?) the footprints have simplification issues (see
> > https://files.slack.com/files-pri/T029HV94T-FTDGDHXTM/image.png for
> > instance) where they are too detailed, not square enough, etc. Some
> > buildings also have holes in them, when there's none in the imagery.
> >
> > So I think it's too bad to be used directly, without a lot of manual
> > effort to simplify, square and redraw the shapes. However, the
> > address data is very interesting, so maybe we could extract from
> > it? Or we could use a separate dataset if they have addresses
> > separately.
> >
> > ___
> > Imports mailing list
> > impo...@openstreetmap.org  
> > https://lists.openstreetmap.org/listinfo/imports
> >  


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

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


Re: [OSM-talk-fr] BANO est-il mort?

2020-08-29 Diskussionsfäden Philippe Verdy
J'aimerais bien relancer le groupe de Niort, mais leur choix de s'implanter
à "NiortTech" (C'est en fait un espace commercial de coworking) qui demande
8 euros par demi-journée d'occupation et par personne n'est pas du tout
dans mes moyens (pas plus que leurts réunions dans des bars-restaux où il
faut consommer ou participer).

On n'y trouve en fin de compte que des entrepreneurs ou des directeurs
techniques de grosses sociétés ou des responsables administratifs et des
commerciaux. Ambiance costard-cravatte, réunions souvent à caractère
promotionnel ou publicitaire, on dirait des exposés qui veulent imiter les
Shows Apple: un orateur qui attend des applaudissements, et très peu
d'interaction. Encore moins de socialisation.

De toute façon le lieu est fermé depuis des mois et fonctionne surout par
cooptation en fonction d'intérêts professionnels directs. On y parle du
"libre" mais tout le modne est là pour vendre sa solution. Ca
limite l'intérêt et clairement c'est peu ouvert. Que dire encore des
"Meetups" qui se réunissent une fois par semaine en changeant de ville:
Poitiers, Nantes, La Rochelle, ... ce petit monde fait du tourisme et là
encore ce n'est pas dans mes moyens.

Que dire des contacts avec les collectivités locales : aucun intérêt de
leur part, aucune aide pour monter un atelier collectif local.

Niort est très cloisonné (et comme je ne suis pas originaire de la région,
je ne rentre pas dans les clans formés) Ca fait plus de 10 ans que j'y suis
et c'est le seul endroit où je n'ai pu développer facilement des contacts
avec au moins une douzaine de contacts réguliers (pour n'importe quelle
activité). Alors qu'avant j'ai habité plusieurs régions et travaillé
facilement dans plein de pays européens (dont une longue période en
Allemagne à Hambourg, et en Angleterre à Londres, en Italie à Milan) et au
Moyen-Orient (dont Beyrouth, Abu Dhabi) et Afrique du Nord (Casablanca,
Rhabbat) et de façon épisodique ailleurs (Portugal, Espagne, Belgique,
Luxembourg, Pays-Bas) et dans une entreprise américaine (poste basé à
Paris, mais voyages aux USA, au Canada, au Royaume-Uni, et toute
l'Europe du Sud). Niort est le pire lieu où malheureusemetn un accident de
la vie m'a immobilisé puis enfermé. Je m'y suis ruiné totalement et n'ai eu
aucune aide.

Les services locaux ont menti, j'ai gagné 3 fois un procès contre la
collectivité, mais les décisions n'ont jamais été appliquées et quand j'ai
eu réparation partielle, au final ça n'a même pas couvert les frais). Je ne
leur faits plus confiance du tout. Là aussi ce sont les mêmes qui menvoient
les "yakas", se défilent de leurs responsabilité, ou s'ils ont un peu de
compassion se contentent d'un "bon courage", ou sinon cont s'en tenir à
leurs procédures farfelues pour ne rien faire. Pour eux je n'ai jamais fait
partie des priorités. Idem pour Pole Emploi qui m'a ruiné sans jamais me
donner un sou. Il a fallu que je soit en situation de famine par 3 fois
(pendant des semaines) et des accidents de santé succesifs pour qu'on
m'apporte un peu d'aide mais au passage me priver encore plus de libertés.
J'ai même bataillé pour recouvrer mon identité et ma citoyenneté, j'ai
moins de droits qu'un immigrant clandestin.

D'où ma référence aux "oubliés". Les quelques personnes qui m'aident un peu
(rarement) se demandent comment je fait pour tenir. J'en ai vu atour de moi
pêter les plombs et se faire sanctionner lourdement, d'autres sans plus de
moyens se faire taxer, voler par l'Etat sans qu'elles puissent agir ou se
résigner (comportement quasi-suicidaire qui tourne vite mal pour elles). Je
ne suis pas dans la résignation, je me défend comme je peux.

Ce qui me fait tenir c'est d'abord la volonté de me rendre utile (et
l'espoir qu'à un moment ou un autre on s'en rendra compte). Je prends donc
très mal les réactions démesurées et hostiles de certaines élites qui n'ont
pas devant elles les difficultés que j'ai et ont encore beaucoup de liberté
(y compris se mettre en retrait quand elles le veulent sans rien demander à
personne).

Pourtant même quand j'avais les moyens et la vie facile j'étais très ouvert
aux autres même moins lotis. J'ai aidé beaucoup de monde autour de moi
(sans rien attendre, j'étais content de le faire), payé énormément
d'impôts sans rechigner (car je pensais que c'était juste, maintenant quand
je vois le gâchis et la façon dont l'Etat n'aide plus que les
plus favorisés et délaisse les autres en leur ajoutant sans arrêt de
nouvelles contraintes), je sais que je n'ai plus rien à attendre de la
collectivité publique (qui me le rends mal, et tolère à peine que je
survive).

Les projet libres sont mes derniers espaces de liberté et de loisir qui me
restent. Mais ne me demandez pas l'impossible.




Le sam. 29 août 2020 à 23:55, Georges Dutreix via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> 29 août 2020 23:23:51 PanierAvide :
>
>
> je remercie les personnes autant que possible de leur contribution, en
> espérant que ceux qui trouveront mon travail utile me 

Re: [OSM-talk-fr] Projet du mois défibrillateurs : c'est parti ! données foireuses de GéoDAE

2020-08-29 Diskussionsfäden Philippe Verdy
Le sam. 29 août 2020 à 22:28,  a écrit :

> Le 29/08/2020 à 10:18, Christian Quest - cqu...@openstreetmap.fr a écrit :
>
> De plus ça ne me semble pas apporter grand chose (parce que c'est une
> donnée dans GéoDAE et que je ne vois pas trop à quoi ça sert : si les
> pompiers arrivent sur place ils verront bien s'il y a un accueil ou une
> sécurité).
>

Je ne vois pas les pompeirs avoir besoin d'un "reception desk" ou d'un
"secuirty desk". S'ils interviennent dans un lieu ils n'ont pas besoin
demander la permission d'agir. De plus ils n'ont pas besoin du DAE, ils en
ont un déjà avec eux.

du ocup l'info ne devrait être là que pour aider le grand public, n'importe
qui se présentant pour demander de l'aide. Si la base GeoDAE mentionne un
DAE, il doit être à disposition que le "desk" soit présent ou non (tant que
le lieu est ouvert au moins).

L'urgence se passe de permission, il ne peut y avoir qu'un contrôle a
posteriori (c'est pour ça que ces appareils disposent de moyens de
communication autonomes, de géolocalisation et télésurveillance). Ce qui
impose aux opérateurs aussi de les maintenir en état pour être prêt le
moment venu (donc avec une batterie en état de marche, avec les accessoires
nécessaires pour l'hygiène, avec une carte SIM et un abonnement mobile
valide, un contrat d'entretien avec engagement de remise en service rapide
après leur usage).

Si les pompiers arrivent, soit l'appareil la déjà été utilisé ou est en
place, mais ils ne vont pas attendre et surtout pas aller en chercher un
ailleurs (sauf cas exceptionnel où leur propre appareil s'avérerait
défaillant) et c'est eux qui soit emporteront l'appareil pour le remette à
disposition de l'exploitant, soit donneront des consignes claires aux
autres témoins ou intervenants sur ce qu'ils doivent faire, eux qui
aviseront aussi l'opérateur pour vérifier ou leur signaler que leur
appareil n'est plus chez eux mais sera remis dans les heures qui viennent
si possible, ou que l'exploitant (ou sa société de maintenance) pourra
venir lui-même récupérer ou remplacer si les délais sont plus longs que ce
que prévoit le contrat de maintenance et les obligations légales de
l'opérateur.

En cas de vol, dégradation par des tiers, c'est du ressort de la police et
de la société d'assurance liée aux contrat de maintenance que l'opérateur
devrait avoir.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


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

2020-08-29 Diskussionsfäden Philippe Verdy
Les "landuse=flowerbed" (parterres de fleur, avec une icône de fleur sur
pied et deux feuilles) ne s'affichent pas davantage, ils sont pourtant dans
les presets d'iD.

On en trouve en quantité au pied des bâtiments, dans les giratoires, le
long de rues pour séparer le trottoir ou une bande cyclable, et dans les
parcs et jardins publics.

Si on tague juste pour le rendu on va mettre du "landuse=grass" (surface
d'herbe entretenue), à ne pas confondre avec les "prairies" ou
"'landuse=meadow" (où l'herbage est irrégulier, non tondu avec souvent
divers arbrisseaux ou buissons, des traces de passages d'animaux d'élevage
ou d'engins agricoles et souvent entouré de haies et d'arbres) et pourtant
ce n'est pas la même chose, mais là on aurait un vert saturé (plus clair
toutefois que le vert des bois et forêts).

En revanche les jardins collectifs (dits "familiaux") sont rendus :
"landuse=allotments" (icone d'arrosoir dans iD, rendu en ocre-vert avec un
semis de points).

iD possède même la notion de "parcelle de jardin familiaux" (icône avec une
pousse de plante dans un bac) avec "allotments=plot" (non rendu
apparemment, devrait faire partie d'un "landuse=allotment" qui est déjà
rendu) : pas vraiment des parcelles au sens cadastral car les jardins
familiaux sont dans un ensemble de parcelles cadastrales d'une
collectivité, qui les réalloue en unités bien plus petites et qui peuvent
changer d'une année à l'autre.


Le sam. 29 août 2020 à 19:24, deuzeffe  a écrit :

> Bonjour,
>
> Suivant le rendu consulté, des noms de leisure=garden s'affichent ou pas.
>
> Exemple :
> - soient les deux polygones suivants : 1/
> https://www.openstreetmap.org/way/67527 et 2/
> https://www.openstreetmap.org/way/294951535
> - au nom près, les attributs sont les mêmes (mêmes couples champ/valeur)
> - le nom de 1/ s'affiche mais pas celui de 2/ sur le rendu standard
> https://www.openstreetmap.org/#map=19/45.79721/1.14039 ou le rendu
> osm-fr en dev
>
> https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#19/45.79725/1.14056
> (osmfr-cartocss étant, vu son nom un fork de Mapnik-cartoCSS, ça parait
> logique ?) ;
> - les deux noms s’affichent sur le rendu cyclable standard
> https://www.openstreetmap.org/#map=19/45.79721/1.14039=C et le
> rendu HOT (qui patine un peu, au passage)
> https://www.openstreetmap.org/#map=19/45.79731/1.14025=H
>
>
> Si un ou une wizard voulait bien m'expliquer ces différences de
> comportement : ordre des couches, encombrement stérique des noms,
> "cékomssa", explication toute bête, autres, je l'en remercie d'avance.
>
> --
> deuzeffe, qui aime bien comprendre pourquoi ça pas marche.
>
> ___
> 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] BANO est-il mort?

2020-08-29 Diskussionsfäden Jérôme Amagat
Vous vous faite du mal à répondre à Philippe, ça ne sert à rien. Ça fait
plusieurs années que je lis ce qui se dit sur cette liste et il est
coutumier de ce genre d'intervention, il ne faut pas y faire attention et
même ne pas le lire, vous vous en porterez que mieux :)

J'ai quand même survolé ce qu'il a dit et j'ai tapé "bano" dans google et
le 1er résultat c'est data.gouv.fr (
https://www.data.gouv.fr/fr/datasets/base-d-adresses-nationale-ouverte-bano/
)
sur cette page beaucoup de date 2014 à 2016. Dans "Origine des données",
les dates pourrait faire croire qu'il n'y a eu aucun ajout d'adresses
depuis 2016, je pense qu'il faudrait supprimer ces dates inutiles. Même
chose pour "Historique du jeu de données" qui ne parle que de 2014. Et des
questions de 2019 n'ont aucune réponse.

Sur google, après data.gouv.fr, c'est  http://prev.openstreetmap.fr/bano
(aussi indiqué sur la page data.gouv.fr), la partie "Les news..." datent de
plusieurs années ça fait pas très "news". rebaptiser "historique", ajouter
des news plus fraîches ?
Et dans les liens au dessus, "graphes d'évolution du contenu" ne mène à
rien et il faudrait indiquer que le rendu est temporairement indisponible.

Ces petits changements ferait moins "mort"
Et ne vous embêtez pas à chercher à discuter avec Philippe...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr