Re: [Talk-it] Reggio nell'Emilia o Reggio Emilia

[Andrea Musuruane]

Ciao,
mi sembra che la soluzione sia semplice. In name si mette il nome
comunemente usato (Reggio Emilia), che è anche quello scritto sui cartelli
stradali, e in official_name si mette "Reggio nell'Emilia". Idem per Reggio
Calabria.

Ciao,

Andrea


On Tue, Nov 17, 2020 at 7:34 AM Lorenzo Beltrami 
wrote:

> Ma sul nome ufficiale del comune non ci sono dubbi: è "Reggio nell'Emilia"
> (avevo messo il link allo statuto già nella prima mail).
> Come non ci sono dubbi sul nome ufficiale della provincia, che è "Reggio
> Emilia" senza preposizione articolata.
>
> Il mio dubbio era su cosa mettere nel tag name del place=city.
> Sui cartelli di inizio centro abitato c'è scritto "Reggio nell'Emilia",
> che è anche il nome ufficiale, ma nel linguaggio di tutti i giorni si dice
> quasi sempre "Reggio Emilia".
>
> Trovo interessante riportare, a prescindere dalla scelta che si farà, il
> nome ufficiale in official_name.
> Non ci avevo pensato perché lo trovavo ridondante...
>
> Ciao
> Lorenzo
>
>
> Il lun 16 nov 2020, 22:27 Martin Koppenhoefer  ha
> scritto:
>
>> io non ho particolari preferenze per il tag name, sicuramente si vogliono
>> al meno un tag official_name e name, e a secondo la scelta forse anche un
>> tag alt_name (se official_name=name)
>> La Provincia si chiama „Provincia di Reggio Emilia„
>> https://www.provincia.re.it/wp-content/uploads/2020/02/Statuto-2019.pdf
>>
>> Per il comune bisogna trovare un documento simile per essere sicuri sul
>> official name
>>
>> 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
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Reggio nell'Emilia o Reggio Emilia

[Lorenzo Beltrami]

Ma sul nome ufficiale del comune non ci sono dubbi: è "Reggio nell'Emilia"
(avevo messo il link allo statuto già nella prima mail).
Come non ci sono dubbi sul nome ufficiale della provincia, che è "Reggio
Emilia" senza preposizione articolata.

Il mio dubbio era su cosa mettere nel tag name del place=city.
Sui cartelli di inizio centro abitato c'è scritto "Reggio nell'Emilia", che
è anche il nome ufficiale, ma nel linguaggio di tutti i giorni si dice
quasi sempre "Reggio Emilia".

Trovo interessante riportare, a prescindere dalla scelta che si farà, il
nome ufficiale in official_name.
Non ci avevo pensato perché lo trovavo ridondante...

Ciao
Lorenzo


Il lun 16 nov 2020, 22:27 Martin Koppenhoefer  ha
scritto:

> io non ho particolari preferenze per il tag name, sicuramente si vogliono
> al meno un tag official_name e name, e a secondo la scelta forse anche un
> tag alt_name (se official_name=name)
> La Provincia si chiama „Provincia di Reggio Emilia„
> https://www.provincia.re.it/wp-content/uploads/2020/02/Statuto-2019.pdf
>
> Per il comune bisogna trovare un documento simile per essere sicuri sul
> official name
>
> 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: [Talk-in] Mapping Water ATM's

[Chetan H A]

Thanks for the answers Mateusz Konieczny.

amenity=vending_machine
vending=water

I agree with the above tags for water atm's.



On Tue, Nov 17, 2020 at 2:18 AM Mateusz Konieczny via Talk-in <
talk-in@openstreetmap.org> wrote:

>
> amenity=vending_machine
> vending=water
>
> is a potential alternative tagging
> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dvending_machine
>
>
> amenity=water_point seems for larger scale
> "Water ATM located at Jayanagar dispenses around 6000 litres daily"
> and article has people with just some large bottles while
> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dwater_point
> describes it as
> "you can get larger amounts of "drinking water" for filling a fresh water
> holding tank, such as found on caravans, RVs and boats."
>
>
> Nov 16, 2020, 15:04 by chetanh...@gmail.com:
>
> Hello all,
>
> In Bengaluru we have public Water ATM's (Water vending machines) across
> the city since 2015. These are not mapped in OSM and are widely used by
> people for drinking purposes. I have tagged one such in RPC layout
> , Vijayanagar.  For
> more information please read this article
> 
> .
>
> OSM tag used:
>
>- amenity=water_point
>
> There are few *amenity=drinking_water *
> in OSM but it would be good if we map all water_points across the city.
>
> Let me know any suggestions on mapping these in the city. Also, I am not
> sure of Water ATM's in the other cities as well.
>
> Regards,
> Chetan
> OSM:Chetan_Gowda
>
>
> ___
> Talk-in mailing list
> Talk-in@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-in
>
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

Re: [Talk-it] Reggio nell'Emilia o Reggio Emilia

[Lorenzo Mastrogiacomi]

Il giorno lun, 16/11/2020 alle 23.57 +0100, Martin Koppenhoefer ha
scritto:
> 
> 
> sent from a phone
> 
> > On 16. Nov 2020, at 23:51, Lorenzo Mastrogiacomi
> >  wrote:
> > 
> > C'è online anche lo statuto del comune di Reggio Emilia e in questo
> > non c'è mai scritto il nome Reggio nell'Emilia
> 
> 
> non ci potevo credere, e infatti c’è scritto nell’articolo 1, come
> spesso (sempre?):
> https://www.comune.re.it/retecivica/urp/regolamenti.nsf/2f35cb03f6fe801ac125778200380a42/7647bf8c7a086544c125688200568fdf/$FILE/Statuto%202018.pdf
> 
> Ciao Martin 
> 

Ah, mi è sfuggito l'articolo 1 :)


Lorenzo

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

Re: [OSM-talk-fr] [OSM-Talk-fr] Nouveaux tags "Ça reste ouvert"

[Pierre-Olivier GREGOIRE]

Selon moi réservation et commande sont deux choses bien distinctes (en
anglais comme en français) :
* on réserve une chambre ou une table : elle ne sera pas affectée à une
autre personne (d'après le larousse : "Action de retenir une place (dans un
train, un avion, au théâtre, etc.), une table (au restaurant), une chambre
(dans un hôtel)."
* on commande avec paiement un bien (d'après larousse "Action de commander
une marchandise, un travail, une œuvre, un repas ; la chose commandée ")

Je trouve personnellement qu'avoir un tag pour ce service (la commande et
retrait en magasin) assez simple.
.

Le lun. 16 nov. 2020 à 23:10,  a écrit :

