Re: [OSM-talk-fr] bâtiment sans numéro de rue

2020-09-08 Per discussione Stéphane Péneau

Le 08/09/2020 à 23:20, Philippe Verdy a écrit :
Note le numéro 1 sur le cadastre est semble-t-il le numéro de 
parcelle. Le 1 est un peu plus au sud (avant les marais, mais c'est le 
seul numéro impair. Il n'y a pas de 2 ni de 3 indiqués, de fait la 
mairie purrait bien être au 3 (à l'entrée de la rue) si le 2 est pour 
l'école juste à côté.


Il y a bien un numéro 3, un peu plus au sud, c'est même toi qui l'a 
ajouté :-)


Stf

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


Re: [OSM-talk-fr] La proposition shadok : les pompes

2020-09-08 Per discussione Gad Jo
Ton dossier pour la proposition est très bien construit et très clair.

Félicitations

Le September 8, 2020 10:12:40 PM UTC, "François Lacombe" 
 a écrit :
>Salut à tous
>
>Voici une proposition de nouveaux tags pour décrire les pompes,
>beaucoup de
>modèles différents, dont je vient d'achever la traduction
>https://wiki.openstreetmap.org/wiki/FR:Proposed_features/Pumping_proposal
>
>Elle m'a occupé une partie du confinement de ce printemps et a déjà
>reçu de
>nombreux commentaires sur la version anglaise, ce qui permet
>aujourd'hui
>d'avoir un modèle assez mature.
>
>L'idée est de réutiliser ce qui a été mis en place pour décrire les
>puits à
>eau ou de pétrole pour l'étendre à d'autres univers comme l'industrie
>ou le
>médical.
>En tout cas il est proposé de considérer les pompes comme des appareils
>à
>part entière, quel que soit leur usage en situation.
>
>Je cherche encore des exemples ou des photos. Certains modèles sont
>quasi
>introuvables dans la nature et ca ne pousse pas sur les arbres.
>
>Le modèle attributaire proposé sera également présenté au groupe de
>travail
>de l'ASTEE qui débute la semaine prochaine pour l'élaboration d'un
>nouveau
>géostandard pour l'adduction d'eau potable et la gestion des eaux
>usées.
>J'essaierai d'y apporter un peu de culture OSM
>(le précédent GT
>https://www.astee.org/groupe-de-travail-sig-participez-a-la-consultation-externe/
>)
>
>Preneur de vos retours, à bientôt
>
>François

-- 
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: [Talk-lt] Vilniaus dviračių maršrutai

2020-09-08 Per discussione Albertas Agejevas
On Tue, Sep 08, 2020 at 11:43:02AM +0300, Frank "Frankas" Wurft, BaltiCCycle.eu 
wrote:
> On 2020-09-08 11:11, Frank "Frankas" Wurft, BaltiCCycle.eu wrote:
> > Aš - kaip autorius - manau, kad neverta :)
> > 
> > Aš norėčiau žymėti tik maršrutus "su infrastruktūra", tr. kai yra takai
> > arba bent ženklai/žymėjimas.

Aišku.

> > Šitie maršrutai vis dar yra "kompromisas", nes dviračių takai vis dar
> > nutruksta  ir pastariuoju metu vyksta daug statybos ir žymėjimo (pvz.
> > yra nauji oražiniai dviračių trasos ženklai Vakarų Vilniuje, "takas
> > aplink Vilnių" ir pesčiųjų trasos). Pvz. dėl "tako aplink Vilnių" aš
> > nesu tikras kiek iš jo liks po keletą metų, labai abejoju ar jį
> > prižiūrės

Pastebėjau naujus trasų ženklus, galvojau, kad ir šitie maršrutai gali
būti sužymėti.

> > Aš pats nebesigaunu, kas kur yra statomas, bet aš matau kad ir OSM šiuo
> > metu "nespėja" atsinaujinti ir Vilniuje yra daug pasenusios
> > informacijos.
> > 
> > Svarbiausiai įkelti informaciją apie naujus dviračių takus o maršrutus
> > paliksime visokiems GPS kelių žemėlapiams :)

Prieš keletą savaičių ir aš buvau nustebęs, kad prieš pusmetį baigti
raudoni takai nepažymėti OSM, tai per praėjusias keletą savaičių
aplankiau kai kuriuos naujus takus, sutikrinau nesenai baigtus projektus
pagal miestai.net forumo dviračių maršrutų temą.  Kai kur vos užbėgau
įvykiams už akių -- pvz. Erfurto gatvės takas dar nebaigtas rytiniame
gale, Senvagės parko (prie Linkmenų g. viršutinės pusės) takas dar
neatidarytas, bet jau pravažiuojamas.

Iš senų laikų pas mus liko sužymėtų Zuoko eros "dvirtakių",
pvz. Žvėryne Narbuto g. abiejose pusėse pažymėti takai, kurie buvo tik
nupiešti ant šaligatvių, o dabar gal net nuvalyti. Vieną gabaliuką
atverčiau atgal į šaligatvį, kur radau nusmėliuotą zuokinį dvirtakį.

Manau, dabartinė būklė pas mus gan tiksli, bent visi stambesni nauji
takai yra pavaizduoti.

Albertas

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


[OSM-talk-fr] La proposition shadok : les pompes

2020-09-08 Per discussione François Lacombe
Salut à tous

Voici une proposition de nouveaux tags pour décrire les pompes, beaucoup de
modèles différents, dont je vient d'achever la traduction
https://wiki.openstreetmap.org/wiki/FR:Proposed_features/Pumping_proposal

Elle m'a occupé une partie du confinement de ce printemps et a déjà reçu de
nombreux commentaires sur la version anglaise, ce qui permet aujourd'hui
d'avoir un modèle assez mature.

L'idée est de réutiliser ce qui a été mis en place pour décrire les puits à
eau ou de pétrole pour l'étendre à d'autres univers comme l'industrie ou le
médical.
En tout cas il est proposé de considérer les pompes comme des appareils à
part entière, quel que soit leur usage en situation.

Je cherche encore des exemples ou des photos. Certains modèles sont quasi
introuvables dans la nature et ca ne pousse pas sur les arbres.

Le modèle attributaire proposé sera également présenté au groupe de travail
de l'ASTEE qui débute la semaine prochaine pour l'élaboration d'un nouveau
géostandard pour l'adduction d'eau potable et la gestion des eaux usées.
J'essaierai d'y apporter un peu de culture OSM
(le précédent GT
https://www.astee.org/groupe-de-travail-sig-participez-a-la-consultation-externe/
)

Preneur de vos retours, à bientôt

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


Re: [OSM-talk-fr] bâtiment sans numéro de rue

