Re: [Talk-it] foot=yes su strade con marciapiede

[solitone]

> On 16 Jul 2019, at 21:05, Volker Schmidt  wrote:
> 
> La possibilità di buon routing pedonale, per ciclisti, e per diversamente 
> abili, distingue OSM dalla competizione. 
> In questo senso routing è un criterio molto importante nelle decisioni come 
> mappare.

Questo è vero, ma io mi riferivo specificamente all’uso di "foot=yes”: è un tag 
che si riferisce a un diritto di accesso, ma qui viene utilizzato per informare 
l’algoritmo di routing. Non sarebbe meglio avere dei tag specifici per il 
routing?
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] question limite nb vues switch to osm

[marc marc]

Le 16.07.19 à 15:38, Frédéric Rodrigo a écrit :
> Le 16/07/2019 à 07:44, Laurence P a écrit :
>>
>> Bonjour,
>>
>> lorsque je tombe sur un site web _français_ qui propose une carte 
>> Google hors service (du fait que le site en question n'ait pas payé 
>> son obole à Google), je leur envoie en général un email pour leur 
>> conseiller de passer à OpenStreetMap.
>>
>> À partir de quel nombre de vues est-il judicieux de les orienter vers 
>> https://switch2osm.org/fr/ ? Je sais qu'il y a les limites fixées par 
>> la fondation OSM... mais qui dépend du trafic total OSM qui lui varie, 
>> je demande juste une grosse fourchette :)
>>
>> Par exemple, dernier site repéré :
>>
>> https://www.chateauvillandry.fr/preparez-votre-visite/les-informations-pratiques/les-tarifs-les-horaires-les-acces/
>>  
>>
>>
>> Merci d'avance de vos réponse.
>>
> 
> De premier abord je pense que les sites qui n'ont pas prit le soin de 
> corriger leur carto doivent être plus ou moins à l'abandon. Je ne sais 
> pas si tu as déjà eu des retours (positif ou non) à tes démarches.
> 
> Ensuite switch2osm est peu à l'abandon, et la version française 
> totalement à l'abandon.
> 
> Je trouve même gênant que la version française existe, en particulier 
> pour la partie serveur de tuiles qui en plus de ne pas être à jour 
> détaille une procédure compliqué. Il existe vraiment des solutions plus 
> simple aujourd'hui.

fred tu as une doc + simple a conseiller ? on peux leur proposer des PR :)

Laurence pour la limite du nombre de tuile, osm.org reste assez vague,
à mes yeux pour éviter qu'un site ne "joue" avec la limite.
je pense cependant que l'exemple que tu décris est vraiment loin
de risquer un abus.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Désignation des supermarchés "Intermarché Super"

[marc marc]

Le 15.07.19 à 15:57, Luc Novales a écrit :
> Le 15/07/2019 à 14:29, marc marc a écrit :

>> iD propose 2 choses :
>>
>> - l'ajout de brand brand:wikipedia brand:wikidata, infos obtenue
>> depuis le projet renseigné par Andrien. est-ce correct ? cela semble.
>>
>> - le changement du name : je comprend pas. selon wikipedia:
>> "Intermarché Super pour la plupart des magasins, environ 2 000 m2"
>> une station d'essence ne me semble pas correspondre à cela.
>> n'y aurait-il pas confusion avec le supermarché à l'autre bout
>> du parking ?
> 
> Petit scarabé, je vais peut être dire des bêtises, mais...
> 
> La station étant celle du supermarché, d'après ce que j'ai lu, il est 
> possible de référencer soit en déclarant une zone pour l'enceinte du 
> magasin, 

je pense que c'est pas courant de mettre un name=* sur un objet
qui inclu magasin+parking+station d'esence+petit magasin
vu que ces objets n'ont pas le même nom
tu peux mettre un landuse, mais le name=* perso j'évite.

> puis en détaillant les bâtiments en fonction de leur 
> utilisation, soit en faisant plusieurs points ou bâtiments séparés.

tout a fait. ce qui dans ce cas revient au même pour les 2 options :
l'essence ne se vend pas dans le petit magasin mais dehors,
pour preuve quand le petit magasin est fermé, on peux quand même
acheter de l'essence par carte.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Taguer une place

[marc marc]

Le 13.07.19 à 13:35, deuzeffe a écrit :
> Rue/voies qui ont le même name= que la place. Donc on doublonne ?
si on veux l'éviter, on peux renseigner le nom sur l'un (la place)
et mettre un noname=yes sur l'autre (la rue).
qu'en penses les autres ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Horaires des stations services

[marc marc]

Bonjour,

la caisse de jour est différente de celle du magasin ?

j'aurais fais 3 objets :
- un pour le lavage payement uniquement par ticket/carte de lavage.
- un pour le station d'essence, 24/7, en précisant les moyens de 
payement, sans y reneigner ce qui se vend dans le magasin.
- un pour le magasin avec vente de gpl+gaz
je crains cependant qu'il n'y ai pas de tag bien définit pour faire
la différence entre le payement en billet à un automate qui scannes
les billets et le payement en billet à la caisse du magasin

Cordialement,
Marc

Le 15.07.19 à 16:27, Luc Novales a écrit :
> Bonjour,
> 
> J'aurai aimé savoir si des conventions ont été définies pour les cas un 
> peu tordus au niveau des horaires comme les stations services. Beaucoup 
> sont déclarées ouvertes 24/7 alors qu'il n'y a qu'un accès à un automate 
> par carte bancaire (pas tous les paiements) et qui ne touche pas tous 
> les produits.
> 
> Un cas d'école :
> 
> https://www.openstreetmap.org/way/84383719
> 
> Cette station distribue différents carburants dont le GPL n'est pas 
> accessible en dehors des heures d'ouverture du magasin qui vend aussi du 
> GAZ.
> 
> L'automate n'est qu'une petite partie de la station qui ne reprend pas 
> la vente, et pour le lavage ce sont des conditions météorologiques qui 
> fixent le fonctionnement. Dans le détail :
> 
> *Automate* (tous carburants sauf GPL) : ouverture 24/7
> 
> *Magasin* : 6h30 - 22h00 (sauf exceptions : certains jours fériés ou 
> manque de personnel)^(1 <#Note1>)
> 
> *Vente de GAZ* : uniquement en *horaire* de la *caisse de jour* 
> (basculement en caisse de nuit 1 heure avant la fermeture)
> 
> *GPL* : heures d'ouverture du magasin
> 
> *Lavage automatique* : Vente de tickets et cartes de lavage aux heures 
> d'ouverture du magasin, mais accès à l'automate quelle que soit l'heure 
> dès lors que la température est supérieure à 4°C.
> 
> 
> Doit-on considérer que la station est ouverte 24/7 et faire les 
> exceptions pour tout le reste ou doit on considérer que la station est 
> ouverte uniquement pendant l'ouverture du magasin et faire presque 
> autant d'exceptions ?
> 
> Pour l'instant, je n'ai mis qu'une exception sur le GPL, mais si on 
> répond à tout ça j'aurais bien avancé ;-)
> 
> Luc.
> 
> 
> Note 1 <#RetNote1> : Cet hiver, la station a eu une période de fermeture 
> à 21h00 mais ce n'est pas une pratique récurrente.
> 
> 
> ___
> 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-de] Einladung zum 13. FOSSGIS-OSM-Hackingevent im Linuxhotel

[Oliver Rudzick]

Hallo allerseits,

 am ersten Adventswochenende vom 29.11.-01.12.2019 findet das
 FOSSGIS-OSM-Hackingevent Nr. 13 [1] im Linuxhotel in Essen statt:

 https://www.fossgis.de/wiki/FOSSGIS_Hacking_Event_2019_Nummer_13

 Das Linuxhotel mit seiner guten technischen Ausstattung und
 dem parkähnlichen Grundstück mit Panoramablick auf die Ruhr
 bietet einen idealen Rahmen für kreatives Arbeiten und
 produktiven Austausch in lockerer, ungezwungener Atmosphäre.

 Das Treffen kann vielfältig genutzt werden.

 Communities und Interessierte aus OpenStreetMap-Projekten sowie
 freien GIS- und Geodaten-Projekten können das Wochenende nutzen,
 um die Arbeit voranzubringen.

 FOSSGIS Aktive können das Wochenende als Arbeitswochenende
 für Vereinsaufgaben nutzen, Vorbereitung von Veranstaltungen
 (FOSSGIS-Konferenz 2020), IT, Öffentlichkeitsarbeit, Messen usw.

 Es stehen 25 Hotelbetten für uns bereit.

 Bitte tragt Euch und falls vorhanden Euer Projekt oder Eure Idee,
 die Ihr umsetzen wollt, im Wiki ein:

 
