Re: [OSM-talk] Let's talk Attribution

[Alexandre Oliveira]

> I absolutely agree that looking at industry standard seems a good indication 
> of what is reasonable.
> If someone is hitting OSM's tile server, then that would be the industry 
> equivalent of using Google or HERE's API, for which they typically require 
> on-map logo attribution.
> For using *data* from someone's geodatabase, on the other hand, the standard 
> attribution for webmaps varies widely from on-map to after several menu 
> choices; and the standard attribution on mobile is 5-6 clicks from the UI.
> Check out HERE's webmap: https://mobile.here.com/?x=ep. It takes 3 clicks to 
> get to this page: https://mobile.here.com/about/notices. And another 4 clicks 
> to get to this page: 
> https://legal.here.com/en-gb/terms/general-content-supplier-terms-and-notices
> After researching this question, I found no commercial data provider that 
> required data attribution as prominently as the FAQ suggests. Industry 
> standard would suggest a *much* less strict interpretation of what is 
> "reasonable" under the ODbL.

I disagree. Google Maps provides both the tiles and the map data, and
I'm pretty sure the attribution works for both services they provide,
i.e., if you used Google's map data you'd still be required to
attribute them in the map layer. The thing is, they don't allow
separation between the tiles and the map data. Assuming someone is
using OSM map data and saying attribution should be less strict is
like selling proprietary software without a EULA or ToS then
complaining that someone is using your software "the wrong way".

> It’s a database technically, but it’s a database purpose-built for making 
> maps. Hence the name OpenStreetMap.
>
> The attribution goes on the map.
>
> This is not a difficult requirement to meet.

Literally this. If the idea is to be an alternative map to proprietary
maps, why do we need to be so passive about attribution? OSM barely
attracts contributors with projects that use attribution, removing the
need of attribution or making it optional (like some people think it
should be) would be the nail in the coffin for the project.

I don't understand. What's the problem about copying what every other
proprietary map does, adding a credit on top of the map layer? Mapping
libraries do this, Google Maps and Bing do it (and they're source for
data). Do we want big companies like Netflix stealing our precious
hard work without even crediting the people that spent their time on
improving OSM? They used OSM data on their recent movie "All The
Bright Places"[0].

> The FAQ is not the license. The license is the ODbL. The ODbL says absolutely 
> nothing about whether attribution should be on a map or not. Read it here: 
> https://opendatacommons.org/licenses/odbl/index.html

And the FAQ specifies conditions to attribute the data. The license
text says there should be attribution, and the FAQ tells you how to do
it. Of course, it would be better if there was a Terms of Use document
for OSM data that explicitly stated that you need to credit OSM for
the map data by adding a text box over the map with the text "(C)
OpenStreetMap contributors" and linking to the wiki page with a list
of contributors.


This "our attribution guideline is too strict! we should make it less
strict!" mentality is saddening. It only enforces the stereotype for
open source and data that "oh, if it's open I can simply steal this
code and not credit the original authors, everyone will think I am
badass for making this!". Is it so hard to stop removing a single line
of code from your projects, so that they can properly attribute OSM?
(AFAIK Leaflet and Mapbox have attribution enabled by default)

[0] https://twitter.com/iamnunocaldeira/status/1254421478705188866

-- 
Atenciosamente,
Alexandre Oliveira.

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

Re: [OSM-talk] Let's talk Attribution

[Kathleen Lu via talk]

I absolutely agree that looking at industry standard seems a good
indication of what is reasonable.
If someone is hitting OSM's tile server, then that would be the industry
equivalent of using Google or HERE's API, for which they typically require
on-map logo attribution.
For using *data* from someone's geodatabase, on the other hand, the
standard attribution for webmaps varies widely from on-map to after several
menu choices; and the standard attribution on mobile is 5-6 clicks from the
UI.
Check out HERE's webmap: https://mobile.here.com/?x=ep. It takes 3 clicks
to get to this page: https://mobile.here.com/about/notices. And another 4
clicks to get to this page:
https://legal.here.com/en-gb/terms/general-content-supplier-terms-and-notices
After researching this question, I found no commercial data provider that
required data attribution as prominently as the FAQ suggests. Industry
standard would suggest a *much* less strict interpretation of what is
"reasonable" under the ODbL.
-Kathleen

On Tue, Apr 28, 2020 at 5:28 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> On 28. Apr 2020, at 23:34, Kathleen Lu via talk 
> wrote:
>
> The FAQ is not the license. The license is the ODbL. The ODbL says
> absolutely nothing about whether attribution should be on a map or not.
> Read it here: https://opendatacommons.org/licenses/odbl/index.html
>
>
>
> I am not a lawyer, but wouldn’t it seem logical to look what others are
> doing, when we must establish what this means: „ You must include a
> notice associated with
> the Produced Work reasonably calculated to make any Person that uses,
> views, accesses, interacts with, or is otherwise exposed to the Produced
> Work aware that Content was obtained from the Database,...“
>
> It says „reasonably calculated to make any Person that uses, views,...aware“,
> any. To me this reads as if it has to be put very prominently, it has to be
> thrown into everyone’s face so that they become aware. Looking at the
> industry standard seems a good indication to find out what is “reasonable”,
> would you agree?
>
> Cheers Martin
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk-fr] "Catastrophe d'Haïti: déjà 10 ans"

[Philippe Verdy]

OSM s'est beaucoup fait connaitre à l'occasion de la catastrophe du
tremblement de terre en Haïti. C'était en 2010. Déjà 10 ans. Un
anniversaire un peu passé à la trappe avec le COVID-19, et non pas à
célébrer mais à considérer :

OSM a-t-il fait de réels progrès ou permis de réelles avancées ailleurs
dans le monde pour suivre les catastrophes ?

La cartographie des pays les moins avancés s'est-elle suffisamment
améliorée pour répondre correctement aux besoins d'aujourd'hui, à la
demande sociale, réduire les écarts de développement ? Quels ont été les
freins ayant empêché un tel développement ?

Et suite aux efforts participatifs, les cartes créées dans l'urgence
ont-elles été maintenues par une plus grande coopération par les agences
nationales officielles (développement de l'Open Data, libéralisation de
l'activité de cartographie) et une implication volontaire même de la part
de grandes sociétés commerciales où l'outil cartographique est perçu non
plus comme un bien privé mais comme une base servant à développer de
nouvelles applications ?

L'effort participatif est-il maintenant destiné à être repartagé librement
et non restreint par des licences qui s'approprient ces efforts (comme le
font encore Google et dans de nombreux pays les agences cartographiques
nationales, au contraire de Facebook et même Microsoft Bing qui ont pris le
pari d'ouvrir leurs données afin de partager les coûts par la participation
du plus grand nombre)?

Les grands décideurs publics et privés ont-ils compris que la cartographie
libre  sert aussi à permettre à de nouvelles opportunités de s'inventer et
s'adapter aux besoins (locaux ou globaux, permanents ou temporaires en
situation de crise), anticiper les crises (voire en estimer la
probabilité), planifier les efforts, réduire les délais de mise en oeuvre
des politiques, constater les défauts de couverture et les résoudre
efficacement en mettre des moyens là où cela rendra le plus grand service
tout en maintenant un équilibre territorial en terme d'offres et de
disponibilité/d'accessibilité des services essentiels à la population ?

Bref cette cartographie libre a-t-elle permis de commencer à effacer les
"hot-spots" de développement et les fractures autant territoriales que
sociales, avec une trop grande concentration et une trop grande dépendance
vis-à-vis de quelques trop gros acteurs ultra concentrés ou centralisés
dans des zones ultra favorisées, mais des acteurs devenus incontournables,
"too big to fail", et aidés inefficacement à la première crise avec forces
milliards dépensés sans que cela améliore la situation globale et la
diversité locale, et pourtant devenus totalement incapables par leur trop
grande normalisation de prendre en compte la diversité des situations de
crise et leur réelle complexité, alors que les efforts locaux coûtent peu,
évitent des gaspillages à cause de principes généraux trop stricts
appliqués à la lettre ?

Le monde ne peut-il pas avoir une plus grande diversité et localisation
fine des offres au lieu de continuer sur la voie d'une "mondialisation"
poussée, dont on voit bien qu'elle conduit à empirer gravement les
catastrophes, et qu'elle complique ou retarde énormément les solutions pour
les réparer, avec des coûts cachés qu'on avait largement sous-estimés,
voire méprisé comme la prévention passée à la trappe car "inutile" aux
besoin à très court terme?

"Gouverner c'est prévoir" dit une célèbre maxime. Et pour prévoir, quoi de
mieux que de bien connaitre le terrain ? Vive la cartographie libre ouverte
à toutes les initiatives locales (même à titre expérimental et temporaire,
car on n'apprend réellement bien que de l'expérience de ses erreurs, quand
leurs conséquences ont un impact limité, et quand on peut ensuite mesurer
les efforts produits et les résultats positifs ou négatifs, si on veut
ensuite étendre les solutions ailleurs.

Et pourtant on voir toujours partout d'appliquer, souvent par la
contrainte, une seule et même "norme", en oubliant à chaque fois toutes les
minorités qui se développent partout dans des tas de domaines différents :
on est tous devenus membres d'au moins une minorité qui se sent exclue, la
"démocratie" de la majorité est celle d'une majorité théorique, de plus en
plus restreinte (un peu comme le modèle du "consommateur type" pour les
publicistes). Même une logique économique se satisferait d'une
déconcentration et de plus de concurrence entre les solutions et de
beaucoup plus d'expérimentations locales, pour peu qu'on leur laisse un
espace de développement possible et qu'on ne leur impose pas les mêmes
contraintes qu'aux grands acteurs promoteurs de leurs propres normes (ainsi
que leurs abus quand ils passent en situation de monopole de fait ou
oligopole concerté).