> Le 16/11/2020 à 22:52, Pierre-Olivier GREGOIRE - po.grego...@gmail.com a
> écrit :
>
> > cette chaine de brasseries très connue sur Lyon propose bien
> > distinctement "vente à emporter" (possibilité d'emporter sa
> > consommation) de "click & collect" (possibilité de commander à
> > distance et de récupérer sa commande une fois qu'elle est prête). Et
> > ce n'est pas un cas isolé.
>
> Oui takeaway=only (à emporter)
>
> et
>
> takeaway=only
>
> reservation=only (à commander puis à retirer)
>
> sont deux choses distinctes.
>
> La page reservation n'est pas réservée ;-) à la réservation d'un créneau
> horaire.
>
> Si tu peux aller au resto et que tu dois réserver tu auras
>
> reservation=only
>
>  > Par contre on peut préciser si il peut être acheté sur place ou si un
> service de "commande puis retrait en magasin" est proposé ou un service
> de livraison.
>
> Là encore : reversation=only, required... ou pas.
>
> takeaway n'est effectivement pas indispensable ici.
>
> KISS
>
> Si on veut faire la combinatoire réservation y compris le mode
> (téléphone, internet, courrier), le mode de retrait (en magasin, à
> l'extérieur) ou de livraison et mettre un tag spécifique à chaque fois
> ça va être compliqué...
>
>
>
> ___
> 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-it] Reggio nell'Emilia o Reggio Emilia

[Martin Koppenhoefer]

sent from a phone

> On 16. Nov 2020, at 23:51, Lorenzo Mastrogiacomi  wrote:
> 
> C'è online anche lo statuto del comune di Reggio Emilia e in questo non c'è 
> mai scritto il nome Reggio nell'Emilia


non ci potevo credere, e infatti c’è scritto nell’articolo 1, come spesso 
(sempre?):
https://www.comune.re.it/retecivica/urp/regolamenti.nsf/2f35cb03f6fe801ac125778200380a42/7647bf8c7a086544c125688200568fdf/$FILE/Statuto%202018.pdf

Ciao Martin 

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

Re: [Talk-it] living street in Italia nel wiki

[Lorenzo Mastrogiacomi]

Il giorno mar, 10/11/2020 alle 00.12 +0100, Martin Koppenhoefer ha
scritto:
> 
> 
> sent from a phone
> 
> > On 7. Nov 2020, at 20:05, Martin Koppenhoefer
> >  wrote:
> > 
> > concordo, ho scritto all'utente invitandolo per parlarne qui o nel
> > wiki.
> 
> 
> trascorsi 3 giorni possiamo interrompere l‘attesa e continuare per
> ora senza di lei la discussione. 
> 
> Per me ha senso fare riferimento al segnale italiano di zona
> residenziale, però aggiungerei che il cartello non implica
> automaticamente living street in OpenStreetMap, soltanto qualora ci
> fossero altre restrizioni indicate.
> 
> Ciao Martin 


Concordo.

Ciao
Lorenzo


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

Re: [Talk-it] Reggio nell'Emilia o Reggio Emilia

[Lorenzo Mastrogiacomi]

Il giorno lun, 16/11/2020 alle 22.26 +0100, Martin Koppenhoefer ha
scritto:
> io non ho particolari preferenze per il tag name, sicuramente si
> vogliono al meno un tag official_name e name, e a secondo la scelta
> forse anche un tag alt_name (se official_name=name)
> La Provincia si chiama „Provincia di Reggio Emilia„
>  https://www.provincia.re.it/wp-content/uploads/2020/02/Statuto-2019.pdf
> 
> Per il comune bisogna trovare un documento simile per essere sicuri
> sul official name
> 
> Ciao Martin 
> 

C'è online anche lo statuto del comune di Reggio Emilia e in questo non
c'è mai scritto il nome Reggio nell'Emilia ma non significa che la
città non si chiami così.
L'ultimo atto del comune credo sia quello del 28/05/2018. È una mozione
per rinominare la città in Reggio Emilia, ma è stata respinta.

Lorenzo

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

Re: [OSM-talk-fr] [OSM-Talk-fr] Nouveaux tags "Ça reste ouvert"

[osm . sanspourriel]

Le 16/11/2020 à 22:52, Pierre-Olivier GREGOIRE - po.grego...@gmail.com a
écrit :


cette chaine de brasseries très connue sur Lyon propose bien
distinctement "vente à emporter" (possibilité d'emporter sa
consommation) de "click & collect" (possibilité de commander à
distance et de récupérer sa commande une fois qu'elle est prête). Et
ce n'est pas un cas isolé.


Oui takeaway=only (à emporter)

et

takeaway=only

reservation=only (à commander puis à retirer)

sont deux choses distinctes.

La page reservation n'est pas réservée ;-) à la réservation d'un créneau
horaire.

Si tu peux aller au resto et que tu dois réserver tu auras

reservation=only

> Par contre on peut préciser si il peut être acheté sur place ou si un
service de "commande puis retrait en magasin" est proposé ou un service
de livraison.

Là encore : reversation=only, required... ou pas.

takeaway n'est effectivement pas indispensable ici.

KISS

Si on veut faire la combinatoire réservation y compris le mode
(téléphone, internet, courrier), le mode de retrait (en magasin, à
l'extérieur) ou de livraison et mettre un tag spécifique à chaque fois
ça va être compliqué...



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

[Talk-us] OSM GeoWeek Career Panels this Wed Nov 18

[Thomas Gertin]

The U.S. Department of State’s MapGive initiative, USAID’s GeoCenter, and
the American Red Cross invite you to participate in a series of career
panels on *Wednesday Nov 18* as part of Geography Awareness Week and
OpenStreetMap Geography Awareness Week (OSMGeoWeek). During this week,
teachers, students, community groups, and map lovers around the world join
to celebrate geography and make maps with OpenStreetMap (OSM), the free and
openly editable map of the world.



As a global coalition of partners, we invite students and young
professionals to participate in a series of virtual career panels. The
career panels will focus on how professionals use OSM in their work. Our
first English panel will feature professionals from the U.S. Government and
NGOs, while the second English panel will feature those from the private
sector. We encourage you to share this invite broadly across your networks.



Each panel will be 1 hour in length with an additional 15 minutes allotted
to Q & As. We will use a single Zoom link for both English panels.



Please make sure to *RSVP* as we’ll be sending a Zoom link using this
Eventbrite registration: bit.ly/GeoWeekCareer



*Tomorrow is the final day to RSVP!*



The following two English panels are being scheduled:



*Government & NGO Career Panel* begins at 1:00pm EST and will include the
U.S Department of State’s Office of the Geographer, USAID, Humanitarian
OpenStreetMap Team, The World Bank, and The President’s Emergency Plan for
AIDS Relief (PEPFAR).



*Private Company Career Panel* begins at 2:30pm EST and will include Maxar,
MapBox, Development Seed, ESRI, Microsoft, Critigen, IncaTech and Azavea!



In addition there will be a French panel:



*The Francophone Career Panel* begins at 12:00pm EST (separate EventBrite
link): Panel sur les Carrières pendant la Semaine de Sensibilisation à la
Géograph




We encourage you to let other interested parties know of these events, and
feel free to reach out via email to osmgeow...@gmail.com if you have any
questions.



We look forward to seeing you there!


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

Re: [OSM-talk-fr] [OSM-Talk-fr] Nouveaux tags "Ça reste ouvert"

[Pierre-Olivier GREGOIRE]

Bonjour

Le lun. 16 nov. 2020 à 21:10,  a écrit :

> On a déjà les moyens de payement, pas la peine d'en inventer (sauf à
> suffixer par covid19).
>
> https://wiki.openstreetmap.org/wiki/FR:Key:payment#Argent_liquide
>
> Ça donnerait :
>
> payment:cash:covid19=no
>
> Par contre un commerçant en dessous d'une certaine somme doit accepter
> le liquide (car contre il peut imposer un payement à la réservation ce
> qui revient à peu près au même).
>
> Et par rapport au message de Vincent : KISS, en français c'est réserver
> et emporter donc :
>
> reservation=only
>

reservation ( https://wiki.openstreetmap.org/wiki/FR:Key:reservation )
indique une réservation d'un créneau plutôt qu'un bien. Ainsi pour un
restaurant, il s'agit de réserver une table avant de venir dîner, pas de
réserver de la nourriture avant de partir avec.
Je me permets une digression au passage : On commence à entendre parler
dans les médias d'une piste pour les magasins de ville : réserver des
créneaux horaires avant de venir. J'utiliserais plutôt
reservation:covid19=required pour un cas de ce type.


le service de "commande à distance puis retrait en magasin" me semble
suffisamment spécifique pour qu'on lui assigne un tag spécifique.

Pour un restaurant, Je le distingue de la possibilité de "plat à emporter"
(qui est plutôt commandé sur place). Exemple :
https://www.ninkasi.fr/infos-covid-19-ninkasi/ : cette chaine de brasseries
très connue sur Lyon propose bien distinctement "vente à emporter"
(possibilité d'emporter sa consommation) de "click & collect" (possibilité
de commander à distance et de récupérer sa commande une fois qu'elle est
prête). Et ce n'est pas un cas isolé.
Au passage ce n'est pas une raison mais pour info la "concurrence" fait
aussi cette distinction.

Pour un magasin de biens, le fait qu'on puisse "emporter" (takeaway) le
bien qu'on vient d'acheter (un livre, une table...) n'a pas besoin d'être
précisé puisque c'est tout le but du magasin. Par contre on peut préciser
si il peut être acheté sur place ou si un service de "commande puis retrait
en magasin" est proposé ou un service de livraison.



>
> takeaway=only
>
> (avec les suffixes covid19 si c'est du temporaire).
>
>
> Le 16/11/2020 à 20:27, Philippe Verdy - ver...@gmail.com a écrit :
> > le paiement sur place en espèces impossible.
> >
>
>
> ___
> 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] Suppression de l'attribut source

[osm . sanspourriel]

Le 16/11/2020 à 12:18, Marc_marc - marc_m...@mailo.com a écrit :


3) JOSM/Vespucci/StreetComple poussent fortement l'ajout
d'un tag source sur le changeset. iD le permet aussi.
tous les éditeurs proposent facilement d'ajouter des sources
ainsi que l'imagerie sat utilisée pour l'alignement.
en tout état de cause, la présence de meta-donnée (les tags de
changeset) sont renseigné par le contributeur de cette modif là
et concernerait cette modif, donc fiable (quand elle existe)
pour connaître la source de ces modifs.


Ceci est partiellement vrai : ils utilisent en général les couches
sélectionnées lors de l'expédition des modifications.

Ce n'est pas parce que tu affiches l'ortho de l'IGN que tu n'as pas
utilisé le cadastre avant.

De même si tu fusionnes deux bouts de bâtiments issus du cadastre,
quelle est la source ?

Cadastre (disons 4 points inchangés, l'ensemble du bâti globalement est
inchangé) ou survey (tu sais qu'il n'y a qu'un bâtiment : les 2 points
supprimés) ou ortho (tu as vérifié sur l'ortho qu'il n'y a qu'un bâtiment).

Donc même avec des outils pas mal faits, dans certains cas je ne sais
trop quelle est la source !

Avoir des outils style DeepHistory intégrés aux éditeurs, ça permettrait
d'y voir plus clair.

N. B. : certaines sources ne portent évidemment que sur certaines
parties objets, ainsi le cadastre ne joue que sur la géométrie, quelques
fois sur le nom ou la plaque de rue.

Et oui, source sur l'objet, sur une partie de l'objet, sur la changeset
ça n'aura de validité que si chacun s'y astreint.

Les sources ajoutées automatiquement sans contrôle explicite de
l'utilisateur ça peut induire le suivant en erreur.

Ce n'est pas pour autant qu'il ne faut pas essayer de le faire proprement.

Jean-Yvon



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

Re: [Talk-it] Reggio nell'Emilia o Reggio Emilia

[Martin Koppenhoefer]

io non ho particolari preferenze per il tag name, sicuramente si vogliono al 
meno un tag official_name e name, e a secondo la scelta forse anche un tag 
alt_name (se official_name=name)
La Provincia si chiama „Provincia di Reggio Emilia„  
https://www.provincia.re.it/wp-content/uploads/2020/02/Statuto-2019.pdf

Per il comune bisogna trovare un documento simile per essere sicuri sul 
official name

Ciao Martin 



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

Re: [talk-au] Naming Ramps in Australia

[cleary]

I agree with Andrew Harvey's comments.  Thanks to Aleksandar for raising this 
issue which has also vexed me.



On Tue, 17 Nov 2020, at 7:52 AM, Andrew Harvey wrote:
> 
> 
> On Tue, 17 Nov 2020 at 00:04, Aleksandar Matejevic (E-Search) via 
> Talk-au  wrote:
> > Hi all, 
> > I have noticed that the majority of ramps in Australia tend to have 
> > descriptive names and that naming format/system is not unique. Also, it is 
> > 50-50 between named and unnamed ramps.  
> > 
> > I have researched ramps across all Australia, looked at Mapillary, OSC, 
> > government data, OSM history. On street level imagery I could not find any 
> > named ramp. In some cases there was an exit number, and it was tagged as 
> > junction:ref because it is not a name of the exit, but all I could find 
> > were just destination signs.  However, on OSM, ramps had names which in 
> > some cases contained information for destinations (John Willcock Link 
> > (Eastbound) to Brand Highway) or their function (Pacific Highway 
> > On/Offramp). Government data was descriptive in some cases, there was no 
> > name in others so no consistency there also. 
> > 
> > I think that ramps do not have names and therefore should not contain a 
> > name key in OSM (only if there is a specific name for it, then it should 
> > have a name key). Exit numbers should be added as junction:ref and 
> > signposts data should be added either as destination relation or 
> > destination key on the way so routing algorithms could pick that info and 
> > give instructions like: "Take the exit toward X,Y,Z". If there is a name, 
> > instructions will be like: "Take left to X,Y,Z onramp/offramp”. 
> > 
> > I am raising this question in hope to get some kind of consensus how to 
> > treat these cases across Australia, so all the ramps have the same format 
> > (conclusion could be added to Australian Tagging Guidelines on wiki page 
> > for all editors to have as instruction). 
> > 
> > What is your opinion on this?
> 
> 
> Great question, I agree with you that most offramps don't have names 
> and shouldn't have a name tag in OSM. Something like "Princes Highway 
> Offramp" unless signposted as that shouldn't be used in my opinion. 
> Instead we should map the destination sign relation (so routers can 
> give correct instructions like "Take exit N towards X" which match the 
> signage) and omit the name tag.
> 
> Not every road way needs a name.
> 
> On Tue, 17 Nov 2020 at 07:28, Ian Bennett  wrote:
> > As a user, I would prefer to hear what I'm looking at. In other words, the 
> > sat nav is saying what 
> > the signage is showing.
> 
> In this case it's best we omit the name tag in OSM where we've mapped a 
> descriptive non-signed name so that routers don't waste time telling 
> you the descriptive name like "Princes Highway Offramp" and instead can 
> focus on what is usually signed, the destination and optionally exit 
> number. 
>  
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>

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

Re: [OSM-talk-fr] [OSM-Talk-fr] Nouveaux tags "Ça reste ouvert"

[Pierre-Olivier GREGOIRE]

Bonjour


Le lun. 16 nov. 2020 à 16:03, Vincent Bergeot  a
écrit :

>
>
>
> On pourrait plus tard décliner la différentiation moyen de commande /
> moyen de retrait :
> peut-être :
> "order:covid19" : yes/no/phone/website voir même "order:url"
> "pick-up:covid19" : "in-store"/"drive"
>
>
> peut-être que description:covid19 est suffisant pour préciser ensuite tous
> les cas, plutôt que de trop décliner en des tags différents ?
>

Oui je suis d'accord. J'aimerais bien y réfléchir sur tagging plus tard
mais pour ça reste ouvert à court terme je pense aussi qu'on peut utiliser
description:covid19 pour les détails.

En regardant à la concurrence (google maps, bing maps, pages jaunes...),
ils ne structurent pas non plus les canaux de commande ou de retrait.

à vous
>
> --
> Vincent Bergeot
>
> ___
> 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-au] Naming Ramps in Australia

[Andrew Harvey]

On Tue, 17 Nov 2020 at 00:04, Aleksandar Matejevic (E-Search) via Talk-au <
talk-au@openstreetmap.org> wrote:

> Hi all,
> I have noticed that the majority of ramps in Australia tend to have
> descriptive names and that naming format/system is not unique. Also, it is
> 50-50 between named and unnamed ramps.
>
> I have researched ramps across all Australia, looked at Mapillary, OSC,
> government data, OSM history. On street level imagery I could not find any
> named ramp. In some cases there was an exit number, and it was tagged as
> junction:ref because it is not a name of the exit, but all I could find
> were just destination signs.  However, on OSM, ramps had names which in
> some cases contained information for destinations (John Willcock Link
> (Eastbound) to Brand Highway) or their function (Pacific Highway
> On/Offramp). Government data was descriptive in some cases, there was no
> name in others so no consistency there also.
>
> I think that ramps do not have names and therefore should not contain a
> name key in OSM (only if there is a specific name for it, then it should
> have a name key). Exit numbers should be added as junction:ref and
> signposts data should be added either as destination relation or
> destination key on the way so routing algorithms could pick that info and
> give instructions like: "Take the exit toward X,Y,Z". If there is a name,
> instructions will be like: "Take left to X,Y,Z onramp/offramp”.
>
> I am raising this question in hope to get some kind of consensus how to
> treat these cases across Australia, so all the ramps have the same format
> (conclusion could be added to Australian Tagging Guidelines on wiki page
> for all editors to have as instruction).
>
> What is your opinion on this?
>

Great question, I agree with you that most offramps don't have names and
shouldn't have a name tag in OSM. Something like "Princes Highway Offramp"
unless signposted as that shouldn't be used in my opinion. Instead we
should map the destination sign relation (so routers can give correct
instructions like "Take exit N towards X" which match the signage) and omit
the name tag.

Not every road way needs a name.

On Tue, 17 Nov 2020 at 07:28, Ian Bennett  wrote:

> As a user, I would prefer to hear what I'm looking at. In other words, the
> sat nav is saying what
> the signage is showing.
>

In this case it's best we omit the name tag in OSM where we've mapped a
descriptive non-signed name so that routers don't waste time telling you
the descriptive name like "Princes Highway Offramp" and instead can focus
on what is usually signed, the destination and optionally exit number.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

[talk-cz] pozvánka na listopadové mapathony

[r.stampach]

Vážení příznivci mapathonů a OpenStreetMap,

v minulých měsících a letech jste se zúčastnili některého z brněnských Missing 
Maps mapathonů. Současná situace, kdy je uzavřena Masarykova univerzita a není 
doporučeno shromažďování ale nedovoluje, abychom se sešli osobně. 
Proto mi dovolte abych vás místo toho pozval na online mapathony, který je 
organizován společně organizačními týmy mapathonů z různých měst České a 
Slovenské republiky. 
Vzhledem k tomu, že ve dnech 16.-18. listopadu oslavíme celosvětový OSM Geo 
Week - týden oslavy geografie - tak se nám v listopadu s nabídkou mapathonů 
roztrhl pytel. Věřím proto, že si každý z vás vybere ten, který se mu časově 
hodí.

Mapathon organizovaný českou komunitou včetně přispění brněnského organizačního 
týmu je naplánován v úterý 24. listopadu 2020 od 18 do 20 hodin. 
Registraci a více informací naleznete zde: 
https://www.eventbrite.co.uk/e/listopadovy-online-mapathon-tickets-127339932165?
V nabídce jsou hned čtyři různé skupiny podle různých úrovní pokročilosti.

Pokud by se někdo nemohl zúčastnit v úterý 27. října, pak jako alternativu lze 
doporučit mapathony organizované našimi slovenskými kolegy.
Kolegové z Bratislavy a Žiliny organizují mapathon ve čtvrtek 19. listopadu 
2020 od 17 do 20 hodin.
Registraci a více informací naleznete zde: 
https://www.eventbrite.co.uk/e/missing-maps-mapathon-bratislava-10-tickets-128429834091
V nabídce jsou dvě skupiny podle pokročilosti.

Do třetice pořádá mapathon skupina UNIPO Mappers z Prešova a to ve čtvrtek 19 
listopadu od 13:15 do 14:55. 
Registraci a více informací naleznete zde: 
https://www.eventbrite.com/e/presov-missing-maps-online-mapathon-for-osm-geo-week-2020-tickets-128979937465?

Každopádně Vám jménem celého organizačního týmu brněnských mapathonů (Jakub, 
Jakub, Katka, Radim, Daniel a Tomáš) všem velice děkuji za Vaši dřívější a snad 
i budoucí účast.

Radim Štampach 
Missing Maps Brno

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

Re: [Talk-in] Mapping Water ATM's

[Mateusz Konieczny via Talk-in]

amenity=vending_machine
vending=water

is a potential alternative tagging
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dvending_machine


amenity=water_point seems for larger scale
"Water ATM located at Jayanagar dispenses around 6000 litres daily"
and article has people with just some large bottles while
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dwater_point
describes it as
"you can get larger amounts of "drinking water" for filling a fresh water
holding tank, such as found on caravans, RVs and boats."


Nov 16, 2020, 15:04 by chetanh...@gmail.com:

> Hello all,
>
> In Bengaluru we have public Water ATM's (Water vending machines) across the 
> city since 2015. These are not mapped in OSM and are widely used by people 
> for drinking purposes. I have tagged one such in > RPC layout 
> > , Vijayanagar.  For more 
> information please read this > article 
> >
>  .
>
> OSM tag used: 
> amenity=water_point 
> There are few > amenity=drinking_water >  
> in OSM but it would be good if we map all water_points across the city. 
>
> Let me know any suggestions on mapping these in the city. Also, I am not sure 
> of Water ATM's in the other cities as well. 
>
> Regards,
> Chetan
> OSM:Chetan_Gowda
>

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

Re: [talk-au] Naming Ramps in Australia

[Ian Bennett]

As a user, I would prefer to hear what I'm looking at. In other words, the sat nav is saying what 
the signage is showing.


Ian

On 17/11/20 12:00 am, Aleksandar Matejevic (E-Search) via Talk-au wrote:

Hi all,
I have noticed that the majority of ramps in Australia tend to have descriptive names and that 
naming format/system is not unique. Also, it is 50-50 between named and unnamed ramps.


I have researched ramps across all Australia, looked at Mapillary, OSC, government data, OSM 
history. On street level imagery I could not find any named ramp. In some cases there was an exit 
number, and it was tagged as junction:ref because it is not a name of the exit, but all I could find 
were just destination signs.  However, on OSM, ramps had names which in some cases contained 
information for destinations (John Willcock Link (Eastbound) to Brand Highway) or their function 
(Pacific Highway On/Offramp). Government data was descriptive in some cases, there was no name in 
others so no consistency there also.


I think that ramps do not have names and therefore should not contain a name key in OSM (only if 
there is a specific name for it, then it should have a name key). Exit numbers should be added as 
junction:ref and signposts data should be added either as destination relation or destination key on 
the way so routing algorithms could pick that info and give instructions like: "Take the exit toward 
X,Y,Z". If there is a name, instructions will be like: "Take left to X,Y,Z onramp/offramp”.


I am raising this question in hope to get some kind of consensus how to treat these cases across 
Australia, so all the ramps have the same format (conclusion could be added to Australian Tagging 
Guidelines on wiki page for all editors to have as instruction).


What is your opinion on this?


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



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

Re: [OSM-talk-fr] [OSM-Talk-fr] Nouveaux tags "Ça reste ouvert"

[osm . sanspourriel]

On a déjà les moyens de payement, pas la peine d'en inventer (sauf à
suffixer par covid19).