2020-09-08 Per discussione Philippe Verdy
Note le numéro 1 sur le cadastre est semble-t-il le numéro de parcelle. Le
1 est un peu plus au sud (avant les marais, mais c'est le seul numéro
impair. Il n'y a pas de 2 ni de 3 indiqués, de fait la mairie purrait bien
être au 3 (à l'entrée de la rue) si le 2 est pour l'école juste à côté.
Le 63 "bis" ne semble pas bon étant donné que sur la rue de la Vallée
d'Authie il n'y a semble-t-il pas d'accès, juste un mur avec des
véhicules stationnés devant.
L'absence de numéro indiquerait sans doute que l'accès à la mairie n'a
jamais été sur la rue de la Vallée (sauf un temps ancien quand ce bloc
incluant la mairie et l'école aurait été une seule et même ferme et avant
que la rue des mairies soit transformé d'un simple chemin agricole en rue).
Le cadastre de toute façon est très mauvais: il a visiblement été
jsute numérisé dans l'état à partir de vieilles planches tracées à main
levée: il n'y a aucun batiment correctement positionné (les écarts sont
TRES variables, les formes c'est un peu du n'importe quoi, les surfaces et
alignements ne correspondent pas).

Pas très étonnant dans ce qui est une petite commune rurale qui même encore
aujourd'hui n'a pas les ressources de revoir ça (et sans doute même pas sa
communauté de communes. D'ailleurs il manque aussi bon nombre d'étangs. On
se demande comment les exploitants de réseaux gèrent leurs propres besoins
(sans se soucier de l'intégration avec le reste des autres éléments
carographiques), ou si à chaque fois c'est juste une opération de sondage
très local pour conduire un chantier mais sans recollecter les résultats
vers un SIG.

Donc à moins que sa ComComm commande (et puisse se payer) des études (ou
qu'elle fasse appel à des aides financières ou techniques de la région ou
du département), il ne faut pas trop se fier au cadastre. D'ailleurs il y a
des tas de bâtiments "fantômes" et de nombreux oublis (mais en général
c'est dépendant de la volonté d'un acteur économique de s'investir dans la
zone, mais dans ce milieu très rural ils ne sont pas très attirés, pourtant
il y aurait un intérêt au moins au plan environnemental de recenser ces
zones de marais pourtant si différentes des grandes concentrations urbaines
du Nord avec leurs grandes zones industrielles à reconvertir et qui
monopolisent les énergies)

Sans doute que la commune verrait d'un bon œil se faire aider ne serait-ce
que par OSM qui montrerait une cartographie plus exacte de la commune et
permettrait ensuite de faire une meilleure planification des besoins et
protéger ce qui le mérite, ou au moins faire des arbitrages avec un œil
éclairé (aussi par la "participation citoyenne" au sens large) pour ensuite
mieux justifier des demandes d'aide.

Si je regarde l'IGN ce n'est pas beaucoup mieux. Pas plus concernant les
agences environnementales: cette zone en bordure du Pas-de-Calais et de la
Picardie semble délaissée depuis longtemps, et la commune ne fait pas
partie non plus du parc naturel régional (créé un un temps où les
Hauts-de-France n'existaient pas encore, ce parc régional semble plus
s'intéresser à la façade maritime, et marais de la Somme, mais pas
tellement aux marais de l'Authie où ne se trouve aucune agglo importante ni
aucun axe de communication, car même l'autoroute côtière A16 ne fait que la
traverser).


Le mar. 8 sept. 2020 à 21:44, pepilepi...@ovh.fr  a
écrit :

> Le 08/09/2020 à 20:20, Philippe Verdy a écrit :
>
> Note que dans ton cas je ne suis pas certyain qu'elle soit au 63 ou 65 de
> la Rue de la Vallée d'Authie. Regarder un peu l'imagerie BDOrtho, on voit
> un accès piéton plutôt depuis la rue des Etangs !
> et d'ailleurs le cadastre y indique que c'est le numéro 1 (donc l'autre
> rue !)
>
> Pas de 63 bis donc!
>
>
> C'est bien con, ça, parce que tous les sites que j'ai regardés en faisant
> une recherche rapide
> 
> donnent comme adresse postale "Rue de la Vallée-de-l'Authie
> 62870 Roussent".
>
> Et si https://www.adresses-mairies.fr/mairie-de-roussent-25022.html la
> situe presque bien sur son plan,
> http://www.linternaute.com/ville/roussent/ville-62723/mairie la met au
> numéro 32 faute de précision sur le numéro...
>
>
>
> Le mar. 8 sept. 2020 à 17:27, Yannick  a écrit :
>
>> Le 08/09/2020 à 17:12, pepilepi...@ovh.fr a écrit :
>> > Le 08/09/2020 à 16:00, osm.sanspourr...@spamgourmet.com a écrit :
>> >>
>> >> Bonjour,
>> >>
>> >> j'ai un bâtiment (une mairie
>> >> ) qui est dans une
>> >> associatedStreet
>> >> > >.
>> >>
>> >> Or selon la mairie et le cadastre il n'y a pas de numéro pour la
>> >> mairie qui est entre le 63 et le 65.
>> >>
>> >> Vaut-il mieux supprimer de l'associatedStreet ou déclarer un faux
>> >> positif car elle fait bien partie de la rue ?
>> >>
>> >> Jean-Yvon
>> >>
>> > Ou écrire au maire pour lui demander de mettre un numéro à sa mairie,
>> > parce que ça fout le bordel 

Re: [Talk-it] IT-Alert: sistema di allarme pubblico

2020-09-08 Per discussione Cascafico Giovanni
Certo, anche in Friuli-Venezia Giulia l'ARPA pubblica i dataset, ma senza
il codice, la SRB non può essere collegata all'evento. Sono sul telefono e
non riesco a cliccare sui pallini della mappa per vedere gli attributi
delle stazioni; se fossero identificabili, si potrebbero generare mappe OSM
al volo per ogni alert geografico.

Il mar 8 set 2020, 11:01 Francesco Pelullo  ha scritto:

>
>
> Il mar 8 set 2020, 10:17 Cascafico Giovanni  ha
> scritto:
>
>> ... direi che alla base di qualsiasi iniziativa OSM sono le
>> coordinate delle BTS [1], che suppongo siano gelosamente custodite
>> dagli operatori.
>>
>> [1] https://it.wikipedia.org/wiki/Stazione_radio_base
>
>
> Non proprio, le coordinate delle SRB sono un dato gestito dalle ARPA/APPA
> e pubblicamente accessibile.
>
> Esempio:
>
>
> http://webapps.comune.trento.it/mapaccel/?project=ambiente=elettromagnetismo=it
>
> http://geomap.arpa.veneto.it/maps/58/view
>
> http://castel.arpalombardia.it/castel/
>
> L'auspicio è che i dati regionali/provinciali un giorno confluiscano nel
> catasto nazionale antenne.
>
> Ciao
> /niubii/
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


[OSM-talk-fr] Fwd: bâtiment sans numéro de rue

2020-09-08 Per discussione osm . sanspourriel

Bonsoir,
Ce n'est pas rue des Étangs (la photo passée est prise de la rue de la
Vallée d'Authie), au 1 rue des Étangs c'est le garage sous la mairie,
pas une entrée publique.

L'entrée se fait bien par la rue de la Vallée d'Authie.

Le plus logique serait 83 bis (sûrement pas 63-65 : 63 et 65 sont
utilisés, 65 de l'autre côté de la rue des Étangs).

Il n'a pas de plaque de rue.

La mairie va avoir le droit à un message puisqu'on n'est pas encore en
dictature.
Il est possible que la mairie utilise un cedex mais dans ce cas on
devrait tomber dessus en faisant des recherches.

Je pense que "Mairie de XXX" suffit au facteur pour trouver ^^.

Jean-Yvon


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


Re: [OSM-talk-fr] Projet du mois défibrillateurs : point d'avancement

2020-09-08 Per discussione Philippe Verdy
On est loin de l'objectif national d'équipement, qui devrait atteindre au
minimum 1 appareil pour 500 habitants, soit 100 000 à 120 000 appareils
(peut-être moins dans les villes denses où l'accessibiltié est plus facile
qu'en milieu rural et où les services d'urgences sont également
beaucoup plus rapides à intervenir).

Si on considère que les ERP doivent être équipés, et qu'en gros ils
reçoivent une centaine de visiteurs au plus, sauf les stades ou campings et
grands hôtels, qui ont une densité plus grande, et les centres commerciaux
qui ont des milliers de visiteurs, plus les établissements publics
municipaux (mairies, salles communales, écoles, médiathèques, musées,
salles d'accueil pour associations), tous les EHPAD, on devrait avoir au
moins une 4 ou 5 appareils même dans les plus petites communes rurales pour
aussi desservir les quartiers résidentiels un peu éloignés du centre, avec
les aires de sport, campings municipaux, aires d'accueil de gens du voyage.
Et au besoin avec des accords public-privé pour les aider à les doter et
les entretenir.

D'ailleurs ces DAE sont aussi l'occasion de trouver les ERP et aller voir
sa mairie pour demander pourquoi certains sites ne sont pas équipés, et
revoir la proximité des équipements avec sa population dans les quartiers
périphériques (pourquoi pas alors aux arrêts de bus en partenariat avec les
sociétés de transport qui elles aussi sont sensées s'équiper: elles
accueillent un public très nombreux sur leur réseau, et même si on n'équipe
pas tous les véhicules, au moins équiper des stations pour pouvoir
intervenir à l'arrêt en sécurité pour tout le monde et permettre aussi de
"dégager" le public inutile et gênant).

Et puisqu'on a une base publique DAE qui se met en place, mettre le tout
sur une carte permet de voir les zones sous-équipées où celles où les DAE
installés n'aident personne autour (notamment ceux en accès restreint dans
une entreprise). Sur une carte je mettrais séparément ces DAE d'accès
restreint (notamment ceux aux sein même des établissements protégés comme
les EHPAD.

Et puis il suffit d'aller voir votre gymnase municipal proche, votre stade,
et les salles de sports privées qui elles aussi devraient être équipées. Et
voir votre comité de quartier (et demander aussi à votre mairie de
planifier des rencontres publiques dans les quartiers et mettre la question
à l'ordre du jour et lui demander de faire cette collecte et le communiquer
(ne serait-ce que par le site de l'intercommunalité qui lui aussi devrait
avoir sa section "open data", et pas que les grosse métropoles).

Des entreprises industrielles seraient aussi concernées (exploitants et
distributeurs sur les réseaux d'énergie notamment, autorités portuaires,
sites "Seveso" et toute industrie classée comme dangereuse par les produits
ou matériels utilisés ou stockés : en cas d'accident industriel, ils
monopilinsent fortement les secours et il faut une capacité locale pour
agir...). Et à mon avis ces matériels devraient aussi être assurés en même
temps que leur contrat d'entretien, et on devrait pouvoir impliquer aussi
les sociétés d'assurances et mutuelles qui couvrent ces risques ou
subventionnent les équipements.

En attendant GeoDAE n'est qu'un jeu d'essai qui n'a pas encore
d'utilisation pratique, il faudra vraiment il plus grande implication aussi
avec tous les services d'urgence (15, SAMU, SDIS, pompiers, services de
police) et de contrôle (y compris la médecine du travail et les comités
d'entreprise) et les assos et comités de quartiers pour que tout le monde
accepte de remonter ses infos et pas chacun dans son coin. Mais
GeoDAE semble ne pas fonctionner avec un guichet pleinement opérationnel.

au passage, au delà de cet équipement, il y a d'autres dispositifs de
sécurité aussi à relever (y compris la surveillance des plages), ainsi que
les dispositifs d'alerte (capteurs divers pour l'air, l'eau/la mer). Et au
final on aierait avoir une carte avec une mesure de l'impact de ces
équipements (délais d'intervention, taux d'utilisation, remises à jour ou
en conformité, relevés des pannes ou appareils perdus/détériorés.

Et si une zone n'a pas besoin de davantage de DAE (sur-équipement) les
entreprises pourraient aussi contribuer d'une autre façon en abondant un
fond d'équipement pour couvrir les zones blanches ou aider les sites peu
favorisés à s'équiper et entretenir. D'ailleuis je ne suis pas sur
qu'inciter chacun d'eux à s'équipper individellement est efficace, et s'il
ne faudrait pas en fait que la répartition des DAE réellement installés
soit du resort d'une autorité de planification qui approuverait ces
équipements (en contrôlant leur installation et leur entretien) ou
simplement recevrait des garanties financières avec une redevance ou des
preuves comptables de contributions vers d'autres secteurs moins favorisés.

Et je suis même convaincu que l'obligation d'assurer ces matériels au sein
de chaque contrat d'entretien permettrait d'utiliser les infras
informatiques des sociétés 

Re: [OSM-talk-fr] bâtiment sans numéro de rue

2020-09-08 Per discussione pepilepi...@ovh.fr
Le 08/09/2020 à 17:27, Yannick a écrit :
> Le 08/09/2020 à 17:12, pepilepi...@ovh.fr a écrit :
>> Le 08/09/2020 à 16:00, osm.sanspourr...@spamgourmet.com a écrit :
>>> Bonjour,
>>>
>>> j'ai un bâtiment (une mairie
>>> ) qui est dans une
>>> associatedStreet
>>> .
>>>
>>> Or selon la mairie et le cadastre il n'y a pas de numéro pour la
>>> mairie qui est entre le 63 et le 65.
>>>
>>> Vaut-il mieux supprimer de l'associatedStreet ou déclarer un faux
>>> positif car elle fait bien partie de la rue ?
>>>
>>> Jean-Yvon
>>>
>> Ou écrire au maire pour lui demander de mettre un numéro à sa mairie,
>> parce que ça fout le bordel dans OSM ?
>>
>> En attendant AMHA c'est un faux positif
>>
>> JP
> Bonsoir,
>
> Moi je lui mettrais 63 bis en avisant le maire.

...

Faut avouer que la dictature a certains mérites...

> Amitiés

Tout autant

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


-- 


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

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


Re: [OSM-talk-fr] bâtiment sans numéro de rue

2020-09-08 Per discussione pepilepi...@ovh.fr
Le 08/09/2020 à 17:22, Vincent de Château-Thierry a écrit :
> Bonjour,
>
>> De: pepilepi...@ovh.fr
>> Le 08/09/2020 à 16:00, osm.sanspourr...@spamgourmet.com a écrit :
>>
>> j'ai un bâtiment (une mairie ) qui est dans une associatedStreet .
>>
>> Or selon la mairie et le cadastre il n'y a pas de numéro pour la
>> mairie qui est entre le 63 et le 65.
>>
>> Vaut-il mieux supprimer de l'associatedStreet ou déclarer un faux
>> positif car elle fait bien partie de la rue ?
>>
>> Jean-Yvon
>>
>>
>> Ou écrire au maire pour lui demander de mettre un numéro à sa mairie,
>> parce que ça fout le bordel dans OSM ?
>>
>> En attendant AMHA c'est un faux positif
>>
>> JP
> Le propos des relations associatedStreet c'est de rassembler les n° d'une 
> rue, non ? Pour moi, en l'absence de n°, la relation est inexploitable 
> puisqu'il lui manque ce pour quoi elle est faite. Donc de mon point de vue, 
> si pas de numero, alors pas de relation, je supprimerais.
> En attendant que le courrier suggéré par JP fasse effet, bien sûr :)

En espérant qu'ils soient pas trop cons, ils comprendront...

J'ai du mal à comprendre que la poste ne leur impose pas une numérotaion
comme elle l'a fait chez moi il y a quelques années.

Bonne soirée,

JP

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


-- 


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

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


Re: [OSM-talk-fr] bâtiment sans numéro de rue

2020-09-08 Per discussione Philippe Verdy
Note que dans ton cas je ne suis pas certyain qu'elle soit au 63 ou 65 de
la Rue de la Vallée d'Authie. Regarder un peu l'imagerie BDOrtho, on voit
un accès piéton plutôt depuis la rue des Etangs !
et d'ailleurs le cadastre y indique que c'est le numéro 1 (donc l'autre rue
!)

Pas de 63 bis donc!

Le mar. 8 sept. 2020 à 17:27, Yannick  a écrit :

> Le 08/09/2020 à 17:12, pepilepi...@ovh.fr a écrit :
> > Le 08/09/2020 à 16:00, osm.sanspourr...@spamgourmet.com a écrit :
> >>
> >> Bonjour,
> >>
> >> j'ai un bâtiment (une mairie
> >> ) qui est dans une
> >> associatedStreet
> >> .
> >>
> >> Or selon la mairie et le cadastre il n'y a pas de numéro pour la
> >> mairie qui est entre le 63 et le 65.
> >>
> >> Vaut-il mieux supprimer de l'associatedStreet ou déclarer un faux
> >> positif car elle fait bien partie de la rue ?
> >>
> >> Jean-Yvon
> >>
> > Ou écrire au maire pour lui demander de mettre un numéro à sa mairie,
> > parce que ça fout le bordel dans OSM ?
> >
> > En attendant AMHA c'est un faux positif
> >
> > JP
>
> Bonsoir,
>
> Moi je lui mettrais 63 bis en avisant le maire.
>
> Amitiés
>
> --
> Yannick VOYEAUD
> Nul n'a droit au superflu tant que chacun n'a pas son nécessaire
> (Camille JOUFFRAY 1841-1924, maire de Vienne)
> http://www.voyeaud.org
> Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/
> Journées du Logiciel Libre: http://jdll.org
> Généalogie en liberté avec Ancestris https://www.ancestris.org
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] bâtiment sans numéro de rue

2020-09-08 Per discussione Philippe Verdy
Si elle est entre le 63 et le 65 (positions cadastrales, alors la mairie
elle-même a son adresse aux deux numéros: 63-65.
Ce n'est pas exceptionnel ça arrive souvent en fait, les terrains et
l'immobilier se vendent, se réaménagent, sont démolis, reconstruits, les
accès sont modifiés...

C'est pour ça qu'on demande de mettre les points d'adresse
préférablement comme neouds indépendants des POI, de préférence en limite
de la voie publique et au droit d'un accès (mais un accès peut ne plus
exister) quand on peut le "rattacher" à une propriété actuelle.

Les POI eux peuvent préciser quelle adresse ils utilisent dans contact:*
(pas besoin dans addr:* qui restent liés aux positions cadastrales selon
les plans de numérotation mis en place par les services municoipaux mais
souvent pas revus pendant des décennies tant qu'il n'y a pas besoin de le
revoir pour créer des "bis", "ter", etc., ou "A"/"B/"C"). Certaines
municipalits ne veulent pas gérer cette complexité et ont choisi une
numérotation métrique (donc avec de larges plages de numéros inutilisés,
l'attribution se faisant alors facilement à la volée des aménagements et on
n'est pas à une petite différence de quelques mètres si un accès est
modifié (le numéro utilisé dans les communications postales et
enregistrements divers n'ont pas besoin de changer et en fait beaucoup
omettent de préciser une plage de numéro mais précisent juste un seul (en
général le plus petit ou le plus "rond").


Le mar. 8 sept. 2020 à 17:12, pepilepi...@ovh.fr  a
écrit :

> Le 08/09/2020 à 16:00, osm.sanspourr...@spamgourmet.com a écrit :
>
> Bonjour,
>
> j'ai un bâtiment (une mairie )
> qui est dans une associatedStreet
> .
>
> Or selon la mairie et le cadastre il n'y a pas de numéro pour la mairie
> qui est entre le 63 et le 65.
>
> Vaut-il mieux supprimer de l'associatedStreet ou déclarer un faux positif
> car elle fait bien partie de la rue ?
>
> Jean-Yvon
>
> Ou écrire au maire pour lui demander de mettre un numéro à sa mairie,
> parce que ça fout le bordel dans OSM ?
>
> En attendant AMHA c'est un faux positif
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [talk-ph] Help fix the road network in the Philippines with MapRoulette challenges

2020-09-08 Per discussione Andrew Wiseman via talk-ph
Hi Eugene,

Thanks for the feedback and for noting that, I just disabled the older 
challenge to prevent that going forward.

Andrew

Andrew Wiseman |  Maps | iPhone: +1.202.270.4464 | andrew_wise...@apple.com 


> On Sep 8, 2020, at 8:27 AM, Eugene Alvin Villar  wrote:
> 
> Hi Andrew,
> 
> Thank you for providing additional MR tasks. I've been looking at these new 
> challenges and I think that two of the challenges seem to have a large amount 
> of duplicate tasks with each other: "Philippines - Overlapping Ways" (12768) 
> and "Philippines - Overlapping Ways / Vías superpuestas" (14203). This means 
> that if a mapper fixes a task in one challenge, another mapper would 
> encounter the exact same task in the other challenge but it is already fixed 
> leading to confusion and wasted time.
> 
> Regards,
> Eugene
> 
> 
> On Wed, Sep 2, 2020 at 6:11 AM Andrew Wiseman via talk-ph 
> mailto:talk-ph@openstreetmap.org>> wrote:
> Hi everyone,
> 
> I updated the MapRoulette challenges with new OSM data again, they are all 
> posted here:  https://maproulette.org/browse/projects/39286 
> 
> 
> Thanks!
> 
> Andrew 
> 
> Andrew Wiseman |  Maps | iPhone: +1.202.270.4464 | andrew_wise...@apple.com 
> 
> 
>> On Feb 25, 2020, at 10:38 AM, Andrew Wiseman via talk-ph 
>> mailto:talk-ph@openstreetmap.org>> wrote:
>> 
>> Hi everyone,
>> 
>> This is Andrew again from Apple. I wanted to let everyone know that we just 
>> updated the MapRoulette challenges related to road network issues in the 
>> Philippines with new OSM data. 
>> 
>> You can find all of the challenges in this MapRoulette project: 
>> https://maproulette.org/browse/projects/39286 
>>  and they include things like 
>> overly sharp road angles, roads that cross but aren’t connected, roads that 
>> aren’t connected to anything, overlapping roads, turn restrictions, roads 
>> that are close but not connected to others, and other similar issues. I plan 
>> to work on some of them myself too.
>> 
>> If you haven’t used it before, MapRoulette lets you go through potential 
>> issues in OSM data one by one and either correct them or indicate they are 
>> not a problem. The challenges were created with our Atlas data analysis 
>> tool: https://github.com/osmlab/atlas .
>> 
>> If you aren’t sure what challenge to try, sharp angles or crossing roads are 
>> probably the easiest but they should all be fairly straightforward.
>> 
>> Please let me know if you have any suggestions or feedback. Thank you! 
>> 
>> Andrew 
>> 
>> Andrew Wiseman |  Maps | iPhone: +1.202.270.4464 | andrew_wise...@apple.com 
>> ___
>> talk-ph mailing list
>> talk-ph@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/talk-ph 
>> 
> 
> ___
> talk-ph mailing list
> talk-ph@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-ph 
> 

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


Re: [Talk-pt] Quadriplicação de vértices geodésicos

2020-09-08 Per discussione Nuno José Almeida
Boa tarde Rui, já tinha percebido pela anterior explicação, que as marcas
pequenas também o são, obrigado anda assim. Tal como disse, assunto
encerrado para mim e 100% aceite.

António Madeira via Talk-pt  escreveu no dia
segunda, 7/09/2020 à(s) 18:41:

> Em casos como estes, onde existem três :
> https://www.openstreetmap.org/#map=19/39.81456/-8.75034
> https://www.openstreetmap.org/#map=19/39.84693/-8.69683
>
> Os pontos referem-se a marcas de bronze? E existem duas no local?
>
>
>
> Às 07:59 de 07/09/2020, Rui Reino Baptista escreveu:
>
> Caros Nuno José Almeida, Filohipo e António Madeira
>
> Não existe absolutamente nenhuma duplicação de vértices geodésicos. Todos
> eles possuem nomes e coordenadas geográficas próprias.
> É até muito natural a existência de várias "marcas" de coordenadas
> conhecidas e materializadas no terreno junto a um vértice geodésico de
> "maior" importância. A sua existência pode dever-se a derivados fatores,
> todos eles relacionados com a observação, coordenação, construção e
> utilização da rede de pontos coordenados.
>
> Ao dispor,
> RB
>
> ___
> Talk-pt mailing 
> listTalk-pt@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-pt
>
>
> ___
> Talk-pt mailing list
> Talk-pt@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-pt
>
___
Talk-pt mailing list
Talk-pt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-pt


Re: [OSM-talk-fr] bâtiment sans numéro de rue

2020-09-08 Per discussione Denis Chenu
Elle ne serait pas Rue des étangs l'entrée ?

C'est bête, ya même une photo :
https://upload.wikimedia.org/wikipedia/commons/thumb/4/42/Roussent%2C_Pas-de-Calais%2C_Fr%2C_mairie_(2).jpg/1200px-Roussent%2C_Pas-de-Calais%2C_Fr%2C_mairie_(2).jpg

Denis

Le 08/09/2020 à 16:00, osm.sanspourr...@spamgourmet.com a écrit :
>
> Bonjour,
>
> j'ai un bâtiment (une mairie
> ) qui est dans une
> associatedStreet
> .
>
> Or selon la mairie et le cadastre il n'y a pas de numéro pour la
> mairie qui est entre le 63 et le 65.
>
> Vaut-il mieux supprimer de l'associatedStreet ou déclarer un faux
> positif car elle fait bien partie de la rue ?
>
> Jean-Yvon
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

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


Re: [talk-ph] Help fix the road network in the Philippines with MapRoulette challenges

2020-09-08 Per discussione Eugene Alvin Villar
Hi Andrew,

Thank you for providing additional MR tasks. I've been looking at these new
challenges and I think that two of the challenges seem to have a large
amount of duplicate tasks with each other: "Philippines - Overlapping Ways"
(12768) and "Philippines - Overlapping Ways / Vías superpuestas" (14203).
This means that if a mapper fixes a task in one challenge, another mapper
would encounter the exact same task in the other challenge but it is
already fixed leading to confusion and wasted time.

Regards,
Eugene


On Wed, Sep 2, 2020 at 6:11 AM Andrew Wiseman via talk-ph <
talk-ph@openstreetmap.org> wrote:

> Hi everyone,
>
> I updated the MapRoulette challenges with new OSM data again, they are all
> posted here:  https://maproulette.org/browse/projects/39286
>
> Thanks!
>
> Andrew
>
> Andrew Wiseman |  Maps | iPhone: +1.202.270.4464 |
> andrew_wise...@apple.com
>
> On Feb 25, 2020, at 10:38 AM, Andrew Wiseman via talk-ph <
> talk-ph@openstreetmap.org> wrote:
>
> Hi everyone,
>
> This is Andrew again from Apple. I wanted to let everyone know that we
> just updated the MapRoulette challenges related to road network issues in
> the Philippines with new OSM data.
>
> You can find all of the challenges in this MapRoulette project:
> https://maproulette.org/browse/projects/39286 and they include things
> like overly sharp road angles, roads that cross but aren’t connected, roads
> that aren’t connected to anything, overlapping roads, turn restrictions,
> roads that are close but not connected to others, and other similar issues.
> I plan to work on some of them myself too.
>
> If you haven’t used it before, MapRoulette lets you go through potential
> issues in OSM data one by one and either correct them or indicate they are
> not a problem. The challenges were created with our Atlas data analysis
> tool: https://github.com/osmlab/atlas.
>
> If you aren’t sure what challenge to try, sharp angles or crossing roads
> are probably the easiest but they should all be fairly straightforward.
>
> Please let me know if you have any suggestions or feedback. Thank you!
>
> Andrew
>
> Andrew Wiseman |  Maps | iPhone: +1.202.270.4464 |
> andrew_wise...@apple.com
> ___
> talk-ph mailing list
> talk-ph@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ph
>
>
> ___
> talk-ph mailing list
> talk-ph@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ph
>
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph


Re: [OSM-talk-fr] bâtiment sans numéro de rue

2020-09-08 Per discussione Yannick
Le 08/09/2020 à 17:12, pepilepi...@ovh.fr a écrit :
> Le 08/09/2020 à 16:00, osm.sanspourr...@spamgourmet.com a écrit :
>>
>> Bonjour,
>>
>> j'ai un bâtiment (une mairie
>> ) qui est dans une
>> associatedStreet
>> .
>>
>> Or selon la mairie et le cadastre il n'y a pas de numéro pour la
>> mairie qui est entre le 63 et le 65.
>>
>> Vaut-il mieux supprimer de l'associatedStreet ou déclarer un faux
>> positif car elle fait bien partie de la rue ?
>>
>> Jean-Yvon
>>
> Ou écrire au maire pour lui demander de mettre un numéro à sa mairie,
> parce que ça fout le bordel dans OSM ?
> 
> En attendant AMHA c'est un faux positif
> 
> JP

Bonsoir,

Moi je lui mettrais 63 bis en avisant le maire.

Amitiés

-- 
Yannick VOYEAUD
Nul n'a droit au superflu tant que chacun n'a pas son nécessaire
(Camille JOUFFRAY 1841-1924, maire de Vienne)
http://www.voyeaud.org
Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/
Journées du Logiciel Libre: http://jdll.org
Généalogie en liberté avec Ancestris https://www.ancestris.org




signature.asc
Description: OpenPGP digital signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] bâtiment sans numéro de rue

2020-09-08 Per discussione Vincent de Château-Thierry
Bonjour,

> De: pepilepi...@ovh.fr
> Le 08/09/2020 à 16:00, osm.sanspourr...@spamgourmet.com a écrit :
> 
> j'ai un bâtiment (une mairie ) qui est dans une associatedStreet .
> 
> Or selon la mairie et le cadastre il n'y a pas de numéro pour la
> mairie qui est entre le 63 et le 65.
> 
> Vaut-il mieux supprimer de l'associatedStreet ou déclarer un faux
> positif car elle fait bien partie de la rue ?
> 
> Jean-Yvon
> 
> 
> Ou écrire au maire pour lui demander de mettre un numéro à sa mairie,
> parce que ça fout le bordel dans OSM ?
> 
> En attendant AMHA c'est un faux positif
> 
> JP

Le propos des relations associatedStreet c'est de rassembler les n° d'une rue, 
non ? Pour moi, en l'absence de n°, la relation est inexploitable puisqu'il lui 
manque ce pour quoi elle est faite. Donc de mon point de vue, si pas de numero, 
alors pas de relation, je supprimerais.
En attendant que le courrier suggéré par JP fasse effet, bien sûr :)

vincent

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


Re: [OSM-talk-fr] bâtiment sans numéro de rue

2020-09-08 Per discussione pepilepi...@ovh.fr
Le 08/09/2020 à 16:00, osm.sanspourr...@spamgourmet.com a écrit :
>
> Bonjour,
>
> j'ai un bâtiment (une mairie
> ) qui est dans une
> associatedStreet
> .
>
> Or selon la mairie et le cadastre il n'y a pas de numéro pour la
> mairie qui est entre le 63 et le 65.
>
> Vaut-il mieux supprimer de l'associatedStreet ou déclarer un faux
> positif car elle fait bien partie de la rue ?
>
> Jean-Yvon
>
Ou écrire au maire pour lui demander de mettre un numéro à sa mairie,
parce que ça fout le bordel dans OSM ?