https://www.fossgis.de/wiki/FOSSGIS_Hacking_Event_2019_Nummer_13#Teilnehmerliste

 Weitere Ideen und Anregungen zur Ausgestaltung sind gerne gesehen und
 werden bestimmt aufgegriffen.

 Wir freuen uns auf ein gemeinsames FOSSGIS Hackingevent im Linuxhotel!

 Viele Grüße

 Oliver

 [1] https://www.fossgis.de/wiki/FOSSGIS_Hacking_Events

 Bericht vom FOSSGIS Hackingevent Nr. 12:
 https://www.fossgis.de/node/332




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

Re: [OSM-talk] handling street names in speech

[Andrew Errington]

I think this is a rendering issue (i.e. rendering speech instead of
graphics) and as such does not belong in OSM.

The work to convert an arbitrary string into speech belongs in the TTS
engine.

If we start putting IPA strings in OSM then we will start getting arguments
about the "correct" pronunciation. At the very least it is tagging for the
renderer, which we should avoid.

IMHO, of course.

Andrew

On Wed, Jul 17, 2019, 09:20 Greg Troxel  wrote:

> John Whelan  writes:
>
> > One or two are problematic usually as the street name is an
> > abbreviation.For example 1e Avenue in French meaning First Avenue.
> >
> > Any suggestions on how these should be handled?  This particular
> > application is aimed at partially sighted people but I feel we should
> > be able to come up with a generic solution.
>
> Two comments:
>
>   osm norms are to expand abbreviations, as I understand it.  So that
>   should be fixed first
>
>   Even after that, we have ref tags, and there is often a road whose ref
>   is something like "CT 2", "US 1", or "I 95".  I don't really think
>   this should be expanded in the database.  Instead, what's needed is a
>   table in the application, perhaps centrally maintained in OSM, of how
>   to pronounce standardize ref abbreviations.  Putting phonetics of
>   "connecticut" on all use of CT or the expanded name is not reasonable.
>
>
> But I agree this needs help.  I get told to turn on "Court 2" and "Ma
> 2".  Luckily I understand this by now and it actually works ok.  But it
> does need fixing.
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk-fr] Import vectoriel d'éléments de cadastre depuis JOSM + documentation

[Baptiste Jonglez]

Salut,

Jusqu'ici, j'importais les bâtiments du cadastre « à la main », en
affichant la couche cadastre dans JOSM et en reproduisant le tracé des
bâtiments en créant les points et polygones moi-même.

Hors, dans les slides de la présentation de Vincent Privat au dernier
SOTM [1], j'ai découvert une méthode bien plus efficace avec le plugin
cadastre-fr, qui permet d'importer une zone en vectoriel et de copier des
bâtiments choisis vers la couche OSM ! (page 16 des slides)

Sauf erreur de ma part, ce n'est documenté nulle part sur le wiki : j'ai
raté quelque chose ?  Les seules choses que j'ai trouvé, c'est :

- le point d'entrée supposé pour le cadastre [2], que je trouve
  relativement peu lisible

- un autre point d'entrée [3] que je trouve bien plus intéressant

- une description de la méthode « à la main » que j'utilisais jusqu'ici [4]

- une méthode d'import semi-automatique à grande échelle [5], qui est
  assez complexe et pas du tout adaptée quand on veut juste importer un ou
  deux bâtiments

- plein de méthodes d'import super complexes que je n'ai pas comprises [6]

- des détails techniques encore plus poussés [7], mais qui j'imagine n'ont
  pas vocation à être utilisés par un « simple » contributeur.

D'où ma (mes) question(s) : si je veux rajouter de la doc sur la méthode
facile dans josm, je mets ça où ?  Et est-ce qu'il n'y aurait pas du
ménage à faire dans toute cette documentation, pour archiver ce qui est
obsolète ?

Merci,
Baptiste

[1] 
https://nextcloud.openstreetmap.fr/index.php/s/xzAqyacaJWsnXNZ/download?path=%2F=SOTMFR2019-67-ce-qui-se-cache-derriere-JOSM-(Privat).pdf
[2] https://wiki.openstreetmap.org/wiki/FR:WikiProject_France/Cadastre
[3] 
https://wiki.openstreetmap.org/wiki/WikiProject_Cadastre_Fran%C3%A7ais/Import_dans_OSM
[4] 
https://wiki.openstreetmap.org/wiki/WikiProject_France/Tracer_des_b%C3%A2timents
[5] 
https://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_b%C3%A2timents
[6] https://wiki.openstreetmap.org/wiki/FR:JOSM/Greffons/Cadastre-fr
[7] 
https://wiki.openstreetmap.org/wiki/WikiProject_Cadastre_Fran%C3%A7ais/Aspects_techniques_du_cadastre_en_ligne


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

Re: [Talk-at] Zweiter Benutzer von addresshistory*org mit edits?

[Rainer Fügenstein]

On 16/07/2019 23:04, Johann Haag wrote:


Urlaubsgrüsse aus Irland.


hat schon jemand die irischen kollegen gewarnt?


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

[Talk-GB] Automated Code-Point Open postcode editing (simple cases only)

[ndrw6]

Hi,

Over past several months I've been adding postcodes from Code-Point 
Open. I've streamlined the procedure a bit, so I can now add the tags 
without spelling out every single one of them, but it is still a manual 
and labour intensive process:


https://github.com/ndrw6/import_postcodes/

While working on that, I've noticed there are a lot of simple cases 
where automatic collation would have produced very similar results. For 
example, in case of existing OSM buildings without an addr:postcode tag 
located at or very near to a Code-Point Open centroid.


Therefore I'm requesting permission to use the following automated edit 
procedure:


1. Open an osm file containing missing postcodes (from the above 
website) in jOSM


1a. Select all points from the above dataset

2. Download OSM data in the area of interest

2a. Select all ways with a "building" tag of typical residential house 
size and without an "addr:postcode" tag (search phrase: 'building 
-"addr:postcode" type:way areasize:50-1000')


3. Use a collation plugin to collate both datasets with "centroid 
distance" set to "< 15m". The condition is there to apply postcodes only 
to small buildings in direct vicinity of the codepoint centroid.


There are some caveats I've noticed, often not different from manual 
editing:


a) Some buildings have addresses added as separate points rather than 
tags (automated edit will add addr:postcode tags directly to the 
building, this is what I chose to do manually as well)


b) Collation plugin doesn't support relations (these postcodes will get 
ignored and can be added later manually)


c) Often OSM buildings contain multiple addresses or postcodes and 
should be split into several buildings or building parts. This affects 
both manual and automated procedure, to minimize the impact I am setting 
relatively small "centroid distance" and building area limits.


Best regards,

ndrw6



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

Re: [OSM-talk] handling street names in speech

[Greg Troxel]

John Whelan  writes:

> One or two are problematic usually as the street name is an
> abbreviation.    For example 1e Avenue in French meaning First Avenue.
>
> Any suggestions on how these should be handled?  This particular
> application is aimed at partially sighted people but I feel we should
> be able to come up with a generic solution.

Two comments:

  osm norms are to expand abbreviations, as I understand it.  So that
  should be fixed first

  Even after that, we have ref tags, and there is often a road whose ref
  is something like "CT 2", "US 1", or "I 95".  I don't really think
  this should be expanded in the database.  Instead, what's needed is a
  table in the application, perhaps centrally maintained in OSM, of how
  to pronounce standardize ref abbreviations.  Putting phonetics of
  "connecticut" on all use of CT or the expanded name is not reasonable.


But I agree this needs help.  I get told to turn on "Court 2" and "Ma
2".  Luckily I understand this by now and it actually works ok.  But it
does need fixing.


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

Re: [Talk-at] Zweiter Benutzer von addresshistory*org mit edits?

[Johann Haag]

Ich muss mich entschuldigen. Ich habe meine Roccat Tyon Maus im Reisegepäck, 14 
Gb Roaming Guthaben bereits gebucht, aber nun festgestellt dass ich meinen 
Laptop zuhause vergessen habe.
Das bedeutet für mich nun, drei Wochen Mapping Pause. Ich hoffe ich gehe Euch 
nicht ab.
Lg Johann

Von meinem iPhone gesendet