Et pour ça, le cadre légal et réglementaire doit mieux protéger les petits
acteurs, à commencer par le monde associatif ou coopératif mais aussi en
déconcentrant les pouvoirs publics et donnant plus de droits aux décideurs
publics locaux (leur action 

Re: [OSM-talk] Let's talk Attribution

[Martin Koppenhoefer]

sent from a phone

> On 28. Apr 2020, at 23:34, Kathleen Lu via talk  
> wrote:
> 
> The FAQ is not the license. The license is the ODbL. The ODbL says absolutely 
> nothing about whether attribution should be on a map or not. Read it here: 
> https://opendatacommons.org/licenses/odbl/index.html


I am not a lawyer, but wouldn’t it seem logical to look what others are doing, 
when we must establish what this means: „ You must include a notice associated 
with
the Produced Work reasonably calculated to make any Person that uses,
views, accesses, interacts with, or is otherwise exposed to the Produced
Work aware that Content was obtained from the Database,...“

It says „reasonably calculated to make any Person that uses, views,...aware“, 
any. To me this reads as if it has to be put very prominently, it has to be 
thrown into everyone’s face so that they become aware. Looking at the industry 
standard seems a good indication to find out what is “reasonable”, would you 
agree?

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

Re: [OSM-talk-fr] [Presse Locale][Ca Urge] Ça reste ouvert :

[Philippe Verdy]

Bref, exiger une communauté locale à Monaco est sans doute trop: cette
communauté est forcément extrêmement réduite, voire inexistante, composée
en fait de contributeurs qui y vont souvent mais sont en fait logés
ailleurs (Le Cap d'Ail ou Roquebrune-Cap-Martin pour les plus aisés sur la
côte, Beausoleil ou la Turbie pour les autres dans les hauteurs les plus
proches de Monaco, sinon venant d'autres villes de la Côte d'Azur française
ou de la Riviera italienne, que ce soit en train ou bus, ou en voiture
s'ils peuvent se garer à Monaco, éventuellement même à pied ou à vélo pour
ceux habitant assez près de la frontière monégasque), plus des voyageurs
professionnels qui peuvent venir de plus loin (y compris régulièrement par
avion depuis l'aéroport Nice-Côte d'Azur) et ceux qui y ont une résidence
secondaire, un bureau ou pas de porte pour une filiale ou une activité
commerciale ou associative, ou encore une embarcation stationnée au port de
Monaco (tant qu'on ne leur impose pas des restrictions de circulation pour
passer la frontière franco-monégasque ou pour voyager de plus loin en avion
via Nice ou Gênes, ni une quinzaine de confinement pour ceux qui peuvent se
loger durablement hors des hôtels fermés).



Le mer. 29 avr. 2020 à 00:41, Philippe Verdy  a écrit :

> Monaco a sa communauté locale très largement liée aux services en France,
> et a de nombreux travailleurs transfrontaliers, venant la plupart de France
> (car Monaco ne peut pas les loger) ou sinon de l'Italie toute proche, y
> compris des personnes monégasques résidant en France ou Italie. De plus la
> réglementation locale de Monaco suit d'assez près celle applicable en
> France (sauf la législation spécifique à certains commerces et aux taxes
> applicables, ou la classification locale des établissements médicaux, bien
> que Monaco coopère largement avec la France et dépend aussi de la France
> pour nombre de services médicaux, avec aussi des reconnaissances mutuelles
> en terme de sécurité sociale: les monégasques ne sont pas obligés de se
> faire soigner uniquement à Monaco qui ne dispose pas de tous les services
> nécessaires pour toutes les spécialités).
>
> Et je suis presque certain que la plupart des contributeurs pour Monaco
> sont en fait en France, et tous parlent français et ont suivi nos règles
> françaises pour le tagging (avec quelques exceptions, dont les tags "FR:*"
> franco-français qui ne les concernent pas, remplacés si nécessaire par des
> tags "MC:*" pour suivre les règles spécifiquement monégasques).
>
> L'Italie est aussi déjà intégrée dans CRO (mais selon les règles
> communautaires italiennes). Bref c'est un tout petit trou qui ne coûte pas
> grand chose de plus.
>
>
>
> Le mar. 28 avr. 2020 à 08:50, PanierAvide  a
> écrit :
>
>> Bonjour,
>>
>> La stratégie adoptée est que ce sont les communautés locales des
>> différents pays qui sont porteurs de l'initiative, donc tant qu'une
>> communauté locale ne se manifeste pas, pas d'ouverture de "Ça reste ouvert"
>> dans un pays. L'idée étant qu'il faut du monde pour traduire, animer,
>> contribuer, gérer les notes... Voir pour référence :
>> https://github.com/osmontrouge/caresteouvert/wiki/Expand-%22%C3%87a-reste-ouvert%22-to-another-country
>>
>> Ceci étant dit, Andorre a été intégré pour ne pas avoir de discontinuité
>> entre France et Espagne, ce ne serait donc pas plus mal d'activer Monaco
>> également sur ce même principe.
>>
>> Cordialement,
>>
>> Adrien P.
>>
>> Le 28/04/2020 à 07:18, Philippe Verdy a écrit :
>>
>> Rien à Monaco (contrairement à Andorre) ou bien c'est groupé avec la
>> France (étant donné la proximité des 4 autres communes françaises autour:
>> Le Cap-d'Ail, La Turbie, Beausoleil et Roquebrune-Cap-Martin qui ont
>> quelques points mais à mon avis même pas assez)?
>>
>> Je ne vois aucun point (même gris) à Monaco (dont les lieux pourraient
>> être indexés avec ceux de la France, ça ne va pas beaucoup révolutionner
>> les statistiques, sauf justement concernant les établissements médicaux,
>> hors l'hôpital qui comme les autres ne sont pas à renseigner car ils sont
>> évidemment ouverts et ont à gérer l'urgence et coopèrent avec toute la
>> région, même si les frontières sont encore fermées ou sévèrement contrôlées
>> par les autorités monégasques, sachant que la population monégasque est
>> relativement âgée et plus exposées aux risques que les communes française
>> autour, mais pourtant il y a des tas de travailleurs transfrontaliers: si
>> la frontière est fermée, nombre de commerces n'ont plus le personnel
>> nécessaire pour ouvrir et les monégasques doivent alors se rendre dans les
>> grandes surfaces ouvertes en France, s'ils peuvent se déplacer, ou utiliser
>> les livraisons s'il y en a en mode transfrontalier).
>>
>> Rien au Luxembourg ni en Belgique (au moins la partie francophone et la
>> capitale si les néerlandophones n'ont pas encore leur version) ? Là encore
>> une bande frontalière peut être concernée en zone moins dense pour des
>> 

Re: [Talk-transit] Making bus lines more specific

[Phake Nick]

在 2020年4月28日週二 20:45，Robin Däneke  寫道：

> Because the discussion of this thread already ran into the direction of
> changing different aspects about the tagging, I used it for the general
> discussion. If we refine the buses, it could go hand in hand with
> everything else. I’d be interested in which refinements would be needed
> there as part of my general suggestion. But in my current WIP-suggestion
> the „bus=yes,tram=yes“ should not be necesarry, only a route relation type
> for each mean of transport.
>

??? "Because the discussion of this thread already ran into the direction
of changing different aspects about the tagging, I used it for the general
discussion. "??? Your reply was literally the second one in the thread that
hijacked it and directed everyone's attention away from the original topic,
and the feature in your WIP are also irrelevant to the bus type refinement
that was being suggested.


> If I could get a list of types of buses, I could think about how to do
> this.
> Idealy, we leave the „route=bus“ and then add another sub_tag group bus=*
> or bus_type=*. Then the generalized „bus" would still be valid but the
> specification would be available if needed...
>
> Should I open a new thread for the general discussion?
>

Congratulations you have already hijacked this thread successfully and
turned this thread into a thread for general discussion that have nothing
to do with the original topic.


> KR
> RobinD
>
> Am 28.04.2020 um 14:34 schrieb Phake Nick :
>
> Excuse me, I am a bit lost on how refining bus stop/station/platform tags
> will help resolving the issue of making bus route tagging more specific,
> and differentiate between different rype of bus services, which is the
> topic of this email thread?
>
> 在 2020年4月28日週二 15:45，Robin Däneke  寫道：
>
>> Hello everybody,
>>
>> I have lately been thinking about somehow reworking (or giving a new push
>> to) the current p_t:v2 scheme.
>> Especially for the fact, that, since it was first proposed and accepted,
>> not a lot has changed in which tags are rendered, how certain things are
>> hence mapped and the Wiki-Pages on the topic have also changed in the last
>> years without any visible going through another proposal process.
>>
>> When I started mapping in 2011, and first read the german and then the
>> english p:t:v2 wiki pages, it was:
>> - highway=bus_stop is a legacy tag that should eventually be completely
>> phased out
>> - stop positions and platforms are to be both mapped
>> and some other things I already forgot…
>> Now, iD has a rule in its verifyer, that requires highway=bus_stop on
>> platform nodes. The point of the public_transport tags is, among other
>> points, to replace less dedicated highway tags.
>> I think it would be time for a p_t:v2.5 proposal, where we take the
>> innicial ideas of the v2, maybe refine a few small details (like is
>> stop_position required, or just platforms, can relations of route-parts be
>> used in route relations to save on redundancy…) and then put it forward for
>> voting. If accepted, we would possibly now have more leverage to get the
>> editor and render-programers to actually properly implement it this time
>> around.
>>
>> Maybe I could find some time to write my suggestions into a document, and
>> we could collect the ideas for those extra tags in there too. I think it
>> would make more sense that way, than just the addition of a few tags to the
>> current scheme, to then be ignored by the rest of OSM once again.
>>
>> Kind Regards
>> Robin D. (emergency99)
>>
>>
>> PS: The problem with bus_stop on platform: platforms can be nodes, lines,
>> ways, even relations, highway=bus_stop can only be a node. This old tag
>> should go the same way as the farm tag, which was (forcefully) abandoned a
>> couple of years back. There it worked, why not for the „new“ p_t scheme?
>>
>> > Am 28.04.2020 um 00:12 schrieb Guilherme Braga Alves <
>> gbragaal...@gmail.com>:
>> >
>> > I read your responses and I tend to agree that the opening_hours tag is
>> enough to characterize services that are only operated during peak hours.
>> >
>> > On the other hand, it seems to me that there is also agreement on the
>> relevance of having tags to differentiate bus services.
>> >
>> > How can we expand this debate and expand this discussion? It may be
>> interesting for other members of the list to speak out, and then we can
>> create or redeem a proposal for implementing new tags.
>> >
>> > P.S .: I don't know if this message will enter the reply queue
>> correctly; I hope I'm not opening a new topic. I apologize for my
>> inexperience with maillists.
>> > ___
>> > Talk-transit mailing list
>> > Talk-transit@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-transit
>>
>>
>> ___
>> Talk-transit mailing list
>> Talk-transit@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-transit
>>
> 

Re: [OSM-talk-fr] [Presse Locale][Ca Urge] Ça reste ouvert :

[Philippe Verdy]

Monaco a sa communauté locale très largement liée aux services en France,
et a de nombreux travailleurs transfrontaliers, venant la plupart de France
(car Monaco ne peut pas les loger) ou sinon de l'Italie toute proche, y
compris des personnes monégasques résidant en France ou Italie. De plus la
réglementation locale de Monaco suit d'assez près celle applicable en
France (sauf la législation spécifique à certains commerces et aux taxes
applicables, ou la classification locale des établissements médicaux, bien
que Monaco coopère largement avec la France et dépend aussi de la France
pour nombre de services médicaux, avec aussi des reconnaissances mutuelles
en terme de sécurité sociale: les monégasques ne sont pas obligés de se
faire soigner uniquement à Monaco qui ne dispose pas de tous les services
nécessaires pour toutes les spécialités).

Et je suis presque certain que la plupart des contributeurs pour Monaco
sont en fait en France, et tous parlent français et ont suivi nos règles
françaises pour le tagging (avec quelques exceptions, dont les tags "FR:*"
franco-français qui ne les concernent pas, remplacés si nécessaire par des
tags "MC:*" pour suivre les règles spécifiquement monégasques).

L'Italie est aussi déjà intégrée dans CRO (mais selon les règles
communautaires italiennes). Bref c'est un tout petit trou qui ne coûte pas
grand chose de plus.



Le mar. 28 avr. 2020 à 08:50, PanierAvide  a écrit :

> Bonjour,
>
> La stratégie adoptée est que ce sont les communautés locales des
> différents pays qui sont porteurs de l'initiative, donc tant qu'une
> communauté locale ne se manifeste pas, pas d'ouverture de "Ça reste ouvert"
> dans un pays. L'idée étant qu'il faut du monde pour traduire, animer,
> contribuer, gérer les notes... Voir pour référence :
> https://github.com/osmontrouge/caresteouvert/wiki/Expand-%22%C3%87a-reste-ouvert%22-to-another-country
>
> Ceci étant dit, Andorre a été intégré pour ne pas avoir de discontinuité
> entre France et Espagne, ce ne serait donc pas plus mal d'activer Monaco
> également sur ce même principe.
>
> Cordialement,
>
> Adrien P.
>
> Le 28/04/2020 à 07:18, Philippe Verdy a écrit :
>
> Rien à Monaco (contrairement à Andorre) ou bien c'est groupé avec la
> France (étant donné la proximité des 4 autres communes françaises autour:
> Le Cap-d'Ail, La Turbie, Beausoleil et Roquebrune-Cap-Martin qui ont
> quelques points mais à mon avis même pas assez)?
>
> Je ne vois aucun point (même gris) à Monaco (dont les lieux pourraient
> être indexés avec ceux de la France, ça ne va pas beaucoup révolutionner
> les statistiques, sauf justement concernant les établissements médicaux,
> hors l'hôpital qui comme les autres ne sont pas à renseigner car ils sont
> évidemment ouverts et ont à gérer l'urgence et coopèrent avec toute la
> région, même si les frontières sont encore fermées ou sévèrement contrôlées
> par les autorités monégasques, sachant que la population monégasque est
> relativement âgée et plus exposées aux risques que les communes française
> autour, mais pourtant il y a des tas de travailleurs transfrontaliers: si
> la frontière est fermée, nombre de commerces n'ont plus le personnel
> nécessaire pour ouvrir et les monégasques doivent alors se rendre dans les
> grandes surfaces ouvertes en France, s'ils peuvent se déplacer, ou utiliser
> les livraisons s'il y en a en mode transfrontalier).
>
> Rien au Luxembourg ni en Belgique (au moins la partie francophone et la
> capitale si les néerlandophones n'ont pas encore leur version) ? Là encore
> une bande frontalière peut être concernée en zone moins dense pour des
> raisons de proximité alors que les services en France peuvent être plus
> éloignés (inaccessibles dans les délais imposés) que ceux dans le pays
> voisin (notamment les supermarchés et hypers, stations-service).
>
>
> Le mar. 21 avr. 2020 à 11:26, PanierAvide  a
> écrit :
>
>> Bonjour,
>>
>> On a pas mal de stats générées ici :
>> https://download.osmontrouge.fr/caresteouvert/
>>
>> Cordialement,
>>
>> Adrien P.
>>
>> Le 21/04/2020 à 11:01, Jacques Lavignotte a écrit :
>> > Bonjour,
>> >
>> > pour la presse locale j'ai besoin de chiffres CRO sur les départements
>> > 86 et 79.
>> >
>> > Nombre commerces dans CRO, nombre de contributeurs, etc.
>> >
>> > C'est pour midi :)
>> >
>> > Merci, Jacques
>> >
>> >
>> > Le 25/03/2020 à 19:44, PanierAvide a écrit :
>> >> Bonjour à tous,
>> >>
>> >> Suite aux échanges divers sur l'épidémie de Covid-19 et comment OSM
>> >> pouvait proposer une information de qualité sur le sujet, nous avons
>> >> enfin publié "Ça reste ouvert", la carte des lieux ouverts pendant le
>> >> confinement : caresteouvert.fr
>> >>
>> >> La carte propose aux visiteurs d'ajouter des infos dans leur commune
>> >> : cela créé une note automatiquement dans OSM, avec les informations
>> >> nécessaires. Ces notes sont à passer en revue pour intégrer les tags
>> >> sur les lieux concernés. En particulier :
>> >>
>> >> - opening_hours:covid19 : horaires 

Re: [OSM-talk] Let's talk Attribution

[Joseph Eisenberg]

It’s a database technically, but it’s a database purpose-built for making
maps. Hence the name OpenStreetMap.

The attribution goes on the map.

This is not a difficult requirement to meet.

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

Re: [OSM-talk] Let's talk Attribution

[Kathleen Lu via talk]

> the header of the code, that's the place where the attribution is expected.
>
> roughly equivalent to some corner in the displayed map, that's what the
> license says, right?
>

I do not think these two things are at all equivalent. OSM is a database,
so the equivalent attribution notice to the header in code would be a text
file that accompanies the database. The UI of an application that uses a
database is the equivalent of the UI of an application that uses code.

the point which surprises me (and IIUC Skyler), is that you state
> something in the license, then you seem not to particularly care if it's
> respected, or not.
>

The FAQ is not the license. The license is the ODbL. The ODbL says
absolutely nothing about whether attribution should be on a map or not.
Read it here: https://opendatacommons.org/licenses/odbl/index.html
The FAQ is an interpretation of the ODbL that some people in the OSMF wrote
up many years ago, and some of that interpretation is from before the
license change. It is not clear that everything in the FAQ is a correct
interpretation of the ODbL. Regarding issues other than attribution, the
OSMF has updated it's license interpretations several times over the years.
It has been debated, but not decided, whether the FAQ interpretations on
attribution should be updated.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Let's talk Attribution

[Mario Frasca]

On 28/04/2020 15:01, Kathleen Lu wrote:
I know no major open source license that requires attribution *in the 
UI that the user sees without clicking on anything*. 


oh, but thinking of code I don't particularly care about the UI.

I care about the code, and if I release some code as GPL, you as a user 
have the right to receive the code, and you as a further developer have 
the right to do whatever you want with the code, but NOT to change the 
license, nor to remove me from the copyright holders.


so again you as a user looking into the code are expected to find my 
name (and that of all previous and subsequent authors).


the header of the code, that's the place where the attribution is expected.

roughly equivalent to some corner in the displayed map, that's what the 
license says, right?


the point which surprises me (and IIUC Skyler), is that you state 
something in the license, then you seem not to particularly care if it's 
respected, or not.


MF


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

Re: [Talk-de] Gewichtung der Straßen im Routing

[Volker Schmidt]

Ich war vielleicht zu stenografisch.
access=designated funktioniert anders.
siehe Wiki:
access=designated
 und Key
motorcar. 
Mit anderen Worten motor_vehicle=designated "produziert" die gleichen
access-Beschraenkungen wie motorroad=yes


On Tue, 28 Apr 2020 at 21:27, pbnoxious  wrote:

> Also vielleicht verstehe ich das ganze access-Zeug falsch, aber sollte
> nicht "motor_vehicle" nur den access für eben diese motorisierten
> Gefährte einschränken? Und sonst die Standartwerte gelten (also
> foot=yes, bicycle=yes, horse=yes usw.)
>
> Bin hier gerade etwas verwirrt ob der Aussage, vielleicht kann das
> jemand mal aufklären.
>
> Grüße
> pbnoxious
>
> On 28/04/2020 17.57, Volker Schmidt wrote:
> > Ich verstehe das tagging da ueberhaupt nicht.
> > Besipiel: Liemekestrasse 
> ist
> > mit seltsaman tags versehen:
> > "motor_vehicle=designated" (d.h. keine Fahrraeder, keine Fussgaenger)
> > obwohl eine Fahrradroute drueberfuehrt?
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
>


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-transit] Making bus lines more specific

[Tijmen Stam]

Hello Robin,

I highly agree with you.
The main reason for PTv2 not having as widespread adoption as it could 
have is that it is not rendered, that is to say, it is not rendered on 
OSM_carto (Osmand's rendering of PTv2 is near-perfect).


However, we're stuck with a rendering "committee" that for years have 
delayed the rendering of PTv2 based on not having the right 
[rendering]datamodel, and now that we have that datamodel, they 
basically say "I oppose the PTv2" and closed all pull requests asking 
for it in may 2019.


See my comment on 
https://github.com/gravitystorm/openstreetmap-carto/pull/3232#issuecomment-491007730


Tijmen / IIVQ





On 28-04-20 13:36, Robin Däneke wrote:
Any tag we could come up with is going to be a partial misnomer for what 
we are trying to model in the Database. In OSM, there are lots of those…


highway=bus_stop on the side of the road is somewhat trivially 
understandable, but that means we need railway=tram_stop, 
railway=train_stop, waterway=ferry_stop and many other tags too, that 
could all be made redundand by the „platform“ node/way/relation being in 
a route relation that is that mean of transport.


The wonderful thing about databases is, that a lot of info kan be given 
on relational levels and inherited by all relation members. We can make 
a bunch of tags redundant by using one. And platform is the most 
truthful there. In Vienna, the Networks (Verkehrsverbunde) are working 
on only having bus stops, that have a visible, higher laying „platform“ 
(or some sort of sidewalk area) at each stop, and I can only imagine, 
the more public_transport gets, the more a bus stop is going to be the 
platform. I think we should not be tagging backwards here.


The pole is a part of the stop, but never „the stop“ itself, even if 
some people tend to see it that way. Alternatively, call it 
public_transport=stop. That would mean one area where pt stops. Then 
that would be the same as a platform, unless it is a node, when that is 
possibly just the pole. But for that, a useful micro-mapping tag 
„public_transport=pole“ would make much more sense, once again then not 
needing bus=yes,tram=yes or something like „bus_stop_pole“ „tram_stop_pole“…


This merging hw=bus_stop, rw=tram_stop into one platform or stop tag 
will make the database much more lean. And in terms of highway=bus_stop 
is difficult to remove: As this tag is the same as the platform (except 
if it is a node connected to a street, then that is a „stop_position" 
and can just be deleted) you could get one mechanical edit to take care 
f it (after getting it approved by the community and/or DWG) So that tag 
is the easiest to just purge from what it’s counterpart in p_t:v2 is!


A stop/platform node on the side of the road does the same, so this is 
just redundancy, and as platform is the more versatile tag, it should 
take precedence in this „tag-fight“.


Thanks for all the input.

KR
RobinD

Am 28.04.2020 um 12:20 schrieb Tony OSM >:


I like node highway=bus_stop for the reasons polyglot gives. bus_stop 
is here to stay cos there are too many to change, by the side of the 
highway they give directionality depending on the customary side of 
the road for driving.


public_transport=platform works well for train and some trams. To me a 
platform is a construct to assist people to get on or off the 
transport vehicle. As a waiting area  - that use is secondary.


In GB some authorities are raising the area around a bus stop to 
enable wheelchair users easier access to buses - so yes a platform tag 
is appropriate, but not for a pole placed in the ground or pedestrian 
part of the road which is the default for buses where I live.


stop_position node - to me has no function - for buses their stop 
position is the bus stop;  for trains they stop at the platform; where 
I live we have 2,3,4,5,6 car trains, the front of the train stops at 
one of two defined positions depending on the number of cars.


Simplification of PTV2 may be helpful, but I have had no strong 
frustrations when using it.


Regards

TonyS999


On 28/04/2020 09:46, Jo wrote:

The basic objection they voice is why need 2 tags, if 1 does the job.

highway=bus_stop

is not exactly nonsensical. It's concise and expresses what is meant. 
(OK, it's not a highway and my preference is to map it next to the 
highway)



public_transport=platform

was designed at first to not need a mode of transport like 
bus=yes/tram=yes. I am the one who proposed adding it, so that it 
COULD start replacing highway=bus_stop back in 2012.


There is not always a platform present, so it's a bit of a misnomer 
as well.


Anyway, someone who wants to render a bus stop ideally wants to look 
at a single tag, not a combination of 2, apparently. For a long time 
it was supposedly a technical problem, but as soon as that was 
resolved somewhere around 2017, it was still considered problematic 
to look at 2 tags.


I wish you good luck with 

Re: [OSM-talk-fr] Libraires et takeaway

[Marc M.]

Bonjour,

Le 28.04.20 à 16:22, Frantz a écrit :
> Que pensez-vous de distinguer avec pickup, déjà utilisé pour les colis :
> - takeaway : achat sur place d'un produit emporté
> - pickup : uniquement retrait d'un produit (sans achat sur place)

veux-tu dire qu'une pizzeria qui propose de commander
sur place ne devrait pas avoir le même tag que si tu
passes la commande par téléphone ?

si oui est-ce que cela ne devrait pas plutôt faire
l'obhjet d'un autre tag genre reservation:media=phone;onsite;web;app ?

Cordialement,
Marc

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

Re: [Talk-transit] Making bus lines more specific

[Tijmen Stam]

I have long ago proposed an addition to the PTv2 "route" schedule, which 
is the "formula" tag. Formula's would be defined within a network (or 
within a nation). For example, in the Netherlands, almost every 
transport network has so-called "buurtbus", litterally "neighbourhood 
bus" although they often run for 30-50 km, in areas too sparsely 
populated for a regular bus. They are driven by volunteers and other 
than it being an 8-person-vehicle, they operate like a normal bus. You 
have to pay, they run a fixed route and timetable.


Next to that, we have several transport authorities demanding the brand 
"R·NET" for faster public transport services.


But then some companies have within their branded network several 
formulas. For example, in the area I work for, the company (Connexxion, 
a subsidary of Transdev) has branded itself as "Overal" (Everywhere) and 
has several lines under formulas as "Buurtbus", "Overal Flex" 
(dial-a-ride on fixed routes and times), "Overal Taxi" (reduced tariff 
taxi), "Texelhopper" (island-specific dial-a-ride).


So I guess this key/value can be used for bus lines like you mean.
Alternatively, a key "brt=yes" can be added. I think the term BRT is 
sufficiently well-known worldwide that is has become something of a 
standard, although what would count as BRT in one area will be the 
lowest quality of buses in others, so it's up to the local transit 
authority to label their bus routes as BRT.

Tijmen / IIVQ

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

Re: [OSM-talk] Let's talk Attribution

[Kathleen Lu via talk]

I find this view quite surprising coming from a software engineer.
I know no major open source license that requires attribution *in the UI
that the user sees without clicking on anything*.
Every example of open source license attribution I have seen is after
several clicks, e.g. Menu->About->Legal Notices->Software
When asked if OSM attribution is the same as open source attribution, my
answer has always been "no, OSM attribution is much stricter."
-Kathleen

On Tue, Apr 28, 2020 at 6:57 AM Mario Frasca  wrote:

> for what it matters, I completely subscribe Skyler's position.
>
> I'm a software engineer, and I produce GPL and AGPL software (not LGPL),
> but I do not have the power to enforce anything, I just hope that people
> will be considerate.
>
> it's surprising that the lax attitude comes from a committee having all
> necessary power.
>
> MF
>
> On 27/04/2020 22:43, Skyler Hawthorne wrote:
> > As a new contributor, and a software engineer, it is surprising to learn
> that there is such a lax attitude towards lack of attribution. Every open
> source software license I can think of has attribution as a central tenet.
> People spend their free time on this stuff, and they do it because they
> care about it. There are people who get pretty upset when they find others
> using their hard work for their own gain without so much as a footnote
> (which is really all the guidelines appear to be asking for).
> >
> > Attribution matters. It lets people know what the project is and that it
> positively impacted their lives. And equally importantly, it bestows a
> modicum of respect and gratitude to the volunteers who spend their free
> time making the project what it is.
> >
> > --
> > Skyler
> >
> > ___
> > 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: [Talk-de] Gewichtung der Straßen im Routing

[pbnoxious]

Also vielleicht verstehe ich das ganze access-Zeug falsch, aber sollte
nicht "motor_vehicle" nur den access für eben diese motorisierten
Gefährte einschränken? Und sonst die Standartwerte gelten (also
foot=yes, bicycle=yes, horse=yes usw.)

Bin hier gerade etwas verwirrt ob der Aussage, vielleicht kann das
jemand mal aufklären.

Grüße
pbnoxious

On 28/04/2020 17.57, Volker Schmidt wrote:
> Ich verstehe das tagging da ueberhaupt nicht.
> Besipiel: Liemekestrasse  ist
> mit seltsaman tags versehen:
> "motor_vehicle=designated" (d.h. keine Fahrraeder, keine Fussgaenger)
> obwohl eine Fahrradroute drueberfuehrt?

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

Re: [Talk-de] Gewichtung der Straßen im Routing

[Tom Pfeifer]

On 28.04.2020 17:35, Florian Lohoff wrote:
> On Tue, Apr 28, 2020 at 03:17:16PM +0200, Tom Pfeifer wrote:
>> Entspricht denn lanes=1 der Realität?
>> Also der Verkehr in beiden Richtungen teilt sich eine Spur?
> 
> Wenn du aneinander vorbei möchtest muss einer auf die Bankette - ja -
> Mindest wenn die ein Trecker oder was breiteres entgegen kommt.

Gut, dann bin ich bei dir, was lanes=1 betrifft.

In England/Irland sind häufig noch engere Straßen anzutreffen, da hast
du statt eines Seitenstreifens hohe Trockensteinmauern oder Hecken.
Da muss einer zurückstoßen, bis irgendwo eine Feldeinfahrt oder Ausweichstelle
kommt.

On 28.04.2020 17:57, Volker Schmidt wrote:
> lanes=1 ohne oneway=no|yes wird von einigen (auch von mir als moeglicher
> Fehler) betrachtet, und ist daher keine gute Idee.

Nein warum - siehe oben.

On 28.04.2020 17:35, Florian Lohoff wrote:
> Die Frage war wie ihr das mit der relativen Gewichtung von
> Routingalternativen bearbeitet und fixed.

Es gibt den Tag "maxspeed:practical", der angibt, wie schnell man
realistischerweise auf einer Strasse vorankommt.
https://wiki.openstreetmap.org/wiki/Key%3Amaxspeed%3Apractical

Auch hierzu das Beispiel Irland - bei der Umstellung der Geschwindigkeiten
von Meilen auf Kilometer pro Stunde hatte man überall, wo das formale
Limit wechselt - typischerweise innerorts 50 und ausserorts 80 - die
rotumrandeten Schilder aufgestellt. Wenn also oben beschriebene
Straße, die sich auch alle paar Meter windet, und gleich der Trecker
um die Ecke kommen konnte, steht da 80 dran, obwohl man sich nur mit
15 vorsichtig vorantasten kann. Da hilft maxspeed:practical dem Router
zu mehr Realismus.

tom

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

Re: [Talk-GB] TfL Cycle Infrastructure Database - matching against OSM

[Brian Prangle]

Hi everyone

Thanks Richard for the huge effort you've put into this ( and Martin) . I'm
happy to help with any manual editing as long as the data is ready-to-go in
JOSM. I think that this is such a vote of confidence in OSM by TfL - and
such a potential global case study - that it warrants a big UK volunteer
takeup to augment the resource that TfL are committing. If it needs
organising as a project then the UK chapter could step into the breach.

Regards

Brian

On Mon, 27 Apr 2020 at 21:16, Rob Nickerson 
wrote:

> Hi Richard, Hi all,
>
> (Sorry for not replying properly to the thread - I don't receive the
> emails into my inbox and nabble is complaining about a broken certificate
> today)
>
> It sounds like you are making good progress. Thanks for all the written
> documentation for those, like myself, who are not so good with ruby. It
> would be good to see those uncontentious edits going in to OSM fairly soon.
> Is the plan to get this fully automated with a test in the dev version of
> osm first?
>
> As for the rest, I am unclear what editor you are planning for people to
> use. Out of interest what editor are the TfL employees being trained on?
> The raster tilesets are obviously a huge advantage but do you plan for
> something that integrates a bit more with the editor? Something along the
> lines of the P2 merging tool, RapID or Hootenanny (also ID)?
>
> Thank you,
> *Rob*
> ___
> 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-de] Gewichtung der Straßen im Routing

[Florian Lohoff]

On Tue, Apr 28, 2020 at 05:57:51PM +0200, Volker Schmidt wrote:
> lanes=1 ohne oneway=no|yes wird von einigen (auch von mir als moeglicher
> Fehler) betrachtet, und ist daher keine gute Idee.

Warum? Woher nimmst du diese Erkenntnis? Gibts in irgendeinem Wiki
Artikel was zu? Das wäre mir völlig neu.

"lanes" beschreibt die Anzahl der markierten! Fahrspuren. D.h. alle
Straßen ohne Fahrbahnmarkierungen sind tendentiell lanes=1 - Der lanes
Artikel spricht davon das dann auch with benutzt werden KANN bzw
das width nützlich sei.

> Kennst du die Gegend persoenlich?

Ja - Aber nicht mein mapping hotspot - Und es geht mir auch nicht um die
millionen Fehler die da rumlungern. Mir sind nur routingänderungen 
aufgefallen die ich für unsinn halte die durch sparse tagging ausgelöst
waren.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

Re: [OSM-talk-fr] gestion du cycle de vie des infos [était: Profusion de clés covid19]

[Marc M.]

Bonjour Stuart,

Le 26.04.20 à 10:36, European Water Project a écrit :
> c'est probablement possible d'ajouter ce metadata sur les tags 
> assez facilement sans besoin d'attendre la nouvelle API

sans attendre, il y a key:date par exemple drink_water:date
mais ce n'est pas une meta.

Je ne vois pas comment ajouter un meta par clef sans modifier
l'api mais je suis ravi d'apprendre comment :)

Cordialement,
Marc

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

Re: [Talk-it] Modifiche massive nomi di strade in seguito a note anonime

[Manuel]

Visto che il documento non è più presente, ho cercato nel sito dell'Agenzia 
delle entrate e ho trovato un documento del 2018 
(https://web.archive.org/web/20191206080650/https://www.agenziaentrate.gov.it/portale/documents/20143/266134/Informativa+Istat_Istruzioni+ordinamento+ecografico.pdf/c7cd141f-4acb-cf5a-42b3-04ade2c69474)
 (versione archiviata, per evitare futuri problemi come il documento 2014). Da 
una scorsa veloce sui punti che ci interessano, mi pare che le norme indicate 
siano comunque le medesime. Non sto dicendo di usare quelle ISTAT, ma se 
vogliamo discutere su un documento ufficiale può essere usato questo.

Il 28/04/2020 18:11, Martin Koppenhoefer ha scritto:

Guardate, *Per tutte le altre regole, fai riferimento al documento*
http://www.agenziaentrate.gov.it/wps/file/Nsilib/Nsi/Schede/FabbricatiTerreni/Portale+per+i+Comuni/Servizi+portale+dei+comuni/toponomastica/Informativa+Istat/Informativa+Istat+ANSC+del+6+maggio_AGGIORNAMENTO+27_11_2014.pdf
e non c'è più. Ci vogliamo veramente basare su questi, che non mantengono 
nemmeno gli URL stabili per più di qualche mese?


--
Manuel Tassi

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

Re: [OSM-talk-ie] Why is Billy parish in Antrim shown as in Athlone Municipal District?

[Alan Grant]

It seems that Nominatim is assigning the island of Ireland as the "parent"
of a lot of parishes and similar boundary relations. Note that it is the
first address item that appears on the details page that Marc linked to.
See the full list in the Parent Of section here:
https://nominatim.openstreetmap.org/details.php?osmtype=R=7681896=place


For all of these, it returns a location near Athlone, presumably because it
is the calculated centre of the island of Ireland.

That sort-of explains why Athlone rather than anywhere else, but it doesn't
explain why the island of Ireland is being treated as the immediate parent
of these parishes in the first place. Especially as it doesn't apply to all
parishes. For example I can't see why the results are different for
Rathbran (which works fine) versus Castlecomer (which doesn't) - see
details at
https://nominatim.openstreetmap.org/details.php?osmtype=R=6236340=boundary
 and
https://nominatim.openstreetmap.org/details.php?osmtype=R=5351850=boundary
respectively.
Unless the "wrong" ones have been added more recently and Nominatim hasn't
fully reflected them in its database? I did notice that Rathbran has a
"computed postcode" and Castlecomer doesn't, but I have no idea if that is
relevant.

As Marc said, this may be something only Nominatim maintainers can answer.

Regards
Alan

On Tue, 28 Apr 2020 at 15:18, Marc Gemis  wrote:

>  it should be returned when the object is outside. => it should NOT be
> returned when the object is outside
>
> On Tue, Apr 28, 2020 at 3:16 PM Marc Gemis  wrote:
> >
> > Brian,
> >
> > I looked at
> https://nominatim.openstreetmap.org/details.php?osmtype=R=10993573=boundary
> > Normally this allows me to understand why a certain admin hierarchy is
> > returned. In this case, I do not understand why the distance is 0.1746
> > for the Athlone Municipal District.
> > It seems to be the admin level 8 that is closest to the centre of
> > Billy Parish. But as it is a relation, it should be returned when the
> > object is outside. (perhaps the relation was not properly closed at
> > the time Nominatim imported the data?)
> >
> > If none here replies you should reach out to the Nominatim maintainers.
> >
> > regards
> > m
> >
> > On Tue, Apr 28, 2020 at 12:40 PM Brian Hollinshead
> >  wrote:
> > >
> > > During the stay at home I have added many CofI parishes to OSM based on
> > > single or combinations of civil parishes.
> > > Please see Billy Parish 10993573, it suggests it is in County
> Roscommon!!
> > > This applies to a number of others as well. Please can somebody
> explain why
> > > to me and also how or who can rectify it. While they all display OK it
> > > might be disconcerting to a person doing a search.
> > > Thank you.
> > > ___
> > > Talk-ie mailing list
> > > Talk-ie@openstreetmap.org
> > > https://lists.openstreetmap.org/listinfo/talk-ie
>
> ___
> Talk-ie mailing list
> Talk-ie@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ie
>
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

Re: [Talk-it] Modifiche massive nomi di strade in seguito a note anonime

[Martin Koppenhoefer]

Am Di., 28. Apr. 2020 um 17:36 Uhr schrieb canfe :

> No, non ci sono due possibilità, ce n'è una sola: quella della wiki.
>
> Cantone Ferruccio (canfe)



Caro Cantone,

magari fosse chiara la wiki, purtroppo per i nomi nella mappa non dice come
fare, dice di fare per stradari, indirizzari e numerazione interna, e dice
di fare così come ISTAT, ma diversamente ("alcune eccezzioni", 14 punti), E
NON CI SONO NEMMENO LE REGOLE COME QUELLA DI NON SCRIVERE TUTTO IN
MAIUSCOLO COME LO PREVEDE ISTAT.

A me sembra una situazione dove le competenze non sono del tutto chiaro, ma
da un punto di vista democratico, il consiglio comunale è direttamente
incaricato dai cittadini, ISTAT no. Capisco che vogliamo rendere facile il
confronto dei nostri dati con i loro, ma non è già possibile, se uno
conosce le regole? Non c'è bisogno eseguire edit automatici senza
conoscenza della situazione reale, dovrebbe essere sufficiente scrivere
regole di traduzione _per il caso di confronto_, invece di modificare i
dati della mappa.

Dipende anche da tutti noi, se i burocrati abbiano il potere che reclamano,
o no ;-)

Guardate, *Per tutte le altre regole, fai riferimento al documento*
http://www.agenziaentrate.gov.it/wps/file/Nsilib/Nsi/Schede/FabbricatiTerreni/Portale+per+i+Comuni/Servizi+portale+dei+comuni/toponomastica/Informativa+Istat/Informativa+Istat+ANSC+del+6+maggio_AGGIORNAMENTO+27_11_2014.pdf
e non c'è più. Ci vogliamo veramente basare su questi, che non mantengono
nemmeno gli URL stabili per più di qualche mese?

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

Re: [Talk-de] Gewichtung der Straßen im Routing

[Volker Schmidt]

lanes=1 ohne oneway=no|yes wird von einigen (auch von mir als moeglicher
Fehler) betrachtet, und ist daher keine gute Idee.

Ich verstehe das tagging da ueberhaupt nicht.
Besipiel: Liemekestrasse  ist
mit seltsaman tags versehen:
"motor_vehicle=designated" (d.h. keine Fahrraeder, keine Fussgaenger)
obwohl eine Fahrradroute drueberfuehrt?
width=4 aber maxspeed=100 passen nicht zusammen.
Dann ist da noch ein tracktype=grade1 an einer Strasse mit 100km/h.

Kennst du die Gegend persoenlich?

Volker




Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Tue, 28 Apr 2020 at 15:18, Tom Pfeifer  wrote:

> On 28.04.2020 14:44, Florian Lohoff wrote:
> > Nachdem ich dann die neue grünen teil mit lanes=1
> > versehen habe ist soeben die route zurück geschwenkt.
>
> Entspricht denn lanes=1 der Realität?
> Also der Verkehr in beiden Richtungen teilt sich eine Spur?
>
> tom
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
>
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-it] Modifiche massive nomi di strade in seguito a note anonime

