Re: [OSM-talk-fr] Suffixe :covid19

[Yves P.]

> Par ici les horaires covid sont spécifique aux confinement. Généralement 
> ouvert de 14h à 16h du mardi au samedi. Voir encore plus restrictive
> Le reste de l'année les horaires sont habituelle.

On est tous d'accord :)


> Si la modifications se fait dans un sens qui va faire les relevés le mois 
> d'après pour contrôler les horaires habituelle ? Autant passer une seule fois 
> pour ajouter la condition horaire covid. Hors confinement elles ne doivent 
> plus être prises en compte.

Là encore, on est aussi tous d'accord :)

C'est la question du verre à moitié vide, ou à moitié plein :

1. Une application comme CRO va afficher les horaires en période covid à partir 
du tag opening_hours:covid19 (comment sait-elle qu'il y a un confinement ??)
2. Mais les applications non prévues pour ça (la majorité ??) va affiché les 
horaires "normaux" (tag opening_hours)

Avec la proposition d'Éric, toutes les applications vont afficher les horaires 
du moment : tag opening_hours :)

Pour répondre à ta remarque, si on note les horaires d'avant confinement dans 
le tag opening_hours:before_covid19, alors on pourra faire facilement du 
nettoyage (manuellement ou automatiquement).
Et ainsi ne passer qu'un seule fois pour ajouter "la condition horaire covid".


> De ce côté osmose fait très bien le job en proposant de transformer les 
> horaires covid en habituelles si elles n'existerait pas (après contrôle sur 
> place). Autrement la suppression des heures covid est proposé (pas le moment 
> de les supprimer)

L'analyseur Osmose le fera tout aussi bien en utilisant les clés 
opening_hours:before_covid19 et opening_hours (plutôt que opening_hours:covid19 
et opening_hours)

L'autre alternative est de ne rien changer, et d'espérer que toutes les 
applications utilisent opening_hours:covid19.
A-t-on une liste ?
Exhaustive ??

D'après Taginfo 
 il y a :
 Ça reste ouvert (It stays open) 

 iD Editor 
 AnyFinder - The universal POI finder and locator app 


__
Yves

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

Re: [OSM-talk-fr] Suffixe :covid19

[Gad Jo]

Je ne suis pas d'accord. Par ici les horaires covid sont spécifique aux 
confinement. Généralement ouvert de 14h à 16h du mardi au samedi. Voir encore 
plus restrictive

Le reste de l'année les horaires sont habituelle.

Si la modifications se fait dans un sens qui va faire les relevés le mois 
d'après pour contrôler les horaires habituelle ? Autant passer une seule fois 
pour ajouter la condition horaire covid. Hors confinement elles ne doivent plus 
être prises en compte.
De ce côté osmose fait très bien le job en proposant de transformer les 
horaires covid en habituelles si elles n'existerait pas (après contrôle sur 
place). Autrement la suppression des heures covid est proposé (pas le moment de 
les supprimer)

Le 20 novembre 2020 14:55:18 UTC, "Éric Gillet"  a 
écrit :
>Bonjour,
>
>Le suffixe :covid19 (opening_hours:covid19, delivery:covid19 etc.) a été 
>créé pour le premier confinement, lorsque beaucoup de monde espérait 
>qu'il soit de courte durée et enraye la pandémie.
>La covid19 n'a pas disparu après le premier confinement, mais beaucoup 
>de commerces "non-essentiels" ont rouvert, ou on retrouvé un 
>fonctionnement "classique". D'ici quelques semaines (croisons les 
>doigts), on aura la même situation : déconfinement, peut-être 
>couvre-feu, mais néanmoins covid19 toujours présente.
>
>Ce suffixe ne fait malheureusement pas la distinction entre pandémie et 
>confinement (et couvre-feu etc.), il est donc difficile de connaître son 
>application. De plus, même si l'on dit qu'il ne s'applique que pour le 
>confinement, il est difficile de savoir si les horaires (ou autre) sont 
>revenues à la version pré-confinement, sont restées telle-quelles ou ont 
>été modifiées.
>
>Ne faudrait-il pas de nouveau utiliser les tags sans suffixe :covid19, 
>gérer ces modifications comme des changements classiques ? Que ce soit 
>pour les descriptions, horaires, livraisons, service à emporter etc.
>
>Cela a également l'avantage que ces tags sont affichés et modifiés par 
>la plupart des applications, contrairement aux suffixes :covid19. Cela 
>engendre des contradictions si les contributeurs ou applications ne 
>gèrent pas les deux.
>
>Qu'en pensez-vous ?
>
>Éric
>
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
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-cz] SotM CZ+SK 2020

[Jiri Vlasak]

Ahoj,

já jen doplním, že Meeting Missing Maps CZ & SK jsme už udělali. Omlouvám se,
na poslední chvíli jsem posílal mail, ale neprošel spam filtrem a pak už jsem
to neřešil.

Použili jsme BigBlueButton zajištěný OSMF [1] a záznamy jsou dostunlé online
[2].

Pěkný den,
jiri

[1]: https://wiki.openstreetmap.org/wiki/Cs:BigBlueButton
[2]: https://libre.video/video-channels/mmm_czsk/videos

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

Re: [OpenStreetMap Serbia] Dodate zabrane skretanja u OSM

[Pedja Supurovic via Talk-rs]

Kul!

Okači ovo na forum, da eventualno neko ko poznaje teren gde ima 
nerešenih znakova može da uskoči.


Pedja


On 21.11.2020 00:15, Nemanja Bracko (E-Search) via Talk-rs wrote:
https://maproulette.org/browse/challenges/14783 



Rezultat je sledeći:

  * Dodato novih zabrana: 710*
  * Zabrane koje su inkluzivne: 999**
  * Zabrane koje su već bile ubačene: 65
  * Zabrane koje su zastarele ili pogrešne detekcije: 144
  * Zabrane koje su nam bili duplikati unutar samog seta: 33
  * Nismo mogli da rešimo: 89***


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

[OpenStreetMap Serbia] Dodate zabrane skretanja u OSM

[Nemanja Bracko (E-Search) via Talk-rs]

Pozdrav svima!

Hteo sam samo da vas obavestim da je moj tim danas završio zadatak koji smo 
dodali pretprošlog petka, te da smo dodali sve zabrane skretanja za koje je 
postojala indicija od strane Mapillary-ja.
Dobili smo neprocesirane, validirane detekcije, te smo uspeli da sa nekih 
17.000 detekcija smanjimo na 2.040.
Kada smo završni postprocesiranje detekcija (objedinjavanjem istih detekcija 
unutar bafera od 5 metara, te spajanja svih i pravljenja jednog centeroida), 
zadatak smo objavili ovde:
https://maproulette.org/browse/challenges/14783

Rezultat je sledeći:

  *   Dodato novih zabrana: 710*
  *   Zabrane koje su inkluzivne: 999**
  *   Zabrane koje su već bile ubačene: 65
  *   Zabrane koje su zastarele ili pogrešne detekcije: 144
  *   Zabrane koje su nam bili duplikati unutar samog seta: 33
  *   Nismo mogli da rešimo: 89***

*Jedan te isti znak prepoznat iz više smerova. Znamo da smo ga u nekoliko 
slučajeva obeležavali kao "dodato" u statistici, međutim ne verujem da je taj 
procenat veći od 5%;
**Ukoliko se zabrana skretanja odnosi na suprotan smer jednosmerne ulice 
(zabranjen ulazak u ulicu iz smera koji se posmatra), onda je to inkluzivna 
zabrana skretanja i nije potrebno da se doda relacija;
***Iz bilo kog razloga, npr: iz sporedne ulice je snimak uhvatio znak za 
zabranu skretanja, ali nemamo pokrivenost iz te ulice na koju se odnosi 
zabrana; moguća je loša detekcija; slika je muljava, te nismo mogli 100% da 
budemo sigurni da li je potrebno dodati, odnosno da li je detekcija dobra, itd.