En attendant AMHA c'est un faux positif

JP

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


-- 


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

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


Re: [OSM-talk-fr] Umap et ODBL

2020-09-08 Per discussione Vincent Bergeot

Le 08/09/2020 à 16:44, Cyrille37 OSM a écrit :

Bonjour Jacques,

Le 08/09/2020 à 16:38, Jacques Lavignotte a écrit :
les données d'une carte Umap passent-elles de facto sous la licence 
ODBL ?


De mon avis il n'y a aucun rapport entre la licence des données OSM et 
les données que l'on peut intégrer dans le logiciel UMAP.


il y a même un champs où l'on renseigne la licence des données 
utilisateur, que l'on peut atteindre sur une carte en cliquant sur à 
propos en bas à droite puis Crédits



La question est plutôt quelles sont les conditions d'utilisation du 
service umap.openstreetmap.fr (le service, pas le logiciel) : quand 
j'y verse des données, que deviennent elles... C'est toute la question 
des CGU de n'importe (de tout) service mis à disposition sur Internet.


Il faut donc consulter les Conditon Générale d'Utilisation, aka CGU, 
du **service** umap que tu utilises.


rha oui, en gros sur l'instance umap.openstreetmap.fr rien n'est écrit 
alors que cela devrait être le cas. Une piste -> compléter la page 
Mentions Légales (https://www.openstreetmap.fr/mentions-legales/) et y 
faire référence depuis les divers services osm-fr !


En gros le contenu c'est : nous n'utilisons pas les données, nous ne les 
regardons pas, nous ne les vendons pas, vous en restez les proprio, ... 
mais c'est à écrire ! Si quelqu'un veut l'écrire !






Cyrille37.


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



--
Vincent Bergeot


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


Re: [OSM-talk-fr] Umap et ODBL

2020-09-08 Per discussione Cyrille37 OSM

Bonjour Jacques,

Le 08/09/2020 à 16:38, Jacques Lavignotte a écrit :

les données d'une carte Umap passent-elles de facto sous la licence ODBL ?


De mon avis il n'y a aucun rapport entre la licence des données OSM et 
les données que l'on peut intégrer dans le logiciel UMAP.


La question est plutôt quelles sont les conditions d'utilisation du 
service umap.openstreetmap.fr (le service, pas le logiciel) : quand j'y 
verse des données, que deviennent elles... C'est toute la question des 
CGU de n'importe (de tout) service mis à disposition sur Internet.


Il faut donc consulter les Conditon Générale d'Utilisation, aka CGU, du 
**service** umap que tu utilises.


Cyrille37.


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


[OSM-talk-fr] Umap et ODBL

2020-09-08 Per discussione Jacques Lavignotte

Bonjour,

les données d'une carte Umap passent-elles de facto sous la licence ODBL ?


Jacques

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

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


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

2020-09-08 Per discussione Philippe Verdy
Le mar. 8 sept. 2020 à 09:24, Christian Quest  a
écrit :

> Le 07/09/2020 à 10:53, osm.sanspourr...@spamgourmet.com a écrit :
> > Salut,
> >
> > Le 07/09/2020 à 10:45, Denis Chenu via Talk-fr -
> > talk-fr@openstreetmap.org a écrit :
> >> Aucune raison de faire les 2.
> >
> > Si, certains systèmes ne traitent qu'un et donc les utilisateurs
> > débutants ajoutent l'autre.
> >
> La plus mauvaise raison selon moi.
>
> Le wiki est clair, pas de double objet, un POI est prioritairement
> surfacique sauf si le wiki indique pour le tag en question qu'il n'est
> que ponctuel... donc si les outils ne savent pas gérer ça, c'est à eux
> d'évoluer.
>

Donc tu te fais une remarque à toi-même concernant le rendu carto français
(celui par défaut sur openstreetmap.fr).


> Quand on met les 2, ça pénalise les outils qui suivent les règles à des
> traitements supplémentaires de dédoublonnage... merci !
>

La "pénalisation" est déjà en place et minime (et même possible puisque
Osmose sait le détecter et je ne pense pas que ça lui demande tant de
travail que ça.


> Il y a aussi le cas des places avec Nominatim et le rendu osm-fr (mais
> > là j'ai indiqué un contournement possible).
>
> Quel problème sur les place=* et le rendu FR ?  Il manque la prise en
> compte des polygones ?
>

Justement c'est bien ça, cette "règle" n'est  pas appliquée; pour s'éviter
d'avoir à gérer des doublons, il ne charge qu'une partie des données
valides et oublient les autres.
Si l'outil DOIT charger à la fois les points et les polygones pour les
mêmes tags, forcément il va devoir détecter et gérer les pseudo-"doublons"
proprement. C'est un phase de validation au même titre que le travail de
préparation et d'intégration dans les contributions d'OSM.

Et il y a des tas de raisons pour lesquelles même ces "doublons" sont
involontaires, notamment:
- des tas de noeuds non trouvés à la position attendue pour une recherche,
qui font qu'ils sont réajoutés
- le cas du serveur de données OSM qui ne charge pas tout (exemple très
régulièrment avec iD il manque des données ou on se retrouve avec une carte
totalement vide, le serveur a tronqué les données retournées (sans produire
aucune erreur, les erreurs qu'on voit dans la console sont essentiellement
celles de chargement des tuiles du fond de carte, des erreurs "mixed
content" sur certains fonds de carte (notamment les tuiles OrthoBD); l'API
de chargement de données n'est pas si stable que ça et les navigateurs ont
également renforcé récemment leur sécurité pour bloquer toute sorte de
choses silencieusement (et accélérer le reste du rendu sans épuiser les
ressources du poste client).
- la plupart des erreurs ne produisent aucun message dans le journal de la
console, des gestionnaires d'exception internes à l'appli les capture pour
ne pas planter l'appli, mais oublient de signaler ne serait-ce que sur la
console (que seuls les utilisateurs avancés vont consulter car la plupart
ne comprennent rien à ce qui y est affiché s'ils ne sont pas "développeurs
web".

Je parlais d'ID mais on a le même problème aussi dans JOSM (où là aussi
tout n'est pas chargé, et c'est même pas un bogue mais "par design"
pusique c'est conçu pour que ce soit l'utilisateur qui demande lui-même les
données) du fait ds limites du serveur OSM.org (divers "quotas"
d'utilisation appliqués silencieusement).

Tout n'est pas parfait, et je ne vois pas comment un rendu conforme peut
valablement se passer de charger les deux types d'objets et éviter une
phase de validation/dédoublonnage pour avoir un rendu correct (et s'il fait
un rendu incorrect, forcément les utilisateurs qui ne voient rien seront
tentés de rajouter à nouveau ce qui parait manquer).

Si le rendu ne fait les choses qu'à moitié, on reporte les problèmes et là
encore c'est fait silencieusement. Et pas la peine de renvoyer alors les
utilisateurs à une "faute" de leur part alors que ce qu'ils font est
parfaitement conforme à ce qui est documenté et ce qu'ils voient (dans les
limites qui lui sont imposées par les outils utilisés). Les "politiques"
d'OSM sont avant tout et en premier lieu à faire appliquer aux outils avant
d'incriminer les utilisateurs qui font du mieux qu'ils peuvent pour la
plupart.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Absence de licence sur l'application DIrectMairie de l'ADULLACT

2020-09-08 Per discussione Vincent Bergeot

Le 08/09/2020 à 09:21, Brice a écrit :

Le 05/09/2020 à 17:50, Vincent Bergeot a écrit :
j'ai également signalé sur la forge de l'adullact : 
https://gitlab.adullact.net/directmairie/directmairie/-/issues/113


Et moi via Twitter : 
https://twitter.com/bmallet/status/1284223078000713728
Agacement et lassitude en voyant cela de la part d'une association 
libriste.


reçu à l'instant 
"https://gitlab.adullact.net/directmairie/directmairie/-/issues/113;.


En résumé, c'est mis à jour depuis 6 mois pour la prochaine version mais 
non déployée : 
https://gitlab.adullact.net/directmairie/directmairie/-/issues/75


à plus

--
Vincent Bergeot


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


[OSM-talk-fr] bâtiment sans numéro de rue

2020-09-08 Per discussione osm . sanspourriel

Bonjour,

j'ai un bâtiment (une mairie
) qui est dans une
associatedStreet
.

Or selon la mairie et le cadastre il n'y a pas de numéro pour la mairie
qui est entre le 63 et le 65.

Vaut-il mieux supprimer de l'associatedStreet ou déclarer un faux
positif car elle fait bien partie de la rue ?

Jean-Yvon

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


Re: [Talk-it] IT-Alert: sistema di allarme pubblico

2020-09-08 Per discussione Lorenzo Rolla
Casualmente ho scoperto il sito di Alert.it:
https://www.it-alert.it.

Per il momento è abbastanza vuoto...



Il giorno mar 8 set 2020 alle 11:01 Francesco Pelullo 
ha scritto:

>
>
> Il mar 8 set 2020, 10:17 Cascafico Giovanni  ha
> scritto:
>
>> ... direi che alla base di qualsiasi iniziativa OSM sono le
>>
>>
>> coordinate delle BTS [1], che suppongo siano gelosamente custodite
>>
>>
>> dagli operatori.
>>
>>
>>
>>
>>
>> [1] https://it.wikipedia.org/wiki/Stazione_radio_base
>
>
> Non proprio, le coordinate delle SRB sono un dato gestito dalle ARPA/APPA
> e pubblicamente accessibile.
>
> Esempio:
>
>
> http://webapps.comune.trento.it/mapaccel/?project=ambiente=elettromagnetismo=it
>
> http://geomap.arpa.veneto.it/maps/58/view
>
> http://castel.arpalombardia.it/castel/
>
> L'auspicio è che i dati regionali/provinciali un giorno confluiscano nel
> catasto nazionale antenne.
>
> Ciao
> /niubii/
>
>
>
>
> ___
>
> Talk-it mailing list
>
> Talk-it@openstreetmap.org
>
> https://lists.openstreetmap.org/listinfo/talk-it
>
> --
Lorenzo Rolla
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [Talk-ko] Seoul bike rental stations import

2020-09-08 Per discussione Faustin Pegeot
Hi everyone,
for everyone interested here's an update.
I split the data on 따릉이 bike stations by district and analyzed the
positions more precisely in my district (중랑구, 52 stations) and found 3
stations with invalid data. Better than nothing, but at that point I
gave up on automatic import of the whole thing, and switched to manual
import with individual checks for each station.

It's a bit more tiresome so it might take longer, but I'm still on the project.

If anyone is motivated and wants to work on a specific district,
please let me know and I can send you a JOSM file with all stations
for that district, with name and tags pre-filled. All you have to do
at that point will be to open the file in JOSM to verify the location,
remove duplicates (already existing entries), add english name if
possible, for each station.

Thanks!
Faustin


2020-07-16 13:27 UTC, Faustin Pegeot :
> Hi,
> I noticed that the Seoul bike (따릉이) infrastructure near me was missing
> from OpenStreetMap. I managed to download the existing OSM data using
> https://overpass-turbo.eu/# (searching for tag amenity=bicycle_rental)
> and I found only 131 existing stations.
>
> In parallel, I got official data from
> https://www.data.go.kr/data/15051893/fileData.do and they report 1540
> stations. The data is complete, with name, latitude, longitude, bike
> capacity and everything. I managed to load the whole data into a
> data-frame with Python and sanity-check it all and it all looks fine.
> For those who want to see it, I attached all the data on my GitHub @
> https://github.com/mistrpopo/osm_ddareungi/blob/master/osm_ddareungi_compare.txt
>
> I am still in the process of comparing the two data sets to see
> whether they align well with the rest of the infrastructure (don't
> want to get bike stations in the middle of the street), but it looks
> promising so I want to start discussing the possibility of doing a
> mass import.
>
> Regarding licencing compatibility, the data is licenced under :
> - CC-BY
> - KOGL (Korean Open Government Licence) type 1. (in Korean 공공누리)
>
> From what I gathered, CC-BY is not fully compatible with OSM terms :
> https://blog.openstreetmap.org/2017/03/17/use-of-cc-by-data/
>
> Regarding KOGL type 1, here is an english version of the licence :
> https://www.mcst.go.kr/kor/s_open/kogl/koglType.jsp?pTab=05
>
> And here is a guide on licence compatibility for OGL-based licences :
> https://wiki.osmfoundation.org/wiki/Licence/Licence_Compatibility#Open_Government_Licence_.28OGL.29_based_licences
>
> I don't have any experience with licences, so I am not sure where to
> continue from here. It sounds like we can use the data under KOGL
> licence (on the condition that we cite the source, which we will do
> under https://wiki.openstreetmap.org/wiki/Import/Catalogue ).
>
> If not, I understand that I must require explicit permission. I also
> have the contact details for the Korean "Open Data Portal" :
> - tel :  공공데이터 개방문의 1566-0025
> - email : opendata_h...@nia.or.kr
> However, my Korean is sketchy and I am not sure whether they speak
> english, therefore if a native person could contact them, that would
> be great. I am not sure how many active users there are in Korea ...
> but if there are, please get in touch!
>
> Thank you
> Faustin
>

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


Re: [talk-cz] Chybný název katastrálního území Josefov v Praze

2020-09-08 Per discussione Jan Dudík
Ještě existuje katastrální území Úsov-Židovská obec, které je taky enkláva
- mohlo by se to ověřit na ní...
---
Ing. Jan Dudík
projekce dopravních staveb
tel. 777082195


út 8. 9. 2020 v 12:57 odesílatel  napsal:

> Myslel jsem si, že je chyba v tom, že přímo na té cestě tvořící hranici <
> https://www.openstreetmap.org/way/187925892> jsou boundary=administrative
> a admin_level=10, i když by (zdálo by se) měly být jen na nadřazené relaci <
> https://www.openstreetmap.org/relation/428844> (kde jsou také, spolu
> právě s názvy atd.).
>
> Jenže když koukám na <
> https://wiki.openstreetmap.org/wiki/Cs:Relation:boundary>, tak to je
> takhle prý správně (na rozdíl od běžných multipolygonů); takže by chyba
> byla prostě v tom nástroji, že neumí s daty takových enkláv správně
> pracovat.
>
> Na druhou stranu je to trochu zvláštní konvence a wiki říká, že značení
> cest je „volitelné“. Ale další diskusi nechám na někom, kdo tomu rozumí…
>
> -- Petr Kadlec / Mormegil
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz


Re: [talk-cz] Chybný název katastrálního území Josefov v Praze

2020-09-08 Per discussione petr . kadlec
Myslel jsem si, že je chyba v tom, že přímo na té cestě tvořící hranici <
https://www.openstreetmap.org/way/187925892> jsou boundary=administrative a
admin_level=10, i když by (zdálo by se) měly být jen na nadřazené relaci <
https://www.openstreetmap.org/relation/428844> (kde jsou také, spolu právě
s názvy atd.).

Jenže když koukám na <
https://wiki.openstreetmap.org/wiki/Cs:Relation:boundary>, tak to je takhle
prý správně (na rozdíl od běžných multipolygonů); takže by chyba byla
prostě v tom nástroji, že neumí s daty takových enkláv správně pracovat.

Na druhou stranu je to trochu zvláštní konvence a wiki říká, že značení
cest je „volitelné“. Ale další diskusi nechám na někom, kdo tomu rozumí…

-- Petr Kadlec / Mormegil
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz


[talk-cz] Chybný název katastrálního území Josefov v Praze

2020-09-08 Per discussione Martin Milichovský
Pro zjištění názvů správních celků Česka s jejich synchronizaci s těmito
údaji na projektu drobnepamatky.cz podle polohy památky používám službu
https://global.mapit.mysociety.org/. Už delší dobu ale nefunguje spárování
názvu katastrálního území Josefov v Praze. Například po zadání polohy této
sochy https://www.drobnepamatky.cz/node/9722 by se zde
https://global.mapit.mysociety.org/point/4326/14.418603,50.0903.html jako
poslední položka mělo zobrazit Josefov, ale zobrazuje se "Unknown name for
way with ID 187925892". Přitom památka třeba z katastrálního území Staré
město (a celé ČR, kromě Josefova) má výpis takto, správně:
https://global.mapit.mysociety.org/point/4326/14.421145,50.08.html .
Šlo by opravit?
Díky.
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz


[Talk-it] Webinar sulla cura di OSM

2020-09-08 Per discussione Cascafico Giovanni
A seguito di una proposta di Alessandro Sarretta, questa discussione
per organizzare un webinar sul "giardinaggio", interazione con nuovi
utenti, alert vandalismi e strumenti correlati.

Obiettivo: dal verbale stendere delle linee guida e buone pratiche
attraverso whodidit, osmcha ecc.

Dove:
uno dei server jitsi [1] TBD

Quando:
framadate [2]

[1] https://iorestoacasa.work/server.html
[2] https://framadate.org/osmgarden

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


Re: [Talk-it] IT-Alert: sistema di allarme pubblico

2020-09-08 Per discussione Francesco Pelullo
Il mar 8 set 2020, 10:17 Cascafico Giovanni  ha
scritto:

> ... direi che alla base di qualsiasi iniziativa OSM sono le
> coordinate delle BTS [1], che suppongo siano gelosamente custodite
> dagli operatori.
>
> [1] https://it.wikipedia.org/wiki/Stazione_radio_base


Non proprio, le coordinate delle SRB sono un dato gestito dalle ARPA/APPA e
pubblicamente accessibile.

Esempio:

http://webapps.comune.trento.it/mapaccel/?project=ambiente=elettromagnetismo=it

http://geomap.arpa.veneto.it/maps/58/view

http://castel.arpalombardia.it/castel/

L'auspicio è che i dati regionali/provinciali un giorno confluiscano nel
catasto nazionale antenne.

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


Re: [Talk-lt] Vilniaus dviračių maršrutai

2020-09-08 Per discussione Frank "Frankas" Wurft, BaltiCCycle.eu
atsiprasau, gali buti kad as netycia laiska siunciau i asmenini adresa  
ne i groupsa ;)


On 2020-09-08 11:11, Frank "Frankas" Wurft, BaltiCCycle.eu wrote:

Sveiki!

Aš - kaip autorius - manau, kad neverta :)

Aš norėčiau žymėti tik maršrutus "su infrastruktūra", tr. kai yra 
takai arba bent ženklai/žymėjimas.
Tas pats galioja dviračių maršrutams kitur (Saugumose teritorijose). 
Turi būti bent ženklai arba žymėjimas.
Išimtinis atvėjis yra planuojami nacionaliniai arba tarptautiniai 
maršrutai. Bet toks maršrutas turi turėti aiškų "savininką" (valdytoją)


jeigu visokius asmeninius maršrutus nori įkelti greitai gausis 
makaluzę ir bus perpildyta neaiškais maršrutais. Pvz. dviračių 
maršrutams buvo ir  2015 m. knygutė.


Šitie maršrutai vis dar yra "kompromisas", nes dviračių takai vis dar 
nutruksta  ir pastariuoju metu vyksta daug statybos ir žymėjimo (pvz. 
yra nauji oražiniai dviračių trasos ženklai Vakarų Vilniuje, "takas 
aplink Vilnių" ir pesčiųjų trasos). Pvz. dėl "tako aplink Vilnių" aš 
nesu tikras kiek iš jo liks po keletą metų, labai abejoju ar jį prižiūrės


Aš pats nebesigaunu, kas kur yra statomas, bet aš matau kad ir OSM 
šiuo metu "nespėja" atsinaujinti ir Vilniuje yra daug pasenusios 
informacijos.


Svarbiausiai įkelti informaciją apie naujus dviračių takus o maršrutus 
paliksime visokiems GPS kelių žemėlapiams :)


Toliau informuosiu ar pavyks ir ženklinti šio žemėlapio maršrutus, ten 
kur truksta ženklų.


On  2020-09-07 22:55, Albertas Agejevas wrote:

Sveiki,

Prieš kelis mėnesius Frankas Kulikauskas Wurft čia teiravosi apie
dviračių takų ir maršrutų žymėjimą.  Jo darbo rezultatas --
savivaldybės lankstinukas, kurį dalino per Sostinės dienas,
tikriausiai jis yra ir turizmo informacijos kioskuose.  Štai jo PDF:
https://neakivaizdinisvilnius.lt/wp-content/uploads/2020/08/Vilnius-dvira%C4%8Diais-1.pdf

Klausimas: ar turėtume šiuos maršrutus pažymėti OSM?  Ar bus prasmės,
praradant tų maršrutų metainformaciją, lankytinas vietas ir ruožus
intensyviais keliais?

Albertas

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



--

**



Pagarbiai / Yours Sincerly

Frank Kulikauskas (Wurft), M.A.

fran...@balticcycle.eu 
TEL. (mobil): +370 699 56009
FAX +370-5-2784074
SKYPE: Frankasw

www.balticcycle.eu 
RENT-A-BIKE * CYCLING MAPS * CITY TOURS
Vilnius - Klaipeda - Riga - Tallinn
velo-city Vilnius 

*VILNIUS BIKE TOURS & RENTAL
**
Pylimo 31, Vilnius

https://goo.gl/maps/PN8eHbQmxXP2

https://g.page/VeloVilnius



--

**



Pagarbiai / Yours Sincerly

Frank Kulikauskas (Wurft), M.A.

fran...@balticcycle.eu 
TEL. (mobil): +370 699 56009
FAX +370-5-2784074
SKYPE: Frankasw


www.balticcycle.eu 
RENT-A-BIKE * CYCLING MAPS * CITY TOURS
Vilnius - Klaipeda - Riga - Tallinn

velo-city Vilnius 

*VILNIUS BIKE TOURS & RENTAL
**
Pylimo 31, Vilnius

https://goo.gl/maps/PN8eHbQmxXP2

https://g.page/VeloVilnius
___
Talk-lt mailing list
Talk-lt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-lt


Re: [Talk-it] IT-Alert: sistema di allarme pubblico

2020-09-08 Per discussione Cascafico Giovanni
Il sistema di allarme, che entra in sperimentazione ad ottobre, manda
messaggi sia a livello nazionale che per area geografica (cerchio o
poligono convesso). In quest'ultimo caso, se guardiamo le implicazioni
geografiche, direi che alla base di qualsiasi iniziativa OSM sono le
coordinate delle BTS [1], che suppongo siano gelosamente custodite
dagli operatori.

[1] https://it.wikipedia.org/wiki/Stazione_radio_base

Il 08/09/20, Lorenzo Rolla ha scritto:
> Gentilissimi, magari a qualcuno viene qualche idea per sviluppare altre
> iniziative... Buona giornata. Lorenzo  (leggere gli allegati)
>
> DECRETO DEL PRESIDENTE DEL CONSIGLIO DEI MINISTRI 19 giugno 2020, n.
> 110  Regolamento
> recante modalita' e criteri di attivazione e gestione del servizio
> IT-Alert. (20G00129) (GU Serie Generale n.222 del 07-09-2020)
> note: Entrata
> in vigore del provvedimento: 22/09/2020
>
>
> https://www.gazzettaufficiale.it/atto/serie_generale/caricaDettaglioAtto/originario?atto.dataPubblicazioneGazzetta=2020-09-07=20G00129=false
> --
> Lorenzo Rolla
>

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


Re: [OSM-talk-fr] Tags addr: pour les radars

2020-09-08 Per discussione osm . sanspourriel

Le 08/09/2020 à 09:41, Christian Quest - cqu...@openstreetmap.fr a écrit :


Je ne sais pas si nominatim utilise les polygones pour son géocodage
inverse.


Si : /j'avais échangé avec Sarah suite à une erreur, en fait il se
trompe si un place= surfacique touche la voirie et que l'objet cherché
est de l'autre côté. //
/

/Exemple ://
/

/https://www.openstreetmap.org/search?query=l%27estran%2C%20guidel#map=19/47.78802/-3.48578
/

/Théâtre //L'Estran, Rue Général de Gaulle, Les Jardins de Vitalis,
Kerprat, Guidel, Lorient, Morbihan, Bretagne, France métropolitaine,
56520, France /

/Les Jardins de Vitalis touchent la Rue Général de Gaulle et L'Estran
aussi alors qu'il est de l'autre côté de la route./

/Problème subsidiaire : L'Estran est au 1 Allée de Kerprat, je pense que
pour le géocodage inverse de Nominatim, les adresses ne sont pas
utilisées dans un premier temps or le POI L'Estran est plus proche de la
rue que de l'allée./

/A l'opposé l'API de gouv.fr marche bien ://
/

/|curl 
"https://api-adresse.data.gouv.fr/reverse/?lon=|//|-3.4857794=|//|47.7880168"
 |/

/||//
///


Les addr:* ne devrait servir qu'à décrire des adresses, et rien d'autre.

Quand du courrier peut être envoyé à un POI à une adresse postale, on
utilise contact:*


Hélas les outils ne le favorisent guère, promouvant les addr: y compris
country et compagnie, sans intérêt en France.

Jean-Yvon

 ,

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


Re: [OSM-talk-fr] Tags addr: pour les radars

2020-09-08 Per discussione Christian Quest

Le 07/09/2020 à 18:12, Topographe Fou a écrit :

Bonjour,

Je vois plus de problème que d'avantages à l'utilisation des addr sur 
les radars :


1. Cela revient à utiliser is_in, un tag qui avait une raison d'être à 
une époque mais qui n'a presque plus de raison de vivre aujourd'hui, 
surtout dans un pays comme le nôtre ou les différents échelons 
administratifs sont assez bien cartographiés (Romain, ton approche par 
area est la bonne, merci pour la suggestion que tu lui fait)


MERCI !

Oui, ces tags n'ont vraiment pas d'intérêt vu que tout le zonage 
administratif est fait.



2. Je ne comprend pas l'argument du "oui mais moi j'en ai besoin" : 
dans ce cas on fait la même chose pour les bancs, les lampadaires, les 
poteaux et les routes, selon les hobbies de chacun ? C'est ingérable 
et redondant. L'énergie de ce contributeur va être vite usée car je 
doute que Romain soit le seul à ne pas comprendre la pertinence de ces 
tags sur un radar.


Ce ré-utilisateur "qui en a besoin" se fiche même du code postal, il 
veut retrouver le département... qui lui dit qu'il n'y a pas 100% de 
cohérence entre code postal et numéro INSEE de départements (et je ne 
parle pas de 2A/2B) ?



3. il n'y a pas si longtemps on a eu une longue discussion sur 
l'unicité des adresses. Je vois mal comment en s'arrêtant au pays ou à 
la ville on est unique.
Ce n'est même pas l'objet ici... vu que c'est le département qui est 
recherché.


4. rien ne dit qu'une relation radar de vitesse ne soit pas à cheval 
sur deux villes (en même temps ce n'est peut-être jamais le cas de par 
les contraintes d'implantation ?)


Question naïve : les radars n'ont pas une référence unique pour 
faciliter les consolidations ?


Sinon l'API Nominatim permet de geocoder plusieurs objets à la fois de 
mémoire pour qui code un minimum.


Je ne sais pas si nominatim utilise les polygones pour son géocodage 
inverse.


Une telle API serait relativement facile à mettre en place. Je pensais 
même que https://geo.api.gouv.fr/ le proposait déjà, mais non.




Donc à fond derrière Romain :)



Les addr:* ne devrait servir qu'à décrire des adresses, et rien d'autre.

Quand du courrier peut être envoyé à un POI à une adresse postale, on 
utilise contact:*



Pour compléter, la notion de zonage de code postal est malheureusement 
une règle avec des exceptions, car les codes postaux ne suivent pas 
forcément une logique de zone polygonale. Le CP n'est qu'une info 
utilisée pour la distribution du courrier qui n'est pas forcément faite 
par zone.


Dans le cas cité... le CP 69000 n'existe même pas, c'est un abus comme 
75000 pour "Paris".



--
Christian Quest - OpenStreetMap France

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


Re: [Talk-it] Alberi monumentali d’Italia

2020-09-08 Per discussione Cascafico Giovanni
Qui [1] trovare una mappa di audit per evidenziare come verrebbe la
conflation. Ho selezionato la regione Piemonte perchè in OSM ci sono
già diversi alberi da fondere col dataset MIPAAF.

L'audit lo abilito quando avremo compatibilità sulla licenza, per
evitare che qualcuno inizi a lavorare per niente. Per ora possiamo
cercare un consenso sul tagging.


[1] http://audit.osmz.ru/project/AM-PIE/

Il 07/09/20, Martin Koppenhoefer ha scritto:
>
>
> sent from a phone
>
>> On 7. Sep 2020, at 09:50, Cascafico Giovanni  wrote:
>>
>> però tuttosommato mettere un nodo in corrispondenza del
>> centroide di un bosco con il tag "se possibile trasformare in
>> filare/poligono" sarebbe tanto brutto?
>
>
> generalmente i metodi possono coesistere: se mappi un natural=tree_row può
> contenere nodi taggati con natural=tree e se il filare è parte di un viale
> si può aggiungere anche tree_lined al highway=* (senza togliere gli altri
> elementi)
>
>
> Ciao Martin
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>

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


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

2020-09-08 Per discussione Christian Quest

Le 07/09/2020 à 10:53, osm.sanspourr...@spamgourmet.com a écrit :

Salut,

Le 07/09/2020 à 10:45, Denis Chenu via Talk-fr -
talk-fr@openstreetmap.org a écrit :

Aucune raison de faire les 2.


Si, certains systèmes ne traitent qu'un et donc les utilisateurs
débutants ajoutent l'autre.


La plus mauvaise raison selon moi.

Le wiki est clair, pas de double objet, un POI est prioritairement 
surfacique sauf si le wiki indique pour le tag en question qu'il n'est 
que ponctuel... donc si les outils ne savent pas gérer ça, c'est à eux 
d'évoluer.


Quand on met les 2, ça pénalise les outils qui suivent les règles à des 
traitements supplémentaires de dédoublonnage... merci !




Il y a aussi le cas des places avec Nominatim et le rendu osm-fr (mais
là j'ai indiqué un contournement possible).


Quel problème sur les place=* et le rendu FR ?  Il manque la prise en 
compte des polygones ?





Donc plusieurs raisons, mais pas de bonnes raisons !

Et là le rôle des utilisateurs expérimentés c'est de proposer des
solutions pour que ce genre de cas ne se présente plus. 



Plus la règle est respectée, plus les outils devront s'adapter... et 
cette règle existe depuis 2009 et n'a jamais été remise en question à ce 
que je sache.


--
Christian Quest - OpenStreetMap France


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


Re: [OSM-talk-fr] Absence de licence sur l'application DIrectMairie de l'ADULLACT

2020-09-08 Per discussione Brice

Le 05/09/2020 à 17:50, Vincent Bergeot a écrit :
j'ai également signalé sur la forge de l'adullact : 
https://gitlab.adullact.net/directmairie/directmairie/-/issues/113


Et moi via Twitter : https://twitter.com/bmallet/status/1284223078000713728
Agacement et lassitude en voyant cela de la part d'une association libriste.

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


[Talk-it] IT-Alert: sistema di allarme pubblico

2020-09-08 Per discussione Lorenzo Rolla
Gentilissimi, magari a qualcuno viene qualche idea per sviluppare altre
iniziative... Buona giornata. Lorenzo  (leggere gli allegati)

DECRETO DEL PRESIDENTE DEL CONSIGLIO DEI MINISTRI 19 giugno 2020, n.
110  Regolamento
recante modalita' e criteri di attivazione e gestione del servizio
IT-Alert. (20G00129) (GU Serie Generale n.222 del 07-09-2020)
note: Entrata
in vigore del provvedimento: 22/09/2020


https://www.gazzettaufficiale.it/atto/serie_generale/caricaDettaglioAtto/originario?atto.dataPubblicazioneGazzetta=2020-09-07=20G00129=false
-- 
Lorenzo Rolla
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


[OSM-talk-fr] Projet du mois défibrillateurs : point d'avancement

2020-09-08 Per discussione PanierAvide

Bonjour à tous,

Petit point d'étape sur le projet du mois :

- 538 nouveaux défibrillateurs ont été ajoutés depuis le 24/08
- 106 personnes ont contribué au moins une fois
- 6893 défibrillateurs sont recensés dans OSM

Toutes les statistiques sont disponibles ici (actualisées 
quotidiennement) : https://projetdumois.fr/projects/2020-09_aed


C'est une bonne dynamique, mais je sais que la communauté peut aller 
encore plus loin :-)


Pas envie d'y passer trop de temps ? Voici comment vous pouvez 
contribuer à votre échelle en 10 minutes :


- Transférer l'article OSM France à votre groupe local ou dans vos 
réseaux : https://www.openstreetmap.fr/projet-du-mois-defibrillateurs/
- Ajouter le défibrillateur de votre quartier sur l'outil 
projetdumois.fr : https://projetdumois.fr/projects/2020-09_aed
- Appeler la mairie de la commune voisine pour leur demander où sont 
situés leurs défibrillateurs
- Demander à vos proches s'ils connaissent des localisations de 
défibrillateurs


Lancez-vous et participez à faire d'OSM une base de données qui sauve 
aussi des vies ! ;-)