https://wiki.openstreetmap.org/wiki/FR:Key:payment#Argent_liquide

Ça donnerait :

payment:cash:covid19=no

Par contre un commerçant en dessous d'une certaine somme doit accepter
le liquide (car contre il peut imposer un payement à la réservation ce
qui revient à peu près au même).

Et par rapport au message de Vincent : KISS, en français c'est réserver
et emporter donc :

reservation=only

takeaway=only

(avec les suffixes covid19 si c'est du temporaire).


Le 16/11/2020 à 20:27, Philippe Verdy - ver...@gmail.com a écrit :

le paiement sur place en espèces impossible.




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

Re: [OSM-talk-fr] [OSM-Talk-fr] Nouveaux tags "Ça reste ouvert"

[Philippe Verdy]

Note aussi: les magasins ouverts en "clickandcollect" n'obligent pas tous à
commander en ligne: on peut passer commande sur le pas de la porte et
revenir plus tard. Le problème, c'est surtout le paiement (les boutiques en
clickandcollect ou vendeurs "à la roulotte" y compris les foodtrucks, ne
veulent pas mettre leur caisse près de la porte ouverte (même si elle est
barrée par un meuble de service) pour des raisons de sécurité aussi, et ne
peuvent pas non plus ouvrir s'il y a une file d'attente sur la rue (c'est
un gros problème pour la vente de nourriture à emporter, type fastood: en
général on veut manger quand c'est prêt, sans attendre et c'est vite
périmé, donc comment éviter les files d'attente sur le trottoir? Certains
ont des livraisons, comme les pizzas, mais en plus il y a le couvre-feu qui
les oblige à fermer très vite le soir).

La vente à emporter c'est pas évident pour tout le monde.

Au final pour beaucoup les seuls magasins encore accessibles sont les
supermarchés et hypers (avec restriction de l'affluence et
controle/surveillance des entrées devenu obligatoire, par un vigile ou par
certains employés du magasin pour réguler les entrées et répartir les
clients en caisse : si les caisses ont trop de monde à attendre, l'entrée
est refusée, les clients doivent attendre leur tour dehors et entrent au
compte-goutte avec la sortie des autres clients; pour accélérer le flux,
les commerces ont déjà réduit leur offre au delà même des restrictions
gouvernementales, et les espaces de circulation, on ne doit plus "trainer"
dans les rayons et certains limitent les quantités dans les charriots, le
temps dans le magasin est limité, on vous invite alors à prendre
l'essentiel, passer vite aux caisses et revenir plus tard pour le reste; ça
se passe surtout en début de soirée ou le samedi; moins de choix, plus
aucune "promotion", plus de produits "en vrac", plus de produits en lots
importants, moins de marques... Là aussi on vous invite à commander sur
Internet et retirer en "drive" mais ce n'est pas possible pour tout le
monde). Pour les familles nombreuses, ou les personnes éloignées sans
véhicule (avec des transports en commun également très réduits et limités
en capacité et fréquence), faire ses courses est devenu compliqué.


Le lun. 16 nov. 2020 à 16:03, Vincent Bergeot  a
écrit :

> Bonjour,
>
> je reprends ce petit bout de ton mail
> Le 10/11/2020 à 11:52, Pierre-Olivier GREGOIRE a écrit :
>
> *Les tags :*
>
> Maintenant il est vrai que "takeway:covid19" a été utilisé pendant le
> premier confinement pour un mélange des deux concepts : "retrait en
> magasin" et "consommer à emporter". Personnellement je préfererais :
> * Introduire une nouvelle clef "order_and_collect:covid19"
> * il faudra décider ce qu'on fait des anciens tags pour les magasins : en
> tant que consommateur de donnée, toujours interpréter takeaway:covid19
> comme équivalent à "order_and_collect:covid19" quand il ne s'agit pas d'un
> restaurant ou d'un café ou d'un bar peut-être ?
>
> Pour les livraisons je pense qu'on peut rester sur "delivery:covid19" qui
> personnellement ne me pose aucun souci.
>
> pour ma part, favorable à la notion order_and_collect:covid19 -> l'accès
> au magasin est fermé sauf pour venir chercher une commande préalablement
> réalisée. C'est sans doute un des cas les plus fréquents en ce moment.
>
>
>
>
> On pourrait plus tard décliner la différentiation moyen de commande /
> moyen de retrait :
> peut-être :
> "order:covid19" : yes/no/phone/website voir même "order:url"
> "pick-up:covid19" : "in-store"/"drive"
>
>
> peut-être que description:covid19 est suffisant pour préciser ensuite tous
> les cas, plutôt que de trop décliner en des tags différents ?
>
> à vous
>
> --
> Vincent Bergeot
>
> ___
> 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] [OSM-Talk-fr] Nouveaux tags "Ça reste ouvert"