Pored regularnih zabrana skretanja za motorna vozila, dodata je veća količina 
zabrana koja se odnosila na hgv (odnosno teretna vozila), kao i uslovne zabrane 
skretanja (bilo da se radi o vremenskom uslovu, nosivost ili kojim vozilima je 
dozvoljeno skretanje).

Pozdrav,
Nemanja
___
Talk-rs mailing list
Talk-rs@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-rs

[Talk-africa] Community in Mauritania

[Sören Reinecke]

Hi Africans,

is there an active community of (local) mappers mapping Mauritania? We
prefer local mappers but are also happy to hear from armchair mappers
mapping Mauritania based on imagery or on another means of data.

Cheers

Sören Reinecke
___
Talk-africa mailing list
Talk-africa@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-africa

Re: [Talk-de] Carsharing-Stationen Cambio und Stadtmobil Stuttgart

[Michael Reichert]

Hallo,

Am 20.11.20 um 14:26 schrieb Holger Bruch:
> Stadtmobil Stuttgart wird kommende Woche eine CSV-Datei der lokalen Stationen 
> auf https://stuttgart.stadtmobil.de/  unter 
> offener Lizenz bereitstellen.

Stadtmobil Karlsruhe hat seine Stationen dieses Jahr selber in OSM
(ein)gepflegt. Zahlreiche waren aber durch entsprechende Kunden
innerhalb der Karlsruhe OSM-Community schon erfasst, wenn auch in
veraltetem Zustand.

Viele Grüße

Michael



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

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

[Robert Grübler]

Am 19. November 2020 02:01 schrieb Kevin Kofler

> In dem Vergleich schneidet aber keine der Online-Karten wirklich gut ab

Du meinst keine ist empfehlenswert? 

OK, mein Anspruch war zu hoch. Vielleicht ist es besser nicht von 
„empfehlenswerten Karten“ zu sprechen sondern von „geeigneten Karten“. Ich 
meine damit alle Karten, welche die Mindestanforderungen erfüllen. Diese 
Punkteliste, die alle erfüllt sein müssen, ist sicher einfacher zu erstellen 
als eine Liste von Bewertungskriterien mit deren  numerischen 
Gewichtungsfaktoren.

Meine Mindestanforderungen sind:
1.  Basiert auf OSM
2.  Richtet sich an Wanderer
3.  Hat eine Legende für Wanderwege
4.  Deckt zumindest ein Kontinent ab
5.  Aktualisiert zumindest 1x jährlich
6.  Stellt sac_scale zumindest in 2 Gruppen dar

„trail_visibility“ darzustellen halte ich für keine Mindestanforderung.

LG Robert



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

Re: [OSM-talk-fr] Suffixe :covid19

[Yves P.]

> 
> En revanche avec le déconfinement progressif on devrait voir les magasins 
> retrouver leurs horaires habituels. Je serais plutôt partisan de conserver le 
> tag avec des horaires décrits finements lorsqu'il y a de vraies différences 
> mais pour les cas où les horaires sont les mêmes, privilégier la valeur 
> "same" plutôt que de copier les valeurs de opening_hours.

Il me semble que opening_hours:covid19=same était prévue pour ça.
Il aurait donc des interprétations de la "norme" ;)

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

Re: [OSM-talk-fr] Suffixe :covid19

[Pierre-Olivier GREGOIRE]

Re-bonjour ;)

J'avais la même idée initialement quand je suis reparti dans la mise à jour
des magasins sur Lyon, en supposant que les horaires d'origines n'avaient
plus de valeur.

De ce que j'ai pu voir sur Lyon, il y a quand même beaucoup de magasins qui
ont clairement des horaires "spécifiques confinement". Les horaires
habituels restent sur le site web et sur la vitrine mais une annonce sur
facebook ou sur le site web indique les modifications apportées
temporairement pendant le confinement.

Pour les magasins qui ne peuvent pas faire de vente en magasin en
particulier, les horaires affichés pendant le confinement sont souvent des
horaires de retrait de commande.

Je viens de faire un essai dans 3 magasins que je viens de vérifier (sans
sélection promis) :
* https://www.caresteouvert.fr/@45.759447,4.834247,18.06/place/n6920787480
(charcuterie) :
 - habituellement Tu-Sa 08:30-13:30, 15:00-19:30. Ce sont toujours les
horaires indiqués sur le site web
 - pendant le confinement : le site indique un service "spécialement
adaptés" et les horaires sont légèrement réduis : Tu-Sa
08:30-13:00,15:00-18:30
* https://www.caresteouvert.fr/@45.750527,4.888045,17.47/place/n6655041936
(sushi) :
 - habituellement mo-sa 11:00-14:30, 18:00-21:30; su off . Ce sont les
horaires indiquée sur le site web
 - pendant le confinement : Mo-Sa 11:30-13:30,18:00-21:00. Le site
indiqué ces horaires spécifiquement pendant le confinement par un message
dédié
* https://www.caresteouvert.fr/@45.751035,4.887766,17.47/place/n6222998836
(librairie) :
 - habituellement : Tu-Fr 09:30-13:00,14:30-19:30; Sa
09:00-13:00,15:00-19:00
 - en ce moment ouvert uniquement pour les retraits donc Mardi –
Mercredi – Vendredi de 9h30 à 12h30 et de 14h30 à 19h Samedi de 9h à 13h et
c'est affiché comme un horaire exceptionnel sur leur site.

En revanche avec le déconfinement progressif on devrait voir les magasins
retrouver leurs horaires habituels. Je serais plutôt partisan de conserver
le tag avec des horaires décrits finements lorsqu'il y a de vraies
différences mais pour les cas où les horaires sont les mêmes, privilégier
la valeur "same" plutôt que de copier les valeurs de opening_hours.

Pierre-Olivier


Le ven. 20 nov. 2020 à 16:29, David Faure via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> On vendredi 20 novembre 2020 15:55:18 CET Éric Gillet wrote:
> > Le suffixe :covid19 (opening_hours:covid19, delivery:covid19 etc.) a été
> > créé pour le premier confinement, lorsque beaucoup de monde espérait
> > qu'il soit de courte durée et enraye la pandémie.
> > La covid19 n'a pas disparu après le premier confinement, mais beaucoup
> > de commerces "non-essentiels" ont rouvert, ou on retrouvé un
> > fonctionnement "classique". D'ici quelques semaines (croisons les
> > doigts), on aura la même situation : déconfinement, peut-être
> > couvre-feu, mais néanmoins covid19 toujours présente.
> >
> > Ce suffixe ne fait malheureusement pas la distinction entre pandémie et
> > confinement (et couvre-feu etc.), il est donc difficile de connaître son
> > application. De plus, même si l'on dit qu'il ne s'applique que pour le
> > confinement, il est difficile de savoir si les horaires (ou autre) sont
> > revenues à la version pré-confinement, sont restées telle-quelles ou ont
> > été modifiées.
> >
> > Ne faudrait-il pas de nouveau utiliser les tags sans suffixe :covid19,
> > gérer ces modifications comme des changements classiques ? Que ce soit
> > pour les descriptions, horaires, livraisons, service à emporter etc.
> >
> > Cela a également l'avantage que ces tags sont affichés et modifiés par
> > la plupart des applications, contrairement aux suffixes :covid19. Cela
> > engendre des contradictions si les contributeurs ou applications ne
> > gèrent pas les deux.
>
> Je suis 100% d'accord.
>
> --
> David Faure, fa...@kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>
>
>
>
> ___
> 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] Suffixe :covid19

[Yves P.]

> Ne faudrait-il pas de nouveau utiliser les tags sans suffixe :covid19, gérer 
> ces modifications comme des changements classiques ? Que ce soit pour les 
> descriptions, horaires, livraisons, service à emporter etc.
> 
> Cela a également l'avantage que ces tags sont affichés et modifiés par la 
> plupart des applications, contrairement aux suffixes :covid19. Cela engendre 
> des contradictions si les contributeurs ou applications ne gèrent pas les 
> deux.