Cordialement,

--
Adrien P.


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


Re: [Talk-it] R: R: R: R: Edit automatici su nome strade

2020-09-08 Per discussione Simone Saviolo
Il giorno mar 8 set 2020 alle ore 08:47 Simone Saviolo <
simone.savi...@gmail.com> ha scritto:

> [...] non stiamo dando un'informazione sbagliata, il che è meglio di
> un'informazione "corretta ma non enciclopedicamente corretta".
>

Nota per il futuro: rileggi prima di inviare, non dopo. Intendevo dire che
l'informazione può essere corretta, corretta ma incompleta oppure
sbagliata. L'importante è che l'informazione non sia sbagliata; correggere
un'informazione corretta ma incompleta *senza essere sicuri al 100%
(ragionevolmente) di non peggiorarla* è da evitare.

Ciao,

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


Re: [Talk-it] R: R: R: R: Edit automatici su nome strade

2020-09-08 Per discussione Simone Saviolo
Il giorno mar 8 set 2020 alle ore 06:10 canfe  ha
scritto:

> E’ vero, anche io inseguo chi lascia errori (e probabilmente qualcuno
> inseguirà me, solo che non me lo scrive mai), però rimane quel 95% di
> lavoro fatto che senza sistemi automatici non verrà mai fatto e rimane lì.
> Da anni.
>