[Philippe Verdy]

Le lun. 9 nov. 2020 à 20:40, Yves P.  a écrit :

> - safety:mask:covid19
> 
> =yes/given/sold pas certain que l'on ai encore besoin de ça. On déprécie ?
>
>
> Poubelle ! je ne comprends même pas comment c'est arrivé dans CRO ;)
>
> - delivery:covid19
> =yes
> 
> fonctionne toujours pour indiquer la possibilité de livraison.
> Par contre j'ai l'impression que cela s'applique à plus de catégories de
> POIs (pas uniquement sur les restaurant mais aussi pour les librairies
> ,
> et potentiellement je pense aussi aux bibliothèques)
>
>
> A tous les commerçants qui le souhaitent (Tiens, ça ne fonctionne pas pour
> les coiffeurs, les ongleries… :D )
>
>
> mais surtout qu'il faut maintenant indiquer le Click and collect.
>
>
> delivery:covid19=yes va bien ?
>

Non car "delivery" indique un service de livraison (à domicile). le
"clickandcollect" c'est la possibilité de retier sur place (la boutique est
fermée à l'exception du pas de porte avec une barrière, on ne peut pas
entrer mais on peut se faire remettre les colis préparés (aux heures
d'ouverture indiquées, éventuellement adaptées avec :"covid19") et
éventuellement payer.

Attention : certains commerces "clickandcollect" ne traitent QUE les
commandes payées en ligne, car il n'y a plus de caisse ni échange de
monnaie). Ceux qui n'ont pas d'internet ou de carte de paiement à distance
ne peuvent PAS aller dans ces commerces (tout le monde n'a pas une carte
"CB", beaucoup n'ont que des cartes de retrait simple d'espèces). Nombre de
commerces n'acceptent pas non plus les paiements mobiles (eux aussi
réservés à certaines catégories de personnes, et pas sur tous les
abonnements mobiles, et il faut un terminal compatible: le commerçant ne
veut pas toucher votre smartphone, pas plus que la monnaie, pour ne pas
risquer de contaminer son propre commerce: ça commence maintenant dans les
bureaux de tabac et marchands de journaux, dont déjà le bar est fermé; il
n'est pas évident de décontaminer des pièces et billets et les manipuler
facilement et sans risque).

Donc il faudrait un autre tag pour le paiement en ligne obligatoire, ou le
paiement sur place en espèces impossible.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-at] ALS-Daten frei zugänglich

[Friedrich Volkmann]

On 15.11.20 18:13, Patrick Strasser-Mikhail wrote:
Ich wäre einmal sehr interessiert an einer Darstellung von dir, was alles 
brauchbar bis super funktioniert. Man könnte den Eindruck bekommen, dass 
gerade _alles_ beim Zusammenbrechen ist.


Meine Höhlenlinien für Garmin sind brauchbar.

Ich fände es schön in deinen Beiträgen zumindest einen explizit positiven 
Aspekt zu finden, probiers einmal.


Wenn ich Talent für Schönreden hätte, wär ich Unternehmer oder Makler 
geworden und stinkreich.


Höhenlinien muss auch irgendwer einmal aus den Daten extrahieren. 
Anscheinend hast du das schon einmal gemacht. Kannst du skizzieren wie das 
am besten geht (Algoritmus, bestes Datenformat)? Geht das mit einem 
Einzeiler oder dauert das ein paar Nachmittage?


Ich hab es wie gesagt für Garmin-Geräte gemacht, und zwar mit den 
Shellscript im Anhang.


Tiles zu rendern hab ich auch probiert, aber nicht zusammengebracht, darum 
kann ich dazu keinen Tipp geben.


Ich hab eine Garmin-Karte (.IMG) mit den genauen Höhenlinien 
veröffentlicht, die hat auch keinen interessiert.


Wenn man nicht gerade ein Garmin-Gerät hat werden die wohl eher weniger 
nützlich sein.
Wenn es aber außer dir sonst noch zumindest eine Person nutzen kann war es 
nicht nur ein privates Vergnügen (was Grund genug sein könnte sich selber 
sowas zu erstellen).


Weiß nicht, was du mit dem Absatz ausdrücken willst. Wer als Mapper oder 
Anwender im Gelände unterwegs ist, kommt um Garmin kaum herum. Zwar sind die 
Garmin-Modelle in den letzten 10 Jahren nicht besser geworden und 
hochpreisige Handys haben heute auch schon einen guten GPS-Empfang, aber der 
Stromverbrauch und die Robustheit machen immer noch einen entscheidenden 
Unterschied.


Ein WMS mit Höhenlinien wär super sowohl als Overlay für Online-Karten als 
auch als Hintergrund zum Editieren, aber das hat noch keiner gemacht.


Genau. Gute Idee. Vorschläge wie man das macht?


Du kannst an den Beitrag von scubbx am 20.1.2019, Message-ID 
, anknüpfen. Vector 
Tiles sind wahrscheinlich effizienter als ein WMS.


Ein Webservice, das als Parameter die Koordinaten nimmt und die Seehöhe 
retourniert, wär auch super. Hat auch noch keiner gemacht.


Genau. Gute Idee. Vorschläge wie man das macht?


Während für die Höhenlinien der 10x10m-Raster völlig ausreicht, ist bei 
Höhenabfragen der 1x1m-Raster um Welten besser. Der braucht allerdings den 
100-fachen Speicher.