A priori je suis d'accord.


Les horaires pré covid sont imprimés, gravés sur beaucoup de vitrines, plaques…
En allant sur le terrain on peut toujours les voir, avec en plus une affiche 
collée sur la porte.

Du coup pouvoir voir les 2 dans l'objets OSM sans consulter l'historique est 
pratique.

Ne faudrait-il pas renommer les tags ?

opening_hours = horaires actuels (ça revient à ta proposition).
opening_hours:before_covid = les "anciens".

Comme ça si on se débarrasse du corona virus, on pourra nettoyer facilement les 
tags.
opening_hours ← opening_hours:before_covid
puis suppression de opening_hours:before_covid

__
Yves

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

Re: [OSM-talk-fr] Suffixe :covid19

[David Faure via Talk-fr]

On vendredi 20 novembre 2020 15:55:18 CET Éric Gillet wrote:
> Le suffixe :covid19 (opening_hours:covid19, delivery:covid19 etc.) a été
> créé pour le premier confinement, lorsque beaucoup de monde espérait
> qu'il soit de courte durée et enraye la pandémie.
> La covid19 n'a pas disparu après le premier confinement, mais beaucoup
> de commerces "non-essentiels" ont rouvert, ou on retrouvé un
> fonctionnement "classique". D'ici quelques semaines (croisons les
> doigts), on aura la même situation : déconfinement, peut-être
> couvre-feu, mais néanmoins covid19 toujours présente.
> 
> Ce suffixe ne fait malheureusement pas la distinction entre pandémie et
> confinement (et couvre-feu etc.), il est donc difficile de connaître son
> application. De plus, même si l'on dit qu'il ne s'applique que pour le
> confinement, il est difficile de savoir si les horaires (ou autre) sont
> revenues à la version pré-confinement, sont restées telle-quelles ou ont
> été modifiées.
> 
> Ne faudrait-il pas de nouveau utiliser les tags sans suffixe :covid19,
> gérer ces modifications comme des changements classiques ? Que ce soit
> pour les descriptions, horaires, livraisons, service à emporter etc.
> 
> Cela a également l'avantage que ces tags sont affichés et modifiés par
> la plupart des applications, contrairement aux suffixes :covid19. Cela
> engendre des contradictions si les contributeurs ou applications ne
> gèrent pas les deux.

Je suis 100% d'accord.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

[OSM-talk-fr] Suffixe :covid19

[Éric Gillet]

Bonjour,

Le suffixe :covid19 (opening_hours:covid19, delivery:covid19 etc.) a été 
créé pour le premier confinement, lorsque beaucoup de monde espérait 
qu'il soit de courte durée et enraye la pandémie.
La covid19 n'a pas disparu après le premier confinement, mais beaucoup 
de commerces "non-essentiels" ont rouvert, ou on retrouvé un 
fonctionnement "classique". D'ici quelques semaines (croisons les 
doigts), on aura la même situation : déconfinement, peut-être 
couvre-feu, mais néanmoins covid19 toujours présente.


Ce suffixe ne fait malheureusement pas la distinction entre pandémie et 
confinement (et couvre-feu etc.), il est donc difficile de connaître son 
application. De plus, même si l'on dit qu'il ne s'applique que pour le 
confinement, il est difficile de savoir si les horaires (ou autre) sont 
revenues à la version pré-confinement, sont restées telle-quelles ou ont 
été modifiées.


Ne faudrait-il pas de nouveau utiliser les tags sans suffixe :covid19, 
gérer ces modifications comme des changements classiques ? Que ce soit 
pour les descriptions, horaires, livraisons, service à emporter etc.


Cela a également l'avantage que ces tags sont affichés et modifiés par 
la plupart des applications, contrairement aux suffixes :covid19. Cela 
engendre des contradictions si les contributeurs ou applications ne 
gèrent pas les deux.


Qu'en pensez-vous ?

Éric


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

Re: [OSM-talk-fr] Changements "anciens" de limites communales

[Philippe Verdy]

Les communes associées sont toujours des communes (au même titre que les
communes déléguées dans les communes nouvelles) même si elles ne sont pas
de plein exercice. Et ont une identité légale, juridique et comptable. La
seule chose vraiment changé c'est la fusion en un conseil municipal unique,
mais pourtant il y a bien une identité réelle, leur code INSEE est toujours
valide, il y a toujours des références dessus sur les identités de
personnes physiques et morales qui y sont enregistrées, et elles ont
conservé leur toponymie propre.
Elles devraient toutes être présentes. Un certain nombre sont dans OSM,
mais il en manque encore (et pourtant on a des tracés précis dans le
cadastre, où on les repère par le découpage zonal, avec les planches codées
pas seulement en lettres mais avec en préfixe les 3 chiffres initiaux
correspondant au code commune (sauf la commune chef-lieu, qui porte le
numéro "000" s'il y en a un, ou alors pas indiqué du tout) pour éviter les
lettrages identiques (certaines communes ont opté pour un relettrage par
exemple en ajoutant une lettre, ou lorsque le zonage des communes membres a
été redécoupé, tout en conservant l'ancienne limite toujours en vigueur,
par exemple pour aménager une zone d'activité ou un nouveau quartier à
lotir).
Ce zonage cadastral fait toujours référence (par exemple dans les actes
notariés): le cadastre a donc des limites précises (autant que les
frontières communales actuelles, sauf qu'elles ont rarement besoin de
conflation manuelle d'une commune à l'autre.
Tant qu'il n'y a pas eu de fusion pleine, le découpage zonal cadastral doit
conserver ces limites dans le plan d'assemblage de la commune.


Le jeu. 19 nov. 2020 à 00:38, Jérôme Amagat  a
écrit :

> En anciennes communes qui ont encore une "existence" aujourd'hui, il y a
> les communes qui sont devenues communes associées mais ça date des années
> 70. Il en manque beaucoup dans OSM.
>
> Le mer. 18 nov. 2020 à 18:48, Christian Quest  a
> écrit :
>
>> Le 18/11/2020 à 18:23, Yann-Vari Gwiader a écrit :
>> > Bonjour,
>> >
>> > Avant les incitations récentes aboutissant au regroupement de
>> > certaines communes en France, les modifications des délimitations
>> > communales ont été des phénomènes courants au XXème siècle. Il
>> > s'agissait souvent de regrouper plusieurs communes en une, ou alors de
>> > démembrer une ou plusieurs communes pour en créer une nouvelle, ou
>> > alors de transferts de bouts de territoires d'une commune à une autre.
>> >
>> > La page suivante du wiki :
>> >
>> https://wiki.openstreetmap.org/wiki/Talk:France/Limites_administratives/Tracer_les_limites_administratives#Anciennes_limites_administratives_.28r.C3.A9gion.2Fd.C3.A9partement.2Farrondissement.2Fcommune.29
>> >
>> > indique : "Il est toujours pertinent de conserver les anciennes
>> > limites (en positionnant disused:boundary sur la relation + en
>> > complétant par end_date la date de fin de vie de la limite, ainsi que
>> > source et source:url pour fournir la référence du changement)".
>> >
>> > J'ai un certain nombre d'exemples en tête concernant des modifications
>> > territoriales de communes qui ont été réalisées dans les années 1950
>> > et pour lesquelles des éléments (décrets + indications portées sur le
>> > cadastre napoléonien) permettent de reconstituer les changements qui
>> > ont eu lieu. Ces éléments ne sont pas, à cette heure, stockés dans
>> > OpenStreetMap pour les exemples que j'ai en tête.
>> >
>> > La question que je me pose est de savoir si le mode opératoire
>> > mentionné sur la page wiki ci-dessus est à jour et complet (dans
>> > l'hypothèse où l'inclusion de telles informations est validée par la
>> > communauté).
>> >
>> > Merci pour vos éclairages,
>> > Yann
>>
>>
>> C'est essentiellement pour les fusions récentes que l'on a conservé les
>> limites, je ne pense pas que pour des changements antérieurs (année 50
>> !) on ait quoi que ce soit dans OSM en France.
>>
>> Ajouter ces infos passerait sûrement mal au niveau de la communauté,
>> assez attaché à cartographier le monde tel qu'il est et pas tel qu'il
>> était il y a 70 ans. On a l'exemple des anciennes voies ferrées ou déjà
>> il y a presque une sorte de tolérance à avoir ces tracés alors qu'il n'y
>> a plus rien de visible sur le terrain.
>>
>> Il faudrait voir si Open Historical Map est encore actif et si ça ne
>> pourrait pas être ajouté là bas.
>>
>> --
>> Christian Quest - OpenStreetMap France
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-de] Carsharing-Stationen Cambio und Stadtmobil Stuttgart

[Hartmut Holzgraefe]

On 2020-11-20 14:26, Holger Bruch wrote:

> Erfreulicherweise haben Cambio und Stadtmobil Stuttgart reagiert. Cambio 
> gestattet die Nutzung ihrer Auskunfts-API, um Carsharing-Stationen in OSM zu 
> übernehmen, Mail siehe unten.

super, ich habe auch gleich eine Station gefunden die hier in Bielefeld
noch nicht erfasst war.

Schade beim Cambio-Api nur, dass zwar in der JSON-Antwort zu finden ist
welche Fahrzeugarten an den jeweiligen Stationen zu finden sind, nicht
aber die Anzahl. Aber irgendwas ist ja immer ;)

PS: hier das quick PHP Script mit dem ich das Cambio-Format in OSM
XML gewandelt habe um die Daten in JSOM laden zu können:

 $lat, "lon" => $lon, "name" => $station["name"]];
}