[Martin Koppenhoefer]

Am Di., 28. Apr. 2020 um 13:50 Uhr schrieb Maurizio Napolitano <
napoo...@gmail.com>:

> Lancio un appello:
> ragioniamo su questa pagina qualora volessimo cambiare la questione?
>
> https://wiki.openstreetmap.org/wiki/IT:Editing_Standards_and_Conventions#Nomi_delle_strade



Mi sembra che già la prima frase è strana: "

L'ISTAT con il documento "ISTRUZIONI PER L’ORDINAMENTO ECOGRAFICO
"
determina la regolamentazione tecnica prevista dalla normativa vigente in
materia di stradario, indirizzario e numerazione interna, che i Comuni
italiani devono seguire.

Anche la comunità italiana ha deciso di seguire queste regole, con alcune
eccezioni."


Visto che si tratta della "regolamentazione tecnica prevista dalla
normativa vigente in materia di stradario, indirizzario e numerazione
interna", e visto che noi discutiamo della mappa, non mi sembra pertinente.
In generale penso sia auspicabile che i nomi delle strade (name su highway)
siano uguali ai "addr:street", per questo non vedo un grande senso
nell'applicazione delle regole di ISTAT nel campo degli indirizzi.

Per i nomi delle strade ci sono le regole dell'intero progetto

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

punta a https://wiki.openstreetmap.org/wiki/Names

e suggerisce nel caso di multipli nomi di mettere ogni variante in un tag
semantico derivato da "name" (tipo short_name).


La pagina https://wiki.openstreetmap.org/wiki/Good_practice

in particolare
https://wiki.openstreetmap.org/wiki/Good_practice#Verifiability

Sui nomi ISTAT il documento è molto chiaro:
Don't map your local legislation, if not bound to objects in realityThings
such as local traffic rules should only be mapped when there are objects
which represent these rules on the ground, e.g. a traffic sign, road
surface marking. Other rules that can not be seen in some way should not be
mapped, as they are not universally verifiable.

essenzialmente significa che un altro mappatore dovrebbe essere in grado di
andare nello stesso posto e raccogliere gli stessi dati ("verificando"
quelli raccolti da chi è passato prima).

Personalmente, sono meno severo di questa verificabilità delle cose "nello
stesso posto", per me questo stesso posto potrebbe essere anche un
documento pubblicamente accessibile (quindi anche una direttiva ISTAT, se
fosse significativa), ma so che altri lo vedono diversamente e non vogliono
sapere di altri fonti che non quelli nel posto / in loco.

Il caso ISTAT è ancora diverso, è una normativa tecnica che descrive come i
comuni devono agire. Ma noi non siamo i comuni, e se i comuni non agiscono,
non ci sta niente da mappare per noi. In loco ci sono maggiormente vecchi
cartelli anche quando i nomi sono stati adeguati (costi ecc.), e quindi
finchè non troviamo le delibere nuove direi che non abbiamo nemmeno motivo
di cambiare il "official_name", certamente non il "name", che dovrebbe
essere il "nome comune" (common default name).
Altre direttive dicono: "Apart from following the above rules, you should
always enter the full name *as it appears on the street name signs*. Be
aware that street signs may contain errors."

https://wiki.openstreetmap.org/wiki/Names

Ciao

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

Re: [OSM-talk-fr] attribution manquante

[osm . sanspourriel]

Le 28/04/2020 à 13:55, Philippe Verdy - ver...@gmail.com a écrit :


Il serait bon que les tiers intervenants pour les sites de l'Education
nationales s'engagent avec une charte contractuelle les obligeant à
maintenir après livraison les défauts et la conformité légale des
sites (les attributions nécessaires, les copyright des images
utilisées, etc.), des oublis sont possibles dans le cadre de
développement accéléré et mise en ligne "au fil de l'eau".


C'est sans doute déjà le cas, le problème n'est pas la clause mais que
les personnes de l’Éducation Nationale ont actuellement d'autres priorités.

Par contre leurs prestataires qui ne doivent pas être à leur première
intégration de carto devraient le savoir et ne devraient pas nécessiter
un rappel de l'Éducation Nationale ou de notre part.

Le 28/04/2020 à 13:55, Philippe Verdy - ver...@gmail.com a écrit :

Ce n'est donc pas un refus ou un abus volontaire, c'est juste un oubli
au milieu de pleins de priorités


On n'a pas dit ça non plus, on dit juste que l'attribution n'est pas une
option.

Il faudrait peut-être proposer une iframe prêt à l'emploi mais c'est
déjà le cas (hormis le fait que les tuiles sont celle de la fondation).

https://www.openstreetmap.org/export/embed.html?bbox=-117.46584177017213%2C34.323838805680516%2C-117.44150876998903%2C34.33916616897204=mapnik;
style="border: 1px solid black">https://www.openstreetmap.org/#map=16/34.3315/-117.4537;>View
Larger Map


View Larger Map 

Jean-Yvon

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

Re: [Talk-it] Modifiche massive nomi di strade in seguito a note anonime

[canfe]

No, non ci sono due possibilità, ce n'è una sola: quella della wiki.

Cantone Ferruccio (canfe)



--
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-de] Gewichtung der Straßen im Routing

[Florian Lohoff]

On Tue, Apr 28, 2020 at 03:17:16PM +0200, Tom Pfeifer wrote:
> On 28.04.2020 14:44, Florian Lohoff wrote:
> > Nachdem ich dann die neue grünen teil mit lanes=1
> > versehen habe ist soeben die route zurück geschwenkt.
> 
> Entspricht denn lanes=1 der Realität?
> Also der Verkehr in beiden Richtungen teilt sich eine Spur?

Wenn du aneinander vorbei möchtest muss einer auf die Bankette - ja -
Mindest wenn die ein Trecker oder was breiteres entgegen kommt.

Ich frage mich aber warum sich alle an DIESEM konkreten fall hochziehen.
Die Frage war wie ihr das mit der relativen Gewichtung von
Routingalternativen bearbeitet und fixed.

Oder bin ich der einziger der sich sowas systematisch ansieht?

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

[talk-cz] Online mapathon MissingMaps

[Jan Macura]

Zdravím ve spolek,

již za něco málo přes hodinu máte další příležitost zúčastnit se mapathonu
Missing Maps.

Začátek dnes v 18.00. Připojit se je možné přes
https://bluejeans.com/6911373877, kde zadáte Meeting ID 691 137 3877, bez
hesla, instalace není nutná.

Další informace najdete na OSM wiki:
https://wiki.openstreetmap.org/wiki/Cs:Mapathon/online

Jsou vítáni jak zkušení mapaři tak i začátečníci.

Na (virtuální) setkání se těší
 Honza Macura
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-it] Modifiche massive nomi di strade in seguito a note anonime

[Alessandro P. via Talk-it]

  
  
Il 28/04/20 11:53, Martin Koppenhoefer
  ha scritto:


  
  

  Am Di., 28. Apr. 2020 um
08:25 Uhr schrieb Francesco Ansanelli :
  
  

  

  

  

  
  
  1) innanzitutto vi chiedo un parere su
che cosa debba andare nel tag "name": a mio
parere si mappa quello che c'è sul campo
(nel caso della nota in questione "Via Pio
XI", che compare sui cartelli) e si potrebbe
usare "alt_name" o anche "official_name",
che vedo esistere, per altri nomi come
quello ISTAT. Ma su questo accetto
volentieri pareri da chi è più esperto.

  

  

  
  
  
  Concordo. Ma official_name è un tag
equivoco perché molto spesso lungo le strade ci sono più
versioni del nome. 

  
  
  
  
  
  infatti, "official_name" non è il nome che si trova sul
cartello, è il nome che si trova nella delibera comunale che
ha istituito il nome. ISTAT (e quantomeno chi produce
cartelli stradali) non può cambiare i nomi, lo devono fare i
consigli comunali tramite delibera.
  



  


Ciao,
come scrissi alcuni anni fa, anche leggendo le targhe a volte si
rimane nel dubbio. Tempo fa a Genova sue 3 targhe di una via, la più
vecchia riportava nome e cognome per esteso, una seconda l'iniziale
del nome e il cognome, la terza il solo cognome. :-)
In molti casi io utilizzo name e alt_name; a volte uso anche
short_name, che è il nome con cui si cita abitualmente la strada (ad
esempio: Corso Garibaldi https://www.openstreetmap.org/way/34203490
).

Sò che non ho dato alcun contributo a dirimere la questione, perchè
secondo me non riusciremo a raggiungere un accordo. Io cerco di
usare il (mio) buon senso e allo stesso tempo cercare di rendere
fruibile la paccata di dati presenti nel dB di OSM.

Alessandro Ale_Zena_IT
  


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

Re: [OSM-talk-fr] Libraires et takeaway

[Frantz]

28 avril 2020 11:18 "leni"  a écrit:

> ce serait donc takeaway:covid19=only et reservation:covid19=required
> puisque le reste du temps tu n'as pas besoin de réserver

Je m'en sors avec :
- opening_hours:covid19=open : un service est proposé
- access:covid19=no : il faut commander avant de se déplacer
- takeaway:covid19=yes : à emporter, ce qui hors restaurant peut se comprendre 
comme retrait
- description:covid19=Uniquement retrait après commande par téléphone : vu la 
période, la priorité c'est d'être clair quitte à doubler ;)

-- 
Frantz

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

Re: [OSM-talk-fr] Libraires et takeaway

[Frantz]

Bonjour,

28 avril 2020 10:58 "Marc M."  a écrit:

> takeaway indique que tu emportes au lieu de "consommer" sur place.
> donc à priori je ne vois pas ce qui empêche de généraliser à un service
> non-alimentaire, c'est même une bonne idée de généraliser.
> 
> Mais takeaway=yes est à mon avis par défaut pour une librairie:
> un librairie permet d'emporter le livre pour le "consommer" chez soi.

C'est en effet un manque qui apparaît particulièrement en ce moment.

Que pensez-vous de distinguer avec pickup, déjà utilisé pour les colis :
- takeaway : achat sur place d'un produit emporté
- pickup : uniquement retrait d'un produit (sans achat sur place)

-- 
Frantz

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

Re: [Talk-it] [Import] Bologna - Coronavirus spesa a domicilio

[Cascafico Giovanni]

Il giorno mar 28 apr 2020 alle ore 10:32 Martin Koppenhoefer <
dieterdre...@gmail.com> ha scritto:
> > On 28. Apr 2020, at 09:50, Cascafico Giovanni 
wrote:
> > Ho pensato ad un import tramite umap e level0.
> > 600+ nodi non solo pochi, ma ho trovato problemi a taggare
automaticamente. Se pensate possa essere oneroso, posso riconsiderare un
import automatico.
>
> visto che si usano tag specifici (*:covid19), dal mio punto di vista la
cosa più importante sarebbe la conflation (sia l’identificazione di POI già
esistenti, per aggiungere queste proprietà covid, sia il fatto che non
sovrascriviamo i valori covid su oggetti taggati già (però possiamo
verificare in caso ci sono contraddizioni). Se si riuscisse a fare questo
in automatico, per me sarebbe ok.

Questo sarebbe un import manuale, nel senso che la mappa che ho preparato
presenta (suggerisce) dei tag OSM da fondere con gli eventuali POI
preesistenti: il tagging e la conflation quindi la fa il mappatore per ogni
POI, portando (come valore aggiunto) lo sforzo semantico nel tradurre
categoria, descrizione (e se non basta info in rete) in tag OSM. Potrebbe
essere una richiesta un po' impegnativa (il numero di POI è oltre i 600).
Se tale numero rappresentasse quindi uno scoglio, potrei preparare un
import automatico, ma sarebbe prono a diversi errori sui tag (senza
comunque sovrascriverne).

Insomma, l'editor Level0 è abbastanza semplice e, sopratutto, veloce.
Magari vale la pena provare con qualche edit, senza farvi spaventare da
quanto scritto sopra ;-)
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-ie] Overpass query?

[John Kennedy]

Good stuff Brian.

Just looking at Cork Airport, it appears that when overpass looks for Civil
parishes inside area["name"="Diocese of Cloyne"] it includes Cork Airport
civil parish for some reason. This may be a limitation of how overpass or
underlying technologies calculate geospatial queries - possibly based on
civil parish centroids, approximation of diocese area by concave hulls etc.
rather than precise polygon boundary definitions.

I won't investigate further but I guess key point is it is always worth
checking overpass query results visually for accuracy too.

Cheerio
 - John



On Tue, 28 Apr 2020 at 14:46, Brian Hollinshead 
wrote:

> John and Donal, This made it so easy. In under eleven minutes I loaded all
> 87 civil parishes into Josm and Excluding the four in Ardfert, there was
> one duplicate name, selected the 83 I wanted, the downloaded all the
> members, then using John's select the dissolved members I created a new
> Diocese of Cork relation, changed the three enclaves from outer to inner ,
> uploaded the file and sat back. So much easier than any other method.
> many thanks for your interest.
>
> On Tue, 28 Apr 2020 at 12:30, John Kennedy  wrote:
>
> > Hi Brian.
> > Does this work?
> >
> > https://overpass-turbo.eu/s/TnN
> >
> > I attempt to gather all CPs in Cork.
> > Then all CPs in the mapped dioceses.
> > Then take the difference.
> >
> > But I just query by area name - this could be tightened further.
> >
> > Rgds/
> >  - John
> >
> >
> >
> >
> > On Tue, 28 Apr 2020 at 09:20, Brian Hollinshead 
> > wrote:
> >
> > > Hi Donal,
> > > Thanks for having a go at that overpass query. Your offer showed the
> > > Diocese of Ardfert which has perhaps six Cork civil parishes. I had not
> > > included it in my enquiry for fear of complicating it further.
> > >
> > > If you run overpass, include all County Cork on screen and use wizard:
> > > boundary=historic_diocese, the resultant white space is the Diocese of
> > Cork
> > > (1837)  from which i wish to load all the civil parishes into JOSM for
> > > further progress.
> > >
> > > For anyone new to this conversation that is : all the civil parishes in
> > > County cork not already mapped in OSM as parts or all of the Dioceses
> of
> > > Ardfert and Aghadoe, Cloyne or Ross. (as boundary=historic_diocese)
> > >
> > > Further suggestions from anyone more familiar with overpass than I am
> > will
> > > be most welcome.
> > >
> > > Thanks
> > >
> > > On Tue, 28 Apr 2020 at 00:17, Donal Hunt 
> > > wrote:
> > >
> > > > Hi Brian,
> > > >
> > > > I tried to take a stab at this but overpass got the better of me!!
> > > >
> > > > Here is what I've got so far: https://overpass-turbo.eu/s/Tn4
> > > >
> > > > This will give you an area excluding the two diocese relations you
> > > > mentioned. I think you either need to do a map_to_area or a Recurse
> > > up/down
> > > > relations function after that but I can't wrap my head around that
> part
> > > and
> > > > there are few examples that explain it well enough...
> > > >
> > > > Also - in hindsight, my query result only returns other diocesan
> areas
> > > that
> > > > are not Ross / Cloyne. There are obviously parts of Cork that aren't
> > > > contained within a diocesan area right now.
> > > >
> > > > Hopefully one of the overpass gurus here will put us out of our
> > misery!!
> > > =)
> > > >
> > > > Donal
> > > >
> > > > On Sat, Apr 25, 2020 at 4:38 PM Brian Hollinshead <
> > br...@hollinshead.net
> > > >
> > > > wrote:
> > > >
> > > > > Overpass query: County Cork comprises the Dioceses of Cloyne, Cork
> > and
> > > > > Ross. I have added Cloyne and Ross as boundary=historic_diocese to
> > OSM.
> > > > > Please can I use overpass to load the remaining civil parishes into
> > > JOSM.
> > > > > Something  like  boundary=civil_parish in "County Cork" BUT NOT
> > > > > (boundary=civil_parish in "Diocese of Cloyne") OR NOT
> > > > > (boundary=civil_parish in "Diocese of Ross). I seem to remember
> that
> > > > > boundary!=xxx omits what follows but am unsure.
> > > > > Thanks
> > > > > ___
> > > > > Talk-ie mailing list
> > > > > Talk-ie@openstreetmap.org
> > > > > https://lists.openstreetmap.org/listinfo/talk-ie
> > > > >
> > > >
> > > >
> > > > --
> > > > Donal Hunt
> > > > OpenStreetMap Ireland
> > > > donal.h...@openstreetmap.ie | +353 87 8175123
> > > > ___
> > > > Talk-ie mailing list
> > > > Talk-ie@openstreetmap.org
> > > > https://lists.openstreetmap.org/listinfo/talk-ie
> > > >
> > > ___
> > > Talk-ie mailing list
> > > Talk-ie@openstreetmap.org
> > > https://lists.openstreetmap.org/listinfo/talk-ie
> > >
> > ___
> > Talk-ie mailing list
> > Talk-ie@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-ie
> >
> ___
> Talk-ie mailing list
> Talk-ie@openstreetmap.org

Re: [OSM-talk] Let's talk Attribution

[Mario Frasca]

for what it matters, I completely subscribe Skyler's position.

I'm a software engineer, and I produce GPL and AGPL software (not LGPL), 
but I do not have the power to enforce anything, I just hope that people 
will be considerate.


it's surprising that the lax attitude comes from a committee having all 
necessary power.


MF

On 27/04/2020 22:43, Skyler Hawthorne wrote:

As a new contributor, and a software engineer, it is surprising to learn that 
there is such a lax attitude towards lack of attribution. Every open source 
software license I can think of has attribution as a central tenet. People 
spend their free time on this stuff, and they do it because they care about it. 
There are people who get pretty upset when they find others using their hard 
work for their own gain without so much as a footnote (which is really all the 
guidelines appear to be asking for).

Attribution matters. It lets people know what the project is and that it 
positively impacted their lives. And equally importantly, it bestows a modicum 
of respect and gratitude to the volunteers who spend their free time making the 
project what it is.

--
Skyler

___
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-ie] Overpass query?

[Brian Hollinshead]

John and Donal, This made it so easy. In under eleven minutes I loaded all
87 civil parishes into Josm and Excluding the four in Ardfert, there was
one duplicate name, selected the 83 I wanted, the downloaded all the
members, then using John's select the dissolved members I created a new
Diocese of Cork relation, changed the three enclaves from outer to inner ,
uploaded the file and sat back. So much easier than any other method.
many thanks for your interest.

On Tue, 28 Apr 2020 at 12:30, John Kennedy  wrote:

> Hi Brian.
> Does this work?
>
> https://overpass-turbo.eu/s/TnN
>
> I attempt to gather all CPs in Cork.
> Then all CPs in the mapped dioceses.
> Then take the difference.
>
> But I just query by area name - this could be tightened further.
>
> Rgds/
>  - John
>
>
>
>
> On Tue, 28 Apr 2020 at 09:20, Brian Hollinshead 
> wrote:
>
> > Hi Donal,
> > Thanks for having a go at that overpass query. Your offer showed the
> > Diocese of Ardfert which has perhaps six Cork civil parishes. I had not
> > included it in my enquiry for fear of complicating it further.
> >
> > If you run overpass, include all County Cork on screen and use wizard:
> > boundary=historic_diocese, the resultant white space is the Diocese of
> Cork
> > (1837)  from which i wish to load all the civil parishes into JOSM for
> > further progress.
> >
> > For anyone new to this conversation that is : all the civil parishes in
> > County cork not already mapped in OSM as parts or all of the Dioceses of
> > Ardfert and Aghadoe, Cloyne or Ross. (as boundary=historic_diocese)
> >
> > Further suggestions from anyone more familiar with overpass than I am
> will
> > be most welcome.
> >
> > Thanks
> >
> > On Tue, 28 Apr 2020 at 00:17, Donal Hunt 
> > wrote:
> >
> > > Hi Brian,
> > >
> > > I tried to take a stab at this but overpass got the better of me!!
> > >
> > > Here is what I've got so far: https://overpass-turbo.eu/s/Tn4
> > >
> > > This will give you an area excluding the two diocese relations you
> > > mentioned. I think you either need to do a map_to_area or a Recurse
> > up/down
> > > relations function after that but I can't wrap my head around that part
> > and
> > > there are few examples that explain it well enough...
> > >
> > > Also - in hindsight, my query result only returns other diocesan areas
> > that
> > > are not Ross / Cloyne. There are obviously parts of Cork that aren't
> > > contained within a diocesan area right now.
> > >
> > > Hopefully one of the overpass gurus here will put us out of our
> misery!!
> > =)
> > >
> > > Donal
> > >
> > > On Sat, Apr 25, 2020 at 4:38 PM Brian Hollinshead <
> br...@hollinshead.net
> > >
> > > wrote:
> > >
> > > > Overpass query: County Cork comprises the Dioceses of Cloyne, Cork
> and
> > > > Ross. I have added Cloyne and Ross as boundary=historic_diocese to
> OSM.
> > > > Please can I use overpass to load the remaining civil parishes into
> > JOSM.
> > > > Something  like  boundary=civil_parish in "County Cork" BUT NOT
> > > > (boundary=civil_parish in "Diocese of Cloyne") OR NOT
> > > > (boundary=civil_parish in "Diocese of Ross). I seem to remember that
> > > > boundary!=xxx omits what follows but am unsure.
> > > > Thanks
> > > > ___
> > > > Talk-ie mailing list
> > > > Talk-ie@openstreetmap.org
> > > > https://lists.openstreetmap.org/listinfo/talk-ie
> > > >
> > >
> > >
> > > --
> > > Donal Hunt
> > > OpenStreetMap Ireland
> > > donal.h...@openstreetmap.ie | +353 87 8175123
> > > ___
> > > Talk-ie mailing list
> > > Talk-ie@openstreetmap.org
> > > https://lists.openstreetmap.org/listinfo/talk-ie
> > >
> > ___
> > Talk-ie mailing list
> > Talk-ie@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-ie
> >
> ___
> Talk-ie mailing list
> Talk-ie@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ie
>
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

Re: [Talk-transit] Making bus lines more specific

[Robin Däneke]

Sorry, I sent this mail only to Dave, sending it to the list for reference too.



> -It is a current, valid tag that's more detailed, clear, precise & more 
> popular than PTv2 equivalent.

That needs 100 other tags in other tagging families to make any sense, and 
hence helps to clutter up the database. I feel like many forget: OSM is not a 
map, it is a database. And sidenote: there are axioms/rules on what not to do 
in a database. OSM is the best example for any of those. 

> Platforms should only be mapped if there's a clear, raised section of 
> pavement for boarding a bus/tram. In OSM we map the physical world.

More and more stops have these. If we do not want the platform to be a simple 
way to say „public transport stops here“ but as this „real world“ definition, 
then that should be only even used when micro mapping, not as a general tag, 
but it is used as a general tag, so your definition is just not the tag 
definition, as that would not be allowed to be a node then...

> highway=bus_stop is far more "dedicated" than public_transport=platform which 
> require further tags to clarify.

if relations are correctly used (as they should be in a database) no 
elaborating tag is needed on the single platform.

> Oh dear.
> PTv2 was sold as a complete schema, fully formed with no requirements for 
> amendments, yet there are these frequent proposals to tweak.

Because no one shouted at each mapper that didn’t adopt the voted for scheme, 
so many kept mapping in old ways or mixed it wrongly. Also, the old tags were 
kept carefully instead of booting them out when they shuld have left the 
dataset 9 years ago. Now that we have the problem, we should solve it and not 
be so ignorant and conservative of the mixed bag of screw-up that this has 
become. 

> PTv2 adds nothing but extra tags & confusion. It runs in parallel to a schema 
> which has worked well since the OSMs inception. 

To me, the singular highway=bus_stop nodes that were strewn across the 
countryside, on the side of many roads with no name tags, no relations and 
nothing else, has not worked in the slightest. It worked as much, if not less, 
than how p_t:v2 could work if everybody would have moved to it in 2010.

Public transport is a complex topic. It is surely not as easy as mapping 
„amenity=waste_basket“ or „highway=street_lamp“. It has it’s complex sides, and 
especially because of that there should not be 100 low level tags to determine 
the type of something but rather one easy-to-map general one (for buses, trams, 
trains, boats, aerialways… alike) to map the area where people wait (as this is 
ALWAYS the same thing, a platform in one valid sense) and deal with what stops 
there in the more complex part (relations), without which, public_transport 
mapping is useless and could be stopped instantly.

> Time to drop it completely.

No, public_transport is its own category that deserves its own tags. Especially 
as the railway=* tags have quite a lot of technical and operational sub-tags, 
that have nothing to do with passenger transit. We should definitely have an 
own category for the, to most people important kind of transport. Disconnected 
from more technical tagging families.

That is my rational here.

Whatever I come up with (and will ask for constructive critisism about here) in 
the future shall be, what p_t:v2 didn’t even try to be. The p_t-community made, 
small attempts at best to make it „the solution“ it was supposed to be. I am 
fighting with this inbetween state since that scheme came into existence. Could 
we please finally fix it, and then have it properly accepted (maybe with 
technical aid of OSMF/DWG) almost 10 years later? Is that truely much to ask 
for?

KR
RobinD

PS: In public transport, there are some things (like routes) that make sense in 
the database, but do not, as such, exist physically. The „we map the real 
world“ is such an outdated view. The world of relevant geo-referenced data has 
become to big to just map trash cans and trees. Because the OSM wouldn’t be 
much more, if not also some theoretical concepts would have made it into it. I 
am sure we could discuss the definition of what a building is, how a company is 
a „real“ thing or whatever, but that would be besides this topic.
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [OSM-talk-fr] gestion du cycle de vie des infos [était: Profusion de clés covid19]

[Philippe Verdy]

Même sans API OSM pour le faire, il y a moyen de développer des outils qui
vont fouiller les évolutions "tag par tag" pour voir ce qui est réellement
changé : la valeur du tag (modification, ajout ou suppression) ou la
géométrie.

De tels outils peuvent se spécialiser par domaine (liste thématique des
tags surveillés).

Bref un outil de veille qualité comparable à Osmose, mais allant fouiller
dans les dates des changesets, et utilisant des recherches de listes
d'objets surveillés avec des requêtes façon Overpass (si nécessaire sur sa
propre base locale importée et alimentée avec les diffs), pour ensuite
alimenter sa base séparée de suivi thématique de ces objets (cette base
thématique peut se réduire à uniquement ces objets).

Un tel outil permettrait des statistiques thématiques pour savoir "où on en
est" et mesurer zone par zone le degré de couverture et de fraîcheur pour
ces objets, pourrait réalimenter automatiquement une tâche de type
"maproulette" pour le passage en révision au delà d'un délai passé
(ajustable en fonction des priorités, les plus anciens en premier) et un
rendu des objets trouvés sur une carte comme le fait Osmose.

Il commencerait au départ sur une thématique réduite (et dans une zone
géographique limitée), ensuite si la base locale de suivi le permet,
ajouter de nouvelles thématiques de suivi et étendre la zone géographique.

Cette fonctionnalité au final pourrait aussi être ajoutée à Osmose,
indépendamment de ses autres analyses de qualité existantes, qui pour
l'instant ne visent pas à évaluer la fraicheur (ni réellement le degré de
couverture sauf sur les sources de données externes "à intégrer").






Le sam. 25 avr. 2020 à 15:49, Marc M.  a écrit :

> Bonjour Stuart,
>
> Je suis bien conscient que c'est totalement insuffisant.
> mais je suis partisan de la politique des petits pas :
> sans admin osm.org, même avec notre "accord" sur l'utilité
> d'une metadata par tag, cela n'aura pas lieu à court terme
> non seulement parce que api v0.7 n'est pas pour demain mais
> surtout qu'il y a une résistance à l'envisager.
>
> Du coup je pense que le meilleur moyen pour que cela aboutise
> un jour, c'est d'utilise ce qu'on a (les metadata par objet et
> survey:date), montrer que c'est utile et qu'il y a une utilité
> à aller + loin.
>
> donc je vise petit. si ta fontaine est aussi veille que
> https://www.openstreetmap.org/way/46627516
> cela ne sert a rien de se poser la question de quand date
> la dernier vérif du panneau "eau potable".
> Par contre on peux facilement rajouter dans la liste
> "eau potable : vérif toute les... 3 ans ?"
> (valeur arbitraire, chaque utilisateur choisit ses priorités,
> qui varient sûrement en fonction de la densité de point d'eau
> dans les environs).
>
> Cordialement,
> Marc
>
> Le 21.04.20 à 16:31, European Water Project a écrit :
> > Bonjour Marc,
> >
> > De regarder la date de dernière change set d'un objet ou le tag
> > survey:date d'un objet est certe beaucoup mieux que rien, mais me semble
> > peu ambitieux par rapport à une solution avec du meta data au niveau
> > clef.Par exemple, quelqu'un qui vérifie dans un survey,  l'existence
> > d'une fontaine, ne vérifiera pas systématiquement la potabilité de l'eau
> > ou si l'eau coule. .. qq chose qui devrait être fait tous les x années
> > selon le pays et la région.
> >
> >
> https://wiki.openstreetmap.org/wiki/Rarely_verified_and_third-party_data_staleness_in_OpenStreetMap
>
> >
> >
> >
> >
> >
> > A bientôt,
> >
> >
> >
> >
> >
> > Stuart
> >
> >
> >
> > On Tue, 21 Apr 2020 at 15:24, Marc M.  > > wrote:
> >
> > Bonjour,
> >
> > Merci Stuart d'avoir relancé le sujet ici.
> >
> > Le 21.04.20 à 14:09, European Water Project a écrit :
> > > Est-ce qu'OSMdevrait réfléchir à une durée de vie, si pas vérifiés,
> > > pour certains tags ?
> >
> > je pense que oui, j'ai dans l'idée que nous pourrions construire
> > communautairement une liste de catégorie, un peu comme celle de ta
> page.
> > l'important dans un premier temps n'est pas tant de mettre une durée
> de
> > vie sur des données mais de les classer relativement entre elle.
> >
> > exemple et ordre de grandeur qui me vient en tête :
> > batiment en construction : vérif mensuel
> > borne véhicule électrique : 6 mois
> > commerce : vérif annuelle
> > borne incendie : 2 ans
> > caractéristiques des batiments existant : 10 ans
> >
> > les valeurs exacte importe peu (chacun devrait pouvoir choisir
> > un multiple de celle-ci pour cibler d'abord le "pire" en terme
> > de fraicheur)
> > Mais un ordre de grandeur permet de faire des apps du genre :
> > - si un objet importé n'a jamais été vu (au sens source=survey),
> > proposer à quelqu'un de le valider (et donc améliorer souvent
> > sa position et rajouter d'autre info.
> > (c'est le sens de Geocropping)
> > - si une zone en construction a + de X mois,
> > demander au 

Re: [Talk-de] Gewichtung der Straßen im Routing

[Tom Pfeifer]

On 28.04.2020 14:44, Florian Lohoff wrote:
> Nachdem ich dann die neue grünen teil mit lanes=1
> versehen habe ist soeben die route zurück geschwenkt.

Entspricht denn lanes=1 der Realität?
Also der Verkehr in beiden Richtungen teilt sich eine Spur?

tom

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

Re: [OSM-talk-ie] Why is Billy parish in Antrim shown as in Athlone Municipal District?

[Marc Gemis]

Brian,

I looked at 
https://nominatim.openstreetmap.org/details.php?osmtype=R=10993573=boundary
Normally this allows me to understand why a certain admin hierarchy is
returned. In this case, I do not understand why the distance is 0.1746
for the Athlone Municipal District.
It seems to be the admin level 8 that is closest to the centre of
Billy Parish. But as it is a relation, it should be returned when the
object is outside. (perhaps the relation was not properly closed at
the time Nominatim imported the data?)

If none here replies you should reach out to the Nominatim maintainers.

regards
m

On Tue, Apr 28, 2020 at 12:40 PM Brian Hollinshead
 wrote:
>
> During the stay at home I have added many CofI parishes to OSM based on
> single or combinations of civil parishes.
> Please see Billy Parish 10993573, it suggests it is in County Roscommon!!
> This applies to a number of others as well. Please can somebody explain why
> to me and also how or who can rectify it. While they all display OK it
> might be disconcerting to a person doing a search.
> Thank you.
> ___
> Talk-ie mailing list
> Talk-ie@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ie

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

Re: [OSM-talk-ie] Why is Billy parish in Antrim shown as in Athlone Municipal District?

[Marc Gemis]

 it should be returned when the object is outside. => it should NOT be
returned when the object is outside

On Tue, Apr 28, 2020 at 3:16 PM Marc Gemis  wrote:
>
> Brian,
>
> I looked at 
> https://nominatim.openstreetmap.org/details.php?osmtype=R=10993573=boundary
> Normally this allows me to understand why a certain admin hierarchy is
> returned. In this case, I do not understand why the distance is 0.1746
> for the Athlone Municipal District.
> It seems to be the admin level 8 that is closest to the centre of
> Billy Parish. But as it is a relation, it should be returned when the
> object is outside. (perhaps the relation was not properly closed at
> the time Nominatim imported the data?)
>
> If none here replies you should reach out to the Nominatim maintainers.
>
> regards
> m
>
> On Tue, Apr 28, 2020 at 12:40 PM Brian Hollinshead
>  wrote:
> >
> > During the stay at home I have added many CofI parishes to OSM based on
> > single or combinations of civil parishes.
> > Please see Billy Parish 10993573, it suggests it is in County Roscommon!!
> > This applies to a number of others as well. Please can somebody explain why
> > to me and also how or who can rectify it. While they all display OK it
> > might be disconcerting to a person doing a search.
> > Thank you.
> > ___
> > Talk-ie mailing list
> > Talk-ie@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-ie

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

Re: [Talk-transit] Making bus lines more specific

[Dave F via Talk-transit]

On 28/04/2020 08:45, Robin Däneke wrote:

Hello everybody,

I have lately been thinking about somehow reworking (or giving a new push to) 
the current p_t:v2 scheme.
Especially for the fact, that, since it was first proposed and accepted, not a 
lot has changed in which tags are rendered, how certain things are hence mapped 
and the Wiki-Pages on the topic have also changed in the last years without any 
visible going through another proposal process.

When I started mapping in 2011, and first read the german and then the english 
p:t:v2 wiki pages, it was:
- highway=bus_stop is a legacy tag that should eventually be completely phased 
out


It is a current, valid tag that's more detailed, clear, precise & more 
popular than PTv2 equivalent.



- stop positions and platforms are to be both mapped


Platforms should only be mapped if there's a clear, raised section of 
pavement for boarding a bus/tram. In OSM we map the physical world.



and some other things I already forgot…
Now, iD has a rule in its verifyer, that requires highway=bus_stop on platform 
nodes. The point of the public_transport tags is, among other points, to 
replace less dedicated highway tags.


highway=bus_stop is far more "dedicated" than public_transport=platform 
which require further tags to clarify.



I think it would be time for a p_t:v2.5 proposal,


Oh dear.
PTv2 was sold as a complete schema, fully formed with no requirements 
for amendments, yet there are these frequent proposals to tweak.


PTv2 adds nothing but extra tags & confusion. It runs in parallel to a 
schema which has worked well since the OSMs inception. Time to drop it 
completely.


DaveF

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

Re: [OSM-talk-ie] Overpass query?

[Brian Hollinshead]

John,
All civil parishes show if you run boundary=civil_parish in Overpass.

On Tue, 28 Apr 2020 at 13:04, John Kennedy  wrote:

> Cool. Yep, I was lucky spotted the difference description:
> https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#Difference
>
> Brian, I just noticed that Cork Airport and nearby are not highlighted in
> the results...maybe the civil parish definitions are missing/broken in
> those areas.
> Rgds/
>  - John.
>
> On Tue, 28 Apr 2020 at 12:52, Brian Hollinshead 
> wrote:
>
> > Hi John,
> > That is great thank you. It does include the four parishes from Diocese
> of
> > Ardfert but I can cope the that. I did not want all the Cloyne Parishes
> in
> > Cork County lest there would be duplicate names.
> >
> > Regards
> >
> > On Tue, 28 Apr 2020 at 12:30, John Kennedy  wrote:
> >
> > > Hi Brian.
> > > Does this work?
> > >
> > > https://overpass-turbo.eu/s/TnN
> > >
> > > I attempt to gather all CPs in Cork.
> > > Then all CPs in the mapped dioceses.
> > > Then take the difference.
> > >
> > > But I just query by area name - this could be tightened further.
> > >
> > > Rgds/
> > >  - John
> > >
> > >
> > >
> > >
> > > On Tue, 28 Apr 2020 at 09:20, Brian Hollinshead  >
> > > wrote:
> > >
> > > > Hi Donal,
> > > > Thanks for having a go at that overpass query. Your offer showed the
> > > > Diocese of Ardfert which has perhaps six Cork civil parishes. I had
> not
> > > > included it in my enquiry for fear of complicating it further.
> > > >
> > > > If you run overpass, include all County Cork on screen and use
> wizard:
> > > > boundary=historic_diocese, the resultant white space is the Diocese
> of
> > > Cork
> > > > (1837)  from which i wish to load all the civil parishes into JOSM
> for
> > > > further progress.
> > > >
> > > > For anyone new to this conversation that is : all the civil parishes
> in
> > > > County cork not already mapped in OSM as parts or all of the Dioceses
> > of
> > > > Ardfert and Aghadoe, Cloyne or Ross. (as boundary=historic_diocese)
> > > >
> > > > Further suggestions from anyone more familiar with overpass than I am
> > > will
> > > > be most welcome.
> > > >
> > > > Thanks
> > > >
> > > > On Tue, 28 Apr 2020 at 00:17, Donal Hunt <
> donal.h...@openstreetmap.ie>
> > > > wrote:
> > > >
> > > > > Hi Brian,
> > > > >
> > > > > I tried to take a stab at this but overpass got the better of me!!
> > > > >
> > > > > Here is what I've got so far: https://overpass-turbo.eu/s/Tn4
> > > > >
> > > > > This will give you an area excluding the two diocese relations you
> > > > > mentioned. I think you either need to do a map_to_area or a Recurse
> > > > up/down
> > > > > relations function after that but I can't wrap my head around that
> > part
> > > > and
> > > > > there are few examples that explain it well enough...
> > > > >
> > > > > Also - in hindsight, my query result only returns other diocesan
> > areas
> > > > that
> > > > > are not Ross / Cloyne. There are obviously parts of Cork that
> aren't
> > > > > contained within a diocesan area right now.
> > > > >
> > > > > Hopefully one of the overpass gurus here will put us out of our
> > > misery!!
> > > > =)
> > > > >
> > > > > Donal
> > > > >
> > > > > On Sat, Apr 25, 2020 at 4:38 PM Brian Hollinshead <
> > > br...@hollinshead.net
> > > > >
> > > > > wrote:
> > > > >
> > > > > > Overpass query: County Cork comprises the Dioceses of Cloyne,
> Cork
> > > and
> > > > > > Ross. I have added Cloyne and Ross as boundary=historic_diocese
> to
> > > OSM.
> > > > > > Please can I use overpass to load the remaining civil parishes
> into
> > > > JOSM.
> > > > > > Something  like  boundary=civil_parish in "County Cork" BUT NOT
> > > > > > (boundary=civil_parish in "Diocese of Cloyne") OR NOT
> > > > > > (boundary=civil_parish in "Diocese of Ross). I seem to remember
> > that
> > > > > > boundary!=xxx omits what follows but am unsure.
> > > > > > Thanks
> > > > > > ___
> > > > > > Talk-ie mailing list
> > > > > > Talk-ie@openstreetmap.org
> > > > > > https://lists.openstreetmap.org/listinfo/talk-ie
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Donal Hunt
> > > > > OpenStreetMap Ireland
> > > > > donal.h...@openstreetmap.ie | +353 87 8175123
> > > > > ___
> > > > > Talk-ie mailing list
> > > > > Talk-ie@openstreetmap.org
> > > > > https://lists.openstreetmap.org/listinfo/talk-ie
> > > > >
> > > > ___
> > > > Talk-ie mailing list
> > > > Talk-ie@openstreetmap.org
> > > > https://lists.openstreetmap.org/listinfo/talk-ie
> > > >
> > > ___
> > > Talk-ie mailing list
> > > Talk-ie@openstreetmap.org
> > > https://lists.openstreetmap.org/listinfo/talk-ie
> > >
> > ___
> > Talk-ie mailing list
> > Talk-ie@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-ie
> >
> 

Re: [OSM-talk-fr] Faut-il dissuader :?==?utf-8?q? addr:city La Ronze addr:postcode ddlll

[Philippe Verdy]

On dirait que "ddlll" vient de l'explication d'un prof qui a dit qu'on
devait utiliser le format "ddlll" pour le code postal et ça a été appliqué
"à la lettre" par un élève "consciencieux" qui n'a pas réellement compris
la directive donnée.
Quant à "Aszerr", ça ressemble un peu à n'importe quoi, une erreur de
saisie pas corrigée et oubliée ensuite, validée telle quelle, ou l'élève
n'a pas su quoi mettre et a saisi n'importe quoi juste parce qu'on lui a
dit qu'il "fallait "renseigner ce champ.
Les profs ne sont pas tous bien formés pour connaitre nos directives. Mais
comme les classes sont fermées, c'est sans doute un élève qui télétravaille
chez lui en suivant un cours en ligne avec peu ou pas d'encadrement (et les
parents à côté ne sont pas là pour mieux les guider. En ce temps de
confinement, les cours en ligne devraient axer non pas sur une marche à
suivre à la lettre, mais indiquer plutôt les guides de contributeur qu'on a
développé collectivement, et inciter ces élèves en télétravail à s'inscrire
directement sur nos groupes de coopération (avec leur propre compte) et
ensuite s'essayer à quelques tâches simples mentionnées dans les cours en
ligne. On devrait indiquer aux concepteurs des cours en ligne qu'il n'y a
pas que les profs en ligne pour aider, que la communauté OSM est aussi là
pour aider et expliquer.

Que le télétravail fourni et réalisé dans OSM (qui n'est évalué par aucun
prof) n'est pas sans surveillance et sans condition: les "profs" c'est nous
tous ici, à défaut de ceux de l'éducation nationale et de l'aide des
parents qui ne savent pas expliquer et guider (pourtant je pense que pour
le télétravail, l'éducation nationale devrait proposer des cours destinés
aux parents qui veulent guider leurs enfants).

Les écoles rouvrent peut-être le 11 mai, mais partiellement, et pas tour
tous les élèves en même temps: le télétravail va continuer encore après
(avec l'école ouverte un jour sur deux pour les élèves ou seulement une
demi-journée par élève, en les divisant en deux groupes séparés), mais
encore certaines écoles resteront localement fermées (quand les maires,
chefs d'établissement et enseignants ne veulent pas prendre en charge le
risque sanitaire et la responsabilité légale que ça implique).

Ca me fait penser que : "ça reste ouvert" devra mentionner les écoles
ouvertes au moins partiellement à partir du 11 mai et signaler celles qui
restent fermées.

Mais là je suppose que les parents seront les premiers au courant, il
savent déjà dans quelle école sont inscrits leurs enfants et n'ont pas le
choix pour les mettre ailleurs. À moins qu'existent à partir du 11 mai des
solutions alternatives à ces établissements, comme des ateliers organisés à
l'extérieur ou dans des assos pour des petits groupes d'élèves à proximité
des médiathèques municipales, si la météo le permet, ou des activités
sportives, mais il reste le problème de l'accès aux toilettes et celui du
lavage des mains: hors de l'école ou des équipements sportifs municipaux
(où ça peut être encadré pour éviter l'encombrement et nettoyé
convenablement par le personnel de service) ou encore dans des campings et
parcs de loisir (encore fermés aux touristes, mais loués ou prêtés à
l'occasion pour les petits groupes d'élèves), je vois mal faire de telles
activités n'importe où dehors.




Le ven. 24 avr. 2020 à 12:44, Yves P.  a écrit :

> > Faut-il dissuader de tagger  addr:city et addr:postcode ?
> Pour moi, oui.
>
> Aszerr et ddlll sont-ils des exemples ?
> Ou est-ce le résultat d'une séance de cartographie au collège ?
>
> __
> Yves
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-transit] Making bus lines more specific

[Robin Däneke]

Because the discussion of this thread already ran into the direction of 
changing different aspects about the tagging, I used it for the general 
discussion. If we refine the buses, it could go hand in hand with everything 
else. I’d be interested in which refinements would be needed there as part of 
my general suggestion. But in my current WIP-suggestion the „bus=yes,tram=yes“ 
should not be necesarry, only a route relation type for each mean of transport. 

If I could get a list of types of buses, I could think about how to do this.
Idealy, we leave the „route=bus“ and then add another sub_tag group bus=* or 
bus_type=*. Then the generalized „bus" would still be valid but the 
specification would be available if needed...

Should I open a new thread for the general discussion?

KR
RobinD

> Am 28.04.2020 um 14:34 schrieb Phake Nick :
> 
> Excuse me, I am a bit lost on how refining bus stop/station/platform tags 
> will help resolving the issue of making bus route tagging more specific, and 
> differentiate between different rype of bus services, which is the topic of 
> this email thread?
> 
> 在 2020年4月28日週二 15:45，Robin Däneke  > 寫道：
> Hello everybody,
> 
> I have lately been thinking about somehow reworking (or giving a new push to) 
> the current p_t:v2 scheme.
> Especially for the fact, that, since it was first proposed and accepted, not 
> a lot has changed in which tags are rendered, how certain things are hence 
> mapped and the Wiki-Pages on the topic have also changed in the last years 
> without any visible going through another proposal process.
> 
> When I started mapping in 2011, and first read the german and then the 
> english p:t:v2 wiki pages, it was:
> - highway=bus_stop is a legacy tag that should eventually be completely 
> phased out
> - stop positions and platforms are to be both mapped
> and some other things I already forgot…
> Now, iD has a rule in its verifyer, that requires highway=bus_stop on 
> platform nodes. The point of the public_transport tags is, among other 
> points, to replace less dedicated highway tags.
> I think it would be time for a p_t:v2.5 proposal, where we take the innicial 
> ideas of the v2, maybe refine a few small details (like is stop_position 
> required, or just platforms, can relations of route-parts be used in route 
> relations to save on redundancy…) and then put it forward for voting. If 
> accepted, we would possibly now have more leverage to get the editor and 
> render-programers to actually properly implement it this time around.
> 
> Maybe I could find some time to write my suggestions into a document, and we 
> could collect the ideas for those extra tags in there too. I think it would 
> make more sense that way, than just the addition of a few tags to the current 
> scheme, to then be ignored by the rest of OSM once again. 
> 
> Kind Regards
> Robin D. (emergency99)
> 
> 
> PS: The problem with bus_stop on platform: platforms can be nodes, lines, 
> ways, even relations, highway=bus_stop can only be a node. This old tag 
> should go the same way as the farm tag, which was (forcefully) abandoned a 
> couple of years back. There it worked, why not for the „new“ p_t scheme?
> 
> > Am 28.04.2020 um 00:12 schrieb Guilherme Braga Alves  > >:
> > 
> > I read your responses and I tend to agree that the opening_hours tag is 
> > enough to characterize services that are only operated during peak hours.
> > 
> > On the other hand, it seems to me that there is also agreement on the 
> > relevance of having tags to differentiate bus services.
> > 
> > How can we expand this debate and expand this discussion? It may be 
> > interesting for other members of the list to speak out, and then we can 
> > create or redeem a proposal for implementing new tags.
> > 
> > P.S .: I don't know if this message will enter the reply queue correctly; I 
> > hope I'm not opening a new topic. I apologize for my inexperience with 
> > maillists.
> > ___
> > Talk-transit mailing list
> > Talk-transit@openstreetmap.org 
> > https://lists.openstreetmap.org/listinfo/talk-transit 
> > 
> 
> 
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-transit 
> 
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit

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