Esattamente cos'è che rimane lì da anni?

Il dubbio se "Garibaldi" sia Giuseppe oppure no? Ma allora dovrebbe venirti
anche ogni volta che vedi "via San Martino": a chi si riferisce? Al santo?
Alla cittadina? Alla battaglia che si svolse nei pressi della cittadina?

Il fastidio  che "Garibaldi" è un nome impreciso? Anche "Giuseppe
Garibaldi" lo è: a parte la battuta che potrei fare citando il film
"Buongiorno presidente", il condottiero era Giuseppe Maria Garibaldi. E, di
nuovo, dovresti essere altrettanto preciso con tutti i nomi indicati
parzialmente: potremmo discuterne seduti su una panchina di piazza Camillo
Paolo Filippo Giulio Benso, conte di Cavour, di Cellarengo e di Isolabella.

Insomma, "via Garibaldi" è un dato non completamente corretto, ma
sicuramente non sbagliato. A Vercelli abbiamo almeno due esempi di omonimia
nelle vie: ci sono due vie Borgogna e due vie Ara; se non indicassi il nome
in quel caso sarebbe un vero errore, diversamente non stiamo dando
un'informazione sbagliata, il che è meglio di un'informazione "corretta ma
non enciclopedicamente corretta".

Infine, molti Comuni includono regolarmente il solo cognome nei segnali
stradali - sarebbe curioso verificare le ordinanze e scoprire che magari
quella via si chiama proprio esattamente "via Garibaldi".