$id = -1;

echo "\n";
echo "\n";
echo "  \n";

foreach ($out as $node) {
echo "\n";
echo "  \n";
echo "  \n";
echo "\n";
$id--;
}

echo "\n";


-- 
hartmut

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

[Talk-de] Local Chapter and Community Congress am 21.11.2020

[Hanna Krüger]

Hallo zusammen,

morgen um 13:00 Uhr (12:00 UTC) findet der LCCC der OSM Foundation über 
BigBlueBottom statt. Mehr zum Programm findet ihr unter: 
https://wiki.openstreetmap.org/wiki/Foundation/Local_Chapters/Local_Chapters_Congress/2020

Wer teilnehmen möchte, sollte sich vorher über das Anmeldeformular registrieren.

Liebe Grüße
Hanna
— 
Hanna Krüger
Schriftführerin

FOSSGIS e.V.
Römerweg 5
79199 Kirchzarten

E-Mail: hanna.krue...@fossgis.de
Web: fossgis.de

Eintragung im Vereinsregister der Stadt Mainz. Registernummer: 90 VR 3594.
Vertreten durch Dominik Helle, Jörg Thomsen, Jochen Topf, Hanna Krüger





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

[Talk-de] Carsharing-Stationen Cambio und Stadtmobil Stuttgart

[Holger Bruch]

Hallo zusammen,

auch wenn die Woche schon so gut wie vorbei ist: anlässlich des 
OSM-Mapping-Wochenschwerpunktes Carsharing habe ich bei Carsharing-Anbietern 
angefragt, ob diese nicht ihre APIs zugänglich machen oder zumindest Daten 
ihrer Standorte veröffentlichen möchten [1].

Erfreulicherweise haben Cambio und Stadtmobil Stuttgart reagiert. Cambio 
gestattet die Nutzung ihrer Auskunfts-API, um Carsharing-Stationen in OSM zu 
übernehmen, Mail siehe unten.

Stadtmobil Stuttgart wird kommende Woche eine CSV-Datei der lokalen Stationen 
auf https://stuttgart.stadtmobil.de/  unter 
offener Lizenz bereitstellen.

Viele Grüße,
Holger

[1] https://twitter.com/stadtnavi/status/1327670771888611328 
 

Hallo Holger und alle Aktiven bei OSM,
 
wie besprochen hier unsere Übersicht zur Stations-API:
Stationsübersicht - API für OSM
Stadt/Region
Eurocode
Link
Aachen
AAC
https://cwapi.cambio-carsharing.com/pub/AAC/stations 

Berlin
BRL
https://cwapi.cambio-carsharing.com/pub/BRL/stations 

Bielefeld
BIL
https://cwapi.cambio-carsharing.com/pub/BIL/stations 

Bremen
BRE
https://cwapi.cambio-carsharing.com/pub/BRE/stations 

Flensburg
FLB
https://cwapi.cambio-carsharing.com/pub/FLB/stations 

Hamburg
HAM
https://cwapi.cambio-carsharing.com/pub/HAM/stations 

Köln
KOE
https://cwapi.cambio-carsharing.com/pub/KOE/stations 

Lüneburg
LBG
https://cwapi.cambio-carsharing.com/pub/LBG/stations 

Oldenburg
OLD
https://cwapi.cambio-carsharing.com/pub/OLD/stations 

Saarbrücken
SAB
https://cwapi.cambio-carsharing.com/pub/SAB/stations 

Wuppertal
WUP
https://cwapi.cambio-carsharing.com/pub/WUP/stations 

in Belgien:
Brüssel
BXL
https://cwapi.cambio-carsharing.com/pub/BXL/stations 

Wallonie
WAL
https://cwapi.cambio-carsharing.com/pub/WAL/stations 

Flandern
VLA
https://cwapi.cambio-carsharing.com/pub/VLA/stations 

Deeplinks für Stationen folgen diesem Muster:
https://www.cambio-carsharing.de/station/BRE/2936.html 
 
 
Die Daten dieser offenen APIs dürfen für die Integration auf OpenStreetMap 
verwendet werden.
 
Bei Fragen könnt ihr euch gern an mich wenden – vorzugsweise per E-Mail.
 
Vielen Dank für eure Arbeit und viele Grüße
 
Carolin
 
Carolin Hinz-Sowade
Digital Marketing Managerin
cambio Mobilitätsservice GmbH & Co.KG 
Humboldtstraße 131-137 
28203 Bremen

TeamWeb ät cambio-carsharing.com 




-- 
MITFAHR|DE|ZENTRALE
Einfach Mitfahren!
@mfdz_de
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-talk-fr] Proposition - Vote - Les pompes

[Jacques Lavignotte]

Le 19/11/2020 à 20:19, François Lacombe a écrit :

le vote sur la proposition traitant des pompes est finalement ouvert


A voté !


--
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] Proposition - Vote - Les pompes

[François Lacombe]

Merci Cyrille

C'est bien par la discussion qu'on arrivera à trouver la meilleure solution.
J'ai bien conscience que la proposition prévoit des changements, en
contrepartie de concepts plus largement définis définis qu'actuellement

Bon weekend

François