Re: [Talk-de] Gewichtung der Straßen im Routing

[Florian Lohoff]

On Tue, Apr 28, 2020 at 01:12:30PM +0200, Volker Schmidt wrote:
> Beispiele?

Das war der Schwenk heute morgen. Grün ist neu. Da wird dann der
vermeindliche Autofahrer durch eher den Outback geschickt bzw durch die
Siedlung (maxspeed=30). Da hatte jemand den dem neuen Grünen teil am
westlichen Ende maxspeed=100 getagged.

Macht halt wenig Sinn.

https://osm.zz.de/routeqa/?rid=187615,203745

Nachdem ich dann die neue grünen teil mit lanes=1
versehen habe ist soeben die route zurück geschwenkt.

https://osm.zz.de/routeqa/?rid=203750,203905

Ich weiss aber nicht was das mit der theoretischen Betrachtung
von Straßengewichtungen zu tun hat.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

Re: [Talk-transit] Making bus lines more specific

[Phake Nick]

Excuse me, I am a bit lost on how refining bus stop/station/platform tags
will help resolving the issue of making bus route tagging more specific,
and differentiate between different rype of bus services, which is the
topic of this email thread?

在 2020年4月28日週二 15:45，Robin Däneke  寫道：

> Hello everybody,
>
> I have lately been thinking about somehow reworking (or giving a new push
> to) the current p_t:v2 scheme.
> Especially for the fact, that, since it was first proposed and accepted,
> not a lot has changed in which tags are rendered, how certain things are
> hence mapped and the Wiki-Pages on the topic have also changed in the last
> years without any visible going through another proposal process.
>
> When I started mapping in 2011, and first read the german and then the
> english p:t:v2 wiki pages, it was:
> - highway=bus_stop is a legacy tag that should eventually be completely
> phased out
> - stop positions and platforms are to be both mapped
> and some other things I already forgot…
> Now, iD has a rule in its verifyer, that requires highway=bus_stop on
> platform nodes. The point of the public_transport tags is, among other
> points, to replace less dedicated highway tags.
> I think it would be time for a p_t:v2.5 proposal, where we take the
> innicial ideas of the v2, maybe refine a few small details (like is
> stop_position required, or just platforms, can relations of route-parts be
> used in route relations to save on redundancy…) and then put it forward for
> voting. If accepted, we would possibly now have more leverage to get the
> editor and render-programers to actually properly implement it this time
> around.
>
> Maybe I could find some time to write my suggestions into a document, and
> we could collect the ideas for those extra tags in there too. I think it
> would make more sense that way, than just the addition of a few tags to the
> current scheme, to then be ignored by the rest of OSM once again.
>
> Kind Regards
> Robin D. (emergency99)
>
>
> PS: The problem with bus_stop on platform: platforms can be nodes, lines,
> ways, even relations, highway=bus_stop can only be a node. This old tag
> should go the same way as the farm tag, which was (forcefully) abandoned a
> couple of years back. There it worked, why not for the „new“ p_t scheme?
>
> > Am 28.04.2020 um 00:12 schrieb Guilherme Braga Alves <
> gbragaal...@gmail.com>:
> >
> > I read your responses and I tend to agree that the opening_hours tag is
> enough to characterize services that are only operated during peak hours.
> >
> > On the other hand, it seems to me that there is also agreement on the
> relevance of having tags to differentiate bus services.
> >
> > How can we expand this debate and expand this discussion? It may be
> interesting for other members of the list to speak out, and then we can
> create or redeem a proposal for implementing new tags.
> >
> > P.S .: I don't know if this message will enter the reply queue
> correctly; I hope I'm not opening a new topic. I apologize for my
> inexperience with maillists.
> > ___
> > Talk-transit mailing list
> > Talk-transit@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-transit
>
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [OSM-talk-ie] Overpass query?

[John Kennedy]

Cool. Yep, I was lucky spotted the difference description:
https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#Difference

Brian, I just noticed that Cork Airport and nearby are not highlighted in
the results...maybe the civil parish definitions are missing/broken in
those areas.
Rgds/
 - John.

On Tue, 28 Apr 2020 at 12:52, Brian Hollinshead 
wrote:

> Hi John,
> That is great thank you. It does include the four parishes from Diocese of
> Ardfert but I can cope the that. I did not want all the Cloyne Parishes in
> Cork County lest there would be duplicate names.
>
> Regards
>
> On Tue, 28 Apr 2020 at 12:30, John Kennedy  wrote:
>
> > Hi Brian.
> > Does this work?
> >
> > https://overpass-turbo.eu/s/TnN
> >
> > I attempt to gather all CPs in Cork.
> > Then all CPs in the mapped dioceses.
> > Then take the difference.
> >
> > But I just query by area name - this could be tightened further.
> >
> > Rgds/
> >  - John
> >
> >
> >
> >
> > On Tue, 28 Apr 2020 at 09:20, Brian Hollinshead 
> > wrote:
> >
> > > Hi Donal,
> > > Thanks for having a go at that overpass query. Your offer showed the
> > > Diocese of Ardfert which has perhaps six Cork civil parishes. I had not
> > > included it in my enquiry for fear of complicating it further.
> > >
> > > If you run overpass, include all County Cork on screen and use wizard:
> > > boundary=historic_diocese, the resultant white space is the Diocese of
> > Cork
> > > (1837)  from which i wish to load all the civil parishes into JOSM for
> > > further progress.
> > >
> > > For anyone new to this conversation that is : all the civil parishes in
> > > County cork not already mapped in OSM as parts or all of the Dioceses
> of
> > > Ardfert and Aghadoe, Cloyne or Ross. (as boundary=historic_diocese)
> > >
> > > Further suggestions from anyone more familiar with overpass than I am
> > will
> > > be most welcome.
> > >
> > > Thanks
> > >
> > > On Tue, 28 Apr 2020 at 00:17, Donal Hunt 
> > > wrote:
> > >
> > > > Hi Brian,
> > > >
> > > > I tried to take a stab at this but overpass got the better of me!!
> > > >
> > > > Here is what I've got so far: https://overpass-turbo.eu/s/Tn4
> > > >
> > > > This will give you an area excluding the two diocese relations you
> > > > mentioned. I think you either need to do a map_to_area or a Recurse
> > > up/down
> > > > relations function after that but I can't wrap my head around that
> part
> > > and
> > > > there are few examples that explain it well enough...
> > > >
> > > > Also - in hindsight, my query result only returns other diocesan
> areas
> > > that
> > > > are not Ross / Cloyne. There are obviously parts of Cork that aren't
> > > > contained within a diocesan area right now.
> > > >
> > > > Hopefully one of the overpass gurus here will put us out of our
> > misery!!
> > > =)
> > > >
> > > > Donal
> > > >
> > > > On Sat, Apr 25, 2020 at 4:38 PM Brian Hollinshead <
> > br...@hollinshead.net
> > > >
> > > > wrote:
> > > >
> > > > > Overpass query: County Cork comprises the Dioceses of Cloyne, Cork
> > and
> > > > > Ross. I have added Cloyne and Ross as boundary=historic_diocese to
> > OSM.
> > > > > Please can I use overpass to load the remaining civil parishes into
> > > JOSM.
> > > > > Something  like  boundary=civil_parish in "County Cork" BUT NOT
> > > > > (boundary=civil_parish in "Diocese of Cloyne") OR NOT
> > > > > (boundary=civil_parish in "Diocese of Ross). I seem to remember
> that
> > > > > boundary!=xxx omits what follows but am unsure.
> > > > > Thanks
> > > > > ___
> > > > > Talk-ie mailing list
> > > > > Talk-ie@openstreetmap.org
> > > > > https://lists.openstreetmap.org/listinfo/talk-ie
> > > > >
> > > >
> > > >
> > > > --
> > > > Donal Hunt
> > > > OpenStreetMap Ireland
> > > > donal.h...@openstreetmap.ie | +353 87 8175123
> > > > ___
> > > > Talk-ie mailing list
> > > > Talk-ie@openstreetmap.org
> > > > https://lists.openstreetmap.org/listinfo/talk-ie
> > > >
> > > ___
> > > Talk-ie mailing list
> > > Talk-ie@openstreetmap.org
> > > https://lists.openstreetmap.org/listinfo/talk-ie
> > >
> > ___
> > Talk-ie mailing list
> > Talk-ie@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-ie
> >
> ___
> Talk-ie mailing list
> Talk-ie@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ie
>
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

Re: [OSM-talk-fr] attribution manquante

[Philippe Verdy]

J'ai déjà contacté l'Education nationale concernant les cartes affichées
sur leurs sites. Ils m'ont répondu que c'était une erreur d'interprétation
des conditions mais que la correction allait venir bientôt, mais qu'ils
sont très occupés avec beaucoup de travail à faire sur des tas de nouveaux
sites ou fonctionnalités pour gérer ce qui est maintenant demandé pour
gérer la situation avec le COVID19 (téléenseignement, gestion des
personnels, sites d'information divers pour parents, enseignants, espaces
dédiés aux élèves, espaces d'échange d'information sur les mesures
administratives et organisationnelles, modification des examens, etc.)
Le tout fait en télétravail (donc pas facile non plus à coordonner, les
délais s'allongent).
Et il faut être patient, car tout n'est pas fait par l'Education nationale
elle-même mais des lots sont faits par des sociétés qui oublient des
spécifications ou font juste le minimum (parfois livrent des lots "test" au
fil de l'eau, mais ils sont mis en ligne plus tôt que prévu alors que le
débogage n'est pas terminé).
Les cahiers des charges techniques des nouvelles fonctions réalisées ont
été expédiés, la validation des lots fournis par les sociétés tierces est
aussi accélérée.
Mais la mise en ligne est accélérée par les besoins, malgré les défauts
constatés (avec des risques élevés en terme de sécurité et protection de la
vie privée, sachant qu'ils ont des urgences à résoudre d'abord concernant
les attaques malveillantes des sites concernés: si une fonctionnalité très
utile a un risque constaté, elle est fermée et c'est urgent de la corriger
avant de la rouvrir...)
Il serait bon que les tiers intervenants pour les sites de l'Education
nationales s'engagent avec une charte contractuelle les obligeant à
maintenir après livraison les défauts et la conformité légale des sites
(les attributions nécessaires, les copyright des images utilisées, etc.),
des oublis sont possibles dans le cadre de développement accéléré et mise
en ligne "au fil de l'eau".
Le minimum serait que ces intervenants tiers s'engagent tous à une clause
de garantie pendant au moins 3 mois après la mise en ligne de leurs lots
livrés, et que les recettes de lots réalisés en interne fassent l'objet
d'un suivi d'évaluation pendant la même période au moins pour une
revalidation plus pointilleuse des points techniques ou légaux posant
problème. Mais il semble que vu le cadre réglementaire et légal changeant
très rapidement en ce moment, c'est difficile de prévoir justement toutes
les conditions légales (le droit d'auteur semble être une condition un peu
oubliée au milieu d'un énorme paquet de conditions: la réglementation
administrative propre à l'éducation nationale, les décrets et arrêtés pris
d'urgence, les demandes des établissements, enseignants et syndicats,
passant sans doute en priorité).
Ce n'est donc pas un refus ou un abus volontaire, c'est juste un oubli au
milieu de pleins de priorités, mais avec des équipes techniques réduites et
des moyens compliqués à gérer en télétravail pour coordonner les équipes
(il serait donc bon que les lots à faire sur les sites de l'Education
nationale se fassent sur des lots plus petits, gérables par des équipes
plus petites, quitte à mettre en ligne des sites séparés plus nombreux mais
isolés entre eux, avec des facilités réduites de navigation entre ces
fonctions, puis revoir plus tard l'intégration complète).

Le lun. 20 avr. 2020 à 21:24, tuxayo  a écrit :

>
>
> On 20-04-20 17:36, David Crochet wrote:
> > L'attribution est manquante pour ce site :
> >
> > https://affectation3e.phm.education.gouv.fr
>
> En effet!
>
> Est-ce que vous avez un compte sur le wiki d'OSM?
> Il y a une page qui fait l'inventaire des cas où la licence n'est pas
> correctement attribuée.
>
> https://wiki.openstreetmap.org/wiki/FR:Manque_d%27attribution_appropri%C3%A9e
>
> À++ :)
>
> --
> tuxayo
>
> ___
> 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-ie] Overpass query?

[Brian Hollinshead]

Hi John,
That is great thank you. It does include the four parishes from Diocese of
Ardfert but I can cope the that. I did not want all the Cloyne Parishes in
Cork County lest there would be duplicate names.

Regards

On Tue, 28 Apr 2020 at 12:30, John Kennedy  wrote:

> Hi Brian.
> Does this work?
>
> https://overpass-turbo.eu/s/TnN
>
> I attempt to gather all CPs in Cork.
> Then all CPs in the mapped dioceses.
> Then take the difference.
>
> But I just query by area name - this could be tightened further.
>
> Rgds/
>  - John
>
>
>
>
> On Tue, 28 Apr 2020 at 09:20, Brian Hollinshead 
> wrote:
>
> > Hi Donal,
> > Thanks for having a go at that overpass query. Your offer showed the
> > Diocese of Ardfert which has perhaps six Cork civil parishes. I had not
> > included it in my enquiry for fear of complicating it further.
> >
> > If you run overpass, include all County Cork on screen and use wizard:
> > boundary=historic_diocese, the resultant white space is the Diocese of
> Cork
> > (1837)  from which i wish to load all the civil parishes into JOSM for
> > further progress.
> >
> > For anyone new to this conversation that is : all the civil parishes in
> > County cork not already mapped in OSM as parts or all of the Dioceses of
> > Ardfert and Aghadoe, Cloyne or Ross. (as boundary=historic_diocese)
> >
> > Further suggestions from anyone more familiar with overpass than I am
> will
> > be most welcome.
> >
> > Thanks
> >
> > On Tue, 28 Apr 2020 at 00:17, Donal Hunt 
> > wrote:
> >
> > > Hi Brian,
> > >
> > > I tried to take a stab at this but overpass got the better of me!!
> > >
> > > Here is what I've got so far: https://overpass-turbo.eu/s/Tn4
> > >
> > > This will give you an area excluding the two diocese relations you
> > > mentioned. I think you either need to do a map_to_area or a Recurse
> > up/down
> > > relations function after that but I can't wrap my head around that part
> > and
> > > there are few examples that explain it well enough...
> > >
> > > Also - in hindsight, my query result only returns other diocesan areas
> > that
> > > are not Ross / Cloyne. There are obviously parts of Cork that aren't
> > > contained within a diocesan area right now.
> > >
> > > Hopefully one of the overpass gurus here will put us out of our
> misery!!
> > =)
> > >
> > > Donal
> > >
> > > On Sat, Apr 25, 2020 at 4:38 PM Brian Hollinshead <
> br...@hollinshead.net
> > >
> > > wrote:
> > >
> > > > Overpass query: County Cork comprises the Dioceses of Cloyne, Cork
> and
> > > > Ross. I have added Cloyne and Ross as boundary=historic_diocese to
> OSM.
> > > > Please can I use overpass to load the remaining civil parishes into
> > JOSM.
> > > > Something  like  boundary=civil_parish in "County Cork" BUT NOT
> > > > (boundary=civil_parish in "Diocese of Cloyne") OR NOT
> > > > (boundary=civil_parish in "Diocese of Ross). I seem to remember that
> > > > boundary!=xxx omits what follows but am unsure.
> > > > Thanks
> > > > ___
> > > > Talk-ie mailing list
> > > > Talk-ie@openstreetmap.org
> > > > https://lists.openstreetmap.org/listinfo/talk-ie
> > > >
> > >
> > >
> > > --
> > > Donal Hunt
> > > OpenStreetMap Ireland
> > > donal.h...@openstreetmap.ie | +353 87 8175123
> > > ___
> > > Talk-ie mailing list
> > > Talk-ie@openstreetmap.org
> > > https://lists.openstreetmap.org/listinfo/talk-ie
> > >
> > ___
> > Talk-ie mailing list
> > Talk-ie@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-ie
> >
> ___
> Talk-ie mailing list
> Talk-ie@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ie
>
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

Re: [Talk-it] Modifiche massive nomi di strade in seguito a note anonime

[Maurizio Napolitano]

> In realtà dovrebbe essere:
> Viale dei Giardini

Lancio un appello:
ragioniamo su questa pagina qualora volessimo cambiare la questione?
https://wiki.openstreetmap.org/wiki/IT:Editing_Standards_and_Conventions#Nomi_delle_strade

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

Re: [Talk-it] Modifiche massive nomi di strade in seguito a note anonime

[Francesco Ansanelli]

Il mar 28 apr 2020, 11:13 Lorenzo Stucchi  ha
scritto:

> Ciao,
>
> Concordo con quanto è stato detto prima, vorrei però sottolineare il
> problema principale che sono le note anonime.
>
> Ne vengono caricate a decine ogni giorno, (30 solo stamattina) [1] sono
> anonime e non è possibile risalire a chi le pubblica e tra l’altro
> contengono informazioni sbagliate su quale sia il nome corretto delle vie.
> Sembrano tutte con lo stesso formato, ad esempio:
>
> “ Da direttive ISTAT il nome è
> Piazza ventisei maggio “
>

Avevo trovato un caso:

Da direttive ISTAT il nome è
Viale giardini

In realtà dovrebbe essere:
Viale dei Giardini

non essendo giardini pinco pallino..

>
> Servirebbe secondo me poter capire come vengono create, avete qualche idea?
>

Si potrebbe provare a risalire dall'indirizzo IP per provare a capire se si
tratta di un server o un utente privato e da che parte del mondo lavora.
Però credo sia un indagine che può fare solo chi gestisce il server

>
> Ciao,
> Lorenzo Stucchi
>
> [1] https://ent8r.github.io/NotesReview/expert/?query=ISTAT
>
>
> Il giorno 28 apr 2020, alle ore 09:42, Andrea Musuruane <
> musur...@gmail.com> ha scritto:
>
> Ciao,
> concordo con canfe.
>
> In questa ML si rifanno periodicamente le stesse discussioni,
> dimenticandosi di averle già fatte. Sarebbe utile rileggersi gli ultimi
> thread.
>
> https://lists.openstreetmap.org/pipermail/talk-it/2017-April/058290.html
>
> https://lists.openstreetmap.org/pipermail/talk-it/2017-December/061356.html
>
> https://lists.openstreetmap.org/pipermail/talk-it/2018-January/061775.html
>
> https://lists.openstreetmap.org/pipermail/talk-it/2018-October/064461.html
>
>
> 
> Per quanto riguarda la questione "si mappa quello che c'è sul campo",
> vorrei sottolineare che non l'abbiamo mai fatto.Spesso gli odonomi sono
> indicati sui cartelli tutti in maiuscolo (a volte tutti in minuscolo) e non
> abbiamo mai inserito i nomi in questo modo ma abbiamo deciso di seguire la
> regole della lingua italiana, specificando di iniziare con una lettera
> maiuscola (Via e non via). Sovente gli odonimi riferiti a personaggi
> storici sono abbreviati o parziali e noi abbiamo sempre detto di inserirli
> completi. Allo stesso modo abbiamo deciso di seguire le regole ISTAT per
> avere delle regole uniformi in tutta Italia (tra l'altro non c'è alcun
> obbligo da parte dei comuni di adeguare la cartellonistica, ma solo di
> adeguare lo stradario - quindi a meno di non leggersi tutti i giorni l'albo
> pretorio di tutti i comuni italiani, non vi è modo di scoprire questi
> adeguamenti). Tutte queste regole servono oltre che a standardizzare la
> mappa, anche ai motori di ricerca, perché altrimenti un utente dovrebbe già
> sapere se in un comune c'è scritto sui cartelli "via 25 aprile" o "VIA
> MAZZINI" oppure "Via G. Garibaldi".
>
> Ciao,
>
> Andrea
>
>
>
> On Tue, Apr 28, 2020 at 8:57 AM canfe  wrote:
>
>> Non sono d'accordo.
>> C'è una pagina wiki che specifica come vanno scritti i nomi delle vie.
>> O le regole valgono per tutti o ognuno si inventa quella che piu' gli
>> piace.
>>
>> https://wiki.openstreetmap.org/wiki/IT:Editing_Standards_and_Conventions#Nomi_delle_strade
>>
>> Inoltre mi denuncio di avere fatto un editing massivo cambiando tutti i
>> nomi
>> di via undici febbraio in tutto il Piemonte a suo tempo.
>> Revert??
>>
>>
>>
>> --
>> 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
>
>
> ___
> 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-ie] Overpass query?

[Donal Hunt]

Took a look and looks sane to me. I was trying this last night but failing!


On Tue, 28 Apr 2020, 12:30 John Kennedy,  wrote:

> Hi Brian.
> Does this work?
>
> https://overpass-turbo.eu/s/TnN
>
> I attempt to gather all CPs in Cork.
> Then all CPs in the mapped dioceses.
> Then take the difference.
>
> But I just query by area name - this could be tightened further.
>
> Rgds/
>  - John
>
>
>
>
> On Tue, 28 Apr 2020 at 09:20, Brian Hollinshead 
> wrote:
>
> > Hi Donal,
> > Thanks for having a go at that overpass query. Your offer showed the
> > Diocese of Ardfert which has perhaps six Cork civil parishes. I had not
> > included it in my enquiry for fear of complicating it further.
> >
> > If you run overpass, include all County Cork on screen and use wizard:
> > boundary=historic_diocese, the resultant white space is the Diocese of
> Cork
> > (1837)  from which i wish to load all the civil parishes into JOSM for
> > further progress.
> >
> > For anyone new to this conversation that is : all the civil parishes in
> > County cork not already mapped in OSM as parts or all of the Dioceses of
> > Ardfert and Aghadoe, Cloyne or Ross. (as boundary=historic_diocese)
> >
> > Further suggestions from anyone more familiar with overpass than I am
> will
> > be most welcome.
> >
> > Thanks
> >
> > On Tue, 28 Apr 2020 at 00:17, Donal Hunt 
> > wrote:
> >
> > > Hi Brian,
> > >
> > > I tried to take a stab at this but overpass got the better of me!!
> > >
> > > Here is what I've got so far: https://overpass-turbo.eu/s/Tn4
> > >
> > > This will give you an area excluding the two diocese relations you
> > > mentioned. I think you either need to do a map_to_area or a Recurse
> > up/down
> > > relations function after that but I can't wrap my head around that part
> > and
> > > there are few examples that explain it well enough...
> > >
> > > Also - in hindsight, my query result only returns other diocesan areas
> > that
> > > are not Ross / Cloyne. There are obviously parts of Cork that aren't
> > > contained within a diocesan area right now.
> > >
> > > Hopefully one of the overpass gurus here will put us out of our
> misery!!
> > =)
> > >
> > > Donal
> > >
> > > On Sat, Apr 25, 2020 at 4:38 PM Brian Hollinshead <
> br...@hollinshead.net
> > >
> > > wrote:
> > >
> > > > Overpass query: County Cork comprises the Dioceses of Cloyne, Cork
> and
> > > > Ross. I have added Cloyne and Ross as boundary=historic_diocese to
> OSM.
> > > > Please can I use overpass to load the remaining civil parishes into
> > JOSM.
> > > > Something  like  boundary=civil_parish in "County Cork" BUT NOT
> > > > (boundary=civil_parish in "Diocese of Cloyne") OR NOT
> > > > (boundary=civil_parish in "Diocese of Ross). I seem to remember that
> > > > boundary!=xxx omits what follows but am unsure.
> > > > Thanks
> > > > ___
> > > > Talk-ie mailing list
> > > > Talk-ie@openstreetmap.org
> > > > https://lists.openstreetmap.org/listinfo/talk-ie
> > > >
> > >
> > >
> > > --
> > > Donal Hunt
> > > OpenStreetMap Ireland
> > > donal.h...@openstreetmap.ie | +353 87 8175123
> > > ___
> > > Talk-ie mailing list
> > > Talk-ie@openstreetmap.org
> > > https://lists.openstreetmap.org/listinfo/talk-ie
> > >
> > ___
> > Talk-ie mailing list
> > Talk-ie@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-ie
> >
> ___
> Talk-ie mailing list
> Talk-ie@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ie
>
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

Re: [Talk-transit] Making bus lines more specific

[Robin Däneke]

Any tag we could come up with is going to be a partial misnomer for what we are 
trying to model in the Database. In OSM, there are lots of those…

highway=bus_stop on the side of the road is somewhat trivially understandable, 
but that means we need railway=tram_stop, railway=train_stop, 
waterway=ferry_stop and many other tags too, that could all be made redundand 
by the „platform“ node/way/relation being in a route relation that is that mean 
of transport.

The wonderful thing about databases is, that a lot of info kan be given on 
relational levels and inherited by all relation members. We can make a bunch of 
tags redundant by using one. And platform is the most truthful there. In 
Vienna, the Networks (Verkehrsverbunde) are working on only having bus stops, 
that have a visible, higher laying „platform“ (or some sort of sidewalk area) 
at each stop, and I can only imagine, the more public_transport gets, the more 
a bus stop is going to be the platform. I think we should not be tagging 
backwards here.

The pole is a part of the stop, but never „the stop“ itself, even if some 
people tend to see it that way. Alternatively, call it public_transport=stop. 
That would mean one area where pt stops. Then that would be the same as a 
platform, unless it is a node, when that is possibly just the pole. But for 
that, a useful micro-mapping tag „public_transport=pole“ would make much more 
sense, once again then not needing bus=yes,tram=yes or something like 
„bus_stop_pole“ „tram_stop_pole“…

This merging hw=bus_stop, rw=tram_stop into one platform or stop tag will make 
the database much more lean. And in terms of highway=bus_stop is difficult to 
remove: As this tag is the same as the platform (except if it is a node 
connected to a street, then that is a „stop_position" and can just be deleted) 
you could get one mechanical edit to take care f it (after getting it approved 
by the community and/or DWG) So that tag is the easiest to just purge from what 
it’s counterpart in p_t:v2 is!

A stop/platform node on the side of the road does the same, so this is just 
redundancy, and as platform is the more versatile tag, it should take 
precedence in this „tag-fight“.

Thanks for all the input.

KR 
RobinD

> Am 28.04.2020 um 12:20 schrieb Tony OSM :
> 
> I like node highway=bus_stop for the reasons polyglot gives. bus_stop is here 
> to stay cos there are too many to change, by the side of the highway they 
> give directionality depending on the customary side of the road for driving.
> 
> public_transport=platform works well for train and some trams. To me a 
> platform is a construct to assist people to get on or off the transport 
> vehicle. As a waiting area  - that use is secondary.
> 
> In GB some authorities are raising the area around a bus stop to enable 
> wheelchair users easier access to buses - so yes a platform tag is 
> appropriate, but not for a pole placed in the ground or pedestrian part of 
> the road which is the default for buses where I live. 
> 
> stop_position node - to me has no function - for buses their stop position is 
> the bus stop;  for trains they stop at the platform; where I live we have 
> 2,3,4,5,6 car trains, the front of the train stops at one of two defined 
> positions depending on the number of  cars.
> 
> Simplification of PTV2 may be helpful, but I have had no strong frustrations 
> when using it.
> 
> Regards
> 
> TonyS999
> 
> 
> 
> On 28/04/2020 09:46, Jo wrote:
>> The basic objection they voice is why need 2 tags, if 1 does the job.
>> 
>> highway=bus_stop
>> 
>> is not exactly nonsensical. It's concise and expresses what is meant. (OK, 
>> it's not a highway and my preference is to map it next to the highway)
>> 
>> 
>> public_transport=platform
>> 
>> was designed at first to not need a mode of transport like bus=yes/tram=yes. 
>> I am the one who proposed adding it, so that it COULD start replacing 
>> highway=bus_stop back in 2012.
>> 
>> There is not always a platform present, so it's a bit of a misnomer as well.
>> 
>> Anyway, someone who wants to render a bus stop ideally wants to look at a 
>> single tag, not a combination of 2, apparently. For a long time it was 
>> supposedly a technical problem, but as soon as that was resolved somewhere 
>> around 2017, it was still considered problematic to look at 2 tags.
>> 
>> I wish you good luck with proposing another way of mapping public transport. 
>> Many have tried before you. It's really hard to beat status quo. And the 
>> status quo is not the same across the planet. If you can propose something 
>> that is both simpler, more elegant and still expressive enough for all 
>> usecases, I'll vote yes on it.
>> 
>> Polyglot
>> 
>> On Tue, Apr 28, 2020 at 10:26 AM Robin Däneke > > wrote:
>> Indeed, these are good points. I would say, that the „platform“ is enough. 
>> This could then mean either the „stop pole“ of the station (which I would 
>> not say is the most important piece as 

Re: [Talk-it] Modifiche massive nomi di strade in seguito a note anonime

[Maurizio Napolitano]

On Mon, Apr 27, 2020 at 10:55 PM Marco Minghini
 wrote:
>
> Ciao a tutti,
> un paio di settimane fa Lorenzo Stucchi aveva segnalato su Telegram 
> l'apertura di circa 200 note in corrispondenza di strade, da parte di un 
> utente anonimo nella zona nord di Milano (fino a Como e Lecco) in cui viene 
> segnalato che "Da direttive ISTAT il nome è ..." seguito dal presunto nome 
> ISTAT della strada in questione. In buona sostanza, le modifiche proposte 
> vogliono il nome della strada modificato da "Via XXV Aprile" a "Via 
> venticinque aprile", da "Via Vittorio Emanuele II" a "Via Vittorio Emanuele 
> secondo", e così via in modo simile.

Da direttiva ISTAT i nomi sarebbero anche tutti maiuscoli


> 1) innanzitutto vi chiedo un parere su che cosa debba andare nel tag "name": 
> a mio parere si mappa quello che c'è sul campo (nel caso della nota in 
> questione "Via Pio XI", che compare sui cartelli) e si potrebbe usare 
> "alt_name" o anche "official_name", che vedo esistere, per altri nomi come 
> quello ISTAT. Ma su questo accetto volentieri pareri da chi è più esperto.

In ogni caso questa questione era già stata risolta qui
https://wiki.openstreetmap.org/wiki/IT:Editing_Standards_and_Conventions#Nomi_delle_strade

> 2) a prescindere da quale nome vada messo in quale tag, il messaggio che 
> compare su ogni nota aperta da anonimi ci ricorda che "Questa nota include 
> commenti da parte di utenti anonimi che devono essere verificati in modo 
> indipendente". Le note sono un bene prezioso, ma come minimo l'informazione 
> contenuta va verificata prima di fare modifiche, in questo caso recuperando 
> la fonte del presunto nome corretto o chiedendola all'autore della nota.
>
> 3) Cambiare oltre 200 nomi di strade (che corrispondono probabilmente a 
> migliaia di way) è una modifica massiva che credo vada discussa con la 
> comunità prima di essere fatta. Noto invece che l'utente mcheck chiude decine 
> e decine di note ogni giorno in diverse parti di Italia, senza verificare la 
> fonte, senza commentare le note e senza rispondere ai commenti degli altri.