> Am 16.07.2019 um 22:04 schrieb Johann Haag :
> 
> Lese gerade belustigt Eure Theorien,
> Urlaubsgrüsse aus Irland.
> Ja das war ich... das Delete in Tirol ein Versehen.
> Lg
> 
> Von meinem iPhone gesendet
> 
>> Am 16.07.2019 um 08:37 schrieb vari...@mailbox.org:
>> 
>> Es gibt offensichtlich einen neuen Benutzer, der oft nichts anderes macht, 
>> als den Tag at_bev:addr_date=2019-04-01 zu löschen. Wurde auch gefragt, 
>> warum er das gemacht hat ohne Antwort: 
>> https://www.openstreetmap.org/changeset/72163441 weiter Beispiele z. B. 
>> https://www.openstreetmap.org/node/6468524050/history und 
>> https://www.openstreetmap.org/node/6468524046/history  und erzeugt somit aus 
>> vielen importierten Adressen eine v2. 
>> 
>> Bei diesem Changeset von Landeskarte hat auch dann addresshistory 
>> weiterkommentiert: https://www.openstreetmap.org/changeset/71428706 Im Blog 
>> ist auf einen ziemlich netten Hinweis auch eher pampig 
>> https://www.openstreetmap.org/user/Landeskarte/diary/43306 
>> http://whosthat.osmz.ru/  Eine Whoisabfrage nach "landeskarte" und nach 
>> "addresshistory*" gehen beide auf geocodec zurück. 
>> 
>> Während natürliche mehrere Accounts erlaubt sind, widerspricht das "mal den 
>> Tag mit BEV löschen" meiner Meinung nach Sachen. Änderung ohne Verbesserung, 
>> der Lizenzhinweis geht verloren (Adresse immerhin per Datensatz reingeholt 
>> und nicht per survey) und es wirkt, als wollte er dem "nur v1 löschen" 
>> entgehen. 
>> https://wiki.openstreetmap.org/wiki/OpenStreetMap_account#Account_Names_and_Multi_Account_Policies
>> 
>> Was wird hier auf der Liste von solchen Edits bzw. Zweitaccounts gehalten? 
>> z. B. für Imports wird das ja klar gefordert und sollte dann aber auch klar 
>> kommuniziert werden und beides ist nicht der Fall.
>> ___
>> Talk-at mailing list
>> Talk-at@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-at
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Zweiter Benutzer von addresshistory*org mit edits?

[Johann Haag]

Lese gerade belustigt Eure Theorien,
Urlaubsgrüsse aus Irland.
Ja das war ich... das Delete in Tirol ein Versehen.
Lg

Von meinem iPhone gesendet

> Am 16.07.2019 um 08:37 schrieb vari...@mailbox.org:
> 
> Es gibt offensichtlich einen neuen Benutzer, der oft nichts anderes macht, 
> als den Tag at_bev:addr_date=2019-04-01 zu löschen. Wurde auch gefragt, warum 
> er das gemacht hat ohne Antwort: 
> https://www.openstreetmap.org/changeset/72163441 weiter Beispiele z. B. 
> https://www.openstreetmap.org/node/6468524050/history und 
> https://www.openstreetmap.org/node/6468524046/history  und erzeugt somit aus 
> vielen importierten Adressen eine v2. 
> 
> Bei diesem Changeset von Landeskarte hat auch dann addresshistory 
> weiterkommentiert: https://www.openstreetmap.org/changeset/71428706 Im Blog 
> ist auf einen ziemlich netten Hinweis auch eher pampig 
> https://www.openstreetmap.org/user/Landeskarte/diary/43306 
> http://whosthat.osmz.ru/  Eine Whoisabfrage nach "landeskarte" und nach 
> "addresshistory*" gehen beide auf geocodec zurück. 
> 
> Während natürliche mehrere Accounts erlaubt sind, widerspricht das "mal den 
> Tag mit BEV löschen" meiner Meinung nach Sachen. Änderung ohne Verbesserung, 
> der Lizenzhinweis geht verloren (Adresse immerhin per Datensatz reingeholt 
> und nicht per survey) und es wirkt, als wollte er dem "nur v1 löschen" 
> entgehen. 
> https://wiki.openstreetmap.org/wiki/OpenStreetMap_account#Account_Names_and_Multi_Account_Policies
> 
> Was wird hier auf der Liste von solchen Edits bzw. Zweitaccounts gehalten? z. 
> B. für Imports wird das ja klar gefordert und sollte dann aber auch klar 
> kommuniziert werden und beides ist nicht der Fall.
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-it] Depuratore

[scratera]

...per come la vedo io è a tutti gli effetti un depuratore chiuso come ce ne
sono molti in giro non necessariamente sono all'aperto 

https://www.theplan.it/images/stories/gallery48707/06.jpg

..quindo come tale metterei bulding=yes
man_made=wastewater_plant



--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

Re: [Talk-it] foot=yes su strade con marciapiede

[Volker Schmidt]

La possibilità di buon routing pedonale, per ciclisti, e per diversamente
abili, distingue OSM dalla competizione.
In questo senso routing è un criterio molto importante nelle decisioni come
mappare.

On Tue, 16 Jul 2019, 20:55 solitone via Talk-it, 
wrote:

>
> > On 16 Jul 2019, at 16:18, Volker Schmidt  wrote:
> >
> > Per motivi di routing pedonale è giusto che la strada porti un foot=yes,
> ma anche questo manca spesso, ma i casi sono in aumento, grazie a iD.
>
> Non conosco i dettagli del problema, ma il mio primo pensiero è stato:
> "mappare per il routing" non assomiglia a "mappare per il rendering"?
> ___
> 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] foot=yes su strade con marciapiede

[solitone via Talk-it]

> On 16 Jul 2019, at 16:18, Volker Schmidt  wrote:
> 
> Per motivi di routing pedonale è giusto che la strada porti un foot=yes, ma 
> anche questo manca spesso, ma i casi sono in aumento, grazie a iD.

Non conosco i dettagli del problema, ma il mio primo pensiero è stato: "mappare 
per il routing" non assomiglia a "mappare per il rendering"?
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk] handling street names in speech

[Colin Smale]

On 2019-07-16 19:52, Jo wrote:

> If we were to make such exceptions, we would get into trouble really fast, as 
> some streets are signed differently on one end and on the other, depending 
> how big the street sign is, or in what period it was put there.

Don't shoot the messenger, I didn't write the wiki! 

> Expanding abbreviations is the norm. I try to do it even for first and middle 
> names of people, when the street is named after a person. That only works if 
> it's possible to find it somewhere, of course.

Apparently not everyone agrees with you, otherwise those exceptions
would not be noted in the wiki. Are you recommending that the exceptions
be removed from the wiki? 

> Polyglot 
> 
> On Tue, Jul 16, 2019 at 7:40 PM Colin Smale  wrote: 
> 
> On 2019-07-16 19:07, Nuno Caldeira wrote: 
> also on the the standard mapping convetions, its mentioned in bold : 
> 
> DON'T USE ABBREVIATIONS
> 
> https://wiki.openstreetmap.org/wiki/Editing_Standards_and_Conventions 
> 
> But exceptions are made in some cases, including where the signage uses the 
> abbreviation: 
> 
> https://wiki.openstreetmap.org/wiki/Names#Abbreviation_.28don.27t_do_it.29 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] handling street names in speech

[Jo]

If we were to make such exceptions, we would get into trouble really fast,
as some streets are signed differently on one end and on the other,
depending how big the street sign is, or in what period it was put there.

Expanding abbreviations is the norm. I try to do it even for first and
middle names of people, when the street is named after a person. That only
works if it's possible to find it somewhere, of course.

Polyglot

On Tue, Jul 16, 2019 at 7:40 PM Colin Smale  wrote:

> On 2019-07-16 19:07, Nuno Caldeira wrote:
>
> also on the the standard mapping convetions, its mentioned in bold :
>
> Don't use abbreviations
> https://wiki.openstreetmap.org/wiki/Editing_Standards_and_Conventions
>
>
>
> But exceptions are made in some cases, including where the signage uses
> the abbreviation:
>
> https://wiki.openstreetmap.org/wiki/Names#Abbreviation_.28don.27t_do_it.29
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-at] Zweiter Benutzer von addresshistory*org mit edits?

[gppes_osm--- via Talk-at]

Ich hatte es schon im CS-Kommentar geschrieben, diese "at_bev:addr_date"-Edits 
von "Landeskarte" sind aus meiner Sicht zu revertieren. Auch wenn pro CS 
anscheinend "nur" einzelne hundert Nodes bearbeitet wurden: Wir haben derzeit 
einfach zu viele undiskutierte mechanische Edits im Staate Oesterreich...

Lg, Gppes