Le ven. 20 nov. 2020 à 13:35, Cyrille37 OSM via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Hello again
>
> Je suis aux bouts de mes arguments, les points de vue différents sont
> indissociables de notre humanité :-) Je laisse donc mon vote "pour" en
> confiance et en encouragement de ton implication :-D
>
> Cyrille37.
> Le 20/11/2020 à 13:08, François Lacombe a écrit :
>
> Cyrille,
>
> Parfois, les usages établis l'ont été à des époques où nous partions d'une
> feuille blanche.
> S'interdire de les améliorer (donc de remplacer certaines choses parfois)
> parce qu'ils existent aurait pu être opposé à OSM lorsqu'il remplace
> d'autres choses.
>
> En l'occurrence, pump=powered a beau être simple, il ne veut
> malheureusement rien dire et posera certainement des problèmes quand il
> s'agira de mettre osm en correspondance avec d'autres standards.
> Si il s'agit d'indiquer que la pompe n'est pas activable à la main, on
> peut mettre handle=no
>
> Je le redis, pump=* actuel ne parle pas de pompe, uniquement de puis et de
> moteurs éventuels. Pas des pompes.
>
> François
>
> Le ven. 20 nov. 2020 à 12:55, Cyrille37 OSM via Talk-fr <
> talk-fr@openstreetmap.org> a écrit :
>
>> François
>>
>> Je rejoins assez "Jeisenbe" sur le fait de ne pas déprécier les valeurs
>> précédentes qui correspondent à un usage établi. Pourquoi ne pas seulement
>> enrichir l'existant ?
>>
>> Pour ma part je trouve excellent les tags pump=manual et pump=powered,
>> c'est exactement de mon niveau. Ensuite s'ils peuvent être enrichis par
>> d'autres tags, yes, no problemo :-)
>>
>> C/.
>> Le 20/11/2020 à 12:25, Cyrille37 OSM a écrit :
>>
>> François
>>
>> Ceux qui sont contre disent que c'est "pump=powered" qui disparaît dans
>> la proposition, ce qui enlève la permission de tagger simplement.
>>
>> Cyrille.
>> Le 20/11/2020 à 10:37, François Lacombe a écrit :
>>
>> Bonjour Cyrille,
>>
>> Merci pour ton commentaire.
>>
>> Le ven. 20 nov. 2020 à 10:10, Cyrille37 OSM via Talk-fr <
>> talk-fr@openstreetmap.org> a écrit :
>>
>>> Je suis sensible au contre argument :
>>> *Any tagging scheme allowing to tag extreme detail uninteresting to
>>> nearly all people must allow also tagging basic info without making
>>> mandatory to specify details*
>>>
>> Cela tombe bien parce que je ne comprends pas cette phrase.
>> Il n'y a aucun tag obligatoire (sinon évidemment le man_made, mais c'est
>> une évidence), surtout pas le mechnical_driver.
>>
>>> Mais je n'ai pas analysé précisément la proposition pour confirmer sa
>>> véracité, seulement lu les 3 oppositions qui je trouve se rejoignent sur la
>>> nécessité de tagger simplement un pompe.
>>>
>> C'était bien le but je vous rassure, visiblement on est tous d'accord
>> (mais certains se sentent quand même obligés de voter contre)
>>
>>> Cette proposition permet-elle de continuer à tagger très simplement une
>>> pompe avec un seul tag, sans autre connaissance des détails ?
>>>
>> Oui, man_made=pump : c'est une pompe et suffit à lui-même, on est pas
>> obligé de faire plus.
>>
>> Le point central de la proposition est de cesser d'utiliser "pump" pour
>> parler du moteur puisque c'est le cas aujourd'hui.
>> Une pompe est souvent animée par un moteur, on a donc deux appareils
>> pompe + moteur, il me semble logique qu'OSM ait deux tags pour parler
>> respectivement de la pompe et du moteur.
>>
>> Bonne fin de semaine à vous tous
>>
>> François
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Proposition - Vote - Les pompes

[Cyrille37 OSM via Talk-fr]

Hello again

Je suis aux bouts de mes arguments, les points de vue différents sont 
indissociables de notre humanité :-) Je laisse donc mon vote "pour" en 
confiance et en encouragement de ton implication :-D


Cyrille37.

Le 20/11/2020 à 13:08, François Lacombe a écrit :

Cyrille,

Parfois, les usages établis l'ont été à des époques où nous partions 
d'une feuille blanche.
S'interdire de les améliorer (donc de remplacer certaines choses 
parfois) parce qu'ils existent aurait pu être opposé à OSM lorsqu'il 
remplace d'autres choses.


En l'occurrence, pump=powered a beau être simple, il ne veut 
malheureusement rien dire et posera certainement des problèmes quand 
il s'agira de mettre osm en correspondance avec d'autres standards.
Si il s'agit d'indiquer que la pompe n'est pas activable à la main, on 
peut mettre handle=no


Je le redis, pump=* actuel ne parle pas de pompe, uniquement de puis 
et de moteurs éventuels. Pas des pompes.


François

Le ven. 20 nov. 2020 à 12:55, Cyrille37 OSM via Talk-fr 
mailto:talk-fr@openstreetmap.org>> a écrit :


François

Je rejoins assez "Jeisenbe" sur le fait de ne pas déprécier les
valeurs précédentes qui correspondent à un usage établi. Pourquoi
ne pas seulement enrichir l'existant ?

Pour ma part je trouve excellent les tags pump=manual et
pump=powered, c'est exactement de mon niveau. Ensuite s'ils
peuvent être enrichis par d'autres tags, yes, no problemo :-)

C/.

Le 20/11/2020 à 12:25, Cyrille37 OSM a écrit :


François

Ceux qui sont contre disent que c'est "pump=powered" qui
disparaît dans la proposition, ce qui enlève la permission de
tagger simplement.

Cyrille.

Le 20/11/2020 à 10:37, François Lacombe a écrit :

Bonjour Cyrille,

Merci pour ton commentaire.

Le ven. 20 nov. 2020 à 10:10, Cyrille37 OSM via Talk-fr
mailto:talk-fr@openstreetmap.org>> a
écrit :

Je suis sensible au contre argument :
/Any tagging scheme allowing to tag extreme detail
uninteresting to nearly all people *must allow also tagging
basic info without making mandatory to specify details*/

Cela tombe bien parce que je ne comprends pas cette phrase.
Il n'y a aucun tag obligatoire (sinon évidemment le man_made,
mais c'est une évidence), surtout pas le mechnical_driver.

Mais je n'ai pas analysé précisément la proposition pour
confirmer sa véracité, seulement lu les 3 oppositions qui je
trouve se rejoignent sur la nécessité de tagger simplement
un pompe.

C'était bien le but je vous rassure, visiblement on est tous
d'accord (mais certains se sentent quand même obligés de voter
contre)

Cette proposition permet-elle de continuer à tagger très
simplement une pompe avec un seul tag, sans autre
connaissance des détails ?

Oui, man_made=pump : c'est une pompe et suffit à lui-même, on
est pas obligé de faire plus.

Le point central de la proposition est de cesser d'utiliser
"pump" pour parler du moteur puisque c'est le cas aujourd'hui.
Une pompe est souvent animée par un moteur, on a donc deux
appareils pompe + moteur, il me semble logique qu'OSM ait deux
tags pour parler respectivement de la pompe et du moteur.

Bonne fin de semaine à vous tous

François

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


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

Re: [OSM-talk-fr] Proposition - Vote - Les pompes

[François Lacombe]

Cyrille,

Parfois, les usages établis l'ont été à des époques où nous partions d'une
feuille blanche.
S'interdire de les améliorer (donc de remplacer certaines choses parfois)
parce qu'ils existent aurait pu être opposé à OSM lorsqu'il remplace
d'autres choses.

En l'occurrence, pump=powered a beau être simple, il ne veut
malheureusement rien dire et posera certainement des problèmes quand il
s'agira de mettre osm en correspondance avec d'autres standards.
Si il s'agit d'indiquer que la pompe n'est pas activable à la main, on peut
mettre handle=no

Je le redis, pump=* actuel ne parle pas de pompe, uniquement de puis et de
moteurs éventuels. Pas des pompes.

François