Österreich hat 83879 km² ≈ 10^11 m².

Eine normale Datenbanktabelle mit den Feldern RW, HW und Sh braucht nach 
meiner Berechnung etwas in der Größenordnung von 1 TB, ist aber wegen der 
Hohen Anzahl Datensätze unhandlich.


Geschickter ist sicherlich eine Array DB, aber damit habe ich keine 
Erfahrung. Die Geoinformatiker unter uns wissen wahrscheinlich, welche dafür 
geeignet ist.


Dazu ein Apache-Webserver und ein Python/Perl/PHP/dgl. Script, das ist keine 
Hexerei.


Ich werfe als Idee noch eine Profilfunktion ein: Man übergibt einen Pfad und 
bekommt ein Höhenprofil zurück.


Der Pfad und das daraus erzeugte Höhenprofil bestehen nur aus diskreten 
Werten, die erst in der Darstellung intrapoliert werden. D.h. der Server 
müsste halt ein Array von Werten akzeptieren bzw. zurückgeben (JSON, XML 
oder banalen Plaintext mit Zeilenumbrüchen als Trennzeichen). Das ist im 
Prinzip nicht viel anders, als das Service für jeden Punkt einzeln aufzurufen.


Die Gefahr bei sowas ist, dass es von einzelnen Usern oder Apps für 
Massenabfragen missbraucht wird und der Server damit lahmgelegt wird.


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


all.sh
Description: application/shellscript
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-GB] Service road with private locked gate and routing apps

[Mat Attlee]

A quick update to say I've surveyed the service road and it looks very much
abandoned as covered in debris and overgrowth which I've marked accordingly
https://www.openstreetmap.org/changeset/94215820

On Mon, 16 Nov 2020 at 13:44, Mat Attlee  wrote:

> I'll add a note accordingly to the road as it does appear to be disused
> but with the redevelopment of Marian Court maybe it will be reopened.
>
> On Mon, 16 Nov 2020 at 13:15, Dave F via Talk-GB <
> talk-gb@openstreetmap.org> wrote:
>
>> I wouldn't have mapped that as any kind of road at all. From aerial
>> imagery the west end is blocked by a container & vegetation suggests it's
>> not been used for years.
>>
>> On 16/11/2020 11:18, Mat Attlee wrote:
>>
>> There is a service road in Homerton that I noticed several different
>> routing apps including Cycle Streets, Komoot and Citymapper were taking me
>> down eg https://www.cyclestreets.net/journey/72171728/
>>
>> Upon surveying this service road it is very much closed to the public
>> with locked gates which I marked as thus
>> https://www.openstreetmap.org/changeset/93935943
>>
>> However these routing apps still use this service road. Have I missed
>> something or does it take a while for the changes to propagate?
>>
>> ___
>> Talk-GB mailing 
>> listTalk-GB@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-gb
>>
>>
>> ___
>> Talk-GB mailing list
>> Talk-GB@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb
>>
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] Suppression de l'attribut source (Re: Import des horaires des bureaux de poste)

[Jérôme Amagat]

Je suis d'accord, aucune solution n'est parfaite. Mais dire, on supprime
source=* car la source est quelque part dans l'historique de l'objet, je
n'y vois pas la solution miracle, loin de là.

Il faut revenir au sujet de cette discussion, on parle de modifier un tag
sur 1000 objets en France. Est ce qu'au niveau mondial, il a été décidé de
supprimer le tag source=* ? A ma connaissance non.

Je ne vois pas de problème à parler de la façon d'indiquer la source, mais
le principal ici, c'est d'aider David pour son import en se limitant à
l'usage aujourd'hui. Et pour moi, ça veut dire, (toujours pour son
changeset sur les heures d'ouverture), on ne touche pas à source=*, et on
met la source sur le changeset, on peut aussi l'ajouter dans
source:opening_hours=* mais pas d'obligation.

Et si un jour, il est décidé que le tag source=* était superflu, il sera
facile de le supprimer à ce moment-là.

Mon avis sur la façon d'indiquer la source : c'est le truc que je n'aime
pas lors de mes contributions à osm, je sais jamais quoi mettre et où,
surtout que la plupart du temps, je modifie des choses très différentes
avec des sources différentes. Quant tout (ou presque) vient d'une même
source, c'est facile de mettre la source sur le changeset mais c'est pas la
solution la plus simple pour les suivant qui voudrait savoir qui et à
partir de quelle source a été ajouter un tag, "il faudrait" que chaque tag
ait sa source et sa date de modification, c'est la ou le tag source:*=* est
utile mais comme il n'est pas lié au *=*, on peut modifier l'un sans
modifier l'autre et ça complique beaucoup l'édition. "Il faudrait" que
l'éditeur face le gros du travail, si lorsque l'on modifie un tag,
l'éditeur lie au tag la source du changeset et sa date de modification et
que cette info était facile à avoir dans l'éditeur pour les suivant, ça
simplifierait les choses mais il y a toujours le problème des sources
multiples et s'il faut écraser l'ancienne source ou l'ajouter...

Le lun. 16 nov. 2020 à 12:22, Marc_marc  a écrit :

> Bonjour,
>
> Le 16.11.20 à 10:23, Jean-Claude Repetto a écrit :
> > L'indication exclusive de la source sur le changeset n'est qu'un
> > pis-aller,
>
> dr;tl : la "vie" d'un tag source dans les différents cas
> de figure explique mieux les problèmes et les solutions.
>
> version longue :
>
> dans cette discussion, j'ai l'impression qu'il y a une tendance
> à "ce que je fais est parfait, les autres font du mauvais"
> qui ne se base pas assez sur la réalité tant des capacités
> des éditeurs que du comportement réel des contributeurs.
>
> prenons un exemple :
> j'importe un bâtiment à partir du cadastre avec source=cadastre
> sur l'objet building comme jadis et source=cadastre sur le changeset.
> ensuite un autre contributeur modifie la géométrie (la position
> des 4 nœuds) du bâtiment parce que celle du cadastre est erronée,
> ainsi qu'il a pu le constater sur place.
> il modifie aussi building=yes en building=detached
>
> Quel est la source actuelle de l'objet et de sa géométrie ?
> il ne subsiste plus aucune information venant du cadastre.
> toutes les infos de l'objet actuelle proviennent du terrain.
> est-t-on d'accord qu'il ne devrait donc plus y avoir
> aucune trace de source=ccadastre sur la version actuelle ?
>
> voyons ce qui se passe dans la réalité lors de cette modif
>
> 1) AUCUN éditeur à ma connaissance ne va modifier la source
> déclarée sur l'objet sauf intervention humaine spécifique,
> elle va donc se désynchroniser. si quelqu'un se base sur la source
> de l'objet et crois que l'objet actuel vient du cadastre il se trompe.
> à l'inverse tous les éditeurs vont fournir des meta-donées (le
> changeset) puis celui-ci est imposé par l'api.
>
> 2) certains préconisent alors d'ajouter source:geometry
> et source:building. mais là aussi aucun éditeur
> ne les traire comme une meta-donnée. c'est qu'une donnée
> comme une autre, uniquement modifié par intervention humaine
> spécifique. donc cela revient exactement à la même chose que
> le point précédent (source:geometry=cadastre sur l'objet
> ne dit pas que la géométrie actuelle vient du cadastre).
>
> 3) JOSM/Vespucci/StreetComple poussent fortement l'ajout
> d'un tag source sur le changeset. iD le permet aussi.
> tous les éditeurs proposent facilement d'ajouter des sources
> ainsi que l'imagerie sat utilisée pour l'alignement.
> en tout état de cause, la présence de meta-donnée (les tags de
> changeset) sont renseigné par le contributeur de cette modif là
> et concernerait cette modif, donc fiable (quand elle existe)
> pour connaître la source de ces modifs.
>
> 4) le cas d'une session de modif avec plus d'une source.
> certains changeset mixent plusieurs sources
> et mixent donc aussi des âges de source différents.
> Il faut se souvenir que le tag source dans osm permet
> la traçabilité et la communication entre contributeur.
> Pour gérer ces mix, il y a 3 écoles :
> - plusieurs source:tag1 source:tag2 sur l'objet
> Hors on a vu ci dessous que cela ne 

Re: [OSM-talk-fr] [OSM-Talk-fr] Nouveaux tags "Ça reste ouvert"

[Vincent Bergeot]

Bonjour,

je reprends ce petit bout de ton mail
Le 10/11/2020 à 11:52, Pierre-Olivier GREGOIRE a écrit :

*Les tags :*

Maintenant il est vrai que "takeway:covid19" a été utilisé pendant le 
premier confinement pour un mélange des deux concepts : "retrait en 
magasin" et "consommer à emporter". Personnellement je préfererais :

* Introduire une nouvelle clef "order_and_collect:covid19"
* il faudra décider ce qu'on fait des anciens tags pour les magasins : 
en tant que consommateur de donnée, toujours interpréter 
takeaway:covid19 comme équivalent à "order_and_collect:covid19" quand 
il ne s'agit pas d'un restaurant ou d'un café ou d'un bar peut-être ?


Pour les livraisons je pense qu'on peut rester sur "delivery:covid19" 
qui personnellement ne me pose aucun souci.


pour ma part, favorable à la notion order_and_collect:covid19 -> l'accès 
au magasin est fermé sauf pour venir chercher une commande préalablement 
réalisée. C'est sans doute un des cas les plus fréquents en ce moment.






On pourrait plus tard décliner la différentiation moyen de commande / 
moyen de retrait :

peut-être :
"order:covid19" : yes/no/phone/website voir même "order:url"
"pick-up:covid19" : "in-store"/"drive"



peut-être que description:covid19 est suffisant pour préciser ensuite 
tous les cas, plutôt que de trop décliner en des tags différents ?


à vous

--
Vincent Bergeot

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

[Talk-in] Mapping Water ATM's

[Chetan H A]

Hello all,

In Bengaluru we have public Water ATM's (Water vending machines) across the
city since 2015. These are not mapped in OSM and are widely used by people
for drinking purposes. I have tagged one such in RPC layout
, Vijayanagar.  For
more information please read this article

.

OSM tag used:

   - amenity=water_point