> Gesendet: Dienstag, 16. Juli 2019 um 09:37 Uhr
> Von: vari...@mailbox.org
> An: talk-at@openstreetmap.org
> Betreff: [Talk-at] Zweiter Benutzer von addresshistory*org mit edits?
>
> Es gibt offensichtlich einen neuen Benutzer, der oft nichts anderes macht, 
> als den Tag at_bev:addr_date=2019-04-01 zu löschen. Wurde auch gefragt, warum 
> er das gemacht hat ohne Antwort: 
> https://www.openstreetmap.org/changeset/72163441 weiter Beispiele z. B. 
> https://www.openstreetmap.org/node/6468524050/history und 
> https://www.openstreetmap.org/node/6468524046/history  
> https://www.openstreetmap.org/node/6468524046/history und erzeugt somit aus 
> vielen importierten Adressen eine v2.
> 
> Bei diesem Changeset von Landeskarte hat auch dann addresshistory 
> weiterkommentiert: https://www.openstreetmap.org/changeset/71428706 Im Blog 
> ist auf einen ziemlich netten Hinweis auch eher pampig 
> https://www.openstreetmap.org/user/Landeskarte/diary/43306 
> http://whosthat.osmz.ru/  http://whosthat.osmz.ru/ Eine Whoisabfrage nach 
> "landeskarte" und nach "addresshistory*" gehen beide auf geocodec zurück.
> 
> Während natürliche mehrere Accounts erlaubt sind, widerspricht das "mal den 
> Tag mit BEV löschen" meiner Meinung nach Sachen. Änderung ohne Verbesserung, 
> der Lizenzhinweis geht verloren (Adresse immerhin per Datensatz reingeholt 
> und nicht per survey) und es wirkt, als wollte er dem "nur v1 löschen" 
> entgehen. 
> https://wiki.openstreetmap.org/wiki/OpenStreetMap_account#Account_Names_and_Multi_Account_Policies
> 
> Was wird hier auf der Liste von solchen Edits bzw. Zweitaccounts gehalten? z. 
> B. für Imports wird das ja klar gefordert und sollte dann aber auch klar 
> kommuniziert werden und beides ist nicht der Fall.
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
>

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

Re: [OSM-talk] handling street names in speech

[Colin Smale]

On 2019-07-16 19:07, Nuno Caldeira wrote:

> also on the the standard mapping convetions, its mentioned in bold : 
> 
> DON'T USE ABBREVIATIONS
> 
> https://wiki.openstreetmap.org/wiki/Editing_Standards_and_Conventions

But exceptions are made in some cases, including where the signage uses
the abbreviation: 

https://wiki.openstreetmap.org/wiki/Names#Abbreviation_.28don.27t_do_it.29___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] handling street names in speech

[Jo]

When using OsmAnd in the streets of Brussels, it doesn't matter what the
language is set to, the French - Dutch combo is consistently pronounced
wrongly.

IPA would indeed solve that.

Editor support would be very welcome to enter the proper characters and to
listen to the result, both in JOSM and iD. And maybe even to help mappers
get started with the most likely pronunciation for a given language.

It would need to be used for ALL tags that contain names, not only the ones
that have 'deviant' pronunciation. In a mutlilingual system it's almost
impossible to define what is and what isn't 'deviating', as the
pronunciation rules are different across almost all languages.

For JOSM, should I propose this as GSoC project for next summer, or would
it not be that hard to implement by our overworked core developers? Or
would it make sense I
give it a go myself?

Polyglot

On Tue, Jul 16, 2019 at 7:10 PM Nuno Caldeira 
wrote:

> also on the the standard mapping convetions, its mentioned in bold :
>
> Don't use abbreviations
>
> https://wiki.openstreetmap.org/wiki/Editing_Standards_and_Conventions
>
> A terça, 16/07/2019, 18:05, Stefan Baebler 
> escreveu:
>
>> I think IPA (
>> https://en.m.wikipedia.org/wiki/International_Phonetic_Alphabet ) would 
>> address
>> that problem, but that would require many more tags, which are not trivial
>> for mappers to write.
>>
>> Br,
>> Štefan
>>
>>
>> V tor., 16. jul. 2019 17:55 je oseba Colin Smale 
>> napisala:
>>
>>> The reason for wanting to expand abbreviations in OSM is surely to avoid
>>> ambiguity, not specifically to aid pronunciation or recognition. In the
>>> case of "1e ..." in a certain language context, would that not be
>>> unambiguous? Would a speech synthesiser not know how it should be spoken in
>>> its working language?
>>>
>>> Slight digression: The question does arise of which rules to use to
>>> pronounce foreign names. If I am in Warsaw for example and my satnav
>>> started pronouncing street names in pure Polish I might not recognise any
>>> of them (apologies to any Poles in the audience). But how would it speak
>>> such that I would recognise it, if I was looking for a string with loads of
>>> Ws and Zs that means nothing to me? Use English rules to pronounce a Polish
>>> word?
>>>
>>> On the other hand, if I was in Paris, I would expect it to use French
>>> rules, because I understand French and using English rules would sound
>>> weird although it might well give a lot of laughs...
>>>
>>>
>>>
>>> On 2019-07-16 17:36, John Whelan wrote:
>>>
>>> This approach I like.  Name:expanded perhaps?
>>>
>>> To go back to earlier ideas.
>>>
>>> Expanding the name sounds sensible but unfortunately the street signs
>>> are posted with the abbreviation and some local mappers have a what is on
>>> the sign goes in the map mentality.  Also we have had discussions about
>>> street names in Canada before and the decision was what the municipality
>>> declares the street name is correct.  That was to do with either "rue
>>> Sparks" or should it be "Rue Sparks" in Quebec it would be one way but in
>>> Ontario the other.
>>>
>>> Thoughts
>>>
>>> Thanks John
>>>
>>> Colin Smale wrote on 2019-07-16 11:30 AM:
>>>
>>> On 2019-07-16 16:54, John Whelan wrote:
>>>
>>> One or two are problematic usually as the street name is an
>>> abbreviation.For example 1e Avenue in French meaning First Avenue.
>>>
>>> Any suggestions on how these should be handled?  This particular
>>> application is aimed at partially sighted people but I feel we should be
>>> able to come up with a generic solution.
>>>
>>> Some kind of phonetic (IPA?) representation would be the ultimate
>>> generic solution. Here in NL (and I guess in many other countries) there
>>> are street names which are partially or entirely in other languages, and
>>> the expectation is that they are pronounced as such. For example, Boeing
>>> Avenue would sound completely weird if it were pronounced according to
>>> Dutch rules. Truly multi-lingual countries like Belgium and Switzerland
>>> should be able to make use of name:XX.
>>>
>>> If we had name:XX:ipa=* we would have a place to put it, but the client
>>> app would need to have a way of turning that into sounds. It will only be
>>> needed if the pronunciation deviates from the standard for the language in
>>> question, but speech synthesisers are never perfect and often make
>>> mistakes
>>>
>>>
>>> https://english.stackexchange.com/questions/264239/is-there-any-online-tool-to-read-pronounce-ipa-and-apa-written-words
>>>
>>> Of course we will also need a way of entering IPA symbols
>>>
>>>
>>>
>>>
>>> ___
>>> talk mailing 
>>> listtalk@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk
>>>
>>>
>>> --
>>> Sent from Postbox 
>>>
>>> ___
>>> talk mailing list
>>> talk@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-it] Depuratore

[liste DOT girarsi AT posteo DOT eu]

Il 16/07/19 18:30, Francesco Ansanelli ha scritto:
>> ciao, come mappo un edificio sul quale c'è una targhetta che recita:
>>
>> Depuratore Comune di XY
>>
>> ripeto, all'apparenza è un semplice edificio, esternamente non si vede
>> nient'altro che un edificio.
>>


mancando elementi definitivi, andrei di man_made=wastewaterplant,
building=yes.

Poi se sono uffici o altro, forse lo scoprirai più avanti.
sei un ottimo investigatore cartografico :D :D :D



-- 
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|
Simone Girardelli

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

Re: [OSM-talk] handling street names in speech

[Nuno Caldeira]

also on the the standard mapping convetions, its mentioned in bold :

Don't use abbreviations

https://wiki.openstreetmap.org/wiki/Editing_Standards_and_Conventions

A terça, 16/07/2019, 18:05, Stefan Baebler 
escreveu:

> I think IPA (
> https://en.m.wikipedia.org/wiki/International_Phonetic_Alphabet ) would 
> address
> that problem, but that would require many more tags, which are not trivial
> for mappers to write.
>
> Br,
> Štefan
>
>
> V tor., 16. jul. 2019 17:55 je oseba Colin Smale 
> napisala:
>
>> The reason for wanting to expand abbreviations in OSM is surely to avoid
>> ambiguity, not specifically to aid pronunciation or recognition. In the
>> case of "1e ..." in a certain language context, would that not be
>> unambiguous? Would a speech synthesiser not know how it should be spoken in
>> its working language?
>>
>> Slight digression: The question does arise of which rules to use to
>> pronounce foreign names. If I am in Warsaw for example and my satnav
>> started pronouncing street names in pure Polish I might not recognise any
>> of them (apologies to any Poles in the audience). But how would it speak
>> such that I would recognise it, if I was looking for a string with loads of
>> Ws and Zs that means nothing to me? Use English rules to pronounce a Polish
>> word?
>>
>> On the other hand, if I was in Paris, I would expect it to use French
>> rules, because I understand French and using English rules would sound
>> weird although it might well give a lot of laughs...
>>
>>
>>
>> On 2019-07-16 17:36, John Whelan wrote:
>>
>> This approach I like.  Name:expanded perhaps?
>>
>> To go back to earlier ideas.
>>
>> Expanding the name sounds sensible but unfortunately the street signs are
>> posted with the abbreviation and some local mappers have a what is on the
>> sign goes in the map mentality.  Also we have had discussions about street
>> names in Canada before and the decision was what the municipality declares
>> the street name is correct.  That was to do with either "rue Sparks" or
>> should it be "Rue Sparks" in Quebec it would be one way but in Ontario the
>> other.
>>
>> Thoughts
>>
>> Thanks John
>>
>> Colin Smale wrote on 2019-07-16 11:30 AM:
>>
>> On 2019-07-16 16:54, John Whelan wrote:
>>
>> One or two are problematic usually as the street name is an
>> abbreviation.For example 1e Avenue in French meaning First Avenue.
>>
>> Any suggestions on how these should be handled?  This particular
>> application is aimed at partially sighted people but I feel we should be
>> able to come up with a generic solution.
>>
>> Some kind of phonetic (IPA?) representation would be the ultimate generic
>> solution. Here in NL (and I guess in many other countries) there are street
>> names which are partially or entirely in other languages, and the
>> expectation is that they are pronounced as such. For example, Boeing Avenue
>> would sound completely weird if it were pronounced according to Dutch
>> rules. Truly multi-lingual countries like Belgium and Switzerland should be
>> able to make use of name:XX.
>>
>> If we had name:XX:ipa=* we would have a place to put it, but the client
>> app would need to have a way of turning that into sounds. It will only be
>> needed if the pronunciation deviates from the standard for the language in
>> question, but speech synthesisers are never perfect and often make
>> mistakes
>>
>>
>> https://english.stackexchange.com/questions/264239/is-there-any-online-tool-to-read-pronounce-ipa-and-apa-written-words
>>
>> Of course we will also need a way of entering IPA symbols
>>
>>
>>
>>
>> ___
>> talk mailing 
>> listtalk@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk
>>
>>
>> --
>> Sent from Postbox 
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] handling street names in speech

[Stefan Baebler]

I think IPA (https://en.m.wikipedia.org/wiki/International_Phonetic_Alphabet
) would address that problem, but that would require many more tags, which
are not trivial for mappers to write.

Br,
Štefan


V tor., 16. jul. 2019 17:55 je oseba Colin Smale 
napisala:

> The reason for wanting to expand abbreviations in OSM is surely to avoid
> ambiguity, not specifically to aid pronunciation or recognition. In the
> case of "1e ..." in a certain language context, would that not be
> unambiguous? Would a speech synthesiser not know how it should be spoken in
> its working language?
>
> Slight digression: The question does arise of which rules to use to
> pronounce foreign names. If I am in Warsaw for example and my satnav
> started pronouncing street names in pure Polish I might not recognise any
> of them (apologies to any Poles in the audience). But how would it speak
> such that I would recognise it, if I was looking for a string with loads of
> Ws and Zs that means nothing to me? Use English rules to pronounce a Polish
> word?
>
> On the other hand, if I was in Paris, I would expect it to use French
> rules, because I understand French and using English rules would sound
> weird although it might well give a lot of laughs...
>
>
>
> On 2019-07-16 17:36, John Whelan wrote:
>
> This approach I like.  Name:expanded perhaps?
>
> To go back to earlier ideas.
>
> Expanding the name sounds sensible but unfortunately the street signs are
> posted with the abbreviation and some local mappers have a what is on the
> sign goes in the map mentality.  Also we have had discussions about street
> names in Canada before and the decision was what the municipality declares
> the street name is correct.  That was to do with either "rue Sparks" or
> should it be "Rue Sparks" in Quebec it would be one way but in Ontario the
> other.
>
> Thoughts
>
> Thanks John
>
> Colin Smale wrote on 2019-07-16 11:30 AM:
>
> On 2019-07-16 16:54, John Whelan wrote:
>
> One or two are problematic usually as the street name is an
> abbreviation.For example 1e Avenue in French meaning First Avenue.
>
> Any suggestions on how these should be handled?  This particular
> application is aimed at partially sighted people but I feel we should be
> able to come up with a generic solution.
>
> Some kind of phonetic (IPA?) representation would be the ultimate generic
> solution. Here in NL (and I guess in many other countries) there are street
> names which are partially or entirely in other languages, and the
> expectation is that they are pronounced as such. For example, Boeing Avenue
> would sound completely weird if it were pronounced according to Dutch
> rules. Truly multi-lingual countries like Belgium and Switzerland should be
> able to make use of name:XX.
>
> If we had name:XX:ipa=* we would have a place to put it, but the client
> app would need to have a way of turning that into sounds. It will only be
> needed if the pronunciation deviates from the standard for the language in
> question, but speech synthesisers are never perfect and often make
> mistakes
>
>
> https://english.stackexchange.com/questions/264239/is-there-any-online-tool-to-read-pronounce-ipa-and-apa-written-words
>
> Of course we will also need a way of entering IPA symbols
>
>
>
>
> ___
> talk mailing 
> listtalk@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk
>
>
> --
> Sent from Postbox 
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-it] foot=yes su strade con marciapiede

[Francesco Ansanelli]

Buonasera Volker,

Sono d'accordo sul fatto che manca un sistema di controllo per verificare
se è presente il tag sidewalk=separate per le strade che si trovano in
prossimità di un marciapiede. Credo si possa sviluppare un plugin per
osmose, ammesso che sia considerato da tutti come un errore, che per ogni
marciapiede controlli se esiste anche ad una certa distanza massima (5mt?)
una highway (residential?) con il relativo tag, viceversa errore sul
marciapiede: "way too far from sidewalk".
Successivamente si potrebbero andare a vedere tutte le strade con il tag in
questione che non sono state smarcate dalla prima passata e dare come
avviso: "sidewalk too far from way" sulla strada.

Cosa ne pensa?
Francesco

Il mar 16 lug 2019, 16:19 Volker Schmidt  ha scritto:

> Noto che si diffonde giustamente la mappatura di precisione.
>
> Tante strade al momento non hanno nessuna indicazione circa la presenza o
> meno di marciapiedi, cioè non c'è ne sidewalk=* ne un marciapiede separato.
> Per motivi di routing pedonale è giusto che la strada porti un foot=yes,
> ma anche questo manca spesso, ma i casi sono in aumento, grazie a iD.
>
> Lo stesso vale per la bicicletta, fra altro.Tante strade hanno la
> ciclabile/ciclopedonale parallela e anche cycleway=track (e varianti sul
> tema)
>
> Sono l'unico a preoccuparmi?
>
> Poi mi mancano anche le conoscenze tecniche per scoprire i problemi. Come
> posso trovare marciapiedi (way separati) vicini e paralleli a una strada
> (che porta il tag foot=yes o sidewalk=*).
> Ammetto che sono al livello del Wizard Overpass-
>
> Volker
> ___
> 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] Depuratore

[Francesco Ansanelli]

Ciao Enrico,

Secondo me, l'edificio è 'building=service'... Valuta se mettere un nodo al
suo interno che rappresenta il depuratore (non sapendo nulla, valuterei:
water_supply=pipeline).
Ho trovato questo sul taginfo:
https://taginfo.openstreetmap.org/keys/water_purification#combinations
che può aiutare per descrivere il tipo di depurazione.
Saluti
Francesco

Il mar 16 lug 2019, 17:49 demon_box  ha scritto:

> ciao, come mappo un edificio sul quale c'è una targhetta che recita:
>
> Depuratore Comune di XY
>
> ripeto, all'apparenza è un semplice edificio, esternamente non si vede
> nient'altro che un edificio.
>
> come lo taggo?
>
> grazie
>
> --enrico
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk] handling street names in speech

[Colin Smale]

The reason for wanting to expand abbreviations in OSM is surely to avoid
ambiguity, not specifically to aid pronunciation or recognition. In the
case of "1e ..." in a certain language context, would that not be
unambiguous? Would a speech synthesiser not know how it should be spoken
in its working language? 

Slight digression: The question does arise of which rules to use to
pronounce foreign names. If I am in Warsaw for example and my satnav
started pronouncing street names in pure Polish I might not recognise
any of them (apologies to any Poles in the audience). But how would it
speak such that I would recognise it, if I was looking for a string with
loads of Ws and Zs that means nothing to me? Use English rules to
pronounce a Polish word? 

On the other hand, if I was in Paris, I would expect it to use French
rules, because I understand French and using English rules would sound
weird although it might well give a lot of laughs...

On 2019-07-16 17:36, John Whelan wrote:

> This approach I like.  Name:expanded perhaps?
> 
> To go back to earlier ideas.
> 
> Expanding the name sounds sensible but unfortunately the street signs are 
> posted with the abbreviation and some local mappers have a what is on the 
> sign goes in the map mentality.  Also we have had discussions about street 
> names in Canada before and the decision was what the municipality declares 
> the street name is correct.  That was to do with either "rue Sparks" or 
> should it be "Rue Sparks" in Quebec it would be one way but in Ontario the 
> other.
> 
> Thoughts
> 
> Thanks John  
> 
> Colin Smale wrote on 2019-07-16 11:30 AM:
> 
> On 2019-07-16 16:54, John Whelan wrote: One or two are problematic usually as 
> the street name is an abbreviation.For example 1e Avenue in French 
> meaning First Avenue.
> 
> Any suggestions on how these should be handled?  This particular application 
> is aimed at partially sighted people but I feel we should be able to come up 
> with a generic solution. 
> 
> Some kind of phonetic (IPA?) representation would be the ultimate generic 
> solution. Here in NL (and I guess in many other countries) there are street 
> names which are partially or entirely in other languages, and the expectation 
> is that they are pronounced as such. For example, Boeing Avenue would sound 
> completely weird if it were pronounced according to Dutch rules. Truly 
> multi-lingual countries like Belgium and Switzerland should be able to make 
> use of name:XX. 
> 
> If we had name:XX:ipa=* we would have a place to put it, but the client app 
> would need to have a way of turning that into sounds. It will only be needed 
> if the pronunciation deviates from the standard for the language in question, 
> but speech synthesisers are never perfect and often make mistakes 
> 
> https://english.stackexchange.com/questions/264239/is-there-any-online-tool-to-read-pronounce-ipa-and-apa-written-words
>  
> 
> Of course we will also need a way of entering IPA symbols 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

-- 
Sent from Postbox [1] 

Links:
--
[1] https://www.postbox-inc.com___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-it] Depuratore

[demon_box]

ciao, come mappo un edificio sul quale c'è una targhetta che recita:

Depuratore Comune di XY

ripeto, all'apparenza è un semplice edificio, esternamente non si vede
nient'altro che un edificio.

come lo taggo?

grazie

--enrico




--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

Re: [OSM-talk] handling street names in speech

[john whelan]

I think this one has nailed it.

Thanks John

On Tue, 16 Jul 2019 at 11:36, Stefan Baebler 
wrote:

> Hints to the speaker (human or TTS engine) can be provided via:
> 1) pronunciation tag:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Phonetics eg
> https://wiki.openstreetmap.org/wiki/Key:name:pronunciation
> 2) teach it how to expand appreviations in different languages, eg
> https://wiki.openstreetmap.org/wiki/Name_finder:Abbreviations
> 3) Both :)
>
> br,
> Štefan
>
> On Tue, Jul 16, 2019 at 5:23 PM Mateusz Konieczny 
> wrote:
>
>> The same happened in Poland, abbreviations are expanded.
>>
>>
>> 16 Jul 2019, 17:02 by nunocapelocalde...@gmail.com:
>>
>> in Portugal the community has agreed not to use abreviations.
>>
>> A terça, 16/07/2019, 15:58, John Whelan  escreveu:
>>
>> One or two are problematic usually as the street name is an
>> abbreviation.For example 1e Avenue in French meaning First Avenue.
>>
>> Any suggestions on how these should be handled?  This particular
>> application is aimed at partially sighted people but I feel we should be
>> able to come up with a generic solution.
>>
>> Thanks John
>>
>>
>>
>>
>> --
>>
>> Sent from Postbox 
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] handling street names in speech

[John Whelan]

This approach I like. Name:expanded perhaps?

To go back to earlier ideas.

Expanding the name sounds sensible but unfortunately the street signs 
are posted with the abbreviation and some local mappers have a what is 
on the sign goes in the map mentality.  Also we have had discussions 
about street names in Canada before and the decision was what the 
municipality declares the street name is correct.  That was to do with 
either "rue Sparks" or should it be "Rue Sparks" in Quebec it would be 
one way but in Ontario the other.


Thoughts

Thanks John

Colin Smale wrote on 2019-07-16 11:30 AM:


On 2019-07-16 16:54, John Whelan wrote:

One or two are problematic usually as the street name is an 
abbreviation.    For example 1e Avenue in French meaning First Avenue.


Any suggestions on how these should be handled?  This particular 
application is aimed at partially sighted people but I feel we should 
be able to come up with a generic solution.


Some kind of phonetic (IPA?) representation would be the ultimate 
generic solution. Here in NL (and I guess in many other countries) 
there are street names which are partially or entirely in other 
languages, and the expectation is that they are pronounced as such. 
For example, Boeing Avenue would sound completely weird if it were 
pronounced according to Dutch rules. Truly multi-lingual countries 
like Belgium and Switzerland should be able to make use of name:XX.


If we had name:XX:ipa=* we would have a place to put it, but the 
client app would need to have a way of turning that into sounds. It 
will only be needed if the pronunciation deviates from the standard 
for the language in question, but speech synthesisers are never 
perfect and often make mistakes


https://english.stackexchange.com/questions/264239/is-there-any-online-tool-to-read-pronounce-ipa-and-apa-written-words

Of course we will also need a way of entering IPA symbols




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


--
Sent from Postbox 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] handling street names in speech

[Stefan Baebler]

Hints to the speaker (human or TTS engine) can be provided via:
1) pronunciation tag:
https://wiki.openstreetmap.org/wiki/Proposed_features/Phonetics eg
https://wiki.openstreetmap.org/wiki/Key:name:pronunciation
2) teach it how to expand appreviations in different languages, eg
https://wiki.openstreetmap.org/wiki/Name_finder:Abbreviations
3) Both :)

br,
Štefan

On Tue, Jul 16, 2019 at 5:23 PM Mateusz Konieczny 
wrote:

> The same happened in Poland, abbreviations are expanded.
>
>
> 16 Jul 2019, 17:02 by nunocapelocalde...@gmail.com:
>
> in Portugal the community has agreed not to use abreviations.
>
> A terça, 16/07/2019, 15:58, John Whelan  escreveu:
>
> One or two are problematic usually as the street name is an
> abbreviation.For example 1e Avenue in French meaning First Avenue.
>
> Any suggestions on how these should be handled?  This particular
> application is aimed at partially sighted people but I feel we should be
> able to come up with a generic solution.
>
> Thanks John
>
>
>
>
> --
>
> Sent from Postbox 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] handling street names in speech

[Colin Smale]

On 2019-07-16 16:54, John Whelan wrote:

> One or two are problematic usually as the street name is an abbreviation.
> For example 1e Avenue in French meaning First Avenue.
> 
> Any suggestions on how these should be handled?  This particular application 
> is aimed at partially sighted people but I feel we should be able to come up 
> with a generic solution.

Some kind of phonetic (IPA?) representation would be the ultimate
generic solution. Here in NL (and I guess in many other countries) there
are street names which are partially or entirely in other languages, and
the expectation is that they are pronounced as such. For example, Boeing
Avenue would sound completely weird if it were pronounced according to
Dutch rules. Truly multi-lingual countries like Belgium and Switzerland
should be able to make use of name:XX. 

If we had name:XX:ipa=* we would have a place to put it, but the client
app would need to have a way of turning that into sounds. It will only
be needed if the pronunciation deviates from the standard for the
language in question, but speech synthesisers are never perfect and
often make mistakes 

https://english.stackexchange.com/questions/264239/is-there-any-online-tool-to-read-pronounce-ipa-and-apa-written-words


Of course we will also need a way of entering IPA symbols___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] handling street names in speech

[Mateusz Konieczny]

The same happened in Poland, abbreviations are expanded.


16 Jul 2019, 17:02 by nunocapelocalde...@gmail.com:

> in Portugal the community has agreed not to use abreviations. 
>
> A terça, 16/07/2019, 15:58, John Whelan <> jwhelan0...@gmail.com 
> > > escreveu:
>
>> One or two are problematic usually as the street name is an abbreviation.    
>> For example 1e Avenue in French meaning First Avenue.
>>  
>>  Any suggestions on how these should be handled?  This particular 
>> application is aimed at partially sighted people but I feel we should be 
>> able to come up with a generic solution.
>>  
>>  Thanks John
>>  
>>  
>>  
>>  
>> -- 
>>  
>> Sent from >> Postbox 
>> ___
>>  talk mailing list
>>  >> talk@openstreetmap.org 
>>  >> https://lists.openstreetmap.org/listinfo/talk 
>> 
>>___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] handling street names in speech

[Nuno Caldeira]

in Portugal the community has agreed not to use abreviations.

A terça, 16/07/2019, 15:58, John Whelan  escreveu:

> One or two are problematic usually as the street name is an
> abbreviation.For example 1e Avenue in French meaning First Avenue.
>
> Any suggestions on how these should be handled?  This particular
> application is aimed at partially sighted people but I feel we should be
> able to come up with a generic solution.
>
> Thanks John
>
>
>
> --
> Sent from Postbox 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] handling street names in speech

[John Whelan]

One or two are problematic usually as the street name is an 
abbreviation.    For example 1e Avenue in French meaning First Avenue.


Any suggestions on how these should be handled?  This particular 
application is aimed at partially sighted people but I feel we should be 
able to come up with a generic solution.


Thanks John