Le ven. 20 nov. 2020 à 12:55, Cyrille37 OSM via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> François
>
> Je rejoins assez "Jeisenbe" sur le fait de ne pas déprécier les valeurs
> précédentes qui correspondent à un usage établi. Pourquoi ne pas seulement
> enrichir l'existant ?
>
> Pour ma part je trouve excellent les tags pump=manual et pump=powered,
> c'est exactement de mon niveau. Ensuite s'ils peuvent être enrichis par
> d'autres tags, yes, no problemo :-)
>
> C/.
> Le 20/11/2020 à 12:25, Cyrille37 OSM a écrit :
>
> François
>
> Ceux qui sont contre disent que c'est "pump=powered" qui disparaît dans la
> proposition, ce qui enlève la permission de tagger simplement.
>
> Cyrille.
> Le 20/11/2020 à 10:37, François Lacombe a écrit :
>
> Bonjour Cyrille,
>
> Merci pour ton commentaire.
>
> Le ven. 20 nov. 2020 à 10:10, Cyrille37 OSM via Talk-fr <
> talk-fr@openstreetmap.org> a écrit :
>
>> Je suis sensible au contre argument :
>> *Any tagging scheme allowing to tag extreme detail uninteresting to
>> nearly all people must allow also tagging basic info without making
>> mandatory to specify details*
>>
> Cela tombe bien parce que je ne comprends pas cette phrase.
> Il n'y a aucun tag obligatoire (sinon évidemment le man_made, mais c'est
> une évidence), surtout pas le mechnical_driver.
>
>> Mais je n'ai pas analysé précisément la proposition pour confirmer sa
>> véracité, seulement lu les 3 oppositions qui je trouve se rejoignent sur la
>> nécessité de tagger simplement un pompe.
>>
> C'était bien le but je vous rassure, visiblement on est tous d'accord
> (mais certains se sentent quand même obligés de voter contre)
>
>> Cette proposition permet-elle de continuer à tagger très simplement une
>> pompe avec un seul tag, sans autre connaissance des détails ?
>>
> Oui, man_made=pump : c'est une pompe et suffit à lui-même, on est pas
> obligé de faire plus.
>
> Le point central de la proposition est de cesser d'utiliser "pump" pour
> parler du moteur puisque c'est le cas aujourd'hui.
> Une pompe est souvent animée par un moteur, on a donc deux appareils pompe
> + moteur, il me semble logique qu'OSM ait deux tags pour parler
> respectivement de la pompe et du moteur.
>
> Bonne fin de semaine à vous tous
>
> François
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Proposition - Vote - Les pompes

[Cyrille37 OSM via Talk-fr]

Le 20/11/2020 à 12:42, François Lacombe a écrit :
* pump=powered, s'il est vu comme une manière simple de taguer, est 
trop vague : il y a une multitude de solutions pour motoriser une pompe.


C'est à mon avis justement ce qu'est OSM, ça richesse et son 
accessibilité : à partir de l'information "man_made=pump" permettre au 
"kidam" de signaler qu'il a vu des gens manœuvrer la pompe "pump=manual" 
ou appuyer sur un bouton "pump=powered". Les précisions supplémentaires 
doivent être dans de nouveau tags ou valeurs supplémentaires, 
spécifiques à des usages, mais pas annuler les valeurs simples 
accessibles au plus grand nombre.


Cyrille37.


Il est en plus toujours possible d'utiliser une valeur style 
mechanical_driver=powered en palliatif le temps que quelqu'un donne 
plus de détails si nécessaire.


On en parle sur les bornes à incendie, la question est la même pour 
les services d'urgence ici : si je sais que la pompe du puits est 
motorisée sans plus d'infos et que je ne viens qu'avec du gasoil, 
alors que c'est un moteur électrique, ca ne servira à pas grand chose.


Je constate aussi que ceux qui critiquent maintenant le remplacement 
de pump=powered affirment aussi ne pas savoir pourquoi ces tags ont 
été définis à la base, ça me gêne un peu.


Bon apétit

François

Le ven. 20 nov. 2020 à 12:28, Cyrille37 OSM via Talk-fr 
mailto:talk-fr@openstreetmap.org>> a écrit :


François

Ceux qui sont contre disent que c'est "pump=powered" qui disparaît
dans la proposition, ce qui enlève la permission de tagger simplement.

Cyrille.

Le 20/11/2020 à 10:37, François Lacombe a écrit :

Bonjour Cyrille,

Merci pour ton commentaire.

Le ven. 20 nov. 2020 à 10:10, Cyrille37 OSM via Talk-fr
mailto:talk-fr@openstreetmap.org>> a
écrit :

Je suis sensible au contre argument :
/Any tagging scheme allowing to tag extreme detail
uninteresting to nearly all people *must allow also tagging
basic info without making mandatory to specify details*/

Cela tombe bien parce que je ne comprends pas cette phrase.
Il n'y a aucun tag obligatoire (sinon évidemment le man_made,
mais c'est une évidence), surtout pas le mechnical_driver.

Mais je n'ai pas analysé précisément la proposition pour
confirmer sa véracité, seulement lu les 3 oppositions qui je
trouve se rejoignent sur la nécessité de tagger simplement un
pompe.

C'était bien le but je vous rassure, visiblement on est tous
d'accord (mais certains se sentent quand même obligés de voter
contre)

Cette proposition permet-elle de continuer à tagger très
simplement une pompe avec un seul tag, sans autre
connaissance des détails ?

Oui, man_made=pump : c'est une pompe et suffit à lui-même, on est
pas obligé de faire plus.

Le point central de la proposition est de cesser d'utiliser
"pump" pour parler du moteur puisque c'est le cas aujourd'hui.
Une pompe est souvent animée par un moteur, on a donc deux
appareils pompe + moteur, il me semble logique qu'OSM ait deux
tags pour parler respectivement de la pompe et du moteur.

Bonne fin de semaine à vous tous

François

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

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

Re: [OSM-talk-fr] Proposition - Vote - Les pompes

[Cyrille37 OSM via Talk-fr]

François

Je rejoins assez "Jeisenbe" sur le fait de ne pas déprécier les valeurs 
précédentes qui correspondent à un usage établi. Pourquoi ne pas 
seulement enrichir l'existant ?


Pour ma part je trouve excellent les tags pump=manual et pump=powered, 
c'est exactement de mon niveau. Ensuite s'ils peuvent être enrichis par 
d'autres tags, yes, no problemo :-)


C/.

Le 20/11/2020 à 12:25, Cyrille37 OSM a écrit :


François

Ceux qui sont contre disent que c'est "pump=powered" qui disparaît 
dans la proposition, ce qui enlève la permission de tagger simplement.


Cyrille.

Le 20/11/2020 à 10:37, François Lacombe a écrit :

Bonjour Cyrille,

Merci pour ton commentaire.

Le ven. 20 nov. 2020 à 10:10, Cyrille37 OSM via Talk-fr 
mailto:talk-fr@openstreetmap.org>> a écrit :


Je suis sensible au contre argument :
/Any tagging scheme allowing to tag extreme detail uninteresting
to nearly all people *must allow also tagging basic info without
making mandatory to specify details*/

Cela tombe bien parce que je ne comprends pas cette phrase.
Il n'y a aucun tag obligatoire (sinon évidemment le man_made, mais 
c'est une évidence), surtout pas le mechnical_driver.


Mais je n'ai pas analysé précisément la proposition pour
confirmer sa véracité, seulement lu les 3 oppositions qui je
trouve se rejoignent sur la nécessité de tagger simplement un pompe.

C'était bien le but je vous rassure, visiblement on est tous d'accord 
(mais certains se sentent quand même obligés de voter contre)


Cette proposition permet-elle de continuer à tagger très
simplement une pompe avec un seul tag, sans autre connaissance
des détails ?

Oui, man_made=pump : c'est une pompe et suffit à lui-même, on est pas 
obligé de faire plus.


Le point central de la proposition est de cesser d'utiliser "pump" 
pour parler du moteur puisque c'est le cas aujourd'hui.
Une pompe est souvent animée par un moteur, on a donc deux appareils 
pompe + moteur, il me semble logique qu'OSM ait deux tags pour parler 
respectivement de la pompe et du moteur.


Bonne fin de semaine à vous tous

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

Re: [OSM-talk-fr] Proposition - Vote - Les pompes

[François Lacombe]

Cyrille,

Oui c'est ce à quoi j'étais en train de répondre.