There are few *amenity=drinking_water *
in OSM but it would be good if we map all water_points across the city.

Let me know any suggestions on mapping these in the city. Also, I am not
sure of Water ATM's in the other cities as well.

Regards,
Chetan
OSM:Chetan_Gowda
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

Re: [Talk-ca] How is protect_class used in Canada?

[Brian M. Sperlongano]

Great idea.  I just sent out a message to user webfil, who seems to have
initially mapped those lands.

On Mon, Nov 16, 2020 at 8:16 AM john whelan  wrote:

> >I am guessing that some or all of the categories on that list under
> class 7 can simply be deleted.
>
> Have you attempted to contact the original mappers?
>
> We have a few mappers in Canada who have been mapping for more than ten
> years.
>
> John
>
> On Sun, Nov 15, 2020, 23:28 Brian M. Sperlongano 
> wrote:
>
>> Hello neighbors to the north,
>>
>> I have been working to clean up and improve documentation on tagging of
>> protected areas.  I've found that in many cases the documentation on the
>> wiki does not match how tagging is actually done in real life, so I am
>> working to make the wiki more accurate and make the information more useful
>> to mappers.
>>
>> The wiki [1] lists seven different categories that are tagged
>> protect_class=7 in Canada.  I was able to find wikipedia links for a few of
>> them, but the other items in the list looked like generic terms that were
>> just tossed in there by the original author ~10 years ago.
>>
>> So..  what does protect_class=7 tagging mean in Canada?  Does this have
>> real meaning or is it a long-ago forgotten convention?  Since this value
>> does not render on the default map, it is always paired with something like
>> leisure=nature_reserve to force the drawing of an outline.  An overpass
>> inspection [2] shows that this value is almost entirely in Quebec.
>>
>> I am guessing that some or all of the categories on that list under class
>> 7 can simply be deleted.  I'd like to understand how this tagging is
>> actually used in order to make the documentation useful and/or understand
>> what the Canadian consensus for how these values *should* be used.
>>
>> [1] https://wiki.openstreetmap.org/wiki/Key:protect_class
>> [2] https://overpass-turbo.eu/s/10bS
>>
>> -Brian (Rhode Island, USA)
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-GB] Service road with private locked gate and routing apps

[Mat Attlee]

I'll add a note accordingly to the road as it does appear to be disused but
with the redevelopment of Marian Court maybe it will be reopened.

On Mon, 16 Nov 2020 at 13:15, Dave F via Talk-GB 
wrote:

> I wouldn't have mapped that as any kind of road at all. From aerial
> imagery the west end is blocked by a container & vegetation suggests it's
> not been used for years.
>
> On 16/11/2020 11:18, Mat Attlee wrote:
>
> There is a service road in Homerton that I noticed several different
> routing apps including Cycle Streets, Komoot and Citymapper were taking me
> down eg https://www.cyclestreets.net/journey/72171728/
>
> Upon surveying this service road it is very much closed to the public with
> locked gates which I marked as thus
> https://www.openstreetmap.org/changeset/93935943
>
> However these routing apps still use this service road. Have I missed
> something or does it take a while for the changes to propagate?
>
> ___
> Talk-GB mailing 
> listTalk-GB@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-gb
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-ca] How is protect_class used in Canada?

[john whelan]

>I am guessing that some or all of the categories on that list under class
7 can simply be deleted.

Have you attempted to contact the original mappers?

We have a few mappers in Canada who have been mapping for more than ten
years.

John

On Sun, Nov 15, 2020, 23:28 Brian M. Sperlongano 
wrote:

> Hello neighbors to the north,
>
> I have been working to clean up and improve documentation on tagging of
> protected areas.  I've found that in many cases the documentation on the
> wiki does not match how tagging is actually done in real life, so I am
> working to make the wiki more accurate and make the information more useful
> to mappers.
>
> The wiki [1] lists seven different categories that are tagged
> protect_class=7 in Canada.  I was able to find wikipedia links for a few of
> them, but the other items in the list looked like generic terms that were
> just tossed in there by the original author ~10 years ago.
>
> So..  what does protect_class=7 tagging mean in Canada?  Does this have
> real meaning or is it a long-ago forgotten convention?  Since this value
> does not render on the default map, it is always paired with something like
> leisure=nature_reserve to force the drawing of an outline.  An overpass
> inspection [2] shows that this value is almost entirely in Quebec.
>
> I am guessing that some or all of the categories on that list under class
> 7 can simply be deleted.  I'd like to understand how this tagging is
> actually used in order to make the documentation useful and/or understand
> what the Canadian consensus for how these values *should* be used.
>
> [1] https://wiki.openstreetmap.org/wiki/Key:protect_class
> [2] https://overpass-turbo.eu/s/10bS
>
> -Brian (Rhode Island, USA)
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-GB] Service road with private locked gate and routing apps

[Dave F via Talk-GB]

I wouldn't have mapped that as any kind of road at all. From aerial 
imagery the west end is blocked by a container & vegetation suggests 
it's not been used for years.


On 16/11/2020 11:18, Mat Attlee wrote:
There is a service road in Homerton that I noticed several different 
routing apps including Cycle Streets, Komoot and Citymapper were 
taking me down eg https://www.cyclestreets.net/journey/72171728/


Upon surveying this service road it is very much closed to the public 
with locked gates which I marked as thus 
https://www.openstreetmap.org/changeset/93935943


However these routing apps still use this service road. Have I missed 
something or does it take a while for the changes to propagate?


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


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

[talk-au] Naming Ramps in Australia

[Aleksandar Matejevic (E-Search) via Talk-au]

Hi all,
I have noticed that the majority of ramps in Australia tend to have descriptive 
names and that naming format/system is not unique. Also, it is 50-50 between 
named and unnamed ramps.

I have researched ramps across all Australia, looked at Mapillary, OSC, 
government data, OSM history. On street level imagery I could not find any 
named ramp. In some cases there was an exit number, and it was tagged as 
junction:ref because it is not a name of the exit, but all I could find were 
just destination signs.  However, on OSM, ramps had names which in some cases 
contained information for destinations (John Willcock Link (Eastbound) to Brand 
Highway) or their function (Pacific Highway On/Offramp). Government data was 
descriptive in some cases, there was no name in others so no consistency there 
also.

I think that ramps do not have names and therefore should not contain a name 
key in OSM (only if there is a specific name for it, then it should have a name 
key). Exit numbers should be added as junction:ref and signposts data should be 
added either as destination relation or destination key on the way so routing 
algorithms could pick that info and give instructions like: "Take the exit 
toward X,Y,Z". If there is a name, instructions will be like: "Take left to 
X,Y,Z onramp/offramp".

I am raising this question in hope to get some kind of consensus how to treat 
these cases across Australia, so all the ramps have the same format (conclusion 
could be added to Australian Tagging Guidelines on wiki page for all editors to 
have as instruction).

What is your opinion on this?
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-GB] Service road with private locked gate and routing apps

[Mateusz Konieczny via Talk-GB]

https://wiki.openstreetmap.org/wiki/Surface

https://wiki.openstreetmap.org/wiki/Key:tracktype that is useful tor 
highway=track
and unpaved ones, but mostly duplicate of surface tag

Nov 16, 2020, 12:40 by mattatt...@gmail.com:

> Good point. I will also update the surface and quality of the service road as 
> it is visible through the gate and last I checked it was covered with debris, 
> are there any appropriate tags for that?
>
> On Mon, 16 Nov 2020 at 11:31, David Woolley <> for...@david-woolley.me.uk> > 
> wrote:
>
>> On 16/11/2020 11:18, Mat Attlee wrote:
>>  > Upon surveying this service road it is very much closed to the public 
>>  > with locked gates which I marked as thus 
>>  > >> https://www.openstreetmap.org/changeset/93935943
>>  > 
>>  > However these routing apps still use this service road. Have I missed 
>>  > something or does it take a while for the changes to propagate?
>>  
>>  It takes time for routing engines to update.  However, I would also have 
>>  put access tags on the service road.
>>  
>>  ___
>>  Talk-GB mailing list
>>  >> Talk-GB@openstreetmap.org
>>  >> https://lists.openstreetmap.org/listinfo/talk-gb
>>

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

Re: [OSM-talk-fr] composteur

[Vivien MICHON]

Bonjour,

Bien vu le recensement des composteurs.
Je préciserai la problématique comme suit: comment différencier un point de 
collecte/récupération d'un point de compostage (avec possibilité aussi que ce 
soit les deux).

En d'autres termes, est-ce l'usager qui apporte de la matière organique à 
composter et qui s'occupe lui-même de l'entretien (matière sèche, mélanger, 
veiller à mettre dans le bon bac >> compost de type libre-service ou 
libre-utilisation) ou bien l'usager ne fait que déposer de la matière organique 
et elle est ensuite utilisée en compostage?

De la même façon, l'information sur la possibilité de récupérer ou non du 
compost mature (prêt à être réutilisé comme engrais) serait intéressante.
Enfin, il y a parfois des lombri-composteurs en accès, dont le fonctionnement 
est différent (ne pas y mettre de matière organique acide en particulier, type 
citron ail oignon). Ajouter un TYPE?

Bon... avoir la première info serait déjà top!

Merci :!
Vivien


-Message d'origine-
De : Marc_marc  
Envoyé : lundi 16 novembre 2020 12:30
À : talk-fr 
Objet : [OSM-talk-fr] composteur

Bonjour,

de nombreux nouveaux contributeurs renseignent en ce moment des composteurs.  
une idée de comment les tager ?

le wiki renseigne
https://wiki.openstreetmap.org/wiki/FR:Comment_cartographier_un...#Composteurs
amenity=recycling
+ recycling:green_waste=yes
et/ou recycling:garden_waste=yes
et/ou recycling:organic=yes

mais rien dans ce tag ne différencie le composteur d'un bac de récupération qui 
serra composté ou méthanisé ailleurs.
ne faudrait-il pas rajouter produce=compost ?
autre idée ?

Cordialement,
Marc




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

Re: [OSM-talk-fr] composteur

[osm . sanspourriel]

Bonjour, on peut, ça ne mange pas de pain.

Perso, ça me semble d'un intérêt limité (les utilisateurs verront bien)
mais si certains y trouvent un intérêt ça me semble tout à fait correct.