Ciao,

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


Re: [Talk-it] R: R: R: R: Edit automatici su nome strade

2020-09-08 Per discussione mbranco2
Come si fa cosa?
Scrivere la mail a talk-it lo sai già, se parli di search in Josm,
non posso farlo: è una funzione supersegreta di Josm che viene rivelata
solo agli osmer giudiziosi, però sotto giuramento di non rivelarla a
nessuno...  

Il giorno mar 8 set 2020 alle ore 06:10 canfe  ha
scritto:

> Perché non fai vedere come si fa al meeting di Limone Piemonte al posto
> della relazione su Contour Merge e Multipoligoni?
>
>
>
> Cantone Ferruccio (canfe)
>
>
>
> *Da:* mbranco2 [mailto:mbran...@gmail.com]
> *Inviato:* lunedì 7 settembre 2020 20:15
> *A:* openstreetmap list - italiano
> *Oggetto:* Re: [Talk-it] R: R: R: Edit automatici su nome strade
>
>
>
> Ma no, Ferruccio, c'è scritto che devi comunicare in talk-it:
> "Ehilà, ho trovato x Via Garibaldi e y Via G.Garibaldi; che ne dite se le
> faccio diventare Via Giuseppe Garibaldi?"
>
> E altrettanto nel log della wiki. Non mi sembra quel grosso lavoro
> burocratico...
> Poi - prima di scatenarsi in Josm - sarà meglio leggere le risposte.
>
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it