Il y a plusieurs problèmes auxquels je souhaite apporter une solution
durable :
* pump=* est actuellement réservé aux puits et traite des moteurs au lieu
de parler des pompes elles-même.
* pump=powered, s'il est vu comme une manière simple de taguer, est trop
vague : il y a une multitude de solutions pour motoriser une pompe.
Il est en plus toujours possible d'utiliser une valeur style
mechanical_driver=powered en palliatif le temps que quelqu'un donne plus de
détails si nécessaire.

On en parle sur les bornes à incendie, la question est la même pour les
services d'urgence ici : si je sais que la pompe du puits est motorisée
sans plus d'infos et que je ne viens qu'avec du gasoil, alors que c'est un
moteur électrique, ca ne servira à pas grand chose.

Je constate aussi que ceux qui critiquent maintenant le remplacement de
pump=powered affirment aussi ne pas savoir pourquoi ces tags ont été
définis à la base, ça me gêne un peu.

Bon apétit

François

Le ven. 20 nov. 2020 à 12:28, Cyrille37 OSM via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> François
>
> Ceux qui sont contre disent que c'est "pump=powered" qui disparaît dans la
> proposition, ce qui enlève la permission de tagger simplement.
>
> Cyrille.
> Le 20/11/2020 à 10:37, François Lacombe a écrit :
>
> Bonjour Cyrille,
>
> Merci pour ton commentaire.
>
> Le ven. 20 nov. 2020 à 10:10, Cyrille37 OSM via Talk-fr <
> talk-fr@openstreetmap.org> a écrit :
>
>> Je suis sensible au contre argument :
>> *Any tagging scheme allowing to tag extreme detail uninteresting to
>> nearly all people must allow also tagging basic info without making
>> mandatory to specify details*
>>
> Cela tombe bien parce que je ne comprends pas cette phrase.
> Il n'y a aucun tag obligatoire (sinon évidemment le man_made, mais c'est
> une évidence), surtout pas le mechnical_driver.
>
>> Mais je n'ai pas analysé précisément la proposition pour confirmer sa
>> véracité, seulement lu les 3 oppositions qui je trouve se rejoignent sur la
>> nécessité de tagger simplement un pompe.
>>
> C'était bien le but je vous rassure, visiblement on est tous d'accord
> (mais certains se sentent quand même obligés de voter contre)
>
>> Cette proposition permet-elle de continuer à tagger très simplement une
>> pompe avec un seul tag, sans autre connaissance des détails ?
>>
> Oui, man_made=pump : c'est une pompe et suffit à lui-même, on est pas
> obligé de faire plus.
>
> Le point central de la proposition est de cesser d'utiliser "pump" pour
> parler du moteur puisque c'est le cas aujourd'hui.
> Une pompe est souvent animée par un moteur, on a donc deux appareils pompe
> + moteur, il me semble logique qu'OSM ait deux tags pour parler
> respectivement de la pompe et du moteur.
>
> Bonne fin de semaine à vous tous
>
> François
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Proposition - Vote - Les pompes

[Cyrille37 OSM via Talk-fr]

François

Ceux qui sont contre disent que c'est "pump=powered" qui disparaît dans 
la proposition, ce qui enlève la permission de tagger simplement.


Cyrille.

Le 20/11/2020 à 10:37, François Lacombe a écrit :

Bonjour Cyrille,

Merci pour ton commentaire.

Le ven. 20 nov. 2020 à 10:10, Cyrille37 OSM via Talk-fr 
mailto:talk-fr@openstreetmap.org>> a écrit :


Je suis sensible au contre argument :
/Any tagging scheme allowing to tag extreme detail uninteresting
to nearly all people *must allow also tagging basic info without
making mandatory to specify details*/

Cela tombe bien parce que je ne comprends pas cette phrase.
Il n'y a aucun tag obligatoire (sinon évidemment le man_made, mais 
c'est une évidence), surtout pas le mechnical_driver.


Mais je n'ai pas analysé précisément la proposition pour confirmer
sa véracité, seulement lu les 3 oppositions qui je trouve se
rejoignent sur la nécessité de tagger simplement un pompe.

C'était bien le but je vous rassure, visiblement on est tous d'accord 
(mais certains se sentent quand même obligés de voter contre)


Cette proposition permet-elle de continuer à tagger très
simplement une pompe avec un seul tag, sans autre connaissance des
détails ?

Oui, man_made=pump : c'est une pompe et suffit à lui-même, on est pas 
obligé de faire plus.


Le point central de la proposition est de cesser d'utiliser "pump" 
pour parler du moteur puisque c'est le cas aujourd'hui.
Une pompe est souvent animée par un moteur, on a donc deux appareils 
pompe + moteur, il me semble logique qu'OSM ait deux tags pour parler 
respectivement de la pompe et du moteur.


Bonne fin de semaine à vous tous

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

[OSM-talk-fr] Get-Together CartONG en ligne : formations gratuites, bilan 2020, rencontres et plus!

[Kelly Green]

 
 
  
   
Bonjour à tou.te.s !  

   
   

   
   
Vous êtes invité.e.s à rejoindre le staff et les bénévoles de CartONG du lundi 23 novembre au samedi 28 novembre lors d'un Get-Together en ligne ! C’est l’occasion de participer à des formations gratuites, de découvrir des projets de cartographie et autres, de partager vos expériences, ou de discuter de futurs horizons ! 
   
   
Comment faire pour y participer ? Nous vous invitons à piocher dans les sessions qui vous intéressent. Le programme complet est accessible en ligne sur ce lien. Pas besoin de vous inscrire, c'est gratuit et il suffit de vous connecter sur le lien Skype ou Zoom de la session à l’heure indiquée ! 
   
   
  
Aperçu du programme. Les descriptions des sessions et les liens pour s’y connecter sont accessibles sur ce lien 
   
   
https://mensuel.framapad.org/p/programme-g2g-9k2h 

Un rendez-vous à ne pas manquer le samedi

 Samedi 28 novembre - 14h30-17h30 /  CartONG à l'horizon 2023 : reprenons le cheminement ! FR 
Mais aussi des sessions réparties du lundi au vendredi !

 Lundi 23 novembre - 12h30-13h30 /  À la découverte … des styles & templates CartONG sur QGIS - FR 
 Mardi 24 novembre - 18h30-20h00 / ️ Missing Maps  : Bilan 2020 et perspectives pour demain - FR 
 Mercredi 25 novembre - 12h30-13h30 /  GeOnG 2020 : Partage d'expérience - FR + ENG 
 Mercredi 25 novembre - 19h00-20h00 /  Initiation à JOSM - FR 
 Jeudi 26 novembre - 12h30-13h30 /  Le Webmapping, une réponse aux attentes cartographiques des petites structures de solidarité - FR 
 Jeudi 26 novembre - 18h30-19h30 / ️ Des cartes contre la peine de mort - FR 
 Vendredi 27 novembre - 12h30-13h30 /  Un nouvel envol pour le projet Cartes d'ici & d'ailleurs - FR 
 -
   
   

   
   
L'équipe de CartONG (contact : i...@cartong.org)
   
  
 


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

Re: [OSM-talk-fr] Proposition - Vote - Les pompes

[François Lacombe]

Bonjour Cyrille,

Merci pour ton commentaire.

Le ven. 20 nov. 2020 à 10:10, Cyrille37 OSM via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Je suis sensible au contre argument :
> *Any tagging scheme allowing to tag extreme detail uninteresting to
> nearly all people must allow also tagging basic info without making
> mandatory to specify details*
>
Cela tombe bien parce que je ne comprends pas cette phrase.
Il n'y a aucun tag obligatoire (sinon évidemment le man_made, mais c'est
une évidence), surtout pas le mechnical_driver.

> Mais je n'ai pas analysé précisément la proposition pour confirmer sa
> véracité, seulement lu les 3 oppositions qui je trouve se rejoignent sur la
> nécessité de tagger simplement un pompe.
>
C'était bien le but je vous rassure, visiblement on est tous d'accord (mais
certains se sentent quand même obligés de voter contre)