Jean-Yvon

Le 16/11/2020 à 12:30, Marc_marc - marc_m...@mailo.com a écrit :

Bonjour,

de nombreux nouveaux contributeurs renseignent en ce moment
des composteurs.  une idée de comment les tager ?

le wiki renseigne
https://wiki.openstreetmap.org/wiki/FR:Comment_cartographier_un...#Composteurs
amenity=recycling
+ recycling:green_waste=yes
et/ou recycling:garden_waste=yes
et/ou recycling:organic=yes

mais rien dans ce tag ne différencie le composteur d'un bac
de récupération qui serra composté ou méthanisé ailleurs.
ne faudrait-il pas rajouter produce=compost ?
autre idée ?

Cordialement,
Marc



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



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

Re: [Talk-GB] Service road with private locked gate and routing apps

[Mat Attlee]

Good point. I will also update the surface and quality of the service road
as it is visible through the gate and last I checked it was covered with
debris, are there any appropriate tags for that?

On Mon, 16 Nov 2020 at 11:31, David Woolley 
wrote:

> On 16/11/2020 11:18, Mat Attlee wrote:
> > Upon surveying this service road it is very much closed to the public
> > with locked gates which I marked as thus
> > https://www.openstreetmap.org/changeset/93935943
> >
> > However these routing apps still use this service road. Have I missed
> > something or does it take a while for the changes to propagate?
>
> It takes time for routing engines to update.  However, I would also have
> put access tags on the service road.
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[OSM-talk-fr] composteur

[Marc_marc]

Bonjour,

de nombreux nouveaux contributeurs renseignent en ce moment
des composteurs.  une idée de comment les tager ?

le wiki renseigne
https://wiki.openstreetmap.org/wiki/FR:Comment_cartographier_un...#Composteurs
amenity=recycling
+ recycling:green_waste=yes
et/ou recycling:garden_waste=yes
et/ou recycling:organic=yes

mais rien dans ce tag ne différencie le composteur d'un bac
de récupération qui serra composté ou méthanisé ailleurs.
ne faudrait-il pas rajouter produce=compost ?
autre idée ?

Cordialement,
Marc



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

Re: [Talk-GB] Service road with private locked gate and routing apps

[David Woolley]

On 16/11/2020 11:18, Mat Attlee wrote:
Upon surveying this service road it is very much closed to the public 
with locked gates which I marked as thus 
https://www.openstreetmap.org/changeset/93935943


However these routing apps still use this service road. Have I missed 
something or does it take a while for the changes to propagate?


It takes time for routing engines to update.  However, I would also have 
put access tags on the service road.


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

Re: [OSM-talk-fr] Suppression de l'attribut source (Re: Import des horaires des bureaux de poste)

[Marc_marc]

Bonjour,

Le 16.11.20 à 10:23, Jean-Claude Repetto a écrit :
> L'indication exclusive de la source sur le changeset n'est qu'un
> pis-aller,

dr;tl : la "vie" d'un tag source dans les différents cas
de figure explique mieux les problèmes et les solutions.

version longue :

dans cette discussion, j'ai l'impression qu'il y a une tendance
à "ce que je fais est parfait, les autres font du mauvais"
qui ne se base pas assez sur la réalité tant des capacités
des éditeurs que du comportement réel des contributeurs.

prenons un exemple :
j'importe un bâtiment à partir du cadastre avec source=cadastre
sur l'objet building comme jadis et source=cadastre sur le changeset.
ensuite un autre contributeur modifie la géométrie (la position
des 4 nœuds) du bâtiment parce que celle du cadastre est erronée,
ainsi qu'il a pu le constater sur place.
il modifie aussi building=yes en building=detached

Quel est la source actuelle de l'objet et de sa géométrie ?
il ne subsiste plus aucune information venant du cadastre.
toutes les infos de l'objet actuelle proviennent du terrain.
est-t-on d'accord qu'il ne devrait donc plus y avoir
aucune trace de source=ccadastre sur la version actuelle ?

voyons ce qui se passe dans la réalité lors de cette modif

1) AUCUN éditeur à ma connaissance ne va modifier la source
déclarée sur l'objet sauf intervention humaine spécifique,
elle va donc se désynchroniser. si quelqu'un se base sur la source
de l'objet et crois que l'objet actuel vient du cadastre il se trompe.
à l'inverse tous les éditeurs vont fournir des meta-donées (le
changeset) puis celui-ci est imposé par l'api.

2) certains préconisent alors d'ajouter source:geometry
et source:building. mais là aussi aucun éditeur
ne les traire comme une meta-donnée. c'est qu'une donnée
comme une autre, uniquement modifié par intervention humaine
spécifique. donc cela revient exactement à la même chose que
le point précédent (source:geometry=cadastre sur l'objet
ne dit pas que la géométrie actuelle vient du cadastre).

3) JOSM/Vespucci/StreetComple poussent fortement l'ajout
d'un tag source sur le changeset. iD le permet aussi.
tous les éditeurs proposent facilement d'ajouter des sources
ainsi que l'imagerie sat utilisée pour l'alignement.
en tout état de cause, la présence de meta-donnée (les tags de
changeset) sont renseigné par le contributeur de cette modif là
et concernerait cette modif, donc fiable (quand elle existe)
pour connaître la source de ces modifs.

4) le cas d'une session de modif avec plus d'une source.
certains changeset mixent plusieurs sources
et mixent donc aussi des âges de source différents.
Il faut se souvenir que le tag source dans osm permet
la traçabilité et la communication entre contributeur.
Pour gérer ces mix, il y a 3 écoles :
- plusieurs source:tag1 source:tag2 sur l'objet
Hors on a vu ci dessous que cela ne garanti en rien la source
de l'object actuel dès lors que c'est un donnée à gérer
humainement et non une méta-donnée gérée par l'api.
- plusieurs tags sur le changeset (oui on peux aussi
facilement mettre source:geometry=BDORtho source:name=survey
sur un changeset
- plusieurs changeset : un premier pour ajouter
les objets manquant avec la géométrie basé sur l'imagerie,
un 2ieme pour ajouter ce qui a été vu sur le terrain.

piste d'amélioration :
1) améliorer les éditeurs pour qu'ils affichent dans l'état actuel
de l'objet la source du changeset à côté de la valeur du tag

2) améliorer les éditeurs pour qu'ils invalident le tag source
précédent lorsque la source de l'objet actuel n'est plus celle-là.
Je viens justement de découvrir une règle optionnel dans josm
qui affiche un avertisement bien pratique en modif d'objet avec source=*

3) avis perso : encourager des chageset humainement lisible au lieu
de bloc indigeste qui laisse le contributeur suivant dans le doute :
ajout bati et en même temps un magasin est supprimé : erreur ou
volontaire ? c'est illisible.
quand il y a 2 modifs, c'est évidement possible de les lister
dans le commentaire du changeset. quand un changeset fait 20 choses
en même temps, on se retrouve avec des "..." nocifs.

> mettre source:opening_hours= (...) sur chaque bureau de poste modifé

ce qui ne résout rien, la prochaine modif opening_hours n'invalidera
pas ce tag sur l'objet. par conséquent quant tu vois ce tag
sur un objet, il ne te rient de la source de la valeur actuelle.

PS: ne va oublier la déformation "on a jadis fait comme cela en fr".
il suffit de voir taginfo mondial pour constater la sur-représentation
des sources en fr sur les objets: la moitié des tags source au monde
sur les bâtiments provient de la France alors que le nombre de bâtiment
en France ne représente que 10% du total mondial.
cela montre qu'ailleurs ils n'ont pas ou plus ou moins ce dogme.

Cordialement,
Marc



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

[Talk-GB] Service road with private locked gate and routing apps

[Mat Attlee]

There is a service road in Homerton that I noticed several different
routing apps including Cycle Streets, Komoot and Citymapper were taking me
down eg https://www.cyclestreets.net/journey/72171728/

Upon surveying this service road it is very much closed to the public with
locked gates which I marked as thus
https://www.openstreetmap.org/changeset/93935943

However these routing apps still use this service road. Have I missed
something or does it take a while for the changes to propagate?
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] High quality NLS imagery of buildings and HOUSENUMBERS (!) available in London (and Scotland). Create a tasking manger to add this?

[Ken Kilfedder]

Hi Mark,

If there is absolute confidence in that, can it be added to the wiki page here:
https://wiki.openstreetmap.org/wiki/National_Library_of_Scotland

And can it be added to the default set of old maps in JOSM?

If it is available for use, not point in keeping it a secret.

---
https://hdyc.neis-one.org/?spiregrain
spiregrain_...@ksglp.org.uk

On Fri, 30 Oct 2020, at 6:47 PM, Mark Goodge wrote:
> 
> 
> On 30/10/2020 18:37, Mateusz Konieczny via Talk-GB wrote:
> > 
> > 
> > 
> > Oct 30, 2020, 16:28 by talk-gb@openstreetmap.org:
> > 
> > It has come to my attention that the "Town Plan" map from 1944-1967
> > in NLS is available freely.
> > 
> > What are its licensing terms?
> > 
> > "available freely" does not mean "compatible with OSM license"
> 
> It's out of copyright, so there aren't any licensing issues in deriving 
> data from it.
> 
> I would, though, be a little reluctant to use it as a basis for 
> wholesale numbering without any supporting local knowledge or survey. 
> House numbers can, and sometimes do, change, particularly when streets 
> are renamed or rebuilt. So you can't be 100% certain that a house number 
> in the 1950s is the same number it is now, even if the building is still 
> the same.
> 
> Mark
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>

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

Re: [OSM-talk-fr] Suppression de l'attribut source (Re: Import des horaires des bureaux de poste)

[Jean-Claude Repetto]

Le 15/11/2020 à 21:56, Éric Gillet a écrit :


La majorité des modifications dans osm utilise encore source=*. Osmose 
ajoute source=* et beaucoup de gens l'utilisent toujours.


Si mes calculs sont bons il y a :

64 millions de changesets (sur 93) ont un tag source.
213 millions d'objets (sur 7 milliards) ont un tag source

Ça me semble bien pencher vers l'usage des tags de changeset.