Sono certo che mcheck si farà sentire presto

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

Re: [OSM-talk-ie] Overpass query?

[John Kennedy]

Hi Brian.
Does this work?

https://overpass-turbo.eu/s/TnN

I attempt to gather all CPs in Cork.
Then all CPs in the mapped dioceses.
Then take the difference.

But I just query by area name - this could be tightened further.

Rgds/
 - John




On Tue, 28 Apr 2020 at 09:20, Brian Hollinshead 
wrote:

> Hi Donal,
> Thanks for having a go at that overpass query. Your offer showed the
> Diocese of Ardfert which has perhaps six Cork civil parishes. I had not
> included it in my enquiry for fear of complicating it further.
>
> If you run overpass, include all County Cork on screen and use wizard:
> boundary=historic_diocese, the resultant white space is the Diocese of Cork
> (1837)  from which i wish to load all the civil parishes into JOSM for
> further progress.
>
> For anyone new to this conversation that is : all the civil parishes in
> County cork not already mapped in OSM as parts or all of the Dioceses of
> Ardfert and Aghadoe, Cloyne or Ross. (as boundary=historic_diocese)
>
> Further suggestions from anyone more familiar with overpass than I am will
> be most welcome.
>
> Thanks
>
> On Tue, 28 Apr 2020 at 00:17, Donal Hunt 
> wrote:
>
> > Hi Brian,
> >
> > I tried to take a stab at this but overpass got the better of me!!
> >
> > Here is what I've got so far: https://overpass-turbo.eu/s/Tn4
> >
> > This will give you an area excluding the two diocese relations you
> > mentioned. I think you either need to do a map_to_area or a Recurse
> up/down
> > relations function after that but I can't wrap my head around that part
> and
> > there are few examples that explain it well enough...
> >
> > Also - in hindsight, my query result only returns other diocesan areas
> that
> > are not Ross / Cloyne. There are obviously parts of Cork that aren't
> > contained within a diocesan area right now.
> >
> > Hopefully one of the overpass gurus here will put us out of our misery!!
> =)
> >
> > Donal
> >
> > On Sat, Apr 25, 2020 at 4:38 PM Brian Hollinshead  >
> > wrote:
> >
> > > Overpass query: County Cork comprises the Dioceses of Cloyne, Cork and
> > > Ross. I have added Cloyne and Ross as boundary=historic_diocese to OSM.
> > > Please can I use overpass to load the remaining civil parishes into
> JOSM.
> > > Something  like  boundary=civil_parish in "County Cork" BUT NOT
> > > (boundary=civil_parish in "Diocese of Cloyne") OR NOT
> > > (boundary=civil_parish in "Diocese of Ross). I seem to remember that
> > > boundary!=xxx omits what follows but am unsure.
> > > Thanks
> > > ___
> > > Talk-ie mailing list
> > > Talk-ie@openstreetmap.org
> > > https://lists.openstreetmap.org/listinfo/talk-ie
> > >
> >
> >
> > --
> > Donal Hunt
> > OpenStreetMap Ireland
> > donal.h...@openstreetmap.ie | +353 87 8175123
> > ___
> > Talk-ie mailing list
> > Talk-ie@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-ie
> >
> ___
> Talk-ie mailing list
> Talk-ie@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ie
>
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

Re: [Talk-de] Gewichtung der Straßen im Routing

[Volker Schmidt]

Beispiele?


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Tue, 28 Apr 2020 at 12:50, Florian Lohoff  wrote:

>
> Hi,
> ich habe gerade wieder so zeugs repariert wo jemand im Aussenbereich
> auf Straßen die eher zur Erschließung der Streusiedlungen gedacht sind
> mit einem maxspeed=100 bedacht hat. Natürlich ist das rechtlich richtig
> aber leider völlig an der Realität vorbei.
>
> Das hat natürlich sofort dazu geführt das im routing das als "rat-race"
> Strecke präferiert hat ggü der breit ausgebauten Landstraße die aber
> vielleicht ein maxspeed=70 hat.
>
> Ich habe jetzt da auf dem Rat-Race strecken ein "lanes=1" hinterher
> geworfen was im routing (Zumindest OSRM) die erwartete maxspeed halbiert
> was vermutlich (Bestätigung kommt in 1 1/2 Stunden aus meinem
> Automatismus) das wieder fixed.
>
> Relative Gewichtung von Straßen untereinander sollte ja wenn alles
> sauber getagged ist in 95% der Fälle die Priorität des "offiziellen"
> Straßennetzes wiedergeben. Leider ist unser tagging was maxspeed,
> lanes, shoulder, surface, width angeht ja eher so sparse was das
> routing ziemlich "kaputt" macht.
>
> Wir als OSM wollen ja nicht Leute quer durch die Siedlung schicken
> wenn es eine Bundesstraße gibt.
>
> Wie handhaben hier andere so dinger?
>
> Flo
> --
> Florian Lohoff f...@zz.de
> UTF-8 Test: The  ran after a , but the  ran away
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
>
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [talk-au] Vicmap Lite - Public Land (Parks and Reserves) not working

[Andrew Harvey]

Yep that's fine, but that's for the Vicmap downloadable data, I didn't
realise until now there was a WMS service that was open to the public and
available under the same terms.

On Tue, 28 Apr 2020 at 20:35, Bren Barnes  wrote:

> Hi there, checking the contributors page, Vicmap datasets are CC-BY 4.0
> with waiver.
>
>
> https://wiki.openstreetmap.org/wiki/File:Vicmap_CCBYPermission_OSM_Final_Jan2018_Ltr.pdf
>
> On Tue, 28 Apr 2020 at 18:38, Andrew Davidson  wrote:
>
>> On Tue, Apr 28, 2020 at 6:28 PM Andrew Harvey 
>> wrote:
>>
>>> I was not aware we had permission to use this service, we have
>>> permission to use the data, but I didn't know the API endpoint was for
>>> public use. It looks like the service is down, we could ask the vicmap
>>> people if we can use this service and see if the are aware of the issue.
>>>
>>> The end point has been moved. Someone had fixed the other layers already.
>>
>> The terms and conditions for the WMS service pretty much just say CC-BY
>> 4.0:
>>
>> https://www.data.vic.gov.au/copyright
>>
>>
>> ___
>> 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

[Talk-de] Gewichtung der Straßen im Routing

[Florian Lohoff]

Hi,
ich habe gerade wieder so zeugs repariert wo jemand im Aussenbereich
auf Straßen die eher zur Erschließung der Streusiedlungen gedacht sind
mit einem maxspeed=100 bedacht hat. Natürlich ist das rechtlich richtig
aber leider völlig an der Realität vorbei.

Das hat natürlich sofort dazu geführt das im routing das als "rat-race"
Strecke präferiert hat ggü der breit ausgebauten Landstraße die aber
vielleicht ein maxspeed=70 hat.

Ich habe jetzt da auf dem Rat-Race strecken ein "lanes=1" hinterher
geworfen was im routing (Zumindest OSRM) die erwartete maxspeed halbiert
was vermutlich (Bestätigung kommt in 1 1/2 Stunden aus meinem
Automatismus) das wieder fixed.

Relative Gewichtung von Straßen untereinander sollte ja wenn alles
sauber getagged ist in 95% der Fälle die Priorität des "offiziellen"
Straßennetzes wiedergeben. Leider ist unser tagging was maxspeed,
lanes, shoulder, surface, width angeht ja eher so sparse was das
routing ziemlich "kaputt" macht.

Wir als OSM wollen ja nicht Leute quer durch die Siedlung schicken
wenn es eine Bundesstraße gibt.

Wie handhaben hier andere so dinger? 

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

[OSM-talk-ie] Why is Billy parish in Antrim shown as in Athlone Municipal District?

[Brian Hollinshead]

During the stay at home I have added many CofI parishes to OSM based on
single or combinations of civil parishes.
Please see Billy Parish 10993573, it suggests it is in County Roscommon!!
This applies to a number of others as well. Please can somebody explain why
to me and also how or who can rectify it. While they all display OK it
might be disconcerting to a person doing a search.
Thank you.
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

Re: [talk-au] Vicmap Lite - Public Land (Parks and Reserves) not working

[Bren Barnes]

Hi there, checking the contributors page, Vicmap datasets are CC-BY 4.0
with waiver.

https://wiki.openstreetmap.org/wiki/File:Vicmap_CCBYPermission_OSM_Final_Jan2018_Ltr.pdf

On Tue, 28 Apr 2020 at 18:38, Andrew Davidson  wrote:

> On Tue, Apr 28, 2020 at 6:28 PM Andrew Harvey 
> wrote:
>
>> I was not aware we had permission to use this service, we have permission
>> to use the data, but I didn't know the API endpoint was for public use. It
>> looks like the service is down, we could ask the vicmap people if we can
>> use this service and see if the are aware of the issue.
>>
>> The end point has been moved. Someone had fixed the other layers already.
>
> The terms and conditions for the WMS service pretty much just say CC-BY
> 4.0:
>
> https://www.data.vic.gov.au/copyright
>
>
> ___
> 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: [Talk-it] Modifiche massive nomi di strade in seguito a note anonime

[Manuel]

Il 28/04/2020 11:56, Martin Koppenhoefer ha scritto:

Noi non siamo i comuni...
Se loro procedono, seguiamo, se non lo fanno, non cambiamo nemmeno noi.

Ma senza tenere una linea comune, si rischia di confondere l'utente finale e/o 
rendere meno fruibile la mappa. Personalmente, sono per seguire le indicazioni 
della wiki.

--
Manuel Tassi


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

Re: [OSM-talk] Let's talk Attribution

[Martin Koppenhoefer]

Am Di., 28. Apr. 2020 um 06:51 Uhr schrieb Simon Poole :

>
> Am 27.04.2020 um 19:49 schrieb Alexandre Oliveira:
> > Hello!
> >
> > I'll try to be brief and explain the main problems that exist with
> > OSM's way of handling lack of (proper) attribution.
> >
> There was just a (nearly 100 messages) long thread on the subject here
> not to mention a longish consultation last year, with multiple in person
> sessions, which covered all the issues you touch on.



FWIW, it is a recurring topic and was discussed not only recently but many
many times in the past years. Some projects not attributing in a very
obvious way would not be tolerated by other data providers (e.g. Google,
Here), so it clearly isn't the industry standard of attributing map data to
have the attribution one or more clicks away from the map. Common
attribution requirements are _on_ the map.
Last year, we were told that a new official OSMF attribution guideline was
just about to be released. In March you let us know we should not "hold our
breath" for the new attribution guidance to come out any soon:
https://github.com/openstreetmap/openstreetmap-website/issues/2375#issuecomment-605423823

It does not mean we do not have such guidance, it is already there, in the
legal FAQ:
https://wiki.osmfoundation.org/wiki/Licence/Licence_and_Legal_FAQ#Where_to_put_it.3F

"This credit needs to appear in a place that is reasonable to the medium or
means you are utilising. In other words, you should expect to credit
OpenStreetMap in the same way and with the same prominence as would be
expected by any other map supplier. Therefore:... For a *browsable
electronic map* (e.g. embedded in a web page or mobile phone application),
the credit should typically appear in the corner of the map, as commonly
seen with map APIs/libraries such as Google Maps."


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

Re: [Talk-transit] Making bus lines more specific

[Tony OSM]

I like node highway=bus_stop for the reasons polyglot gives. bus_stop is 
here to stay cos there are too many to change, by the side of the 
highway they give directionality depending on the customary side of the 
road for driving.


public_transport=platform works well for train and some trams. To me a 
platform is a construct to assist people to get on or off the transport 
vehicle. As a waiting area  - that use is secondary.


In GB some authorities are raising the area around a bus stop to enable 
wheelchair users easier access to buses - so yes a platform tag is 
appropriate, but not for a pole placed in the ground or pedestrian part 
of the road which is the default for buses where I live.


stop_position node - to me has no function - for buses their stop 
position is the bus stop;  for trains they stop at the platform; where I 
live we have 2,3,4,5,6 car trains, the front of the train stops at one 
of two defined positions depending on the number of cars.


Simplification of PTV2 may be helpful, but I have had no strong 
frustrations when using it.


Regards

TonyS999


On 28/04/2020 09:46, Jo wrote:

The basic objection they voice is why need 2 tags, if 1 does the job.

highway=bus_stop

is not exactly nonsensical. It's concise and expresses what is meant. 
(OK, it's not a highway and my preference is to map it next to the 
highway)



public_transport=platform

was designed at first to not need a mode of transport like 
bus=yes/tram=yes. I am the one who proposed adding it, so that it 
COULD start replacing highway=bus_stop back in 2012.


There is not always a platform present, so it's a bit of a misnomer as 
well.


Anyway, someone who wants to render a bus stop ideally wants to look 
at a single tag, not a combination of 2, apparently. For a long time 
it was supposedly a technical problem, but as soon as that was 
resolved somewhere around 2017, it was still considered problematic to 
look at 2 tags.


I wish you good luck with proposing another way of mapping public 
transport. Many have tried before you. It's really hard to beat status 
quo. And the status quo is not the same across the planet. If you can 
propose something that is both simpler, more elegant and still 
expressive enough for all usecases, I'll vote yes on it.


Polyglot

On Tue, Apr 28, 2020 at 10:26 AM Robin Däneke > wrote:


Indeed, these are good points. I would say, that the „platform“ is
enough. This could then mean either the „stop pole“ of the station
(which I would not say is the most important piece as that could
also just be a sticker on a shelter or a lamp post) close but not
at the station (sadly there are big inconsequent uses in real
life), or the area of the visible platform, if applicable.

But the rest of the community will have to accept the death of
(old) tags, when it is voted for. If this mailing list could come
up with a proposal most users here could live with, we all vote
for it (with the spelling of the end to certain tags) and it is
accepted that way, the community will have to accept that. The
first iteration was just to „nice“ to that conservative fraction.
Public transport can be complex, but this is why it needs
dedicated (own, simple) tags instead of legacy nonsense.

This is, why I would be happy to have many people work on this
„ideal“ solution, that is simple on the one hand, but powerful on
the other hand. I will make a Document where I put in my personal
critique and goal for a new scheme, and am then looking forward to
input on it. Will share it here when I have a framework of what
the current scheme says and have some changes in it. Then, the
specifying of the bus lines, the simplifying of the bus stations
(so that one or two tags can replace bus_stop but still do the
same thing functionally) and other points could be put in there.
Maybe we actually end up with a useful consensus, that one could
propose.

The more people get on board, the more acceptable it can become...

KR
RobinD


Am 28.04.2020 um 10:07 schrieb Jo mailto:winfi...@gmail.com>>:

For years and years we have tried to convince the people working
on carto, our default rendering to start supporting
public_transport=platform/bus=yes instead of highway=bus_stop.

They have clearly stated that this will never happen. Conclusion:
highway=bus_stop is NOT a legacy tag.

That's my conclusion anyway. In Belgium I'm even considering to
drop public_transport=platform on the bus stop nodes, but that's
not straightforward either anymore,, since the editor software
started to depend on them.

stop_position nodes, I have never considered them to be
important, so I never mapped them for ALL the stops. I do map
them for initial and terminus stops, was I want to split the way
there anyway. What I will definitely not do, the way I see it
done in 

Re: [Talk-it] Modifiche massive nomi di strade in seguito a note anonime

[Martin Koppenhoefer]

Am Di., 28. Apr. 2020 um 08:57 Uhr schrieb canfe :

> Non sono d'accordo.
> C'è una pagina wiki che specifica come vanno scritti i nomi delle vie.
> O le regole valgono per tutti o ognuno si inventa quella che piu' gli
> piace.
>


non si tratta di inventare, ci sono 2 possibilità: nomi come si trovano
scritte sui cartelli ed altri fonti in loco (questo è generalmente il
metodo applicato dal progetto OSM), e nomi ufficiali come assegnati da chi
spetta (consigli comunali). ISTAT invece ha fatto regole che i comuni sono
tenuti a rispettare. Noi non siamo i comuni...
Se loro procedono, seguiamo, se non lo fanno, non cambiamo nemmeno noi.

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

Re: [Talk-it] Modifiche massive nomi di strade in seguito a note anonime

[Martin Koppenhoefer]

Am Di., 28. Apr. 2020 um 08:25 Uhr schrieb Francesco Ansanelli <
franci...@gmail.com>:

>
>> 1) innanzitutto vi chiedo un parere su che cosa debba andare nel tag
>> "name": a mio parere si mappa quello che c'è sul campo (nel caso della nota
>> in questione "Via Pio XI", che compare sui cartelli) e si potrebbe usare
>> "alt_name" o anche "official_name", che vedo esistere, per altri nomi come
>> quello ISTAT. Ma su questo accetto volentieri pareri da chi è più esperto.
>>
>
> Concordo. Ma official_name è un tag equivoco perché molto spesso lungo le
> strade ci sono più versioni del nome.
>