--
Sent from Postbox 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-GB] NaPTAN Aberdeen Import Completion

[Mateusz Konieczny]

Thanks for making this import!

16 lip 2019, 13:47 od silentspike...@gmail.com:

> Just an update to say the import has been completed.
>
> I wrote a diary entry to share some insight (> 
> https://www.openstreetmap.org/user/TheEditor101/diary/390283 
> > ), but no 
> doubt forgot to mention something so feel free to ask me anything.
>
> Now it's time for me to start confirming stop details and fixing 
> discrepancies.
>___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-it] foot=yes su strade con marciapiede

[Volker Schmidt]

Noto che si diffonde giustamente la mappatura di precisione.

Tante strade al momento non hanno nessuna indicazione circa la presenza o
meno di marciapiedi, cioè non c'è ne sidewalk=* ne un marciapiede separato.
Per motivi di routing pedonale è giusto che la strada porti un foot=yes, ma
anche questo manca spesso, ma i casi sono in aumento, grazie a iD.

Lo stesso vale per la bicicletta, fra altro.Tante strade hanno la
ciclabile/ciclopedonale parallela e anche cycleway=track (e varianti sul
tema)

Sono l'unico a preoccuparmi?

Poi mi mancano anche le conoscenze tecniche per scoprire i problemi. Come
posso trovare marciapiedi (way separati) vicini e paralleli a una strada
(che porta il tag foot=yes o sidewalk=*).
Ammetto che sono al livello del Wizard Overpass-

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

Re: [Talk-uy] Proyecto de Importación de Direcciones

[muralito]

Hola Jorge. 

Bienvenido el impulso que le dan a este asunto. 
La documentacion que hicieron me parecio adecuada. 

Lo planteo por la lista talk-uy que creo es lo que tiene llegada mas amplia. 
Estuve viendo que empezaron a importar algunas direcciones en Bella Unón, y hay 
algunos casos que no tengo la confianza de que esten bien, mas bien parecen ser 
errores en los datos fuente, porque son aparentemente incongruencias que habia 
notado cuando revisé versiones anteriores de esos datos para ver si estaban 
como para importar. 

En particular, las numeraciones debieran (*) respetar que (salvo excepciones) 
sigan un crecimiento monotono, van de 50-50 o 100-100 por cuadra, y van pares 
de una acera e impares en la otra. Las calles que corren paralelas en general 
tambien tienen la numeracion sincronizada en esos rangos, como que van todas a 
la misma altura. Las numeraciones, en general, tienen una distribucion uniforme 
por llamarla de alguna forma, que permiten de forma rapida estimar distancias 
entre ellas, etc, por ejemplo si estoy a la altura del 800, y son 100 por 
cuadra, ir al 1200 me lleva 4 cuadras. 

Teniendo esas caracteristicas en cuenta, hay varios nodos que destacan como 
posibles errores por no cumplirlas, nodos con numeracion baja, o lejos de los 
rangos que irian en esa cuadra. No se si eso es apreciable en las fotos o 
videos que tomaron. 

(*) en algunos lugares las numeraciones entregadas son raras o duplicadas, son 
errores historicos de los organismos que la asignan, y que en muchos casos se 
han ido corrigiendo. 

Saludos, 
M. 

De: "Jorge Aguirre"  
Para: "talk-uy"  
Enviados: Viernes, 12 de Julio 2019 20:12:53 
Asunto: [Talk-uy] Proyecto de Importación de Direcciones 

Aprovecho este medio para hacer de su conocimiento que con el equipo de 
editores del grupo Kaart estamos por iniciar un proyecto para hacer una 
importación de las direcciones de Uruguay. 


Se puede leer más al respecto aquí o en la página de wiki de OpenStreetMap del 
Uruguay bajo el inciso - " 5. Proyectos ". 


Estamos abiertos a sus comentarios al respecto para poder realizar esta 
actualización de la mejor manera posible. 


Atentamente, 

Jorge 




Jorge Aguirre | Kaart | +502.4191.1999 | jo...@kaartgroup.com 


KAART CONFIDENTIAL 
This message (including any attachments) is for the private use of the 
addressee only and may contain confidential or privileged information. If you 
have received this message by mistake please notify the sender by return e-mail 
and delete this message and any attachments from your system. Any unauthorized 
use or dissemination of this message, and any attachments in whole or in part 
is strictly prohibited. 


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


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

Re: [talk-cz] Fody verifikace fotek - postup prace

[Tom Ka]

Aktualizace, mame 83% (pres 20 000ks) zverifikovanych fotek, zbyva
1770. Datumove jsme nekde pred v roce 2014.

Bye

čt 20. 6. 2019 v 13:56 odesílatel Tom Ka  napsal:
>
> Ahoj,
>
> jen info - aktualne je jiz verifikovano 75% vsech fotek, datumove jsou
> to (+-) 2016.03 a novejsi. Zbyva 3650.
>
> Konec hlaseni.

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

Re: [OSM-talk-fr] question limite nb vues switch to osm

[Frédéric Rodrigo]

Le 16/07/2019 à 07:44, Laurence P a écrit :


Bonjour,

lorsque je tombe sur un site web _français_ qui propose une carte  
Google hors service (du fait que le site en question n'ait pas payé 
son obole à Google), je leur envoie en général un email pour leur 
conseiller de passer à OpenStreetMap.


À partir de quel nombre de vues est-il judicieux de les orienter vers 
https://switch2osm.org/fr/ ? Je sais qu'il y a les limites fixées par 
la fondation OSM... mais qui dépend du trafic total OSM qui lui varie, 
je demande juste une grosse fourchette :)


Par exemple, dernier site repéré :

https://www.chateauvillandry.fr/preparez-votre-visite/les-informations-pratiques/les-tarifs-les-horaires-les-acces/

Merci d'avance de vos réponse.



De premier abord je pense que les sites qui n'ont pas prit le soin de 
corriger leur carto doivent être plus ou moins à l'abandon. Je ne sais 
pas si tu as déjà eu des retours (positif ou non) à tes démarches.


Ensuite switch2osm est peu à l'abandon, et la version française 
totalement à l'abandon.


Je trouve même gênant que la version française existe, en particulier 
pour la partie serveur de tuiles qui en plus de ne pas être à jour 
détaille une procédure compliqué. Il existe vraiment des solutions plus 
simple aujourd'hui.



My 2cents.

Frédéric.



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

Re: [OSM-talk-be] How owing to FlightRadar24 to follow the Tour de France on a less straight route

[André Pirard]

On 12/07/2019 18.55, André Pirard wrote:


Comment avec FlightRadar24 suivre les avions plutôt que les vélos du 
Tour de France. 



How owing to FlightRadar24  to follow 
the Tour de France on a route 
 
less straight than that of the bikes and than OSM's.
You may right click the video and select "iframe in a new tab" for a 
larger view.


You should probably be able to use Flightradar24 
 and see the planes live if you manage 
to point it where they are 
.


Please forward this to other lists.

This will be my last message about this.
On this 2019-07-15 at around 17:00, I turned FlightRadar24.com 
 on to show the route of the 
10th stage of the Tour de France: Saint-Flour -> Albi 
.
I clicked a few planes along the route until I pinned one that FR24 
labels with a made-up name BE20. It circled in rounds all along he 
track, probably to relay TV signals. You will probably be able to watch 
it during the next stages. (⚠ Tuesday 16 is resting day). Unfortunately, 
albeit F24 archives the history of most flights for replay, it does not 
archive this plane, like e.g. most gliders.
Then I waited until BE20 went nanight in Castres Mazamet Airport 
 to take this picture.

Beware that the pasted over data is that when the plane was above Albi.
In Castres it was less high and going down. And it had a more decided 
speed ;-)


I thought that this could add loving to watch planes to your loving to 
map the land under.
For example, replay the history of this service plane 
 and wonder why it 
goes to those places all over the world to fly in circles. Similar trips 
for this helicopter 
 that I 
found in Albi, Lyon, Brussels near the Tour de France.




All the best,
Cordialement,
Amitiés,

*ㄿ* 
*㈖* *る*
*ェ* *ゝ*







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

Re: [Talk-es] Añadir capa con trazado del metro, cercanías y metro ligero de Madrid, España

[yo paseopor]

En primer lugar , como mola tu mapa y el hecho de que el código esté
disponible. Estoy seguro que a muchos nos puede interesar. en segundo lugar
te recomiendo otro repositorio de github que contiene capas diversas entre
las que puedes encontrar alguna que te pueda interesar como la que sugiere
Jorge.
https://leaflet-extras.github.io/leaflet-providers/preview/

Salut i mapes
yopaseopor

On Tue, Jul 16, 2019 at 2:11 PM Cyttorak  wrote:

> Hola
>
> ¿Como podría añadir una capa en mi mapa
>  para que se vea el trazado (no
> solo las estaciones) de metro, cercanías y metro ligero de Madrid, España?
> ¿Hay alguna capa ya hecha para esto que pueda importar?
>
> Gracias.
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Añadir capa con trazado del metro, cercanías y metro ligero de Madrid, España

[Jorge Sanz Sanfructuoso]

Buenas

Esta por ejemplo la capa de transporte que sale en la pagina de OSM
https://www.openstreetmap.org/#map=14/40.4191/-3.7049=T
Muestra todas las rutas de transporte por lo que también salen buses. No sé
si es lo que necesitas.

Sino en esta sección de la wiki, a lo mejor en alguno de los mapas que
viene puedes encontrar otras cosas
https://wiki.openstreetmap.org/wiki/Public_transport#Maps

Un saludo.

El mar., 16 jul. 2019 a las 14:11, Cyttorak () escribió:

> Hola
>
> ¿Como podría añadir una capa en mi mapa
>  para que se vea el trazado (no
> solo las estaciones) de metro, cercanías y metro ligero de Madrid, España?
> ¿Hay alguna capa ya hecha para esto que pueda importar?
>
> Gracias.
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>


-- 
Jorge Sanz Sanfructuoso - Sanchi
Blog http://jorgesanzs.es/
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

[Talk-es] Añadir capa con trazado del metro, cercanías y metro ligero de Madrid, España

[Cyttorak]

Hola

¿Como podría añadir una capa en mi mapa
 para que se vea el trazado (no
solo las estaciones) de metro, cercanías y metro ligero de Madrid, España?
¿Hay alguna capa ya hecha para esto que pueda importar?

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

Re: [Talk-GB] NaPTAN Aberdeen Import Completion

[Tony Shield]

Hi Spike

Have read your diary and the NaPTAN/Aberdeen page - absolutely excellent.

Yes It will encourage me to have a go for my local area.

Regards

Tony Shield TonyS999

On 16/07/2019 12:47, Silent Spike wrote:

Just an update to say the import has been completed.

I wrote a diary entry to share some insight 
(https://www.openstreetmap.org/user/TheEditor101/diary/390283), but no 
doubt forgot to mention something so feel free to ask me anything.


Now it's time for me to start confirming stop details and fixing 
discrepancies.


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

[Talk-GB] NaPTAN Aberdeen Import Completion

[Silent Spike]

Just an update to say the import has been completed.

I wrote a diary entry to share some insight (
https://www.openstreetmap.org/user/TheEditor101/diary/390283), but no doubt
forgot to mention something so feel free to ask me anything.

Now it's time for me to start confirming stop details and fixing
discrepancies.
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-at] Zweiter Benutzer von addresshistory*org mit edits?

[andreas wecer]

Am Di., 16. Juli 2019 um 12:22 Uhr schrieb Frederik Ramm <
frede...@remote.org>:

> Sollte es ein "multi" von addresshistory*org sein, der damit in perfider
> Weise versucht, unser Aufräumen zu torpedieren, wäre das natürlich ein
> Grund, sämtliche Accounts erstmal für längere Zeit auf Eis zu legen,
> aber ich glaube jetzt mal an das Gute im Menschen und gehe davon aus,
> dass "Landeskarte" jemand anders ist.
>

Ja natürlich ist er das, was er hier nur mit "Nein! Doch! O..."
kommentiert hat:
https://www.openstreetmap.org/changeset/71951271

Das Verschleiern der Nodes dürfte er erst im letzten Changeset gemacht
haben, wobei "verschleiern" ja der falsche Ausdruck ist, es ist mehr ein
trotziges Trollen und Erschweren der Aufräumarbeiten.

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

Re: [Talk-at] Zweiter Benutzer von addresshistory*org mit edits?

[Frederik Ramm]

Hi,

On 16.07.19 09:37, vari...@mailbox.org wrote:
> Es gibt offensichtlich einen neuen Benutzer, der oft nichts anderes
> macht, als den Tag at_bev:addr_date=2019-04-01 zu löschen. Wurde auch
> gefragt, warum er das gemacht hat ohne Antwort:

Hab ihn gesperrt und um Wohlverhalten gebeten:

https://www.openstreetmap.org/user_blocks/3012

Sollte es ein "multi" von addresshistory*org sein, der damit in perfider
Weise versucht, unser Aufräumen zu torpedieren, wäre das natürlich ein
Grund, sämtliche Accounts erstmal für längere Zeit auf Eis zu legen,
aber ich glaube jetzt mal an das Gute im Menschen und gehe davon aus,
dass "Landeskarte" jemand anders ist.

(addresshistory*org listet seine "offiziellen" Zweitaccounts hier
https://www.openstreetmap.org/user/addresshistory*org und solange die
nicht benutzt werden, um Sperren oder Auflagen zu umgehen, ist dagegen
nichts einzuwenden.)

Viele Grüße
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [OSM-talk-fr] Epreuve Cyclo-randonnée Paris-Brest-Paris dans OSM

[Florimond Berthoux]

Le lun. 15 juil. 2019 à 12:13, Phyks  a écrit :

> Salut,
>
> > Pour le besoin de différencier les itinéraires par type de pratique
> > vélo, je suis plus pour dire que route=mtb est une erreur et que la
> > bonne façon de faire c'est la spécialisation :
> > route=bicycle
> > bicycle=mtb/cycling_race/tourism/gravel/commute/...
>
> +1 ! Tu nous gères la proposition de tagging ? :)
>

J'aimerais avoir le temps pour, mais c'est l'été, la saison du vélo ;)

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

[Talk-at] Zweiter Benutzer von addresshistory*org mit edits?

[various]

Es gibt offensichtlich einen neuen Benutzer, der oft nichts anderes macht, als 
den Tag at_bev:addr_date=2019-04-01 zu löschen. Wurde auch gefragt, warum er 
das gemacht hat ohne Antwort: https://www.openstreetmap.org/changeset/72163441 
weiter Beispiele z. B. https://www.openstreetmap.org/node/6468524050/history 
und https://www.openstreetmap.org/node/6468524046/history  
https://www.openstreetmap.org/node/6468524046/history und erzeugt somit aus 
vielen importierten Adressen eine v2.

Bei diesem Changeset von Landeskarte hat auch dann addresshistory 
weiterkommentiert: https://www.openstreetmap.org/changeset/71428706 Im Blog ist 
auf einen ziemlich netten Hinweis auch eher pampig 
https://www.openstreetmap.org/user/Landeskarte/diary/43306 
http://whosthat.osmz.ru/  http://whosthat.osmz.ru/ Eine Whoisabfrage nach 
"landeskarte" und nach "addresshistory*" gehen beide auf geocodec zurück.

Während natürliche mehrere Accounts erlaubt sind, widerspricht das "mal den Tag 
mit BEV löschen" meiner Meinung nach Sachen. Änderung ohne Verbesserung, der 
Lizenzhinweis geht verloren (Adresse immerhin per Datensatz reingeholt und 
nicht per survey) und es wirkt, als wollte er dem "nur v1 löschen" entgehen. 
https://wiki.openstreetmap.org/wiki/OpenStreetMap_account#Account_Names_and_Multi_Account_Policies

Was wird hier auf der Liste von solchen Edits bzw. Zweitaccounts gehalten? z. 
B. für Imports wird das ja klar gefordert und sollte dann aber auch klar 
kommuniziert werden und beides ist nicht der Fall.
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [OSM-talk-fr] Attribution incorrecte

[Vincent Bergeot]

Le 15/07/2019 à 23:12, osm.sanspourr...@spamgourmet.com a écrit :

Je pense préférable que toute personne voyant un tel problème utilise le modèle 
conçu par Deuzeffe et si la personne ne réagit pas coreectement qu'on actionne 
le niveau officiel. En ne respectant pas l'attribution, c'est aussi ton droit 
en tant que contributeur qu'ils bafouent.
Marc ou Deuzeffe te retrouveront le lien si besoin.


il y a la page ici : 
https://wiki.openstreetmap.org/wiki/FR:Lacking_proper_attribution


qui reprend le travail initié par @deuzeffe et @marc et un tableau de suivi.

à plus





Jean-Yvon



Gesendet: Montag, 15. Juli 2019 um 23:04 Uhr
Von: "pepilepi...@ovh.fr - pepilepi...@ovh.fr" 

An: talk-fr@openstreetmap.org
Betreff: [OSM-talk-fr] Attribution incorrecte

Bonjour,

Sur
https://www.clevacances.com/fr/locationvacances/provencealpescotedazur/hautesalpes/saintveran-1905/appartement_65_m2_4_personnes_a_saint_veran_parc_naturel_regional_du_queyras_hautes_alpes/37581
j'ai la très nette impression de reconnaître "notre" OSM.

Et l'attribution est à clevacances...

Un "officiel" pour vérifier et au besoin leur rappeler leur obligation ?

Merci, bonne soirée

Jean-Pierre

--


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


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



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



--
Vincent Bergeot


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