https://aws.amazon.com/fr/blogs/big-data/querying-openstreetmap-with-amazon-athena/ 



https://wiki.openstreetmap.org/wiki/Stats#Nodes.2C_ways_and_relations 



Bonjour,

Indiquer la source d'un changeset est tout à fait insuffisant pour 
assurer une bonne traçabilité d'OSM. En effet, il est rare qu'on utilise 
une seule source dans un changeset, à moins que celui-ci soit très petit.


Par exemple, j'ajoute un bâtiment: la source sera peut-être une imagerie 
aérienne, peut-être le cadastre. Il s'agit d'une chapelle ? La source 
sera mon observation.
Je modifie un chemin: la source sera peut-être une trace GPS,le cadastre 
ou l'imagerie aérienne...


L'indication exclusive de la source sur le changeset n'est qu'un 
pis-aller, destiné à simplifier la tâche des contributeurs. On peut 
éventuellement s'en dispenser mais il ne faut pas inciter les 
contributeurs à ne plus indiquer les sources dans l'objet, et encore 
moins à les supprimer lorsqu'elles existent.


Dans le cas de l'importation dont on discute ici, je suggère de mettre 
source:opening_hours=datanova.laposte.fr (ou équivalent) sur chaque 
bureau de poste modifé.


Jean-Claude

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

Re: [talk-cz] Elektrické nabíjecí stanice pro auta

[petr . kadlec]

> Nabíječkám bych jméno vůbec nedávala. Výjimkou jsou samozřejmě případy,
> kdy to opravdu svoje vlastní jméno má. Jen o žádné takové po okolí nevím.
>

+1. Tohle je ostatně velmi častá chyba, že se do name dává jakékoli
označení či popis toho elementu či dokonce jeho typu. name=potraviny,
name=hřiště atd. To nemusíte psát, to přece vidím!

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

Re: [Talk-it] Reggio nell'Emilia o Reggio Emilia

[Damjan Gerl]

Hm... difficile da scegliere. Sicuramente metterei questi due:

official_name=Reggio nell'Emilia
short_name=Reggio Emilia

per il name vero e proprio non saprei. Anche nello statuto nella prima pagina 
come titolo è usato il nome Reggio Emilia, nel logo anche, quindi non si 
capisce quale sia veramente il nome ufficiale...
Comunque alla fine io sarei più propenso ad usare il nome corto, ampiamente più 
usato.

Damjan

-- Original Header ---

From  : "Lorenzo Beltrami" lorenzo.b...@gmail.com
To  : "openstreetmap list - italiano" talk-it@openstreetmap.org
Cc  : 
Date  : Mon, 16 Nov 2020 08:56:44 +0100
Subject : [Talk-it] Reggio nell'Emilia o Reggio Emilia

> Ciao lista,
> l'altro giorno un utente ha cambiato il tag name di "Reggio nell'Emilia" in
> "Reggio Emilia", più comune nel linguaggio corrente.
> Qua il changeset con la discussione iniziale:
> https://www.openstreetmap.org/changeset/94016817
> 
> Essendosi interessato alla questione anche sorcrosc e trattandosi di un
> capoluogo di provincia mi sembra più sensato discuterne qua in lista
> nazionale (anche perché io ci sono nato e ci vivo per cui la mia
> impressione potrebbe essere parziale).
> 
> Le proposte di tagging sono 2:
> 
> A. name=Reggio nell'Emilia
> alt_name=Reggio Emilia
> (questa è quella attuale)
> 
> B. name=Reggio Emilia
> official_name=Reggio nell'Emilia
> 
> Io sarei per la A. perché "Reggio nell'Emilia":
> 1. Non è soltanto il nome ufficiale (qua si trova lo statuto comunale:
> https://www.comune.re.it/retecivica/urp/regolamenti.nsf/PESDocumentID/7647BF8C7A086544C125688200568FDF?opendocument=Sttt)
> usato nei documenti (official_name), ma è anche:
> 1.1 Quello indicato dai cartelli stradali all'inizio del centro abitato (
> https://www.mapillary.com/map/im/JsGDzOkGmSd4P8hkYQPuAw,
> https://www.mapillary.com/map/im/g8LAy1w_Xq13--Ap0Xwf7w,
> https://goo.gl/maps/oR141boeVJs18WBx5)
> 1.2 Quello usato dall'Istat (http://dati.istat.it/Index.aspx?QueryId=18560)
> 1.3 Quello usato dalla Protezione Civile (
> https://raw.githubusercontent.com/pcm-dpc/COVID-19/master/dati-province/dpc-covid19-ita-province.csv)
> 
> 2. Dal punto di vista più "OSM è un database" non credo sia così utile
> cambiare il nome di un capoluogo di provincia che è sempre stato così fin
> dall'inizio (https://osmlab.github.io/osm-deep-history/#/node/69300019). Se
> qualche vendor già lo usa per integrare servizi potrebbe "scassarsi"
> qualcosa...
> 
> La B. è data dal fatto che:
> 1. "Reggio Emilia" è il nome più comune a livello colloquiale
> 2. Nelle indicazioni viene indicato come "Reggio E."
> 3. Viene usato come abbreviazione anche dal comune stesso. Anche nel sito
> internet ufficiale: https://www.comune.re.it/
> 
> In ultimo una comparazione con l'altra Reggio, Reggio Calabria, che su OSM
> ha nel name "Reggio di Calabria" e in alt_name "Reggio Calabria" come la
> proposta A.: https://www.openstreetmap.org/node/67273280
> 
> Bonus: l'editor di default iD usa il campo wikidata o wikipedia come fonte
> per i testi da mettere in name. Questo è rilevante perché su Wikipedia il
> cambio è stato fatto l'anno scorso (a quanto pare senza una discussione
> sufficiente:
> https://it.wikipedia.org/wiki/Discussione:Reggio_Emilia#Spostamento_a_Reggio_Emilia)
> e ora iD mette "Reggio Emilia" nel name.
> Da allora ci sono stati gli unici tentativi di cambiare name (anche se lo
> scopo del primo tentativo era legato al cattivo rendering di GraphHopper,
> così mi disse l'utente).
> 
> Voi che ne pensate?
> 
> Saluti
> Lorenzo (NonnEmilia)
> 

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

Re: [Talk-it] Key:surface e porfido/basoli/pietre

[Alessandro Sarretta]

Ciao Fabio,

On 15/11/20 21:04, Fabio Bettani wrote:
Grazie a entrambi! Ho riletto le discussioni del 2012 e... in parte ho 
capito meglio. (solo in parte ;-) )


Ai fini di StreetComplete, mi potrei fare portavoce di una proposta di 
modifica della traduzione italiana, per eliminare le diciture attuali 
che sono state causa parziale della mia confusione.
Per paving_stones, al posto di "pavimentato a pietre", proporrei 
"pietre lisce regolari (o piastrelle)".
Per sett, al posto di "bolognini" proporrei "pietre discontinue" o 
"pietre sconnesse".


Vi sembrano descrizioni sensate?
Questo permetterebbe per lo meno di evitare che qualcuno contribuisca 
in buona fede tramite StreetComplete inserendo valori di surface che 
non corrispondono al loro significato reale.


Sul pavè di Milano, oggettivamente la situazione è meno chiara... (tra 
l'altro, la soluzione milanese_paving ha senso, ma mi sembra che anche 
a Roma non manchino pavimentazioni simili...)


Vedo che l'uso di cobblestone:flattened non ha molti consensi, e c'è 
chi argomenta che è equivalente a sett:

https://github.com/westnordost/StreetComplete/issues/728

Se però per coerenza almeno all'interno di Milano si è scelto di 
tenere cobblestone:flattened, non ho problemi a usarlo, anche se vedo 
che attualmente non è tra i valori più diffusi per surface= (è al 31° 
posto: https://taginfo.openstreetmap.org/keys/surface#values)


allora, sicuramente le attuali definizioni non sono molto 
standardizzate, ma personalmente suggerirei di usare la key /surface/ 
per il tipo di superficie, e la key /smoothness/ per il grado di rugosità.


In questo senso, /sett/ sono cubetti di materiale, porfido o basalto, la 
cui superficie è naturalmente poco liscia, ma dipende anche da come sono 
sistemate le fughe. /paving_stones/ invece sono pietre (generalmente 
artificiali, ma anche naturali) con la parte superiore piatta. Di solito 
sono più lisce e con fughe minime, ma anche qui la rugosità dipende dal 
materiale e anche dall'usura. In questo senso ci può essere un 
paving_stones con smoothness migliore di asphalt, ad es. oppure magari 
anche un sett più liscio di un paving_stones molto usurato.


Quindi per me non ci sono in genere molti dubbi nel differenziare sett 
da paving_stone e non mi focalizzarei tanto sulla larghezza della fuga 
tra gli elementi. L'esempio di Bologna che hai linkato da Mapillary per 
me è senza ombra di dubbio paving_stones.


Per la traduzione da mettere in Street complete in effetti è più 
difficile rendere in due parole la differenza. "Pietre lisce regolari" 
mi sembra vada bene. Per sett invece magari "Cubetti irregolari di 
roccia (porfido o basalto)" o qualcosa del genere.


Riguardo a /cobblestone:flattened/, anche secondo me ha poco senso. Per 
il ciottolato (sassi rotondeggianti) si usa unhewn_cobblestone: 
https://wiki.openstreetmap.org/wiki/Tag:surface%3Dunhewn_cobblestone


m2c

Ale


--
Fabio


Il giorno gio 12 nov 2020 alle ore 20:31 Martin Koppenhoefer 
mailto:dieterdre...@gmail.com>> ha scritto:




sent from a phone

> On 12. Nov 2020, at 18:40, Fabio Bettani
mailto:fabio.bett...@gmail.com>> wrote:
>
> O vi sembra che, tra le due, questo sia comunque un caso di
sett, e che il concetto di "paving_stones" sia adatto
esclusivamente alle pavimentazioni iper-regolari


con paving_stones si intende una pavimentazione liscia (che non
crea problemi per bici, per gli skates invece forse sì), quella di
Bologna potrebbe ricadere in questo caso (non conosco bene,
giudicando della foto).

Cheers Martin


___
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