infatti, "official_name" non è il nome che si trova sul cartello, è il nome
che si trova nella delibera comunale che ha istituito il nome. ISTAT (e
quantomeno chi produce cartelli stradali) non può cambiare i nomi, lo
devono fare i consigli comunali tramite delibera.


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

Re: [talk-cz] jak mapovat chodníky

[Jan Macura]

On Tue, 28 Apr 2020 at 11:29, Petr Vozdecký  wrote:

> (...) hned je vidět, (...)
>

Poznámka: 100 % map vytvořených nad daty OSM by bylo užitečnějších s
legendou.

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

Re: [talk-cz] jak mapovat chodníky

[Petr Vozdecký]

wow, to je věcička... :) to by se hodilo jako zajímavá systémová vrstva do
osmap.cz - hned je vidět, kde jsou chyby a nesmysly, které není možné
identifikovat, když to žádný (běžně užívaný) renderer nevykreslí...




vop




-- Původní e-mail --
Od: majkaz 

Předmět: Re: [talk-cz] jak mapovat chodníky "

Takže třeba tady https://osm-tiles.james-ross.co.uk/?map=19/48.973971/
14.476203(https://osm-tiles.james-ross.co.uk/?map=19/48.973971/14.476203) je
 vidět, že ty samostatně zmapované chodníky byly dodatečně přidané k těm, co
jsou na silnici jako vlastnost. Podobně je vidět, že na některých místech
jsou dodatečně zmapované parkovací pruhy jako plochy parkovišť, taky bez
toho, že by se to předtím odstranilo ze silnice.

 

 

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

Re: [OSM-talk-fr] Libraires et takeaway

[leni]

Le 28/04/2020 à 10:58, Marc M. a écrit :

Bonjour,

Le 28.04.20 à 10:41, leni a écrit :

Les libraires sont également fermés, mais il y en a certains qui
prennent les commandes et on peut venir chercher les livres devant la
librairie (certains parlent de drive piéton:-P)  le wiki n'indique
*takeaway *que pour la nourriture, peut-on l'utiliser pour les livres ?

Je suis mitigé.

takeaway indique que tu emportes au lieu de "consommer" sur place.
donc à priori je ne vois pas ce qui empêche de généraliser à un service
non-alimentaire, c'est même une bonne idée de généraliser.

Mais takeaway=yes est à mon avis par défaut pour une librairie:
un librairie permet d'emporter le livre pour le "consommer" chez soi.
Sinon c'est une simple salle de lecture comme il y en a pour les
archives ou documents public.

Du coup peut-être que ton cas se décrit avec takeaway=only :
rien ne se consulte sur place, uniquement à emporter.
sans doute à combiner avec reservation=required vu que tu dois réserver,
tu ne peux pas aller sur place quand cela t'arrange pour choisir
sans prévenir.

Cordialement,
Marc


merci marc

ce serait donc takeaway:covid19=only et reservation:covid19=required 
puisque le reste du temps tu n'as pas besoin de réserver




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

Re: [Talk-it] Modifiche massive nomi di strade in seguito a note anonime

[Lorenzo Stucchi]

Ciao,

Concordo con quanto è stato detto prima, vorrei però sottolineare il problema 
principale che sono le note anonime.

Ne vengono caricate a decine ogni giorno, (30 solo stamattina) [1] sono anonime 
e non è possibile risalire a chi le pubblica e tra l’altro contengono 
informazioni sbagliate su quale sia il nome corretto delle vie. Sembrano tutte 
con lo stesso formato, ad esempio:

“ Da direttive ISTAT il nome è
Piazza ventisei maggio “

Servirebbe secondo me poter capire come vengono create, avete qualche idea?

Ciao,
Lorenzo Stucchi

[1] https://ent8r.github.io/NotesReview/expert/?query=ISTAT


Il giorno 28 apr 2020, alle ore 09:42, Andrea Musuruane 
mailto:musur...@gmail.com>> ha scritto:

Ciao,
concordo con canfe.

In questa ML si rifanno periodicamente le stesse discussioni, dimenticandosi di 
averle già fatte. Sarebbe utile rileggersi gli ultimi thread.

https://lists.openstreetmap.org/pipermail/talk-it/2017-April/058290.html

https://lists.openstreetmap.org/pipermail/talk-it/2017-December/061356.html

https://lists.openstreetmap.org/pipermail/talk-it/2018-January/061775.html


https://lists.openstreetmap.org/pipermail/talk-it/2018-October/064461.html


Per quanto riguarda la questione "si mappa quello che c'è sul campo", vorrei 
sottolineare che non l'abbiamo mai fatto.Spesso gli odonomi sono indicati sui 
cartelli tutti in maiuscolo (a volte tutti in minuscolo) e non abbiamo mai 
inserito i nomi in questo modo ma abbiamo deciso di seguire la regole della 
lingua italiana, specificando di iniziare con una lettera maiuscola (Via e non 
via). Sovente gli odonimi riferiti a personaggi storici sono abbreviati o 
parziali e noi abbiamo sempre detto di inserirli completi. Allo stesso modo 
abbiamo deciso di seguire le regole ISTAT per avere delle regole uniformi in 
tutta Italia (tra l'altro non c'è alcun obbligo da parte dei comuni di adeguare 
la cartellonistica, ma solo di adeguare lo stradario - quindi a meno di non 
leggersi tutti i giorni l'albo pretorio di tutti i comuni italiani, non vi è 
modo di scoprire questi adeguamenti). Tutte queste regole servono oltre che a 
standardizzare la mappa, anche ai motori di ricerca, perché altrimenti un 
utente dovrebbe già sapere se in un comune c'è scritto sui cartelli "via 25 
aprile" o "VIA MAZZINI" oppure "Via G. Garibaldi".

Ciao,

Andrea



On Tue, Apr 28, 2020 at 8:57 AM canfe 
mailto:canfe.n...@gmail.com>> wrote:
Non sono d'accordo.
C'è una pagina wiki che specifica come vanno scritti i nomi delle vie.
O le regole valgono per tutti o ognuno si inventa quella che piu' gli piace.
https://wiki.openstreetmap.org/wiki/IT:Editing_Standards_and_Conventions#Nomi_delle_strade

Inoltre mi denuncio di avere fatto un editing massivo cambiando tutti i nomi
di via undici febbraio in tutto il Piemonte a suo tempo.
Revert??



--
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

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

Re: [OSM-talk-fr] Libraires et takeaway

[Marc M.]

Bonjour,

Le 28.04.20 à 10:41, leni a écrit :
> Les libraires sont également fermés, mais il y en a certains qui
> prennent les commandes et on peut venir chercher les livres devant la
> librairie (certains parlent de drive piéton:-P)  le wiki n'indique
> *takeaway *que pour la nourriture, peut-on l'utiliser pour les livres ?

Je suis mitigé.

takeaway indique que tu emportes au lieu de "consommer" sur place.
donc à priori je ne vois pas ce qui empêche de généraliser à un service
non-alimentaire, c'est même une bonne idée de généraliser.

Mais takeaway=yes est à mon avis par défaut pour une librairie:
un librairie permet d'emporter le livre pour le "consommer" chez soi.
Sinon c'est une simple salle de lecture comme il y en a pour les
archives ou documents public.

Du coup peut-être que ton cas se décrit avec takeaway=only :
rien ne se consulte sur place, uniquement à emporter.
sans doute à combiner avec reservation=required vu que tu dois réserver,
tu ne peux pas aller sur place quand cela t'arrange pour choisir
sans prévenir.

Cordialement,
Marc

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

Re: [OSM-talk-be] Telenav Mapping Project

[Adrian Budugan]

Hello Joost,

Most likely we will begin next week to edit on the map. We will keep you all up 
to date with our progress and any edits that we might do.

Thank you for your support.

p.s.  It’s nice too hear you visited Cluj-Napoca. If it has been a long time 
ago, the city has developed quite fast.



From: joost schouppe 
Sent: Thursday, April 23, 2020 1:10 PM
To: Adrian Budugan 
Cc: OpenStreetMap Belgium 
Subject: Re: [OSM-talk-be] Telenav Mapping Project

Hi Adrian,

Looking forward to your help! Do post here or on our Riot when you start the 
real work.

Error fixing is always helpful. Having looked at the Improve OSM tools, I don't 
see how it could help you much? OpenStreetCam is rather limited in Belgium 
(most of us contribute to Mapillary instead, but the day someone provides a 
server that feeds both projects, I'm sure we'll switch to that!). And for the 
Cygnus tool, you need government data. There is road geometry, but the 
differences are largely because the official data is lagging. I'm not aware of 
Brussels traffic sign data.

Best,
Joost
p.s. I really enjoyed CLuj Napoca when I was there many years ago

Op do 23 apr. 2020 om 11:46 schreef Adrian Budugan 
mailto:adrian.budu...@telenav.com>>:
Hello Joost,

Thank you for your reply and for the info provided. Considering that we will be 
working remotely, we are always checking the history of the edits before making 
any changes. We also decided to first rely on notes, as you suggested, and edit 
only where we are 100% sure.

We will be fixing errors  using the Keep Right tool and add one ways and turn 
restrictions using Improve OSM.

We will keep in touch as much as it is needed and thank you again for your 
feedback.

Kind Regards,
Adrian


From: joost schouppe mailto:joost.schou...@gmail.com>>
Sent: Wednesday, April 22, 2020 9:14 PM
To: OpenStreetMap Belgium 
mailto:talk-be@openstreetmap.org>>
Cc: Adrian Budugan 
mailto:adrian.budu...@telenav.com>>
Subject: Re: [OSM-talk-be] Telenav Mapping Project

Hi Adrian,

To add to that, there's an overview of all the channels at our local chapter's 
website: 
https://openstreetmap.be/en/contact.html

We have decent Mapillary coverage, but are constantly looking to get more and 
better cameras for our volunteers (hint, hint).
There is good and recent imagery (properly indexed both in the imagery layer 
index and the JOSM index). There are also good basemaps from the government, 
which you can use for mapping.

As always, both imagery and basemaps can be outdated - sometimes OSM is ahead, 
sometimes it isn't. There's quite an active community, so be mindful of the 
last edit date on object (I should know, I recently messed up JanFi's work).

What data will you be basing your edits on? I would think that Brussels is 
mapped pretty well, so it might be hard to improve remotely.
It might be useful to start off with just Notes, so that we can review them 
locally. That might avoid any editing conflict.
I think the most active mapper in Brussels is bxl-forever, might be useful to 
engage him directly.

Joost

Op wo 22 apr. 2020 om 20:01 schreef Pieter Vander Vennet 
mailto:pieterv...@posteo.net>>:

Hello Adrian and Telenav-team.

Welcome in Belgium, the more support, the merrier.

First of all, there is quite an active community in Belgium - I'm one of them, 
as are several others. As already mentioned, the matrix-chat is an excellent 
way to reach out to us and have questions answered quite fast - please join us 
here: 
https://riot.im/app/#/room/#osmbe:matrix.org

Second, I was wondering where you are based - the best way to map is by using 
local knowledge and by running around to see what the situation is. Also, being 
here IRL will allow us to meetup or to get in touch with the OpenKnowledge 
Belgium - they do great work for Open Source and Open Data.

However, I presume that you will mostly be doing remote work, based on official 
data and mapillary streetview. This too can be useful, but the situation of 
Brussels is quite volatile and might change a lot. Don't be afraid to to ask us 
(or a local) to check up on the situation.

At last, a lot of cyclists are using OSM in Brussels - the company I work for 
even hosts  a professional cycle route planner for the city. Please, be careful 
not to break it. Especially when adding 'oneway=yes', this might force the 
routeplanner to consider this oneway for cyclists as well. Please, if it is 
clear that cyclists are allowed to go both ways, add 'oneway:bicycle=no' or, 
even better, add the appropriate cycleway tags 

Re: [Talk-transit] Making bus lines more specific

[Jo]

The basic objection they voice is why need 2 tags, if 1 does the job.

highway=bus_stop

is not exactly nonsensical. It's concise and expresses what is meant. (OK,
it's not a highway and my preference is to map it next to the highway)


public_transport=platform

was designed at first to not need a mode of transport like
bus=yes/tram=yes. I am the one who proposed adding it, so that it COULD
start replacing highway=bus_stop back in 2012.

There is not always a platform present, so it's a bit of a misnomer as well.

Anyway, someone who wants to render a bus stop ideally wants to look at a
single tag, not a combination of 2, apparently. For a long time it was
supposedly a technical problem, but as soon as that was resolved somewhere
around 2017, it was still considered problematic to look at 2 tags.

I wish you good luck with proposing another way of mapping public
transport. Many have tried before you. It's really hard to beat status quo.
And the status quo is not the same across the planet. If you can propose
something that is both simpler, more elegant and still expressive enough
for all usecases, I'll vote yes on it.

Polyglot

On Tue, Apr 28, 2020 at 10:26 AM Robin Däneke  wrote:

> Indeed, these are good points. I would say, that the „platform“ is enough.
> This could then mean either the „stop pole“ of the station (which I would
> not say is the most important piece as that could also just be a sticker on
> a shelter or a lamp post) close but not at the station (sadly there are big
> inconsequent uses in real life), or the area of the visible platform, if
> applicable.
>
> But the rest of the community will have to accept the death of (old) tags,
> when it is voted for. If this mailing list could come up with a proposal
> most users here could live with, we all vote for it (with the spelling of
> the end to certain tags) and it is accepted that way, the community will
> have to accept that. The first iteration was just to „nice“ to that
> conservative fraction. Public transport can be complex, but this is why it
> needs dedicated (own, simple) tags instead of legacy nonsense.
>
> This is, why I would be happy to have many people work on this „ideal“
> solution, that is simple on the one hand, but powerful on the other hand. I
> will make a Document where I put in my personal critique and goal for a new
> scheme, and am then looking forward to input on it. Will share it here when
> I have a framework of what the current scheme says and have some changes in
> it. Then, the specifying of the bus lines, the simplifying of the bus
> stations (so that one or two tags can replace bus_stop but still do the
> same thing functionally) and other points could be put in there.
> Maybe we actually end up with a useful consensus, that one could propose.
>
> The more people get on board, the more acceptable it can become...
>
> KR
> RobinD
>
> Am 28.04.2020 um 10:07 schrieb Jo :
>
> For years and years we have tried to convince the people working on carto,
> our default rendering to start supporting public_transport=platform/bus=yes
> instead of highway=bus_stop.
>
> They have clearly stated that this will never happen. Conclusion:
> highway=bus_stop is NOT a legacy tag.
>
> That's my conclusion anyway. In Belgium I'm even considering to drop
> public_transport=platform on the bus stop nodes, but that's not
> straightforward either anymore,, since the editor software started to
> depend on them.
>
> stop_position nodes, I have never considered them to be important, so I
> never mapped them for ALL the stops. I do map them for initial and terminus
> stops, was I want to split the way there anyway. What I will definitely not
> do, the way I see it done in Germany is to duplicate information.
>
> I want to have a single object, preferably a node, that has all the
> details of the stop AND I want to include this object in the route
> relations. 1 object per stop, so not a sequence of
> stop_position/platform/stop_position/platform.
>
> As I don't consider the stop_position nodes to be important enough to map
> them everywhere I don't put name/ref/ etc on them. In Belgium most
> stop_position nodes will have only 1 extra tag, the mode of transport.
>
> For me it's an advantage that highway=bus_stop can only be used on a node.
> I want to map the object that represents the bus stop as a node anyway,
> next to the highway on the side where the passengers wait.
>
> If there is a physical platform, then it makes sense to map it as a way or
> a closed_way/area. In that case it gets highway=platform and possibly
> tactile_paving=yes/wheelchair=yes, maybe a height as well. But no
> repetition of name,ref,route_ref,operator,network, etc.
>
> If there is to be a next version of how we map public transport we should
> think about making it simpler. What I see in Germany is way too complicated
> and error prone, as information is duplicated across objects.
>
> Polyglot
>
>
>
>
> On Tue, Apr 28, 2020 at 9:45 AM Robin Däneke  wrote:

[OSM-talk-fr] #caresteouvert - Libraires

[leni]

Bonjour

Les libraires sont également fermés, mais il y en a certains qui 
prennent les commandes et on peut venir chercher les livres devant la 
librairie (certains parlent de drive piéton:-P)  le wiki n'indique 
*takeaway *que pour la nourriture, peut-on l'utiliser pour les livres ?


leni

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

Re: [talk-au] Vicmap Lite - Public Land (Parks and Reserves) not working

[Andrew Davidson]

On Tue, Apr 28, 2020 at 6:28 PM Andrew Harvey 
wrote:

> I was not aware we had permission to use this service, we have permission
> to use the data, but I didn't know the API endpoint was for public use. It
> looks like the service is down, we could ask the vicmap people if we can
> use this service and see if the are aware of the issue.
>
> The end point has been moved. Someone had fixed the other layers already.

The terms and conditions for the WMS service pretty much just say CC-BY 4.0:

https://www.data.vic.gov.au/copyright
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [OSM-talk-be] Telenav Mapping Project

[Adrian Budugan]

Hello Midgard,

Thank you for your reply. We have indeed encountered many false-positive 
results from keep right during our edits. But as you mentioned, it helps 
bringing up any potential errors that we can review and then correct only if 
needed.

Kind regards, 
Adrian

-Original Message-
From: Midgard  
Sent: Saturday, April 25, 2020 3:24 PM
To: OpenStreetMap Belgium 
Subject: Re: [OSM-talk-be] Telenav Mapping Project

Quoting Adrian Budugan (2020-04-23 13:29:32)
> Hi Marc,
> 
> It's nice to hear from you. From our first analysis, Brussels looks quite 
> complete and correctly mapped. We are looking to  first correct any errors 
> that might come up by running the Keep Right tool.
> Where there will be any doubts, we will leave notes and/or ask the community 
> before making any edits.
> 
> Kind regards,
> Adrian

Keep right "errors" are not always real errors. I see a lot of almost-junction 
reports in my neighbourhood, but they're all false positives.

Of course it highlights a lot of valid problems too. What I mean to say is, 
please don't map for the validator.

Kind regards,
M!dgard

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

Re: [Talk-it] [Import] Bologna - Coronavirus spesa a domicilio

[Martin Koppenhoefer]

sent from a phone

> On 28. Apr 2020, at 09:50, Cascafico Giovanni  wrote:
> 
> I dati del comune di Bologna e zone limitrofe sono appena stati liberati 
> apposta per OSM :-)
> 
> Ho steso una bozza di wiki [1].
> 
> Ho pensato ad un import tramite umap e level0. 
> 600+ nodi non solo pochi, ma ho trovato problemi a taggare automaticamente. 
> Se pensate possa essere oneroso, posso riconsiderare un import automatico.


visto che si usano tag specifici (*:covid19), dal mio punto di vista la cosa 
più importante sarebbe la conflation (sia l’identificazione di POI già 
esistenti, per aggiungere queste proprietà covid, sia il fatto che non 
sovrascriviamo i valori covid su oggetti taggati già (però possiamo verificare 
in caso ci sono contraddizioni). Se si riuscisse a fare questo in automatico, 
per me sarebbe ok.

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

Re: [talk-au] Vicmap Lite - Public Land (Parks and Reserves) not working

[Andrew Davidson]

Would you check to see if it's now pointing at the right layer. You'll have
to refresh the list of imagery in JOSM to update first.

It doesn't seem to have labels but, as I've never used this layer before, I
don't know if it should.



On Tue, Apr 28, 2020 at 5:58 PM Warin <61sundow...@gmail.com> wrote:

> Hi,
>
>
> The JOSM map imagery for Vicmap Lite - Public Land (Parks and Reserves)
> is generating errors and not loading.
>
>
> I have been trying to repair damage done by a new mapper to things
> sourced from this imagery.
>
> Unfortunately the reversion is not repairing the damage on selected
> ways. Reverting it all .. well there are a lot of changesets and it
> would take some time.
>
> Easiest is to rested the boundaries back to the imagery.
>
>
>
>
> ___
> 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: [talk-au] Vicmap Lite - Public Land (Parks and Reserves) not working

[Andrew Harvey]

This was added by an annonymous user in
https://josm.openstreetmap.de/wiki/Maps/Australia?sfp_email=_mail==diff=47_version=46_email=_mail=

I was not aware we had permission to use this service, we have permission
to use the data, but I didn't know the API endpoint was for public use. It
looks like the service is down, we could ask the vicmap people if we can
use this service and see if the are aware of the issue.

The data is still available for download via
http://services.land.vic.gov.au/SpatialDatamart (find VicMap Products then
VicMap Lite, and limit to whole of state vic). The download process can be
hard to workout the first time.

I've downloaded and converted the layer to GeoJSON which can be loaded into
JOSM http://tianjara.net/data/vmlite_public_land_su5.zip

On Tue, 28 Apr 2020 at 17:58, Warin <61sundow...@gmail.com> wrote:

> Hi,
>
>
> The JOSM map imagery for Vicmap Lite - Public Land (Parks and Reserves)
> is generating errors and not loading.
>
>
> I have been trying to repair damage done by a new mapper to things
> sourced from this imagery.
>
> Unfortunately the reversion is not repairing the damage on selected
> ways. Reverting it all .. well there are a lot of changesets and it
> would take some time.
>
> Easiest is to rested the boundaries back to the imagery.
>
>
>
>
> ___
> 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-ie] Overpass query?

[Brian Hollinshead]

Hi Donal,
Thanks for having a go at that overpass query. Your offer showed the
Diocese of Ardfert which has perhaps six Cork civil parishes. I had not
included it in my enquiry for fear of complicating it further.

If you run overpass, include all County Cork on screen and use wizard:
boundary=historic_diocese, the resultant white space is the Diocese of Cork
(1837)  from which i wish to load all the civil parishes into JOSM for
further progress.

For anyone new to this conversation that is : all the civil parishes in
County cork not already mapped in OSM as parts or all of the Dioceses of
Ardfert and Aghadoe, Cloyne or Ross. (as boundary=historic_diocese)

Further suggestions from anyone more familiar with overpass than I am will
be most welcome.

Thanks

On Tue, 28 Apr 2020 at 00:17, Donal Hunt 
wrote:

> Hi Brian,
>
> I tried to take a stab at this but overpass got the better of me!!
>
> Here is what I've got so far: https://overpass-turbo.eu/s/Tn4
>
> This will give you an area excluding the two diocese relations you
> mentioned. I think you either need to do a map_to_area or a Recurse up/down
> relations function after that but I can't wrap my head around that part and
> there are few examples that explain it well enough...
>
> Also - in hindsight, my query result only returns other diocesan areas that
> are not Ross / Cloyne. There are obviously parts of Cork that aren't
> contained within a diocesan area right now.
>
> Hopefully one of the overpass gurus here will put us out of our misery!! =)
>
> Donal
>
> On Sat, Apr 25, 2020 at 4:38 PM Brian Hollinshead 
> wrote:
>
> > Overpass query: County Cork comprises the Dioceses of Cloyne, Cork and
> > Ross. I have added Cloyne and Ross as boundary=historic_diocese to OSM.
> > Please can I use overpass to load the remaining civil parishes into JOSM.
> > Something  like  boundary=civil_parish in "County Cork" BUT NOT
> > (boundary=civil_parish in "Diocese of Cloyne") OR NOT
> > (boundary=civil_parish in "Diocese of Ross). I seem to remember that
> > boundary!=xxx omits what follows but am unsure.
> > Thanks
> > ___
> > Talk-ie mailing list
> > Talk-ie@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-ie
> >
>
>
> --
> Donal Hunt
> OpenStreetMap Ireland
> donal.h...@openstreetmap.ie | +353 87 8175123
> ___
> Talk-ie mailing list
> Talk-ie@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ie
>
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

Re: [Talk-transit] Making bus lines more specific

[Jo]

For years and years we have tried to convince the people working on carto,
our default rendering to start supporting public_transport=platform/bus=yes
instead of highway=bus_stop.

They have clearly stated that this will never happen. Conclusion:
highway=bus_stop is NOT a legacy tag.

That's my conclusion anyway. In Belgium I'm even considering to drop
public_transport=platform on the bus stop nodes, but that's not
straightforward either anymore,, since the editor software started to
depend on them.

stop_position nodes, I have never considered them to be important, so I
never mapped them for ALL the stops. I do map them for initial and terminus
stops, was I want to split the way there anyway. What I will definitely not
do, the way I see it done in Germany is to duplicate information.

I want to have a single object, preferably a node, that has all the details
of the stop AND I want to include this object in the route relations. 1
object per stop, so not a sequence of
stop_position/platform/stop_position/platform.

As I don't consider the stop_position nodes to be important enough to map
them everywhere I don't put name/ref/ etc on them. In Belgium most
stop_position nodes will have only 1 extra tag, the mode of transport.

For me it's an advantage that highway=bus_stop can only be used on a node.
I want to map the object that represents the bus stop as a node anyway,
next to the highway on the side where the passengers wait.

If there is a physical platform, then it makes sense to map it as a way or
a closed_way/area. In that case it gets highway=platform and possibly
tactile_paving=yes/wheelchair=yes, maybe a height as well. But no
repetition of name,ref,route_ref,operator,network, etc.

If there is to be a next version of how we map public transport we should
think about making it simpler. What I see in Germany is way too complicated
and error prone, as information is duplicated across objects.

Polyglot




On Tue, Apr 28, 2020 at 9:45 AM Robin Däneke  wrote:

> Hello everybody,
>
> I have lately been thinking about somehow reworking (or giving a new push
> to) the current p_t:v2 scheme.
> Especially for the fact, that, since it was first proposed and accepted,
> not a lot has changed in which tags are rendered, how certain things are
> hence mapped and the Wiki-Pages on the topic have also changed in the last
> years without any visible going through another proposal process.
>
> When I started mapping in 2011, and first read the german and then the
> english p:t:v2 wiki pages, it was:
> - highway=bus_stop is a legacy tag that should eventually be completely
> phased out
> - stop positions and platforms are to be both mapped
> and some other things I already forgot…
> Now, iD has a rule in its verifyer, that requires highway=bus_stop on
> platform nodes. The point of the public_transport tags is, among other
> points, to replace less dedicated highway tags.
> I think it would be time for a p_t:v2.5 proposal, where we take the
> innicial ideas of the v2, maybe refine a few small details (like is
> stop_position required, or just platforms, can relations of route-parts be
> used in route relations to save on redundancy…) and then put it forward for
> voting. If accepted, we would possibly now have more leverage to get the
> editor and render-programers to actually properly implement it this time
> around.
>
> Maybe I could find some time to write my suggestions into a document, and
> we could collect the ideas for those extra tags in there too. I think it
> would make more sense that way, than just the addition of a few tags to the
> current scheme, to then be ignored by the rest of OSM once again.
>
> Kind Regards
> Robin D. (emergency99)
>
>
> PS: The problem with bus_stop on platform: platforms can be nodes, lines,
> ways, even relations, highway=bus_stop can only be a node. This old tag
> should go the same way as the farm tag, which was (forcefully) abandoned a
> couple of years back. There it worked, why not for the „new“ p_t scheme?
>
> > Am 28.04.2020 um 00:12 schrieb Guilherme Braga Alves <
> gbragaal...@gmail.com>:
> >
> > I read your responses and I tend to agree that the opening_hours tag is
> enough to characterize services that are only operated during peak hours.
> >
> > On the other hand, it seems to me that there is also agreement on the
> relevance of having tags to differentiate bus services.
> >
> > How can we expand this debate and expand this discussion? It may be
> interesting for other members of the list to speak out, and then we can
> create or redeem a proposal for implementing new tags.
> >
> > P.S .: I don't know if this message will enter the reply queue
> correctly; I hope I'm not opening a new topic. I apologize for my
> inexperience with maillists.
> > ___
> > Talk-transit mailing list
> > Talk-transit@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-transit
>
>
> 

[talk-au] Vicmap Lite - Public Land (Parks and Reserves) not working

[Warin]

Hi,


The JOSM map imagery for Vicmap Lite - Public Land (Parks and Reserves) 
is generating errors and not loading.



I have been trying to repair damage done by a new mapper to things 
sourced from this imagery.


Unfortunately the reversion is not repairing the damage on selected 
ways. Reverting it all .. well there are a lot of changesets and it 
would take some time.


Easiest is to rested the boundaries back to the imagery.




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

[Talk-it] [Import] Bologna - Coronavirus spesa a domicilio

[Cascafico Giovanni]

Ciao lista!

I dati del comune di Bologna e zone limitrofe sono appena stati liberati
apposta per OSM :-)

Ho steso una bozza di wiki [1].

Ho pensato ad un import tramite umap e level0.
600+ nodi non solo pochi, ma ho trovato problemi a taggare automaticamente.
Se pensate possa essere oneroso, posso riconsiderare un import automatico.

[1]
https://wiki.openstreetmap.org/wiki/Import/Catalogue/BO-EserciziCommerciali
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Modifiche massive nomi di strade in seguito a note anonime

[Andrea Musuruane]

Ciao,
concordo con canfe.

In questa ML si rifanno periodicamente le stesse discussioni,
dimenticandosi di averle già fatte. Sarebbe utile rileggersi gli ultimi
thread.

https://lists.openstreetmap.org/pipermail/talk-it/2017-April/058290.html

https://lists.openstreetmap.org/pipermail/talk-it/2017-December/061356.html

https://lists.openstreetmap.org/pipermail/talk-it/2018-January/061775.html


https://lists.openstreetmap.org/pipermail/talk-it/2018-October/064461.html


Per quanto riguarda la questione "si mappa quello che c'è sul campo",
vorrei sottolineare che non l'abbiamo mai fatto.Spesso gli odonomi sono
indicati sui cartelli tutti in maiuscolo (a volte tutti in minuscolo) e non
abbiamo mai inserito i nomi in questo modo ma abbiamo deciso di seguire la
regole della lingua italiana, specificando di iniziare con una lettera
maiuscola (Via e non via). Sovente gli odonimi riferiti a personaggi
storici sono abbreviati o parziali e noi abbiamo sempre detto di inserirli
completi. Allo stesso modo abbiamo deciso di seguire le regole ISTAT per
avere delle regole uniformi in tutta Italia (tra l'altro non c'è alcun
obbligo da parte dei comuni di adeguare la cartellonistica, ma solo di
adeguare lo stradario - quindi a meno di non leggersi tutti i giorni l'albo
pretorio di tutti i comuni italiani, non vi è modo di scoprire questi
adeguamenti). Tutte queste regole servono oltre che a standardizzare la
mappa, anche ai motori di ricerca, perché altrimenti un utente dovrebbe già
sapere se in un comune c'è scritto sui cartelli "via 25 aprile" o "VIA
MAZZINI" oppure "Via G. Garibaldi".

Ciao,

Andrea



On Tue, Apr 28, 2020 at 8:57 AM canfe  wrote:

> Non sono d'accordo.
> C'è una pagina wiki che specifica come vanno scritti i nomi delle vie.
> O le regole valgono per tutti o ognuno si inventa quella che piu' gli
> piace.
>
> https://wiki.openstreetmap.org/wiki/IT:Editing_Standards_and_Conventions#Nomi_delle_strade
>
> Inoltre mi denuncio di avere fatto un editing massivo cambiando tutti i
> nomi
> di via undici febbraio in tutto il Piemonte a suo tempo.
> Revert??
>
>
>
> --
> 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: [Talk-it] Modifiche massive nomi di strade in seguito a note anonime

[Francesco Ansanelli]

Il mar 28 apr 2020, 09:28 Alessandro Sarretta 
ha scritto:

> Ciao Canfe,
> On 28/04/20 08:57, canfe wrote:
>
> Non sono d'accordo.
> C'è una pagina wiki che specifica come vanno scritti i nomi delle vie.
> O le regole valgono per tutti o ognuno si inventa quella che piu' gli 
> piace.https://wiki.openstreetmap.org/wiki/IT:Editing_Standards_and_Conventions#Nomi_delle_strade
>
> Inoltre mi denuncio di avere fatto un editing massivo cambiando tutti i nomi
> di via undici febbraio in tutto il Piemonte a suo tempo.
> Revert??
>
> personalmente sono assolutamente d'accordo nel rispettare le decisioni
> discusse e documentate nel wiki e delle quali—ammetto—non riesco sempre a
> tenere traccia. Per il nome, il wiki dice "usate il tag alt_name
> =* per inserire il
> giorno con i numeri romani. Es: Via XXV Aprile"
>
> Mi sembra che gli edits che hai fatto in Piemonte rispettino tutti i
> crismi, cioè hanno un changeset informativo (
> https://www.openstreetmap.org/changeset/77287079) e soprattutto
> mantengono, con uno schema ben definito, anche il nome verificabile a
> terra: name= Via Undici Febbraio , alt_name= Via XI Febbraio,
> short_name=Via 11 Febbraio
>

Aggiungo che a suo tempo stavamo anche analizzando una possibile soluzione
per creare dei controlli che ci venissero in aiuto per uniformare i nomi.
Credo sarebbe veramente molto utile avere i nomi delle strade ben
strutturati, lo scopo principale deve rimanere sempre la navigazione e la
fruibilità. Se devo cercare un indirizzo in una città in cui non sono mai
stato, difficile che mi metto a provare i numeri romani nel box...

> Nel caso evidenziato da Marco invece il nome presente è stato cancellato
> https://www.openstreetmap.org/way/568500510/history e il riferimento alla
> note secondo me è troppo vago.
>
+1

Per quello conviene commentare nel changeset e concordare su questi punti.
>
> Ale
> ___
> 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] Modifiche massive nomi di strade in seguito a note anonime

[Marco Minghini]

Ciao a tutti e grazie per il primo round di commenti,
mi sembra che la discussione si stia concentrando sul punto 1),
evidenziando comunque di riflesso i problemi sui punti 2) e 3).

Sono anch'io d'accordo nel rispettare la wiki e ringrazio per aver
segnalato la pagina, ma faccio notare che:
- l'utente mcheck NON ha cambiato i nomi delle vie così come dice la wiki:
ad esempio ha messo "Via venticinque aprile" ma la wiki dice "Via
Venticinque Aprile". Quindi torniamo al problema di verificare le note e
discuterne con la comunità prima: in questo caso mi pare di capire che
anche se l'ISTAT dice una cosa, noi dovremmo guardare alla wiki.
- l'utente mcheck ha semplicemente modificato il name, ma non ha spostato
il contenuto del vecchio name in un altro tag (ad esempio alt_name)
- l'utente mcheck ha modificato i tag addr:* (grazie Cascafico per la
domanda), il che rende un bel casino un'eventuale contro-modifica dei nomi
o revert.

Su consiglio di Alessandro, l'ho invitato a unirsi a questa discussione.

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

Re: [Talk-it] Modifiche massive nomi di strade in seguito a note anonime

[Alessandro Sarretta]

Ciao Canfe,

On 28/04/20 08:57, canfe wrote:

Non sono d'accordo.
C'è una pagina wiki che specifica come vanno scritti i nomi delle vie.
O le regole valgono per tutti o ognuno si inventa quella che piu' gli piace.
https://wiki.openstreetmap.org/wiki/IT:Editing_Standards_and_Conventions#Nomi_delle_strade

Inoltre mi denuncio di avere fatto un editing massivo cambiando tutti i nomi
di via undici febbraio in tutto il Piemonte a suo tempo.
Revert??


personalmente sono assolutamente d'accordo nel rispettare le decisioni 
discusse e documentate nel wiki e delle quali—ammetto—non riesco sempre 
a tenere traccia. Per il nome, il wiki dice "usate il tag alt_name 
=* per inserire il 
giorno con i numeri romani. Es: Via XXV Aprile"


Mi sembra che gli edits che hai fatto in Piemonte rispettino tutti i 
crismi, cioè hanno un changeset informativo 
(https://www.openstreetmap.org/changeset/77287079) e soprattutto 
mantengono, con uno schema ben definito, anche il nome verificabile a 
terra: name= Via Undici Febbraio , alt_name= Via XI Febbraio, 
short_name=Via 11 Febbraio


Nel caso evidenziato da Marco invece il nome presente è stato cancellato 
https://www.openstreetmap.org/way/568500510/history e il riferimento 
alla note secondo me è troppo vago.


Per quello conviene commentare nel changeset e concordare su questi punti.

Ale

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

Re: [Talk-it] Modifiche massive nomi di strade in seguito a note anonime

[Alecs via Talk-it]

Concordo con te, mi sembra che ormai fosse una regola ormai assodata, non vedo 
nessun problema.
Alecs
--
Inviato da Libero Mail per Android martedì, 28 aprile 2020, 08:58AM +02:00 da 
canfe  canfe.n...@gmail.com :

>Non sono d'accordo.
>C'è una pagina wiki che specifica come vanno scritti i nomi delle vie.
>O le regole valgono per tutti o ognuno si inventa quella che piu' gli piace.
>https://wiki.openstreetmap.org/wiki/IT:Editing_Standards_and_Conventions#Nomi_delle_strade
>
>Inoltre mi denuncio di avere fatto un editing massivo cambiando tutti i nomi
>di via undici febbraio in tutto il Piemonte a suo tempo.
>Revert??
>
>
>
>--
>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: [Talk-it] Modifiche massive nomi di strade in seguito a note anonime

[canfe]

Non sono d'accordo.
C'è una pagina wiki che specifica come vanno scritti i nomi delle vie.
O le regole valgono per tutti o ognuno si inventa quella che piu' gli piace.
https://wiki.openstreetmap.org/wiki/IT:Editing_Standards_and_Conventions#Nomi_delle_strade

Inoltre mi denuncio di avere fatto un editing massivo cambiando tutti i nomi
di via undici febbraio in tutto il Piemonte a suo tempo.
Revert??



--
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-fr] [Presse Locale][Ca Urge] Ça reste ouvert :

[PanierAvide]

Bonjour,

La stratégie adoptée est que ce sont les communautés locales des 
différents pays qui sont porteurs de l'initiative, donc tant qu'une 
communauté locale ne se manifeste pas, pas d'ouverture de "Ça reste 
ouvert" dans un pays. L'idée étant qu'il faut du monde pour traduire, 
animer, contribuer, gérer les notes... Voir pour référence : 
https://github.com/osmontrouge/caresteouvert/wiki/Expand-%22%C3%87a-reste-ouvert%22-to-another-country


Ceci étant dit, Andorre a été intégré pour ne pas avoir de discontinuité 
entre France et Espagne, ce ne serait donc pas plus mal d'activer Monaco 
également sur ce même principe.


Cordialement,

Adrien P.

Le 28/04/2020 à 07:18, Philippe Verdy a écrit :
Rien à Monaco (contrairement à Andorre) ou bien c'est groupé avec la 
France (étant donné la proximité des 4 autres communes françaises 
autour: Le Cap-d'Ail, La Turbie, Beausoleil et Roquebrune-Cap-Martin 
qui ont quelques points mais à mon avis même pas assez)?


Je ne vois aucun point (même gris) à Monaco (dont les lieux pourraient 
être indexés avec ceux de la France, ça ne va pas beaucoup 
révolutionner les statistiques, sauf justement concernant les 
établissements médicaux, hors l'hôpital qui comme les autres ne sont 
pas à renseigner car ils sont évidemment ouverts et ont à gérer 
l'urgence et coopèrent avec toute la région, même si les frontières 
sont encore fermées ou sévèrement contrôlées par les autorités 
monégasques, sachant que la population monégasque est 
relativement âgée et plus exposées aux risques que les communes 
française autour, mais pourtant il y a des tas de travailleurs 
transfrontaliers: si la frontière est fermée, nombre de commerces 
n'ont plus le personnel nécessaire pour ouvrir et les monégasques 
doivent alors se rendre dans les grandes surfaces ouvertes en France, 
s'ils peuvent se déplacer, ou utiliser les livraisons s'il y en a en 
mode transfrontalier).


Rien au Luxembourg ni en Belgique (au moins la partie francophone et 
la capitale si les néerlandophones n'ont pas encore leur version) ? Là 
encore une bande frontalière peut être concernée en zone moins dense 
pour des raisons de proximité alors que les services en France peuvent 
être plus éloignés (inaccessibles dans les délais imposés) que ceux 
dans le pays voisin (notamment les supermarchés et hypers, 
stations-service).



Le mar. 21 avr. 2020 à 11:26, PanierAvide > a écrit :


Bonjour,

On a pas mal de stats générées ici :
https://download.osmontrouge.fr/caresteouvert/

Cordialement,

Adrien P.

Le 21/04/2020 à 11:01, Jacques Lavignotte a écrit :
> Bonjour,
>
> pour la presse locale j'ai besoin de chiffres CRO sur les
départements
> 86 et 79.
>
> Nombre commerces dans CRO, nombre de contributeurs, etc.
>
> C'est pour midi :)
>
> Merci, Jacques
>
>
> Le 25/03/2020 à 19:44, PanierAvide a écrit :
>> Bonjour à tous,
>>
>> Suite aux échanges divers sur l'épidémie de Covid-19 et comment
OSM
>> pouvait proposer une information de qualité sur le sujet, nous
avons
>> enfin publié "Ça reste ouvert", la carte des lieux ouverts
pendant le
>> confinement : caresteouvert.fr 
>>
>> La carte propose aux visiteurs d'ajouter des infos dans leur
commune
>> : cela créé une note automatiquement dans OSM, avec les
informations
>> nécessaires. Ces notes sont à passer en revue pour intégrer les
tags
>> sur les lieux concernés. En particulier :
>>
>> - opening_hours:covid19 : horaires d'ouvertures pendant le
>> confinement (ou off si fermé)
>> - note:covid19 : si des infos supplémentaires sont données
(livraison
>> à domicile, mesures sanitaires...)
>>
>> Pour vous aider à passer en revue les notes, il y a l'outil
>> NotesReview :
>>
>>

https://ent8r.github.io/NotesReview/?query=%23caresteouvert=1=2020-03-23=6%2F47.3691%2F1.0107

>>
>>
>> Et la page de coordination du projet est ici :
>> https://wiki.openstreetmap.org/wiki/France/Covid-19
>>
>> Nous comptons sur la communauté pour intégrer ces infos et faire
>> d'OSM la base de données de référence pendant le confinement
(et même
>> après) !
>>
>> Cordialement,
>>
>

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


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

Re: [Talk-it] Modifiche massive nomi di strade in seguito a note anonime

[Francesco Ansanelli]

Il mar 28 apr 2020, 07:57 Cascafico Giovanni  ha
scritto:

> Almeno gli addr:* sono coerenti adesso?
>

Anche questo è un controllo fondamentale quando si cambiano i nomi:

http://osmose.openstreetmap.fr/it/byuser/mcheck?username=mcheck=5080

Ci tengo a dire che uso il nome di mcheck come esempio perché la
discussione è sulle sue ultime modifiche. Ma vale assolutamente per tutti.

Francesco


> Il mar 28 apr 2020, 00:09 Martin Koppenhoefer  ha
> scritto:
>
>>
>>
>> sent from a phone
>>
>> > On 27. Apr 2020, at 22:55, Marco Minghini 
>> wrote:
>> >
>> > Vi chiedo quindi cosa sia giusto fare in tutti i casi interessati da
>> queste modifiche.
>>
>>
>> intanto hai fatto bene a presentare il problema qui, io sono d’accordo
>> con te in tutti i punti. Finché i nomi non si cambiano ufficialmente (cosa
>> al meno  in parte è stato fatto) lascerei tutto, invece quando cambia il
>> nome ufficiale ma non vengono cambiati i cartelli potremmo mappare il nome
>> ufficiale nel tag official_name, ma non dovremmo per forza cambiare il
>> “name“. Un tag apposito per nomi secondo ISTAT (ma non ufficializzati)
>> penso non sia necessario (forse).
>>
>> 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] Modifiche massive nomi di strade in seguito a note anonime

[Francesco Ansanelli]

Ciao,

Il lun 27 apr 2020, 22:55 Marco Minghini  ha
scritto:

> Ciao a tutti,
> un paio di settimane fa Lorenzo Stucchi aveva segnalato su Telegram
> l'apertura di circa 200 note in corrispondenza di strade, da parte di un
> utente anonimo nella zona nord di Milano (fino a Como e Lecco) in cui viene
> segnalato che "Da direttive ISTAT il nome è ..." seguito dal presunto nome
> ISTAT della strada in questione. In buona sostanza, le modifiche proposte
> vogliono il nome della strada modificato da "Via XXV Aprile" a "Via
> venticinque aprile", da "Via Vittorio Emanuele II" a "Via Vittorio Emanuele
> secondo", e così via in modo simile.
>

Potrebbe essere uno stradario la fonte?
Gli esempi di modifica sembrano corretti, ma andrebbero lasciati tutti i
nomi alternativi in altri tag.
Es.
alt_name=Via XXV Aprile
name=Via Venticinque Aprile
short_name=Via 25 Aprile


> A Lorenzo era stata data solo una risposta su Telegram: "Sono i nomi come
> li vorrebbe ISTAT ma nella realtà nessuno li usa ed anche le
> amministrazioni, almeno dalle mie parti, non sembrano tanto interessate ad
> adeguarsi. Per me la forma corrente va mantenuta, almeno come nome
> alternativo."
>

Sicuramente!

>
> Quello che è successo dopo è che nei giorni scorsi l'utente mcheck ha
> modificato a tappeto i nomi di tutte le strade interessate dalle note e ha
> chiuso tutte le note, commentandole tutte con un semplice 'ok'. Io ne ho
> trovata una nella mia zona, che ho prontamente riaperto e commentato, in
> cui il nome è stato persino modificato da mcheck in modo diverso da come la
> nota suggeriva: https://www.openstreetmap.org/note/2157792
>

Capisco la frustrazione, ma facendo così tante modifiche forse può scappare
un errore e questo mi fa credere che non si tratti di una procedura
automatica.

>
> Mi sembra che in tutto ciò ci sia più di una cosa che non va:
>
> 1) innanzitutto vi chiedo un parere su che cosa debba andare nel tag
> "name": a mio parere si mappa quello che c'è sul campo (nel caso della nota
> in questione "Via Pio XI", che compare sui cartelli) e si potrebbe usare
> "alt_name" o anche "official_name", che vedo esistere, per altri nomi come
> quello ISTAT. Ma su questo accetto volentieri pareri da chi è più esperto.
>

Concordo. Ma official_name è un tag equivoco perché molto spesso lungo le
strade ci sono più versioni del nome. Nel mio comune c'è un cartello:
"Corso Dante Alighieri" e almeno una decina sono: "Corso Dante"... Mica
possiamo spezzare le way finché non vengono sostituiti tutti i cartelli,
giusto?


> 2) a prescindere da quale nome vada messo in quale tag, il messaggio che
> compare su ogni nota aperta da anonimi ci ricorda che "Questa nota include
> commenti da parte di utenti anonimi che devono essere verificati in modo
> indipendente". Le note sono un bene prezioso, ma come minimo l'informazione
> contenuta va verificata prima di fare modifiche, in questo caso recuperando
> la fonte del presunto nome corretto o chiedendola all'autore della nota.
>

Sicuramente è meglio approfondire.


> 3) Cambiare oltre 200 nomi di strade (che corrispondono probabilmente a
> migliaia di way) è una modifica massiva che credo vada discussa con la
> comunità prima di essere fatta. Noto invece che l'utente mcheck chiude
> decine e decine di note ogni giorno in diverse parti di Italia, senza
> verificare la fonte, senza commentare le note e senza rispondere ai
> commenti degli altri.
>


Questi sono tanti campanelli d'allarme. Credo non sia comunque il caso di
riaprire la discussione sui nomi Istat.
Ma invece capire chi mette le note, come vengono evase e se la cosa si può
fare senza verifica sul campo.
Per me si, a patto che si faccia un controllo incrociato (es. mapillary o
strumento analogo) e si lascino i "vecchi" nomi.
Spero che risponda anche l'interessato.


> Vi chiedo quindi cosa sia giusto fare in tutti i casi interessati da
> queste modifiche.
>

Hai fatto bene a scrivergli e scrivere anche qui

>
> Grazie,
> Marco
> ___
> 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