> Cette proposition permet-elle de continuer à tagger très simplement une
> pompe avec un seul tag, sans autre connaissance des détails ?
>
Oui, man_made=pump : c'est une pompe et suffit à lui-même, on est pas
obligé de faire plus.

Le point central de la proposition est de cesser d'utiliser "pump" pour
parler du moteur puisque c'est le cas aujourd'hui.
Une pompe est souvent animée par un moteur, on a donc deux appareils pompe
+ moteur, il me semble logique qu'OSM ait deux tags pour parler
respectivement de la pompe et du moteur.

Bonne fin de semaine à vous tous

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

Re: [OSM-talk-fr] Proposition - Vote - Les pompes

[Cyrille37 OSM via Talk-fr]

Bonjour

Le 19/11/2020 à 20:19, François Lacombe a écrit :
Suite aux annonces faites plus tôt cette année, le vote sur la 
proposition traitant des pompes est finalement ouvert

https://wiki.openstreetmap.org/wiki/Proposed_features/Pumping_proposal


Je suis sensible au contre argument :
/Any tagging scheme allowing to tag extreme detail uninteresting to 
nearly all people *must allow also tagging basic info without making 
mandatory to specify details*/


Mais je n'ai pas analysé précisément la proposition pour confirmer sa 
véracité, seulement lu les 3 oppositions qui je trouve se rejoignent sur 
la nécessité de tagger simplement un pompe.


Cette proposition permet-elle de continuer à tagger très simplement une 
pompe avec un seul tag, sans autre connaissance des détails ?


Merci
Cyrille37.

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

Re: [Talk-it] [Proposal] [RFC] import of new cycle paths of Città Metropolitana di Bologna

[Matteo Fortini]

Grazie Alessandro, ti rispondo sotto.

In generale comprendo le tue perplessità. Dall'altro lato, abbiamo più 
di 900km di ciclabili "vere", realizzate su sede separata dalla sede 
stradale, che ha molto senso vengano inserite in OSM.

Le alternative penso siano:

 * lasciare che ogni singolo o gruppo locale si metta a importare i
   tratti che vede nascere, a mano, senza il supporto di foto
   satellitari, perché la costruzione è troppo recente
 * utilizzare il dataset di Città Metropolitana come base per integrare
   le ciclabili, tutte insieme, o guidate dai gruppi locali


Il 19/11/20 04:48, Alessandro Sarretta ha scritto:


Ciao Matteo,

come pensavi di utilizzare/integrare in OSM le informazioni di questi 
2 shapefile?


Guardando rapidamente ai dati, mi sembra che le geometrie dei file 
condivisi siano molto semplificate e che non potranno comunque in 
nessun caso essere importate tout-court in OSM.




Sì, non ho mai sperato tanto. Penso che importare correttamente qualcosa 
che proviene da altri SIT in OSM sia già un'impresa per dei punti (vedi 
i civici dell'Emilia-Romagna), le strade hanno tante implicazioni anche 
su altri progetti, come per esempio il routing, che penso possano essere 
importate soltanto a mano, a meno che chi le ha progettate non l'abbia 
fatto su OSM (cosa oggi inconcepibile).



Per quanto riguarda il layer itinerari_cicloturistici, mi pare che 
sarà da assegnare (se non già fatto) una relazione con il nome degli 
intinerari ai tratti che li compongono. Se mancano dei pezzi, 
bisognerà disegnarli a mano immagino.


Ancora meno informazioni contiene il secondo shapefile, della rete 
strategica e integrativa. In questo caso, inoltre, credo debbano 
essere considerati solo i tratti segnalati come esistenti, non quelli 
in corso di realizzazione o tantomeno da finanziare, giusto?


Il limite principale mi pare che sia l'assenza di qualsiasi tipo di 
informazione sul tipo di percorso ciclabile, se pista o corsia ciclabile.




Le ciclabili in realtà sono quasi tutte realizzate, posso verificare con 
Città Metropolitana, mi hanno fornito un documento che probabilmente è 
ancora da aggiornare sullo stato d'avanzamento.



On 18/11/20 22:43, Matteo Fortini wrote:
Ho cominciato a riempire una pagina wiki come richiesto dalle linee 
guida. C'è qualcuno/a che vuole dare una mano?


https://wiki.openstreetmap.org/wiki/Import_of_Citt%C3%A0_Metropolitana_di_Bologna%27s_cycling_paths 



Riguardo alla pagina di import, a parte una descrizione del contenuto 
dei file da importare, non sono sicuro di come sia più utile 
descrivere il lavoro da fare, viste le limitazioni descritte sopra.


Forse avere gli shapefile su una uMap può essere la base per un check 
specifico da OSMer della zona?




Sì l'idea è molto buona, appena posso la carico.



Ale




Grazie,
Matteo

Il 08/10/20 18:04, Matteo Fortini ha scritto:
The Città Metropolitana di Bologna in Italy (local authority for the 
Bologna province) has recently built around 100kms of cycle paths.


I asked them if they could provide a dataset to import in OSM.

They provided me the shapefiles for the paths, which are not 
perfectly matching, but are very close.


They waived the license for Openstreetmap as per the attached 
license file, with the same method the Municipality of Bologna used 
to allow the use of their aerial pictures to OSM users (here 
http://dati.comune.bologna.it/node/3446 ).


I ask for your opinion and comments, and at the same time if anyone 
would like to collaborate in the import process.


Thank you
Matteo Fortini



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

--
--

Alessandro Sarretta

skype/twitter: alesarrett
Web: ilsarrett.wordpress.com 

Research information:

  * Google scholar profile

  * ORCID 
  * Research Gate

  * Impactstory 


___
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: [Talk-it] [Proposal] [RFC] import of new cycle paths of Città Metropolitana di Bologna

[Matteo Fortini]

Grazie Volker,
si tratta di ciclabili vere e proprie costruite appositamente e separate 
dalla sede stradale.




Il 18/11/20 23:42, Volker Schmidt ha scritto:

Ciao,

sono interessato in questo lavoro, ma sono sono di Padova. Ho inserito 
parecchi percorsi ciclabili a Padova. E il mio interesse è come viene 
fatto altrove.

Prima domanda:
Parliam do infrastruttrura ciclistica (piste e corsie ciclabili) o di 
percorsi (itinerari) cicloturistici, come dai titoli dei dataset nel 
sito citato (vedi 
https://wikimediaitalia.nws.netways.de/index.php/s/MmH2x6zD9GRdyGL?path=%2Fciclabili 
).

A me interessano entrambe le categorie.
Inoltre mi interessano anche attraversamenti, barriere (archetti, 
paletti ecc) e segnavia (per i percorsi cicloturistici).
Estrapolando dal mio approccio a Padova, consiglio di fare 
sistematicamente foto Mapillary di questi percorsi (cioè in bici sui 
percorsi ciclabili)


Volker

 
	Virus-free. www.avast.com 
 




On Wed, 18 Nov 2020 at 22:44, Matteo Fortini > wrote:


Ho cominciato a riempire una pagina wiki come richiesto dalle linee
guida. C'è qualcuno/a che vuole dare una mano?


https://wiki.openstreetmap.org/wiki/Import_of_Citt%C3%A0_Metropolitana_di_Bologna%27s_cycling_paths



Grazie,
Matteo

Il 08/10/20 18:04, Matteo Fortini ha scritto:
> The Città Metropolitana di Bologna in Italy (local authority for
the
> Bologna province) has recently built around 100kms of cycle paths.
>
> I asked them if they could provide a dataset to import in OSM.
>
> They provided me the shapefiles for the paths, which are not
perfectly
> matching, but are very close.
>
> They waived the license for Openstreetmap as per the attached
license
> file, with the same method the Municipality of Bologna used to
allow
> the use of their aerial pictures to OSM users (here
> http://dati.comune.bologna.it/node/3446
 ).
>
> I ask for your opinion and comments, and at the same time if anyone
> would like to collaborate in the import process.
>
> Thank you
> Matteo Fortini


___
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


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