Re: [Talk-GB] Rockall

2020-06-15 Per discussione Warin

On 16/6/20 7:43 am, Colin Smale wrote:


On 2020-06-15 23:14, barry b wrote:


Hi Folks, I made the below changes to rockall.

snip

I don't know the exact procedure here. I feel i didn't do it right.
Don't worry too much about "not doing it right", just about everybody 
here has "been there done that got the t-shirt".
+1. If we all waited until we were certain it was 'right' the map would 
be very vacant. Best effort etc but there come a time when you have to 
go with what you think is correct.


Me?
place=islet

surface=rock


If you tag just natural=rock then will it be above the sea or under it? 
Place=islet says it is above the sea and then the surface tag gives you 
the rock aspect.



I'd level the admin borders up to the 'experts' ... tends to get messy 
on international things.
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-br] Importações de transformadores.

2020-06-15 Per discussione portalaventura
O artigo [1] apontado pelo Tomio resume o procedimento em relação a 
importações. O artigo [2] detalha o processo, especialmente o guia sobre 
importações [3].


Quais as condições impostas pela empresa para fornecimento dos dados? 
Estão sobre uma licença especifica? Isso é importante para sabermos se 
os dados fornecidos são compatíveis com a ODbl [4], licença utilizada 
pelo projeto. Se a base de dados não é e a empresa não está disposta a 
licenciá-la de maneira compatível com a licença do projeto, não dá pra 
pensar em importá-la.


[1] 
https://wiki.openstreetmap.org/wiki/Brazil/Resumo_Sobre_Importa%C3%A7%C3%B5es


[2] https://wiki.openstreetmap.org/wiki/Import

[3] https://wiki.openstreetmap.org/wiki/Import/Guidelines

[4] https://www.openstreetmap.org/copyright

Em 15/06/2020 10:49, Mapas Osm escreveu:

Olá,
Tenho informações georreferenciadas de transformadores e chaves de 
parte dos estados de São Paulo e Mato Grosso do Sul, os dados foram 
fornecidos pela empresa de energia local. Cada ponto possui seu código 
específico indispensável para sua consulta.
Existe a possibilidade de importar esses dados para o OSM base? Caso 
positivo, como proceder à importação de forma que esses códigos podem 
ser consultados?


Desde já agradeço!

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


--
--
portalaventura

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


Re: [Talk-br] Importações de transformadores.

2020-06-15 Per discussione Helio Cesar Tomio
Tem informações aqui tb:
https://wiki.openstreetmap.org/WikiProject_Brazil/Resumo_Sobre_Importa%C3%A7%C3%B5es

Em seg, 15 de jun de 2020 10:48, Mapas Osm  escreveu:

> Olá,
> Tenho informações georreferenciadas de transformadores e chaves de parte
> dos estados de São Paulo e Mato Grosso do Sul, os dados foram fornecidos
> pela empresa de energia local. Cada ponto possui seu código específico
> indispensável para sua consulta.
> Existe a possibilidade de importar esses dados para o OSM base? Caso
> positivo, como proceder à importação de forma que esses códigos podem ser
> consultados?
>
> Desde já agradeço!
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br


[Talk-us] Rail - Usage vs. Service wiki draft

2020-06-15 Per discussione Chuck Sanders
Good evening - another rail question for those interested.

I'm clear myself on the difference between the two subject keys, but always
thought the sparse wiki definition on the two might not be very clear for
newer editors without a strong railroad background.  In the course of
rooting around for work today through an obscure 315 page FRA guide on
railroad accident reporting, I found a nice definition that's a lot clearer
than the OpenRailwayMap/Tagging one-line explanations.

I've thrown together the following rough draft for a new section on my user
page, to be potentially added between the Useful Combination and the Route
Importance sections of OpenRailwayMap/Tagging in North America:

https://wiki.openstreetmap.org/wiki/User:Nathhad/TaggingNADraft#Usage_vs._Service_-_What_is_a_route.3F

If you have any interest in rail, please take a quick peek, and let me know
if it looks useful, is too wordy or badly worded, or should be left out
altogether.  If it's liked, I'll slide it into the wiki once I've
incorporated feedback.

Thanks!
Chuck
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us


Re: [Talk-africa] MapRoulette challenges to map unmapped towns, and new paint style for JOSM

2020-06-15 Per discussione Andrew Wiseman via Talk-africa
(Français ci-dessous:)

Hi everyone,

I added four more countries thanks to some community requests:

Cameroon:https://maproulette.org/browse/challenges/13673
Chad:https://maproulette.org/browse/challenges/13674
Burundi & Rwanda:https://maproulette.org/browse/challenges/13675

The full list is here: https://maproulette.org/browse/projects/39262


Salut à tous,

Voici Andrew de l'équipe Apple. J'ai récemment publié de nombreux nouveaux 
défis MapRoulette pour cartographier les villes non cartographiées dans divers 
pays du continent.

Il a été créé à partir des données du site Unmapped Places de Pascal Neis 
(https://resultmaps.neis-one.org/unmapped) qui montre les villes, les villages 
et les hameaux qui n'ont pas de routes résidentielles ou non classifiées à 
proximité. Voici ce que j'ai créé jusqu'à présent, faites-moi savoir s'il y a 
d'autres pays qui pourraient vous intéresser et je peux les publier.

Cameroun:   https://maproulette.org/browse/challenges/13673
Tchad:  https://maproulette.org/browse/challenges/13674
Burundi & Rwanda:   https://maproulette.org/browse/challenges/13675
RD Congo:   https://maproulette.org/browse/challenges/13529
Éthiopie:   
https://maproulette.org/browse/challenges/13526
Ghana:  https://maproulette.org/browse/challenges/13527
Nigéria:
https://maproulette.org/browse/challenges/13528
Afrique du Sud: https://maproulette.org/browse/challenges/12452
Tanzanie:   https://maproulette.org/browse/challenges/12458
Ouganda:https://maproulette.org/browse/challenges/13611
Afrique de l'Ouest: https://maproulette.org/browse/challenges/13524

Il y a une liste complète de tous les défis des lieux non cartographiés que 
j'ai publiés ici: https://maproulette.org/browse/projects/39262

Dans MapRoulette, vous pouvez choisir une tâche aléatoire à corriger ou cliquer 
sur une tâche spécifique. Si vous souhaitez effectuer des tâches autour d'un 
certain emplacement, par exemple dans un endroit que vous connaissez, vous 
pouvez cliquer sur l'une d'elles dans la vue Carte, puis cliquer sur "Tâche 
suivante: à proximité" lorsque vous l'avez terminée.

De plus, nous avons récemment créé un style de peinture JOSM qui vise à 
faciliter le mappage et à trouver rapidement les erreurs. Il a beaucoup de 
contrôles intégrés pour la géométrie et les problèmes d'étiquetage des routes 
et d'autres fonctionnalités. Il s'agit d'une version mise à jour du style de 
peinture que nous avons partagé à State of the Map Africa en 2017. Voici où 
vous pouvez le télécharger et les instructions: 
https://github.com/osmlab/applepaintstyles

J'espère que c'est utile! Faites-moi savoir si vous avez des commentaires.

Merci,
Andrew 


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


> On Jun 9, 2020, at 1:45 PM, Andrew Wiseman via Talk-africa 
>  wrote:
> 
> Hi everyone,
> 
> This is Andrew from the Apple team. I recently posted a lot of new 
> MapRoulette challenges for mapping unmapped towns in various countries 
> throughout the continent. 
> 
> It was created using data from Pascal Neis’s Unmapped Places site 
> (https://resultmaps.neis-one.org/unmapped 
> ) which shows towns, villages and 
> hamlets that don’t have residential or unclassified roads nearby. Here is 
> what I’ve created so far, let me know if there are any other countries you’d 
> be interested in and I can post them.
> 
> DR Congo: https://maproulette.org/browse/challenges/13529 
> 
> Ethiopia: https://maproulette.org/browse/challenges/13526 
> 
> Ghana:https://maproulette.org/browse/challenges/13527 
> 
> Nigeria:  https://maproulette.org/browse/challenges/13528 
> 
> South Africa: https://maproulette.org/browse/challenges/12452 
> 
> Tanzania: https://maproulette.org/browse/challenges/12458 
> 
> Uganda:   https://maproulette.org/browse/challenges/13611 
> 
> West Africa:  https://maproulette.org/browse/challenges/13524 
> 
> 
> There’s a full list of all the unmapped places challenges I've posted here: 
> https://maproulette.org/browse/projects/39262 
> 
> 
> In MapRoulette you can either pick a random task to fix or click on a 
> specific one. If you want to do 

Re: [OSM-talk-fr] Cartopartie : comment relever efficacement les horaires des commerces ?

2020-06-15 Per discussione Gad Jo
Bonsoir,


C'est probablement une mauvaise idée mais je tente le coup.

Avec une première équipe qui ajoute à chaud les enseignes avec Osmand ou 
Vespucci. Puis quelques dizaine de minutes plus loin une seconde équipe qui 
ajoute les horaires avec streetcomplete
Il faut rafraîchir régulièrement la liste des requête pour récupérer les ajouts 
tout frais.
Streetcomplete à un super assistant de saisie pour les horaires.

Seul et en saisie à la volée de quelques secondes pendant les balades en 
poussette, je suis obligé de le faire en deux temps. Le laps de temps entre mes 
deux saisie étant très espacé (plusieurs semaines) je ne suis certains pas que 
streetcomplete puisse fonctionner à chaud.
A tester

Le June 14, 2020 7:02:03 PM UTC, Arnaud Champollion 
 a écrit :
>Bonjour,
>
>Je sollicite vos conseils d'organisation.
>
>Jeudi 18 mai le groupe OsmDigne que j'anime sera en cartopartie au 
>centre-ville de Digne-les-Bains, sur le thème des ERP (établissements 
>recevant du public) : commerces, restaurants, bars, cabinets médicaux, 
>administrations ...
>
>http://www.linux-alpes.org/osmdigne-ca-repart/
>
>Nous prévoyons
>
>-  des équipes chargées des relevés de noms, qui annoteront une carte 
>papier imprimée :
>http://linux-alpes.org/osmdigne/bd_gassendi_4_pages.pdf
>
>- des équipes chargées des relevés des horaires
>
>Pour cette deuxième équipe, avez-vous au l'occasion de mettre en place 
>des procédures en particulier ?
>
>Noter les horaires sur place peut être très long, donc j'imaginais
>avoir 
>recours à la photo. Une équipe avec un photographe et un secrétaire, le
>
>premier photographiant les panneaux d'horaires, le second notant dans
>un 
>tableau préalablement numéroté les noms des commerces, afin que l'on 
>puisse établir les correspondances pour le versement des contributions 
>... à considérer que le photographe s'astreigne à ne prendre qu'une 
>seule photo de chaque panneau horaire.
>
>Je suis preneur de toutes vos expériences et conseils pour réaliser ces
>
>relevés sur le terrain de façon fiable et tenable dans le temps.
>
>Merci
>
>Arnaud
>
>
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


[OSM-talk-fr] NRO avec ref ARCEP sans connection_point

2020-06-15 Per discussione deuzeffe

Bonsoir,

Soit un NRO dans un zouli shelter.

Si je lis bien le wiki, les tags minimum sont :
- telecom=exchange
- telecom:medium=fibre

Pour la ref, j'ai eu la mauvaise idée de mettre un ref:FR:ARCEP et donc 
Osmose me signale que ref:FR:ARCEP sans telecom=connection_point, ce 
n'est pas réglo. Ok.


Q1 : j'ai raté quoi ? Que la ref, c'est pas ARCEP ?

Le NRA sis juste à côté est dit raccordé au PM NA__ Je suppose 
que c'est lui (le PM) qui doit porter la ref ARCEP ?


Q2 subsidiaire : est-il dans le NRO (un node en plus dans le polygone du 
NRO) ou qq part ailleurs pas loin (va falloir arpenter...) ?


Merci pour vos lumières.
--
deuzeffe - qui veux la fibre, mais c'est pas pour tout de suite.




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


Re: [Talk-GB] Rockall

2020-06-15 Per discussione Colin Smale
On 2020-06-15 23:14, barry b wrote:

> Hi Folks, I made the below changes to rockall.

Thanks for engaging! 

> The changes i've made are 
> 1) Changed Rockall from Island to Rock 
> 2) Removed the Administration boundary 
> 
> 1) Rockall is not a island.  You could debate its a rock or islet but it cant 
> sustain human life. 
> References: 
> 1) Wikipedia calls it a islet 
> 2 https://www.kildarestreet.com/wrans/?id=2011-03-24.365.0 [1] Irish 
> Government call it a rock 
> 3)https://www.whatdotheyknow.com/request/97923/response/262438/attach/html/3/0109%2012.pdf.html
>  - Uk Government call it a islet  
> 4) The hint is in its name 

OSM knows about islets - tagged as place=islet (as opposed to
place=island) 

> 2) The reason for removing the administration boundary is i wanted to remove 
> the EEZ around rockall.( The big circle) 
> From a visual point of view this looks off. it implies there is an island or 
> county there. But more importantly it is incorrect

Changing the data "incorrectly" to achieve a desired appearance on a
particular map is rather frowned upon in OSM; we call it "tagging for
the renderer". So any arguments that it "looks off" tend to be declared
null and void... The underlying data needs to be correct, and if it
still "looks off", then it's the visualisation that needs fixing. It
even has its own wiki page:
https://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer 

> Firstly even according the the UK. The EEZ wouldn't be 200nm, it would be 12 
> - 
> https://www.whatdotheyknow.com/request/97923/response/262438/attach/html/3/0109%2012.pdf.html
>  [2]

As I read it, it makes it clear that the territorial waters extend to
12nm, and the EEZ to 200nm from the baseline; for this latter purpose
Rockall is ignored as it "cannot sustain life" etc (although it is
covered by that 200nm EEZ) but Rockall itself and the 12nm territorial
sea around Rockall are claimed as UK territory. 

> Secondly. No country accepts the EEZ and is considered international waters. 
> Several countries claim it Iceland, Denmark , UK and Ireland. 
> 
> In the coming months this rock in the middle of nowhere could potentially 
> turn into a larger issue with the UK exit from the EU as Iceland, Ireland and 
> other EU country all fish here 
> Last summer there was a standoff with the UK Navy and fishing boats. The 
> Irish Navy have also regularly patrol the area in protection of fishery 
> 
> I can give a list of references to show the EEZ recognized, but i don't think 
> that helpful 
> 
> I don't know the exact procedure here. I feel i didn't do it right.

Don't worry too much about "not doing it right", just about everybody
here has "been there done that got the t-shirt". 

It's exactly because this is/could be controversial that we need to
tread carefully. We did this recently with Crimea for example. OSM needs
to remain strictly neutral and tends to follow the international
consensus and/or the actual, verifiable status "on the ground". 

Colin 
  

Links:
--
[1] https://www.kildarestreet.com/wrans/?id=2011-03-24.365.0
[2]
https://www.whatdotheyknow.com/request/97923/response/262438/attach/html/3/0109%2012.pdf.html___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] Rockall

2020-06-15 Per discussione Russ Garrett
I'm still a bit confused about this, because the circle rendered
around Rockall on OpenStreetMap is the 12nm limit of territorial
waters, not the 200nm EEZ. We don't render the EEZ on OpenStreetMap,
but as you point out, it is not in dispute that Rockall does not
extend the UK's EEZ. So I'm a bit confused why we're talking about the
EEZ at all here.

If you want to see a map of EEZ claims, I believe this is the best
one: https://www.marineregions.org/eezmapper.php

Russ


On Mon, 15 Jun 2020 at 22:14, barry b  wrote:
>
> Hi Folks, I made the below changes to rockall.
>
> The changes i've made are
> 1) Changed Rockall from Island to Rock
> 2) Removed the Administration boundary
>
> 1) Rockall is not a island.  You could debate its a rock or islet but it cant 
> sustain human life.
> References:
> 1) Wikipedia calls it a islet
> 2 https://www.kildarestreet.com/wrans/?id=2011-03-24.365.0 Irish Government 
> call it a rock
> 3)https://www.whatdotheyknow.com/request/97923/response/262438/attach/html/3/0109%2012.pdf.html
>  - Uk Government call it a islet
> 4) The hint is in its name
>
>
> 2) The reason for removing the administration boundary is i wanted to remove 
> the EEZ around rockall.( The big circle)
> From a visual point of view this looks off. it implies there is an island or 
> county there. But more importantly it is incorrect
>
> Firstly even according the the UK. The EEZ wouldn't be 200nm, it would be 12 
> - 
> https://www.whatdotheyknow.com/request/97923/response/262438/attach/html/3/0109%2012.pdf.html
>
> Secondly. No country accepts the EEZ and is considered international waters.
> Several countries claim it Iceland, Denmark , UK and Ireland.
>
> In the coming months this rock in the middle of nowhere could potentially 
> turn into a larger issue with the UK exit from the EU as Iceland, Ireland and 
> other EU country all fish here
> Last summer there was a standoff with the UK Navy and fishing boats. The 
> Irish Navy have also regularly patrol the area in protection of fishery
>
> I can give a list of references to show the EEZ recognized, but i don't think 
> that helpful
>
> I don't know the exact procedure here. I feel i didn't do it right.
>
> Happy to discuss further.
> Cheers
> Barry
>
> 
> From: Colin Smale 
> Sent: Monday 15 June 2020 21:39
> To: talk-gb@openstreetmap.org 
> Subject: Re: [Talk-GB] Rockall
>
>
> I just pointed the user concerned to the signup page to this mailing list, so 
> he should be here soon! Further to my earlier message I will not make any 
> changes to Rockall until we have had the discussion.
>
> Colin
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb



-- 
Russ Garrett
r...@garrett.co.uk

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


Re: [Talk-br] Importações de transformadores.

2020-06-15 Per discussione Helio Cesar Tomio
Sim, é permitido importações de dados desde que comunicado previamente para
a comunidade local ou do Brasil.
Esse comunicado deve esclarecer a origem dos dados (nao podem ter
copyright), que tipo de dado, como vai ser feito (controle de erros, dados
duplicados,...).

Importacoes sao revertidas senao houver esses esclarecimentos, afim de
evitar danos às informações já existentes ou processos judiciais por parte
de empresas.


Em seg, 15 de jun de 2020 10:48, Mapas Osm  escreveu:

> Olá,
> Tenho informações georreferenciadas de transformadores e chaves de parte
> dos estados de São Paulo e Mato Grosso do Sul, os dados foram fornecidos
> pela empresa de energia local. Cada ponto possui seu código específico
> indispensável para sua consulta.
> Existe a possibilidade de importar esses dados para o OSM base? Caso
> positivo, como proceder à importação de forma que esses códigos podem ser
> consultados?
>
> Desde já agradeço!
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br


Re: [Talk-GB] Rockall

2020-06-15 Per discussione barry b
Hi Folks, I made the below changes to rockall.

The changes i've made are
1) Changed Rockall from Island to Rock
2) Removed the Administration boundary

1) Rockall is not a island.  You could debate its a rock or islet but it cant 
sustain human life.
References:
1) Wikipedia calls it a islet
2 https://www.kildarestreet.com/wrans/?id=2011-03-24.365.0 Irish Government 
call it a rock
3)https://www.whatdotheyknow.com/request/97923/response/262438/attach/html/3/0109%2012.pdf.html
 - Uk Government call it a islet
4) The hint is in its name 


2) The reason for removing the administration boundary is i wanted to remove 
the EEZ around rockall.( The big circle)
From a visual point of view this looks off. it implies there is an island or 
county there. But more importantly it is incorrect

Firstly even according the the UK. The EEZ wouldn't be 200nm, it would be 12 - 
https://www.whatdotheyknow.com/request/97923/response/262438/attach/html/3/0109%2012.pdf.html

Secondly. No country accepts the EEZ and is considered international waters.
Several countries claim it Iceland, Denmark , UK and Ireland.

In the coming months this rock in the middle of nowhere could potentially turn 
into a larger issue with the UK exit from the EU as Iceland, Ireland and other 
EU country all fish here
Last summer there was a standoff with the UK Navy and fishing boats. The Irish 
Navy have also regularly patrol the area in protection of fishery

I can give a list of references to show the EEZ recognized, but i don't think 
that helpful

I don't know the exact procedure here. I feel i didn't do it right.

Happy to discuss further.
Cheers
Barry


From: Colin Smale 
Sent: Monday 15 June 2020 21:39
To: talk-gb@openstreetmap.org 
Subject: Re: [Talk-GB] Rockall


I just pointed the user concerned to the signup page to this mailing list, so 
he should be here soon! Further to my earlier message I will not make any 
changes to Rockall until we have had the discussion.

Colin

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


Re: [Talk-GB] Rockall

2020-06-15 Per discussione Colin Smale
I just pointed the user concerned to the signup page to this mailing
list, so he should be here soon! Further to my earlier message I will
not make any changes to Rockall until we have had the discussion. 

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


Re: [Talk-GB] Rockall

2020-06-15 Per discussione Colin Smale
On 2020-06-15 15:36, Mark Goodge wrote:

> I'd just revert it.

I'll give them until tomorrow to see if there is any further engagement.
Otherwise I will fix it up as place=islet and resurrecting the coastline
and admin boundaries. 

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


Re: [OSM-talk-fr] Comment orthographier un nombre ordinal

2020-06-15 Per discussione Philippe Verdy
Ceci dit les traits d'union sur les adjectifs numéraux sont facultatifs :
ils ne s'imposent que entre les dizaines et unités, entre unités et
centaines, et entre unités et mille/million(s)/milliard(s) ou pour former
un ordinal (dans ce cas on doit tout attacher). C'est la réforme de 1990
qui autorise et recommande les traits d'union entre tous les composants.

Les traits d'union sont en principe obligatoires partout dans
"soixante-dix", "quatre-vingt",  "quatre-vingt-dix", et pour
suffixer l'unité "-et-un" dans 21, 31, 41, 51, 61 ou l'unité "-et-onze"
dans "soixante-et-onze" pour 71, et de "quatre-vingt-onze" à
"quatre-vingt-dix-neuf": cela s'applique au multiplicateur de "vingt" et
les "unités" vigésimales de 11 à 19 (que n'emploient pas Belges et Suisses
qui préfèrent le système décimal strict avec "septante", "octante", et
"nonante" ; ce résidu vigésimal est franco-français, au Canada les deux
sont admis même si le système vigésimal résiste encore ; en Afrique il n'y
a pas de préférence ; en français cadien du sud des USA, "septante",
"octante" et "nonante" sont plus courants, car calqués sur l'anglais qui
n'a gardé trace du système vigésimal que de 11 à 19 ; le système décimal
strict des Belges, Luxembourgeois et Suisses est peut-être influencé par
l'allemand, le néerlandais, même si ces langues nomment les unités avant
les dizaines, accolées en allemand avec un "und" sans aucun trait d'union
sauf éventuel tiret de césure).

Concernant les pluriels, le mot "mille" (qu'on écrit "mil" pour les années,
qui sont des ordinaux même s'il n'y a aucun suffixe) reste toujours
invariable ("deux-mille" ou "deux-mil", pas "deux-milles" ni "deux-mils").
Le mot "cent" a un pluriel irrégulier, il ne prend pas de "s" s'il est
suivi d'un groupe dizaine-unité ou d'un unité (d'où "deux-cents" mais
"deux-cent un" ou "deux-cent-un") ou d'un suffixe ordinal ("deux-centième"
et non "deux-centsième"). Le mot "Mil" peux prendre la majuscule au sens de
la période historique de "l'an Mil" (ou "l'An Mil") quand cela ne désigne
pas l'année au sens strict mais la période de trouble politico-religieux au
Moyen-Âge s'étalant autour de l'an 1000 (plus ou moins 100 ans) : on
pourrait aussi écrire le "l'An Deux-Mille" concernant la période artistique
(ou le "bogue" informatique) qui anticipait le troisième millénaire comme
"le futur" (ce qu'il n'est plus évidemment) selon l'usage des textes écrits
avant.

En principe pour les années aussi on utilise les multiples de "cent(s)" de
11 à 19 au lieu du mot "mil" (donc "l'an douze-cents"  plutôt que "l'an mil
deux-cent" ou "l'an mil-deux-cents"). Noter que là aussi il n'y a pas de
"s" au mot "cent" précédé d'un multiple s'il est suivi d'une dizaine ou
unité: "l'an douze-cent un" ou "l'an douze-cent-un", ce qui évite une
liaison fautive en /-z-/ à cause du "s", mais la liaison en /-t-/ s'entend
parfois).




Le lun. 15 juin 2020 à 19:12, Topographe Fou  a
écrit :

> Je le mettrai bien en exception française des abréviations sur le wiki. On
> est pas au même niveau que rte pour route ou st pour saint ou street. Je le
> mets au même niveau que 1024 au lieu de mille-vingt-quatre.
>
> LeTopographeFou
> *De:* yves.prat...@gmail.com
> *Envoyé:* 15 juin 2020 11:11 AM
> *À:* talk-fr@openstreetmap.org
> *Répondre à:* talk-fr@openstreetmap.org
> *Objet:* Re: [OSM-talk-fr] Comment orthographier un nombre ordinal
>
> Le terrain prime... mais cela a aussi des limites ;)
>
> L’homogénéité dans les données ça ne fait pas de mal surtout quand sur le
> terrain on a pris quelques libertés avec des règles communes.
>
> +1
>
> Donc un "28ième" sur une plaque, je le mettrai en "28e" en name
>
> +1
>
> La page FR:Toponymes, odonymes
>  du wiki cite
> la *charte de toponymie de l'IGN*.
> Elle ne détaille pas encore les ièmes…
>
> Et elle n'est pas (encore) citée dans la page FR:Key:name
>  ;)
>
> __
> 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-us] Rail tagging in US (and North America): operator=* and reporting_marks=*

2020-06-15 Per discussione Chuck Sanders
Nathan,

I've been working to "broaden my horizons" as an east coast guy, and I can
see why it was probably confusing why I didn't understand your references
to line segment numbering.  I've been rooting around in BNSF and UP
timetables, and they really are used prominently over there.  Turns out
this is just a regional thing where I wasn't exposed to them - they're
here, generally, but they aren't used as consistently where I might've seen
them myself, and the line segment numbering itself doesn't show up in ETT's
or some of the track charts.  I must've looked obtuse - oops!  But I'm on
the right path now.

For the major east coast Class I's, NS still isn't using line segment
numbers in the latest ETT's I have for the region I work around.  They do
refer to line segments by name in the ETT, but to confuse matters, they
often group segments with multiple line segment numbers under a single line
segment name for reference in the ETT.  You have to root all the way into
the track charts to get to the number.  So for instance, they lump the line
segments for the Lamberts Point Branch and the Norfolk Terminal mainline
all together under "Lamberts Point to Canal Drive" in the 2008 ETT, but in
the 2009 track charts, that includes line segments 5010, 5022, and maybe
part of 5020.  They don't actually make it clear anywhere in even the track
charts where one LS ends and the next begins, they only list which line
segments are present on that chart page.  And they aren't using the actual
line segment numbers on the FRA crossing inventory forms, either, they're
just filling box 13 with the alpha character part of the mile marker
designation (e.g. "LP" for crossings on the Lamberts Point branch, with LP
mile markers).

I haven't done anything with CSX for ages, and don't have any of their
recent documentation.  I did grab a fairly recent ETT for my area online,
and they unfortunately don't reference the line segment numbers at all.  I
only see track charts online that are as old as my stuff, and they aren't
referencing them either, but those are ancient.  So far the best accessible
source of line segment numbers I've found for them are the crossing
inventory sheets - CSX is at least filling out Block 13 with the line
segment numbers like they're supposed to.  That may be our best source of
numbers for most mappers to use.  CSX's older track charts do sort out
sections according to an EIS# that appears analogous to the line segment
numbers used by others, but unfortunately when compared with any other
current documentation, they appear to have changed numbering systems, so
they may not be usable.  A much newer track chart from them would be a big
help.  (And unfortunately, finding out anything about their old EIS
numbering system from outside, after the fact, is almost impossible since
the acronym overlaps with modern environmental impact studies, which are
obviously the more common use of the term now.)

A lot of my local short lines aren't even filling out block 13 on the
crossing forms, so they'll be the biggest challenge.  The inconsistency is
a little frustrating.

So far the only one in a couple hours worth of looking around who are
actually consistent in all locations that I've looked at is BNSF - one
example is the Pikes Peak Sub (477), which they're consistently numbering
in the ETT and in block 13 of the inventory forms.  UP's numbering the LS
in the ETT but leaving block 13 blank.  I wish my guys out east were being
as consistent as BNSF.

Overall, though, I definitely agree with your assessment that these line
segment numbers are what belongs in the ref tag for us wherever we can find
it - thanks for helping me understand it!

Chuck
Virginia

On Sat, Jun 13, 2020 at 3:10 PM Natfoot  wrote:

> Chuck,
> I think you make some good points in your email.  I would discourage the
> hang ups on the diffring railroad terminology as it is different by
> railroad and location.  Coming to a decision on how we are going to tag is
> more important. I agree that line segments are useful and interested to
> hear how you would suggest to tag them.
>
> Here some examples of the use of the ref=* tag
> https://www.openrailwaymap.org/?lang=null=39.77267707885666=-104.98619109392166=18=standard
>
>
>
> https://www.openrailwaymap.org/?lang=null=39.78832735578315=-104.99941036105156=19=standard
>
>
> https://www.openrailwaymap.org/?lang=null=41.860825816587464=-87.63588219881058=18=standard
>
>
> Regards,
> Nathan P
> email: natf...@gmail.com
>
>
> On Sat, Jun 13, 2020 at 9:28 AM Chuck Sanders  wrote:
>
>> Nathan, thanks - I've been thinking over your email and use case since
>> coffee this morning, and looking for the right questions to pick your brain
>> too, so that we can get the documentation right in the NA tagging wiki, and
>> all of us on the same page.  I also started working up a a NA-specific and
>> simplified JOSM tagging preset, so that's part of my impetus to really
>> start getting into the weeds on this - part of 

Re: [Talk-it] Compresenza addr street e place

2020-06-15 Per discussione fox91fox
Forse può essere utile questa guida delle Poste per la composizione 
degli indirizzi: 
https://www.poste.it/standard_composizione_indirizzi.pdf (vedi pag. 8)


Andrea

On 6/15/20 19:39, Marcello wrote:

Il 15/06/20 16:17, Andrea Musuruane ha scritto:

Ciao,
   è solo una nomenclatura. Si usa addr:city per indicare il comune, 
indipendentemente dal fatto che la sede amministrativa sia taggata 
con place=village, town o city. Proprio per questo motivo addr:town e 
addr:village non sono tag documentati: 
https://wiki.openstreetmap.org/wiki/Key:addr


Ciao,

non trovo nessun riferimento al fatto che addr:city si usa per 
indicare il comune, mi sembra che si usi per indicare la località come 
indicata sull'indirizzo postale. Per esempio se l'indirizzo fosse: 
Sig. Mario Rossi, via Piave 34151 Opicina (TS) secondo me in addr:city 
è corretto mettere Opicina. Normalmente per le frazioni più grandi, 
soprattutto se è anche presente l'ufficio postale, nell'indirizzo è 
presente la località e non il comune, poi la sigla della provincia.




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


Re: [Talk-it] Compresenza addr street e place

2020-06-15 Per discussione Marcello

Il 15/06/20 16:17, Andrea Musuruane ha scritto:

Ciao,
   è solo una nomenclatura. Si usa addr:city per indicare il comune, 
indipendentemente dal fatto che la sede amministrativa sia taggata con 
place=village, town o city. Proprio per questo motivo addr:town e 
addr:village non sono tag documentati: 
https://wiki.openstreetmap.org/wiki/Key:addr


Ciao,

non trovo nessun riferimento al fatto che addr:city si usa per indicare 
il comune, mi sembra che si usi per indicare la località come indicata 
sull'indirizzo postale. Per esempio se l'indirizzo fosse: Sig. Mario 
Rossi, via Piave 34151 Opicina (TS) secondo me in addr:city è corretto 
mettere Opicina. Normalmente per le frazioni più grandi, soprattutto se 
è anche presente l'ufficio postale, nell'indirizzo è presente la 
località e non il comune, poi la sigla della provincia.


--
Ciao
Marcello


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


Re: [Talk-it] Compresenza addr street e place

2020-06-15 Per discussione Federico Cortese
On Mon, Jun 15, 2020 at 7:18 PM Cascafico Giovanni  wrote:
>
> Io pensavo che addr:place risolvesse semplicemente indirizzi senza via e 
> senza preoccuparsi del luogo in cui sono compresi. Devo quindi ogni volta 
> valutare la classe del luogo abitato? E se qualcuno lo cambia, p.es. da 
> hamlet a village, che ne è di tutti gli addr:hamlet?
>
Sì addr:place serve solo per indirizzi senza via, quindi in generale è
giusto toglierlo dove la via c'è già in addr:street.
Se invece addr:place è stato usato per metterci il nome del paese,
frazione o simili, puoi sostituirlo con addr:hamlet, indipendentemente
da come è taggato il place.
Infatti come già ha spiegato Andrea non esistono altri tag addr:town
addr:village ecc.

Ciao,
Federico

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


Re: [Talk-it] Compresenza addr street e place

2020-06-15 Per discussione Cascafico Giovanni
Io pensavo che addr:place risolvesse semplicemente indirizzi senza via e
senza preoccuparsi del luogo in cui sono compresi. Devo quindi ogni volta
valutare la classe del luogo abitato? E se qualcuno lo cambia, p.es. da
hamlet a village, che ne è di tutti gli addr:hamlet?

Il lun 15 giu 2020, 17:16 Alessandro Sarretta 
ha scritto:

> Nel caso specifico concordo con Andrea e Martin sulla sostituzione di
> addr:place con add:hamlet.
>
> Non è indispensabile per avere un indirizzo univoco, ma è
> un'informazione aggiuntiva da preservare mi pare.
>
> Ale
>
>
> On 15/06/20 14:38, Martin Koppenhoefer wrote:
> >
> > sent from a phone
> >
> >> On 15. Jun 2020, at 14:01, Andrea Musuruane  wrote:
> >>
> >> Per questi casi, credo si possa usare addr:hamlet (o addr:suburb)
> >
> >
> > +1, addr:hamlet è il tag per questi casi, addr:place va omesso quando
> addr:street è presente. (e forse addr:suburb ma viene usato poco, ci sono
> più addr:neighbourhood per esempio)
> >
> > 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: [OSM-talk-fr] Comment orthographier un nombre ordinal

2020-06-15 Per discussione Topographe Fou
  Je le mettrai bien en exception française des abréviations sur le wiki. On est pas au même niveau que rte pour route ou st pour saint ou street. Je le mets au même niveau que 1024 au lieu de mille-vingt-quatre. LeTopographeFou   De: yves.prat...@gmail.comEnvoyé: 15 juin 2020 11:11 AMÀ: talk-fr@openstreetmap.orgRépondre à: talk-fr@openstreetmap.orgObjet: Re: [OSM-talk-fr] Comment orthographier un nombre ordinal  Le terrain prime... mais cela a aussi des limites ;)L’homogénéité dans les données ça ne fait pas de mal surtout quand sur le terrain on a pris quelques libertés avec des règles communes.+1Donc un "28ième" sur une plaque, je le mettrai en "28e" en name+1La page FR:Toponymes, odonymes du wiki cite la charte de toponymie de l'IGN.Elle ne détaille pas encore les ièmes…Et elle n'est pas (encore) citée dans la page FR:Key:name ;)__Yves___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Plusieurs SIRET pour un même établissement ?

2020-06-15 Per discussione Philippe Verdy
Ce n'est pas impossible d'avoir deux assos différentes utilisant la même
salle communale. Elles peuvent avoir des programmes avec une présence
multicommunaux et des calendriers différents. Ce genre d'asso en général ne
vit pas avec une seule salle mais fait des projections à divers endroits
dans une région donnée.
Elle choisit une thématique saisonnière pour ses films et fait ensuite ses
"tournées" dans les différentes salles sur un rayon assez large. Selon les
jours la salle sera fermée, ou ouverte par une asso ou une autre, ou louée
pour des réunions publiques ou privées qui n'ont rien à voir avec une
projection ciné, ou pour d'autres types de spectacles (raison pour laquelle
ce genre de salle devrait souvent être taguée comme salle d'activité (salle
"plate", sièges et scène mobiles) ou comme théatre (scène fixe, sièges en
gradins). L'anglais d'ailleurs appelle toutes les *salles* de cinés des
"theater(s)" (ortho US) ou "theatre(s)" (ortho GB) et il est très courant
au Royaume-Uni et aux USA que ces scènes ne soient pas dédiées au seul
genre cinéma et serve de salle de conférence ou de fêtes privées.



Le lun. 15 juin 2020 à 16:54, Yves P.  a écrit :

> @Cyrille37 OSM
>
> Le cinéma en soit n'a pas de SIRET, c'est un bâtiment, seules les
>> organisations en ont un.
>> Il y a donc 3 oragnisations domiciliées à cette adresse.
>>
>
> @Philippe Verdy
>
> Vrai, mais alors elles sont locataires des lieux, probablement une salle
> de spectacle communale
>
>
> Dans le cas que j'ai indiqué (et un autre que j'ai trouvé entre-temps), il
> y a le SIRET qui correspond à la salle appartenant à la commune.
> Et celui de l'association faisant fonctionner la salle (location des
> films, projections…)
>
> Dans le 1er exemple, ce qui est bizarre c'est d'avoir 2 associations pour
> la même salle dans un tout petit village.
>
> La date de création de LE FOYER BAUMOIS STELLA CINEMA n'est pas mentionnée.
> Et CINE BAUME a été créé en 15 avril 2013.
>
> Est-ce que tout simplement, LE FOYER BAUMOIS n'aurait pas changé de nom
> pour devenir CINE BAUME ?
> Il y a peut-être un champ indiquant sa "fermeture'" qui n'a pas été mis à
> jour ?
>
>
> __
> 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-it] Compresenza addr street e place

2020-06-15 Per discussione Giovanni Fasano via Talk-it

Il 15/06/20 16:17, Andrea Musuruane ha scritto:

Ciao,
    è solo una nomenclatura. Si usa addr:city per indicare il comune, 
indipendentemente dal fatto che la sede amministrativa sia taggata con 
place=village, town o city. Proprio per questo motivo addr:town e 
addr:village non sono tag documentati: 
https://wiki.openstreetmap.org/wiki/Key:addr


Analogamente si può usare addr:hamlet o addr:suburb nel caso in cui ci 
siano odonimi identici in luoghi differenti dello stesso comune. E' un 
caso che non dovrebbe succedere in Italia ma accade ancora (l'odonimo 
deve essere unico all'interno dello stesso comune).




Nel comune di Venezia che tu citi nel messaggio successivo ci sono 
numerosi casi di vie con lo stesso nome a Mestre e al Lido frutto del 
fatto che nel passato erano due comuni separati.


--
Giovanni Fasano

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


Re: [OSM-talk-fr] Les glaciers noirs ou partiellement noirs

2020-06-15 Per discussione Philippe Verdy
Le dim. 14 juin 2020 à 09:29, Arnaud Champollion <
arnaud.champoll...@linux-alpes.org> a écrit :

> Bonjour,
>
> Petite question rafraîchissante ️
>
> Pour les glaciers de montagne :
>
> https://wiki.openstreetmap.org/wiki/FR:Tag:natural%3Dglacier
>
> Apparemment on cartographie le contour total de l'emprise du glacier, y
> compris, le cas échéant, sa partie recouverte par une moraine se surface
> (type "glacier noir")
>
> Quand le glacier a une partie visible et une partie recouverte, on le
> coupe en deux et on ajoute surface=scree sur la partie recouverte ?
>

La délimitation  entre la partie "couverte" et le reste est très
variable d'année en année ou de mois en mois (on n'a pas d'imagerie très
fiable dessus, d'autant que les clichés peuvent être avant ou après un
épisode de neige où la moraine de surface n'est plus visible).
Ce qui est en revanche intéressant c'est le recul des langues de glaciers
et leur réduction de largeur dans les vallées glacières. Là ce n'est plus
une simple moraine de surface (draguée par le glacier en mouvement ou les
chutes de roches sur le glacier dans les zones où les sommets et pentes
s'érodent plus vite (épisodes plus nombreux de gel et dégel successifs,
écoulement des eaux). Ces roches ou poussières diverses au dessus du
glacier ne sont pas vraiment des moraines qui normalement sont plutôt
celles arrachées et roulées sur le lit du glacier (mais qui peuvent aussi
déborder latéralement et pour certaines se retrouver au dessus du lit, mais
en principe plus près de l'aval de la langue du glacier.
Le phénomène de glacier noir (qui accélère sa fonte par effet sur l'albedo)
est aussi lié aux pollutions de l'air par l'homme (émissions de particules)
qui se mèlent aux précipitations : même la neige qui tombe n'est plus
immaculée, un rayon de soleil et ça fait fondre en surface, l'eau
s'infiltre dans les crevasses, et va accélérer dessous le glissement du
glacier, et par effet en boule augmenter son crevassement (les crevasses ne
prennent plus le temps de regeler). Tous les glaciers s'écoulent plus vite
aujourd'hui (maintenant plusieurs mètres par jour, des dizaines de mètres
tous les jours: ce qui justifie de ne pas sectionner les glaciers: c'est un
seul flux où tout bouge)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [Talk-it] Compresenza addr street e place

2020-06-15 Per discussione Federico Cortese
On Mon, Jun 15, 2020 at 5:16 PM Alessandro Sarretta
 wrote:
>
> Nel caso specifico concordo con Andrea e Martin sulla sostituzione di
> addr:place con add:hamlet.
>

Anche io concordo con questa soluzione.

Ciao,
Federico

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


Re: [Talk-it] Compresenza addr street e place

2020-06-15 Per discussione Alessandro Sarretta
Nel caso specifico concordo con Andrea e Martin sulla sostituzione di 
addr:place con add:hamlet.


Non è indispensabile per avere un indirizzo univoco, ma è 
un'informazione aggiuntiva da preservare mi pare.


Ale


On 15/06/20 14:38, Martin Koppenhoefer wrote:


sent from a phone


On 15. Jun 2020, at 14:01, Andrea Musuruane  wrote:

Per questi casi, credo si possa usare addr:hamlet (o addr:suburb)



+1, addr:hamlet è il tag per questi casi, addr:place va omesso quando 
addr:street è presente. (e forse addr:suburb ma viene usato poco, ci sono più 
addr:neighbourhood per esempio)

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


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


Re: [OSM-talk-fr] Plusieurs SIRET pour un même établissement ?

2020-06-15 Per discussione Philippe Verdy
Il se peut aussi qu'il restent plusieurs SIRET correspondant à des
organisations successives ayant utilisé ces lieux.
Les établissements peuvent pourtant toujours exister et n'ont pas mis à
jour leur adresse si le SIREN est encore valable (on n'a pas de trace
semble-t-il de la création des SIRET au sein d'un SIREN, c'est assez libre
à la demande de toute organisation qui souhaite créer des établissements ad
hoc pour des raisons comptables/fiscales/contractuelles et faciliter la
gestion ou la justification de certains droits ou exemptions (la condition
étant souvent la séparation comptable, et correctement affecter les
ressources, dépenses et recettes et les justifier).
Occuper/utiliser un lieu chez un tiers souvent nécessite des moyens :
personnel affecté, assurances demandées, droits d'accès,
consommables/eau/énergie, frais de gestion demandés par l'organisation
gérant les lieux...). Si c'est une utilisation régulière (planifiée), créer
un établissement ad hoc est un bon outil de gestion.
L'occupant principal du bâtiment peut ne jamais s'occuper de cinéma, c'est
juste un gestionnaire, son SIRET (ou APE affecté) à cet endroit peut ne pas
correspondre à un cinéma, mais à un autre service plus générique ou
spécialement dédié à la seule gestion immobilière.

Le dim. 14 juin 2020 à 11:52, Cyrille37 OSM  a
écrit :

> Le cinéma en soit n'a pas de SIRET, c'est un bâtiment, seules les
> organisations en ont un.
>
> Il y a donc 3 oragnisations domiciliées à cette adresse.
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Plusieurs SIRET pour un même établissement ?

2020-06-15 Per discussione Yves P.
@Cyrille37 OSM
> 
> Le cinéma en soit n'a pas de SIRET, c'est un bâtiment, seules les 
> organisations en ont un.
> Il y a donc 3 oragnisations domiciliées à cette adresse.
> 

@Philippe Verdy
> Vrai, mais alors elles sont locataires des lieux, probablement une salle de 
> spectacle communale

Dans le cas que j'ai indiqué (et un autre que j'ai trouvé entre-temps), il y a 
le SIRET qui correspond à la salle appartenant à la commune.
Et celui de l'association faisant fonctionner la salle (location des films, 
projections…)

Dans le 1er exemple, ce qui est bizarre c'est d'avoir 2 associations pour la 
même salle dans un tout petit village.

La date de création de LE FOYER BAUMOIS STELLA CINEMA n'est pas mentionnée.
Et CINE BAUME a été créé en 15 avril 2013.

Est-ce que tout simplement, LE FOYER BAUMOIS n'aurait pas changé de nom pour 
devenir CINE BAUME ?
Il y a peut-être un champ indiquant sa "fermeture'" qui n'a pas été mis à jour ?


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


Re: [OSM-talk-fr] Plusieurs SIRET pour un même établissement ?

2020-06-15 Per discussione Philippe Verdy
Vrai, mais alors elles sont locataires des lieux, probablement une salle de
spectacle communale, ayant aussi le SIRET dérivé du SIREN de la commune (ou
de l'organisation propriétaire ou locataire principale ; les autres
domiciliations ne sont pas forcément des sous-locataires, mais des
établissements créés adhoc par d'autres organisations pour s'y domicilier
avec l'accord du résident principal qui gère les lieux).

Nombre de salles communales ont diverses assos "domiciliées" (mais pas
"résidentes" ou locataires en tant que tel, même si elles payent un droit
d'usage ou une cotisation, ou payent indirectement avec une subvention
locale de la commune par exemple à un comité des fêtes ou une asso de
quartier). La commune elle-même peut y domicilier un de ses autres
établissements (comme un centre d'activité, une médiathèque, ayant leurs
animateurs qui s'occupent alors de la programmation, la location des films
et la promotion du programme par tout moyen de publicité).
Les communes à l'occasion peuvent utiliser ces salles pour autre chose
(bureau d'élections, cérémonies officielles, réunions publiques
d'information, présentation de projets, concertation...) ou proposer une
location aux administrés pour autre chose que des projections cinéma
(réservation pour un mariage, réunions syndicales, ...), ou même à des
organisations commerciales (AG, vente de produits locaux, ateliers de
formation). Le lieu peut être tagué de façon générique comme un "theatre"
(avec le nom donné par son occupant principal, indépendamment des noms
donnés par les autres organisations domiciliées pour leurs propres
programmes)

Le dim. 14 juin 2020 à 11:52, Cyrille37 OSM  a
écrit :

> Hello
>
> Le cinéma en soit n'a pas de SIRET, c'est un bâtiment, seules les
> organisations en ont un.
> Il y a donc 3 oragnisations domiciliées à cette adresse.
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [Talk-us] Rail tagging in US (and North America): operator=* and reporting_marks=*

2020-06-15 Per discussione Chuck Sanders
My thoughts exactly.

I think part of the problem is that some map editors spend so much time as
a map editor, they forget to both think as a map user, and to think broadly
that there are a lot of types of map user that are interested in
fundamentally different but compatible things from their map.  In terms of
the maker/user confusion, in that respect I mean they get so used to
looking at a map from a point of view of verifying its accuracy, they
forget a map user looks at a map to find out the information they *don't*
know standing there in the street.

I always feel like the hardcore deletion argument seems to come from people
who can't understand why you'd want to know where a railway went in the
first place, and probably wouldn't know what an abandoned railway on the
ground looked like even if they were standing in the middle of one.  The
"making the map better" argument doesn't really work for me, because even
an abandoned rail route (with signs still visible on the ground) that's
properly tagged doesn't render in the default OpenStreetMap view anyway;
only in the specialist renderings for users that are actually interested in
it, like OpenRailwayMap - so you can't say you're cluttering the map.  I've
seen a few people argue it's to keep the map uncluttered for editors, but
that's a problem with a technical solution, just like "don't tag for the
editor."  I work in JOSM, and if I find that abandoned railways clutter my
work environment, it's trivial to just set a filter so they don't show
anymore.  If someone's editor of choice doesn't have a filter like that,
that's the fault of the editor, not of the person who put in an element
representing something that's still detectable on the map but which another
editor doesn't want to see.

I can see the argument where the route is genuinely razed (the open pit
mine argument), because in that respect all traces on the ground and in
aerial views have been completely eliminated, unlike an abandoned line
where you can still follow its route on the ground in cuttings,
embankments, hedges, building shapes, etc.  It makes total sense in most
mappable features that aren't railways, like someone's example of a castle
where only a corner is standing and detectable.  There, mapping the rest of
the "imaginary" part of a building does clutter the map and make it worse,
and it doesn't give the map user any information they couldn't better
obtain by going to a document that's actually meant to be dedicated to that
structure.  However, even here I feel like shorter razed sections of
railway make a sensible exception, because the many visible portions make
better sense when the railway on a specialist map like OpenRailwayMap is
shown in its entirety, including the brief razed sections, and the "making
the map better by deletion" argument falls flat to me again because neither
the razed nor abandoned portions will render on a map for a user who isn't
specifically interested in it.

Chuck

On Mon, Jun 15, 2020 at 9:29 AM Russell Nelson  wrote:

> On 6/14/20 6:34 PM, Chuck Sanders wrote:
> > after watching the re-discussion of the abandoned railroad line "where
> > do we draw the line" topic, from a somewhat-outside perspective,
>
> I've given up arguing. I treat deletion of abandoned railways as
> vandalism and just fix it. Not seeing something is no reason to delete
> it -- because someone else might be able to see it. This is my classic
> example:
>
> https://www.openstreetmap.org/#map=20/42.721785518232124/-73.69278208233906
>
> How do you explain why this building is a triangle without mapping the
> abandoned railroad which ran along its hypotenuse? Once you do that, it
> becomes obvious.
>
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us


Re: [Talk-it] Compresenza addr street e place

2020-06-15 Per discussione Andrea Musuruane
Non conosco Opicina, ma il tag place non identifica la classificazione
amministrativa, identifica l'importanza del luogo. E' un discorso che
abbiamo fatto tante volte. Così come Mestre è una frazione di Venezia ma
non è taggata place=hamlet!

Ciao,

Andrea


On Mon, Jun 15, 2020 at 4:08 PM fox91fox  wrote:

> Non vorrei andare OT ma a questo punto sembra sbagliato il fatto che
> Opicina sia taggato come place=town invece che place=village.
> Dopotutto è solamente una frazione di Trieste.
>
> Andrea
>
> On 6/15/20 15:19, dam...@damjan.net wrote:
> > Scusate, ma se vi sto dicendo che è un place=town, mi dite di metterlo
> in addr:hamlet? Non capisco con che logica, al massimo potrei metterlo in
> addr:town
> >
> > Damjan
> >
> > -- Original Header ---
> >
> >  From  : "Martin Koppenhoefer" dieterdre...@gmail.com
> > To  : "openstreetmap list - italiano" talk-it@openstreetmap.org
> > Cc  :
> > Date  : Mon, 15 Jun 2020 14:38:35 +0200
> > Subject : Re: [Talk-it] Compresenza addr street e place
> >
> >>
> >> sent from a phone
> >>
> >>> On 15. Jun 2020, at 14:01, Andrea Musuruane 
> wrote:
> >>>
> >>> Per questi casi, credo si possa usare addr:hamlet (o addr:suburb)
> >>
> >>
> >> +1, addr:hamlet è il tag per questi casi, addr:place va omesso quando
> addr:street è presente. (e forse addr:suburb ma viene usato poco, ci sono
> più addr:neighbourhood per esempio)
> >>
> >> 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] Compresenza addr street e place

2020-06-15 Per discussione Andrea Musuruane
Ciao,
   è solo una nomenclatura. Si usa addr:city per indicare il comune,
indipendentemente dal fatto che la sede amministrativa sia taggata con
place=village, town o city. Proprio per questo motivo addr:town e
addr:village non sono tag documentati:
https://wiki.openstreetmap.org/wiki/Key:addr

Analogamente si può usare addr:hamlet o addr:suburb nel caso in cui ci
siano odonimi identici in luoghi differenti dello stesso comune. E' un caso
che non dovrebbe succedere in Italia ma accade ancora (l'odonimo deve
essere unico all'interno dello stesso comune).

Ciao,

Andrea


On Mon, Jun 15, 2020 at 3:19 PM dam...@damjan.net  wrote:

> Scusate, ma se vi sto dicendo che è un place=town, mi dite di metterlo in
> addr:hamlet? Non capisco con che logica, al massimo potrei metterlo in
> addr:town
>
> Damjan
>
> -- Original Header ---
>
> From  : "Martin Koppenhoefer" dieterdre...@gmail.com
> To  : "openstreetmap list - italiano" talk-it@openstreetmap.org
> Cc  :
> Date  : Mon, 15 Jun 2020 14:38:35 +0200
> Subject : Re: [Talk-it] Compresenza addr street e place
>
> >
> >
> > sent from a phone
> >
> > > On 15. Jun 2020, at 14:01, Andrea Musuruane 
> wrote:
> > >
> > > Per questi casi, credo si possa usare addr:hamlet (o addr:suburb)
> >
> >
> >
> > +1, addr:hamlet è il tag per questi casi, addr:place va omesso quando
> addr:street è presente. (e forse addr:suburb ma viene usato poco, ci sono
> più addr:neighbourhood per esempio)
> >
> > Ciao Martin
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [OSM-talk-fr] Cartopartie : comment relever efficacement les horaires des commerces ?

2020-06-15 Per discussione Arnaud Champollion

Le 15/06/2020 à 14:16, Jacques Lavignotte a écrit :

Ca marche même sans OSMAnd dès que les EXIF portent les données GPS.


Oui mais l'avantage avec Osmand c'est que c'est moi qui choisis 
manuellement la géolocalisation de la photo, et non la puce GPS qui peut 
donner un positionnement fantaisiste.






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


Re: [OSM-talk-fr] Cartopartie : comment relever efficacement les horaires des commerces ?

2020-06-15 Per discussione Christian Quest
Depuis des années je ne prends quasiment aucune note, mais que des 
photos... plan large, puis moyen, puis gros plan sur les détails comme 
les horaires d'ouverture ou autre.


Je m'arrange pour que les numéros d'adresse soient lisibles, et bien sûr 
elle sont géoréférencées par le GPS de mon smartphone.


Après dans JOSM, on a toutes les infos et une localisation même 
approximative qui suffit amplement, l'important étant de conserver 
l'ordre des photos.


Parfois, elles restent des mois dans mon smartphone avant que je les 
dépile, c'est mon pense bête... un truc à changer, hop une photo en passant.



--
Christian Quest - OpenStreetMap France


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


Re: [OSM-talk-fr] Numéro sans nom de rue : faux positifs dans la validation de JOSM

2020-06-15 Per discussione Philippe Verdy
"La Place" ici est le nom de la boucle. Les rues qui s'y connectent ont
leur propre nom, dont cette place n'hérite pas.
S'il y a des panneaux je suis presque certain que ça affiche "La Place"
comme nom de "rue".
Bref "La Place" serait donc éligible à une relation associatedStreet sous
ce nom pour ensuite mettre les noeuds membres des adresses situées autour
(s'il y en a, en principe oui et c'est porté au cadastre même si ce n'est
pas affiché sur le terrain)

Le sam. 13 juin 2020 à 20:09,  a écrit :

> La précision "pour la France" est importante car certains pays n'ont pas
> encore les délimitations des différents échelons administratifs et donc le
> is_in est encore utile dans certains pays.
>
> On peut continuer le nettoyage, tell que le nom de rue des points
> d'adresses qui sont dans une relation associatedStreet.
>
> Pour avoir viré des références INSEE sur les mairies des départements
> 59/62, je peux affirmer que le nombre de noms mal tapé est impressionnant
> (merci Osmose).
>
> Et j'ai un cas limite :
>
> https://www.openstreetmap.org/way/122685881#map=19/50.14744/3.81485
>
> 
>
> https://www.taisnieres-en-thierache.fr/ confirme que l'adresse est la
> bonne.
>
> à savoir :
> La Place
> 59550 Taisnières-en-Thiérache
>
> Pas de numéro donc logiquement
>
> add:place=La Place
>
> Et on met La Place en place=square ?
> Mais dans ce cas on ne met pas dans une associatedStreet.
>
> Ou on considère au niveau d'Osmose que c'est un faux positif ?
> Le 13/06/2020 à 19:25, Yves P. - yves.prat...@gmail.com a écrit :
>
> Il me semble qu'il y a eu du ménage de fait sur les is_in=*
>
> Est-ce que ça vaudrait le coup de faire pareil ?
>
> Un petit coup de requête Overpass dans JOSM (pour la France) et… c'est réglé 
> :)
>
> __
> Yves
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [Talk-it] Compresenza addr street e place

2020-06-15 Per discussione fox91fox
Non vorrei andare OT ma a questo punto sembra sbagliato il fatto che 
Opicina sia taggato come place=town invece che place=village.

Dopotutto è solamente una frazione di Trieste.

Andrea

On 6/15/20 15:19, dam...@damjan.net wrote:

Scusate, ma se vi sto dicendo che è un place=town, mi dite di metterlo in 
addr:hamlet? Non capisco con che logica, al massimo potrei metterlo in addr:town

Damjan

-- Original Header ---

 From  : "Martin Koppenhoefer" dieterdre...@gmail.com
To  : "openstreetmap list - italiano" talk-it@openstreetmap.org
Cc  :
Date  : Mon, 15 Jun 2020 14:38:35 +0200
Subject : Re: [Talk-it] Compresenza addr street e place



sent from a phone


On 15. Jun 2020, at 14:01, Andrea Musuruane  wrote:

Per questi casi, credo si possa usare addr:hamlet (o addr:suburb)



+1, addr:hamlet è il tag per questi casi, addr:place va omesso quando 
addr:street è presente. (e forse addr:suburb ma viene usato poco, ci sono più 
addr:neighbourhood per esempio)

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-br] Importações de transformadores.

2020-06-15 Per discussione Mapas Osm
Olá,
Tenho informações georreferenciadas de transformadores e chaves de parte
dos estados de São Paulo e Mato Grosso do Sul, os dados foram fornecidos
pela empresa de energia local. Cada ponto possui seu código específico
indispensável para sua consulta.
Existe a possibilidade de importar esses dados para o OSM base? Caso
positivo, como proceder à importação de forma que esses códigos podem ser
consultados?

Desde já agradeço!
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br


Re: [Talk-GB] Rockall

2020-06-15 Per discussione Mark Goodge



On 15/06/2020 10:23, Colin Smale wrote:
A new mapper has changed the status of Rockall, removing it from the UK 
admin boundaries. As I understand it Rockall is accepted as UK territory 
although it can't be used as a baseline to extend the EEZ. I contacted 
the mapper with a changeset comment and their motivation is based on 
"fixing the EEZ".


Wikipedia suggests that Rockall is considered (administratively 
speaking) part of the isle of Harris, in the Western Isles.


As Rockall has from time to time been the subject of a territorial 
dispute with Ireland, should we use the "disputed territories" process 
for Rockall?


I'd just revert it. There's no dispute as such about the ownership of 
Rockall, as no other country claims it. Ireland doesn't recognise UK 
sovereignty over Rockall, but doesn't claim it for itself either.


I see that the mapper in question has also changed the description of 
Rockall from island to rock, which also seems wrong to me. It is an 
island, albeit a very small one. But those are their only two edits, 
which suggests that they have a particular aganda rather than trying to 
improve OSM.


I think both edits should be reverted for now, but the mapper should be 
invited to suggest the changes he wants here and see if he can get a 
consensus around them.


Mark

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


Re: [Talk-us] Rail tagging in US (and North America): operator=* and reporting_marks=*

2020-06-15 Per discussione Russell Nelson

On 6/14/20 6:34 PM, Chuck Sanders wrote:
after watching the re-discussion of the abandoned railroad line "where 
do we draw the line" topic, from a somewhat-outside perspective,


I've given up arguing. I treat deletion of abandoned railways as 
vandalism and just fix it. Not seeing something is no reason to delete 
it -- because someone else might be able to see it. This is my classic 
example:


https://www.openstreetmap.org/#map=20/42.721785518232124/-73.69278208233906

How do you explain why this building is a triangle without mapping the 
abandoned railroad which ran along its hypotenuse? Once you do that, it 
becomes obvious.




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


Re: [Talk-it] Compresenza addr street e place

2020-06-15 Per discussione dam...@damjan.net
Scusate, ma se vi sto dicendo che è un place=town, mi dite di metterlo in 
addr:hamlet? Non capisco con che logica, al massimo potrei metterlo in addr:town

Damjan

-- Original Header ---

From  : "Martin Koppenhoefer" dieterdre...@gmail.com
To  : "openstreetmap list - italiano" talk-it@openstreetmap.org
Cc  : 
Date  : Mon, 15 Jun 2020 14:38:35 +0200
Subject : Re: [Talk-it] Compresenza addr street e place

> 
> 
> sent from a phone
> 
> > On 15. Jun 2020, at 14:01, Andrea Musuruane  wrote:
> > 
> > Per questi casi, credo si possa usare addr:hamlet (o addr:suburb)
> 
> 
> 
> +1, addr:hamlet è il tag per questi casi, addr:place va omesso quando 
> addr:street è presente. (e forse addr:suburb ma viene usato poco, ci sono più 
> addr:neighbourhood per esempio)
> 
> Ciao Martin

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


Re: [Talk-GB] Rockall

2020-06-15 Per discussione nathan case
I also note that the editor changed Rockall from “island” to “bare rock”, and 
that Colin has question this: https://www.openstreetmap.org/changeset/86624262

For what it’s worth, I suggest the correct tag for Rockall is “islet”: 
https://wiki.openstreetmap.org/wiki/Tag:place%3Dislet This is supported by 
Rockall’s wikipedia page (https://en.wikipedia.org/wiki/Rockall) “Rockall 
(/ˈrɒkɔːl/) is an uninhabitable 
granite islet in the exclusive economic 
zone (EEZ) of the United 
Kingdom,”  and by the (not 
official!) definition of “an islet has little or no vegetation, and cannot 
support human habitation” (https://en.wikipedia.org/wiki/Islet).



From: Andy Townsend 
Sent: 15 June 2020 13:53
To: talk-gb@openstreetmap.org
Subject: Re: [Talk-GB] Rockall

In situations like this I'd invite the new mapper to discuss things more widely 
(which Colin has already done on 
https://www.openstreetmap.org/changeset/86624359 ) and then revert the changes 
pending any discussion here.

The new mapper is already aware of the changeset discussion (they've replied) 
so hopefully won't then just change it back.

Best Regards,

Andy


On 15/06/2020 11:17, Gareth L wrote:
Probably? I am not familiar with the disputed territories process for Osm.

It’s a weird one as only the U.K. has claimed sovereignty. Others don’t accept 
the claim, but also haven’t made a sovereignty claim themselves. So at the 
moment, the U.K. is the administrator - and there is an absence of any others.

I’d say it should remain mapped as U.K. administrative boundary but also 
flagged as disputed.. if that can be done?

Gareth


On 15 Jun 2020, at 10:24, Colin Smale 
 wrote:


A new mapper has changed the status of Rockall, removing it from the UK admin 
boundaries. As I understand it Rockall is accepted as UK territory although it 
can't be used as a baseline to extend the EEZ. I contacted the mapper with a 
changeset comment and their motivation is based on "fixing the EEZ".

Wikipedia suggests that Rockall is considered (administratively speaking) part 
of the isle of Harris, in the Western Isles.

As Rockall has from time to time been the subject of a territorial dispute with 
Ireland, should we use the "disputed territories" process for Rockall?

https://www.openstreetmap.org/changeset/86624359


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



___

Talk-GB mailing list

Talk-GB@openstreetmap.org

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


Re: [OSM-talk-be] Renderen van addr:flats

2020-06-15 Per discussione Sander Deryckere
You can do things with that data besides rendering or using it as a route
location.

If the data is more or less complete, you can process it to get the number
of addresses on a street or in an area (for example, if you want to
distribute a folder to the entire street).
Or as a postal service, you can check if that address needs a flat number,
and suggest a list of flats to the users.

Like that, I always considered the values worth to be in OSM, even if it's
all on the same door/building. Though it's obviously a lot less important
than housenumbers.

Op ma 15 jun. 2020 om 14:47 schreef Marc M. :

> if one building have 2 entrance, it's useful to describe with entrance
> need to be used to reach this flats number.
> but having all flats number on the building or on one-only entrance,
> is like "to reach the inside of the building, reach the building".
> it's a bit like adding entrance=yes on the building to say that a
> building has an entrance somewhere, you don't add any real information.
>
> so at this place, I would not have added any addr:flats which would have
> solved the problem of rendering :) I will only use it in the case of a
> building with more than one entrance, and so addr:flats on the entrance
> does not disturb the display of addr:housenumber for the whole building.
>
> Le 15.06.20 à 13:55, Lionel Giard a écrit :
> > The tagging is correct, it is just not supposed to be on area from the
> > wiki perspective. But indeed I don't see why it is incorrect when a
> > building is only containing this series of flats and only one entrance ?
> > And if that's incorrect why are they rendering addr:flats on area and
> > not node ?! ^^'
> >
> > Le lun. 15 juin 2020 à 13:32, joost schouppe  > > a écrit :
> >
> > Most of this data comes from the GRB import, I would guess. So it
> > comes from CRAB. We use the addr:flats to map the "subaddresses".
> > It seems a little weird to not be able to add the subaddresses on
> > the same object that has the main address.
> > The CRAB import tool mentioned this as an optional tag, that is not
> > so useful for OSM:
> >
> https://wiki.openstreetmap.org/wiki/AGIV_CRAB_Import#Optional_tags.2C_provided_by_the_tool
> > I would concur that the quality of the data is not good enough to
> > import it.
> > Both examples come from endless_autumn, who did a rather
> > quick-and-dirty GRB import - a lot of which was reverted.
> > The GRB-import-validator Midgard made actually flags the flats tag
> > as "consider removing" as well.
> > That said, the wiki doesn't say much about the logic of
> > "subaddresses", maybe we shouldn't use the addr:flats tag -at all-
> > for subaddresses?
> >
> >
> > Op ma 15 jun. 2020 om 09:22 schreef Sander Deryckere
> > mailto:sander...@gmail.com>>:
> >
> > Hmm,
> >
> > it seems indeed that, according to the wiki, this should not be
> > placed on areas.
> > However, I expect that in all these cases, all flats are
> > accessible behind the same door.
> > So correcting the tag will have the same effect.
> >
> > Op ma 15 jun. 2020 om 09:12 schreef Marc M.
> > mailto:marc_marc_...@hotmail.com>>:
> >
> > Hello,
> >
> > Le 15.06.20 à 08:23, Sander Deryckere a écrit :
> > > https://www.openstreetmap.org/#map=19/50.87528/4.69102
> >
> > https://www.openstreetmap.org/way/499694374
> > this look like a mistake :
> > wiki :  marking range of numbers of flats behind a door,
> > but the object isn't a door, it's a building
> >
> > maybe osm.carto should avoid to render tagging mistake and
> > target
> > only node and maybe only with entrance or door tag
> >
> > Regards,
> > Marc
>
> ___
> 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-GB] Rockall

2020-06-15 Per discussione Andy Townsend
In situations like this I'd invite the new mapper to discuss things more 
widely (which Colin has already done on 
https://www.openstreetmap.org/changeset/86624359 ) and then revert the 
changes pending any discussion here.


The new mapper is already aware of the changeset discussion (they've 
replied) so hopefully won't then just change it back.


Best Regards,

Andy


On 15/06/2020 11:17, Gareth L wrote:

Probably? I am not familiar with the disputed territories process for Osm.

It’s a weird one as only the U.K. has claimed sovereignty. Others 
don’t accept the claim, but also haven’t made a sovereignty claim 
themselves. So at the moment, the U.K. is the administrator - and 
there is an absence of any others.


I’d say it should remain mapped as U.K. administrative boundary but 
also flagged as disputed.. if that can be done?


Gareth


On 15 Jun 2020, at 10:24, Colin Smale  wrote:



A new mapper has changed the status of Rockall, removing it from the 
UK admin boundaries. As I understand it Rockall is accepted as UK 
territory although it can't be used as a baseline to extend the EEZ. 
I contacted the mapper with a changeset comment and their motivation 
is based on "fixing the EEZ".


Wikipedia suggests that Rockall is considered (administratively 
speaking) part of the isle of Harris, in the Western Isles.


As Rockall has from time to time been the subject of a territorial 
dispute with Ireland, should we use the "disputed territories" 
process for Rockall?


https://www.openstreetmap.org/changeset/86624359


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


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


Re: [OSM-talk-be] Renderen van addr:flats

2020-06-15 Per discussione Marc M.
if one building have 2 entrance, it's useful to describe with entrance
need to be used to reach this flats number.
but having all flats number on the building or on one-only entrance,
is like "to reach the inside of the building, reach the building".
it's a bit like adding entrance=yes on the building to say that a
building has an entrance somewhere, you don't add any real information.

so at this place, I would not have added any addr:flats which would have
solved the problem of rendering :) I will only use it in the case of a
building with more than one entrance, and so addr:flats on the entrance
does not disturb the display of addr:housenumber for the whole building.

Le 15.06.20 à 13:55, Lionel Giard a écrit :
> The tagging is correct, it is just not supposed to be on area from the
> wiki perspective. But indeed I don't see why it is incorrect when a
> building is only containing this series of flats and only one entrance ?
> And if that's incorrect why are they rendering addr:flats on area and
> not node ?! ^^'
> 
> Le lun. 15 juin 2020 à 13:32, joost schouppe  > a écrit :
> 
> Most of this data comes from the GRB import, I would guess. So it
> comes from CRAB. We use the addr:flats to map the "subaddresses".
> It seems a little weird to not be able to add the subaddresses on
> the same object that has the main address.
> The CRAB import tool mentioned this as an optional tag, that is not
> so useful for OSM:
> 
> https://wiki.openstreetmap.org/wiki/AGIV_CRAB_Import#Optional_tags.2C_provided_by_the_tool
> I would concur that the quality of the data is not good enough to
> import it.
> Both examples come from endless_autumn, who did a rather
> quick-and-dirty GRB import - a lot of which was reverted.
> The GRB-import-validator Midgard made actually flags the flats tag
> as "consider removing" as well.
> That said, the wiki doesn't say much about the logic of
> "subaddresses", maybe we shouldn't use the addr:flats tag -at all-
> for subaddresses?
> 
> 
> Op ma 15 jun. 2020 om 09:22 schreef Sander Deryckere
> mailto:sander...@gmail.com>>:
> 
> Hmm,
> 
> it seems indeed that, according to the wiki, this should not be
> placed on areas.
> However, I expect that in all these cases, all flats are
> accessible behind the same door.
> So correcting the tag will have the same effect.
> 
> Op ma 15 jun. 2020 om 09:12 schreef Marc M.
> mailto:marc_marc_...@hotmail.com>>:
> 
> Hello,
> 
> Le 15.06.20 à 08:23, Sander Deryckere a écrit :
> > https://www.openstreetmap.org/#map=19/50.87528/4.69102
> 
> https://www.openstreetmap.org/way/499694374
> this look like a mistake :
> wiki :  marking range of numbers of flats behind a door,
> but the object isn't a door, it's a building
> 
> maybe osm.carto should avoid to render tagging mistake and
> target
> only node and maybe only with entrance or door tag
> 
> Regards,
> Marc

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


Re: [OSRM-talk] Is STXXL still used in the wild?

2020-06-15 Per discussione Mateusz Loskot
On Mon, 15 Jun 2020 at 13:27, Frédéric Rodrigo  wrote:
>
> Le 15/06/2020 à 11:39, Mateusz Loskot a écrit :
> > On Sun, 14 Jun 2020 at 11:46, Denis Chapligin  wrote:
> >> I was building libraries for a windows build and discovered that STXXL is 
> >> abandonware atm
> > "OSRM is essentially abandonware at this point" too
> > https://lists.openstreetmap.org/pipermail/osrm-talk/2020-March/001849.html
>
>
> It is not totally true. There is still a community, but without access
> to the github repository as commiter.
>
> Ask was already made to reaming people with access, to name new
> commiters and allow the community to take the project.

Some commits are being made and PRs are being merged.
So, I'd suggest to keep submitting PRs and keep on nudging
maintainers, whoever is available out there.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net

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


Re: [OSM-talk-fr] SPAM, Re: Cartopartie : comment relever efficacement les horaires des commerces ?

2020-06-15 Per discussione Georges Dutreix via Talk-fr



Le 15/06/2020 à 14:08, Arnaud Champollion a écrit :
Les photos se trouvent ensuite dans 
/Android/data/net.osmand.plus/files/avnotes/


Je les copies sur mon disque dur, et les ouvre dans un calque avec 
JOSM. Elles apparaissent à l'endroit choisi lors de la prise de vue.


Un truc pour éviter d'aller les chercher dans l'ordiphone :

 *
   optionnel : Démarrer KDE Connect sur l'ordinateur et l'ordiphone
 *
   Dans Osmand, menu /Mes lieux favoris/ > /Notes audio/vidéo/
 *
   Bouton /Partager/ en bas, sélectionner les photos à transférer
 *
   Puis bouton /Partager/ (en haut), sélectionner KDE Connect (ou autre
   chose)
 * Ensuite glisser/déposer dans JOSM

À noter que ce menu /Mes lieux favoris /est aussi le bon endroit pour 
une suppression en masse des photos Osmand.


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


Re: [Talk-it] Compresenza addr street e place

2020-06-15 Per discussione Martin Koppenhoefer


sent from a phone

> On 15. Jun 2020, at 14:01, Andrea Musuruane  wrote:
> 
> Per questi casi, credo si possa usare addr:hamlet (o addr:suburb)



+1, addr:hamlet è il tag per questi casi, addr:place va omesso quando 
addr:street è presente. (e forse addr:suburb ma viene usato poco, ci sono più 
addr:neighbourhood per esempio)

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


Re: [OSM-talk-fr] Cartopartie : comment relever efficacement les horaires des commerces ?

2020-06-15 Per discussione Dlareg
Pour ma part je les prends en photo sans GPS, je prend en photo le nom
de la rue pour mémoire et ensuite je prend une photo d'ensemble du
commerce avec le numéro de rue et le nom pour consolider les
informations déjà existante. Enfin je prend une photo avec les horaires.

Le 14/06/2020 à 22:24, Arnaud Champollion a écrit :
> Mais là on va probablement prendre une centaine de photos, avec des
> devantures de magasin espacées de quelques mètres à peine.
> J'ai un peu peur que la précision du GPS ne soit pas suffisant.


-- 
Dlareg



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


Re: [OSM-talk-fr] Cartopartie : comment relever efficacement les horaires des commerces ?

2020-06-15 Per discussione Eric Brosselin - Osm

Bonjour,

Le 14/06/2020 à 21:02, Arnaud Champollion a écrit :

/
//http://www.linux-alpes.org/osmdigne-ca-repart/ //

//Nous prévoyons //

//-  des équipes chargées des relevés de noms, qui annoteront une 
carte papier imprimée : 
http://linux-alpes.org/osmdigne/bd_gassendi_4_pages.pdf /


Au vu de la carte il paraît difficile d'aller écrire des choses dessus 
ou alors ce sera imprimé en très grand format.
Bon cela peut être utile pour se repérer mais je pense qu'il serait plus 
efficace de faire des "schéma de rue"  (cf ci-dessous)
C'est à dire un schéma linéaire positionnant les POIs 
(commerces,services,...) par rapport aux n°s de rue et aux bâtiments



/-des équipes chargées des relevés des horaires //
/
Je ne comprends pas trop la séparation. Il est tout à fait possible 
d'avoir des binômes où l'un note et l'autre fait la/les photos nécessaires



///
//Pour cette deuxième équipe, avez-vous au l'occasion de mettre en 
place des procédures en particulier ? //


//Noter les horaires sur place peut être très long, donc j'imaginais 
avoir recours à la photo. Une équipe avec un photographe et un 
secrétaire, le premier photographiant les panneaux d'horaires, le 
second notant dans un tableau préalablement numéroté les noms des 
commerces, afin que l'on puisse établir les correspondances pour le 
versement des contributions ... à considérer que le photographe 
s'astreigne à ne prendre qu'une seule photo de chaque panneau horaire. //

/
Cela dépend des infos présentes sur la vitrine et de leur taille mais 
parfois une photo plus large est aussi intéressante car elle permet 
d'avoir le nom et le type du POI en même temps

Et si les horaires sont indiqués en gros ça suffit.
Sinon y ajouter bien sûr un gros plan sur les horaires. Donc deux photos 
ça me paraît bien.



/
//Je suis preneur de toutes vos expériences et conseils pour réaliser 
ces relevés sur le terrain de façon fiable et tenable dans le temps. /


Donc il y a "papier" versus "photo"

J'ai pas mal commencé avec le papier mais je tends plus vers la 
photo-note tout au moins pour les POIs de type commerces, services...

Je garde le papier pour faire des plans de lieux


1/ _Notes "Papier"_

Il est possible de noter très rapidement en abrégé un grand nombre d'infos.

Se définir un "modèle", une façon de noter :

Rue XYZ
n° adresse - nom d'enseigne - type de POI - horaires - contact - 
accessibilité - particularités - notes
n° adresse - nom d'enseigne - type de POI - horaires - contact - 
accessibilité - particularités - notes

...

_Exemple avec 3 commerces sur 2 n°s d'adresse_ :
_
__Rue de la Paix_
n°2 | La Tasse | café | ls 730 1930 sd 8 18 | xx xx 20 30 40 - 
cont...@latasse.fr - www.latasse.fr | access O | 
n°2 | Risquetout | assur | lv 9 18 | xx xx 30 40 50 - 
cont...@risquetout.fr - www.risquetout.fr | access O | ...
n°3 | Lune't | optic | ms 9 19 | xx 40 50 60 - cont...@lunet.fr - 
www.lunet.fr | access O | ...


Cela va assez vite. C'est lisible par tout le monde (sous réserve 
d'expliquer les abréviations)


_Remarques_ :
- abrévier selon ses "goûts" pour les types de POIs, les horaires, 
l'accessibilité, etc.
- pour les horaires utiliser les premières lettres des jours et 
regrouper les chiffres. Exemple :/lv 630 1930/ au lieu de/lundi-vendredi 
06 h 30 - 19 h 30/
- xx xx pour le téléphone indique qu'on connaît déjà la première partie 
du n° selon la région où l'on est, il est donc inutile de la noter.



2/ _Notes "Photo"_

Le "photo-noting" avec OsmAnd est très efficace.
Disponibilité des cartes hors-connexion et pas besoin de GPS

Zoomer.
Placer un repère sur l'emplacement du POI (appui long du doigt)
Un marqueur apparaît => Actions => Prendre une photo
La photo est géolocalisée.

Après pour l'intégration plusieurs méthodes possible :
- importer les photos dans JOSM par exemple
- laisser les photos sur le smartphone /la tablette et les consulter
 Il est possible avec un câble spécial (norme mhl) d'afficher le 
smartphone/la tablette (si compatibles) sur un écran de télévision.


Effacer les photos au fur et à mesure de l'intégration dans OSM.

Voilà

Éric
--

Ci-dessous explication du "schéma de rue"

_Schéma de rue_

Faire un "schéma de rue" (vertical/horizontal) permet très rapidement de 
créer un document qui sera utile pour positionner les POIs par rapport 
aux bâtiments et n°s d'adresse.
Les n°s indiqués dans le cadastre ne correspondent pas toujours avec la 
réalité du terrain c'est l'occasion de les corriger.


Faire cela depuis le trottoir d'en face permet d'avoir plus de recul et 
donc une meilleure vision d'ensemble. Et c'est mieux pour les photos.


1 / _Exemple horizontal_

- c pour commerce
- n°x pour numéro d'adresse
- La "numérotation" reprend à zéro au croisement avec une autre rue (si 
on change de rue)



  rue A croisement rue C rue B

|__c15___n°56__c16_| || |__c1___c2n°1_|_c3 n°2 c4_|___c5_n°3_|

          Bâtiment L        

Re: [OSM-talk-fr] SPAM, Re: Cartopartie : comment relever efficacement les horaires des commerces ?

2020-06-15 Per discussione Jacques Lavignotte



Le 15/06/2020 à 14:08, Arnaud Champollion a écrit :

Je les copies sur mon disque dur, et les ouvre dans un calque avec JOSM. 
Elles apparaissent à l'endroit choisi lors de la prise de vue.


Ca marche même sans OSMAnd dès que les EXIF portent les données GPS.

J.

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

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


Re: [OSM-talk-fr] SPAM, Re: Cartopartie : comment relever efficacement les horaires des commerces ?

2020-06-15 Per discussione Arnaud Champollion

Le 15/06/2020 à 11:10, Georges Dutreix via Talk-fr a écrit :
1) Activer le greffon "Notes audio/vidéo" dans le menu Gestionnaire de 
greffons
2) Choisir un profil (par exemple Piéton), puis dans le menu "Configuer 
l'écran", activer "Action rapide"
3) Une icône "Action rapide" apparaît sur l'écran (index appuyant sur la 
carte), cette icône est repositionnable après un appui long
4) Devant un POI, cliquer sur "Action rapide", on peut alors 
zoomer/dézoomer et repositionner la carte très précisément sous le 
pointeur AVANT de cliquer sur Nouvelle photo


 Yes, je viens de tester.

J'ai pu prendre avec cette méthode des photos "géolocalisées" à 
différents endroits, sans bouger de chez moi.


Les photos se trouvent ensuite dans 
/Android/data/net.osmand.plus/files/avnotes/


Je les copies sur mon disque dur, et les ouvre dans un calque avec JOSM. 
Elles apparaissent à l'endroit choisi lors de la prise de vue.


Je pense qu'on va faire ça, merci.

Arnaud

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


Re: [Talk-it] Compresenza addr street e place

2020-06-15 Per discussione Andrea Musuruane
Ciao,
   questo è errato perché Opicina fa parte del Comune di Trieste. Quindi in
addr:city ci va Trieste. addr:place è sicuramente errato in questo contesto
perché si usa in alternativa ad addr:street quando l'indirizzo si riferisce
a un luogo invece che a una strada. Per questi casi, credo si possa usare
addr:hamlet (o addr:suburb) anche se francamente mi sembra ridondante se
gli indirizzi all'interno del Comune di Trieste sono univoci (come
dovrebbero essere).

Ciao,

Andrea


On Mon, Jun 15, 2020 at 1:39 PM Francesco Ansanelli 
wrote:

> Ciao,
>
> in teoria non serve e credo sia anche dannoso metterli entrambi.
> Se Opicina è una città mettila in City (e togli Trieste).
> Non credo sia necessario avere tutti i livelli di gerarchia
>
> Francesco
>
> Il giorno lun 15 giu 2020 alle ore 13:30 dam...@damjan.net <
> dam...@damjan.net> ha scritto:
>
>> La regola è questa, però alcune volte serve, o è meglio mettere anche il
>> place, per distinguere. Ti faccio un esempio delle nostre parti: Opicina
>> (un town nei pressi di Trieste) - siccome il cap è condiviso con una parte
>> di Trieste-città, in addr:city bisogna mettere Trieste, la via c'è, ma così
>> Opicina non compare da nessuna parte (ed è un town!). L'unico modo è
>> metterlo nel place...
>>
>> Damjan
>>
>> -- Original Header ---
>>
>> From  : "Cascafico Giovanni" cascaf...@gmail.com
>> To  : "openstreetmap list - italiano" talk-it@openstreetmap.org
>> Cc  :
>> Date  : Mon, 15 Jun 2020 12:09:42 +0200
>> Subject : [Talk-it] Compresenza addr street e place
>>
>> > Compresenza addr:street ed addr:place
>> > Vorrei fare un mass-edit in provincia di BZ, rimuovendo addr:place
>> > laddove ci sia anche un addr:street in base a questa query:
>> >
>> > http://overpass-turbo.eu/s/V5A
>> >
>> > Che ne dite?
>> >
>> > ___
>> > 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-be] Renderen van addr:flats

2020-06-15 Per discussione Lionel Giard
The tagging is correct, it is just not supposed to be on area from the wiki
perspective. But indeed I don't see why it is incorrect when a building is
only containing this series of flats and only one entrance ? And if that's
incorrect why are they rendering addr:flats on area and not node ?! ^^'

Le lun. 15 juin 2020 à 13:32, joost schouppe  a
écrit :

> Most of this data comes from the GRB import, I would guess. So it comes
> from CRAB. We use the addr:flats to map the "subaddresses".
> It seems a little weird to not be able to add the subaddresses on the same
> object that has the main address.
> The CRAB import tool mentioned this as an optional tag, that is not so
> useful for OSM:
> https://wiki.openstreetmap.org/wiki/AGIV_CRAB_Import#Optional_tags.2C_provided_by_the_tool
> I would concur that the quality of the data is not good enough to import
> it.
> Both examples come from endless_autumn, who did a rather quick-and-dirty
> GRB import - a lot of which was reverted.
> The GRB-import-validator Midgard made actually flags the flats tag as
> "consider removing" as well.
> That said, the wiki doesn't say much about the logic of "subaddresses",
> maybe we shouldn't use the addr:flats tag -at all- for subaddresses?
>
>
> Op ma 15 jun. 2020 om 09:22 schreef Sander Deryckere  >:
>
>> Hmm,
>>
>> it seems indeed that, according to the wiki, this should not be placed on
>> areas.
>> However, I expect that in all these cases, all flats are accessible
>> behind the same door.
>> So correcting the tag will have the same effect.
>>
>> Op ma 15 jun. 2020 om 09:12 schreef Marc M. :
>>
>>> Hello,
>>>
>>> Le 15.06.20 à 08:23, Sander Deryckere a écrit :
>>> > https://www.openstreetmap.org/#map=19/50.87528/4.69102
>>>
>>> https://www.openstreetmap.org/way/499694374
>>> this look like a mistake :
>>> wiki :  marking range of numbers of flats behind a door,
>>> but the object isn't a door, it's a building
>>>
>>> maybe osm.carto should avoid to render tagging mistake and target
>>> only node and maybe only with entrance or door tag
>>>
>>> Regards,
>>> Marc
>>>
>>> ___
>>> 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
>>
>
>
> --
> Joost Schouppe
> OpenStreetMap  |
> Twitter  | LinkedIn
>  | Meetup
> 
> ___
> 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] Compresenza addr street e place

2020-06-15 Per discussione dam...@damjan.net
Ma poi lo stesso cap comparira in osm con due addr:city differenti (Opicina e 
Trieste)?

Damjan

-- Original Header ---

From  : "Francesco Ansanelli" franci...@gmail.com
To  : "openstreetmap list - italiano" talk-it@openstreetmap.org
Cc  : 
Date  : Mon, 15 Jun 2020 13:38:28 +0200
Subject : Re: [Talk-it] Compresenza addr street e place

> Ciao,
> 
> in teoria non serve e credo sia anche dannoso metterli entrambi.
> Se Opicina è una città mettila in City (e togli Trieste).
> Non credo sia necessario avere tutti i livelli di gerarchia
> 
> Francesco
> 
> Il giorno lun 15 giu 2020 alle ore 13:30 dam...@damjan.net <
> dam...@damjan.net> ha scritto:
> 
> > La regola è questa, però alcune volte serve, o è meglio mettere anche il
> > place, per distinguere. Ti faccio un esempio delle nostre parti: Opicina
> > (un town nei pressi di Trieste) - siccome il cap è condiviso con una parte
> > di Trieste-città, in addr:city bisogna mettere Trieste, la via c'è, ma così
> > Opicina non compare da nessuna parte (ed è un town!). L'unico modo è
> > metterlo nel place...
> >
> > Damjan
> >
> > -- Original Header ---
> >
> > From  : "Cascafico Giovanni" cascaf...@gmail.com
> > To  : "openstreetmap list - italiano" talk-it@openstreetmap.org
> > Cc  :
> > Date  : Mon, 15 Jun 2020 12:09:42 +0200
> > Subject : [Talk-it] Compresenza addr street e place
> >
> > > Compresenza addr:street ed addr:place
> > > Vorrei fare un mass-edit in provincia di BZ, rimuovendo addr:place
> > > laddove ci sia anche un addr:street in base a questa query:
> > >
> > > http://overpass-turbo.eu/s/V5A
> > >
> > > Che ne dite?
> > >
> > > ___
> > > 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] Compresenza addr street e place

2020-06-15 Per discussione Francesco Ansanelli
Ciao,

in teoria non serve e credo sia anche dannoso metterli entrambi.
Se Opicina è una città mettila in City (e togli Trieste).
Non credo sia necessario avere tutti i livelli di gerarchia

Francesco

Il giorno lun 15 giu 2020 alle ore 13:30 dam...@damjan.net <
dam...@damjan.net> ha scritto:

> La regola è questa, però alcune volte serve, o è meglio mettere anche il
> place, per distinguere. Ti faccio un esempio delle nostre parti: Opicina
> (un town nei pressi di Trieste) - siccome il cap è condiviso con una parte
> di Trieste-città, in addr:city bisogna mettere Trieste, la via c'è, ma così
> Opicina non compare da nessuna parte (ed è un town!). L'unico modo è
> metterlo nel place...
>
> Damjan
>
> -- Original Header ---
>
> From  : "Cascafico Giovanni" cascaf...@gmail.com
> To  : "openstreetmap list - italiano" talk-it@openstreetmap.org
> Cc  :
> Date  : Mon, 15 Jun 2020 12:09:42 +0200
> Subject : [Talk-it] Compresenza addr street e place
>
> > Compresenza addr:street ed addr:place
> > Vorrei fare un mass-edit in provincia di BZ, rimuovendo addr:place
> > laddove ci sia anche un addr:street in base a questa query:
> >
> > http://overpass-turbo.eu/s/V5A
> >
> > Che ne dite?
> >
> > ___
> > 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-be] Renderen van addr:flats

2020-06-15 Per discussione joost schouppe
Most of this data comes from the GRB import, I would guess. So it comes
from CRAB. We use the addr:flats to map the "subaddresses".
It seems a little weird to not be able to add the subaddresses on the same
object that has the main address.
The CRAB import tool mentioned this as an optional tag, that is not so
useful for OSM:
https://wiki.openstreetmap.org/wiki/AGIV_CRAB_Import#Optional_tags.2C_provided_by_the_tool
I would concur that the quality of the data is not good enough to import it.
Both examples come from endless_autumn, who did a rather quick-and-dirty
GRB import - a lot of which was reverted.
The GRB-import-validator Midgard made actually flags the flats tag as
"consider removing" as well.
That said, the wiki doesn't say much about the logic of "subaddresses",
maybe we shouldn't use the addr:flats tag -at all- for subaddresses?


Op ma 15 jun. 2020 om 09:22 schreef Sander Deryckere :

> Hmm,
>
> it seems indeed that, according to the wiki, this should not be placed on
> areas.
> However, I expect that in all these cases, all flats are accessible behind
> the same door.
> So correcting the tag will have the same effect.
>
> Op ma 15 jun. 2020 om 09:12 schreef Marc M. :
>
>> Hello,
>>
>> Le 15.06.20 à 08:23, Sander Deryckere a écrit :
>> > https://www.openstreetmap.org/#map=19/50.87528/4.69102
>>
>> https://www.openstreetmap.org/way/499694374
>> this look like a mistake :
>> wiki :  marking range of numbers of flats behind a door,
>> but the object isn't a door, it's a building
>>
>> maybe osm.carto should avoid to render tagging mistake and target
>> only node and maybe only with entrance or door tag
>>
>> Regards,
>> Marc
>>
>> ___
>> 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
>


-- 
Joost Schouppe
OpenStreetMap  |
Twitter  | LinkedIn
 | Meetup

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


Re: [Talk-it] Compresenza addr street e place

2020-06-15 Per discussione dam...@damjan.net
La regola è questa, però alcune volte serve, o è meglio mettere anche il place, 
per distinguere. Ti faccio un esempio delle nostre parti: Opicina (un town nei 
pressi di Trieste) - siccome il cap è condiviso con una parte di Trieste-città, 
in addr:city bisogna mettere Trieste, la via c'è, ma così Opicina non compare 
da nessuna parte (ed è un town!). L'unico modo è metterlo nel place...

Damjan

-- Original Header ---

From  : "Cascafico Giovanni" cascaf...@gmail.com
To  : "openstreetmap list - italiano" talk-it@openstreetmap.org
Cc  : 
Date  : Mon, 15 Jun 2020 12:09:42 +0200
Subject : [Talk-it] Compresenza addr street e place

> Compresenza addr:street ed addr:place
> Vorrei fare un mass-edit in provincia di BZ, rimuovendo addr:place
> laddove ci sia anche un addr:street in base a questa query:
> 
> http://overpass-turbo.eu/s/V5A
> 
> Che ne dite?
> 
> ___
> 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: [OSRM-talk] Is STXXL still used in the wild?

2020-06-15 Per discussione Frédéric Rodrigo

Le 15/06/2020 à 11:39, Mateusz Loskot a écrit :

On Sun, 14 Jun 2020 at 11:46, Denis Chapligin  wrote:

I was building libraries for a windows build and discovered that STXXL is 
abandonware atm

"OSRM is essentially abandonware at this point" too
https://lists.openstreetmap.org/pipermail/osrm-talk/2020-March/001849.html

Best regards,



It is not totally true. There is still a community, but without access 
to the github repository as commiter.


Ask was already made to reaming people with access, to name new 
commiters and allow the community to take the project.



Frédéric Rodrigo.



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


Re: [OSRM-talk] Is STXXL still used in the wild?

2020-06-15 Per discussione Mateusz Loskot
On Mon, 15 Jun 2020 at 12:51, Denis Chapligin  wrote:
> пн, 15 июн. 2020 г. в 12:40, Mateusz Loskot :
>>
>> On Sun, 14 Jun 2020 at 11:46, Denis Chapligin  wrote:
>> >
>> > I was building libraries for a windows build and discovered that STXXL is 
>> > abandonware atm
>>
>> "OSRM is essentially abandonware at this point" too
>> https://lists.openstreetmap.org/pipermail/osrm-talk/2020-March/001849.html
>>
>>
>
> And I'm really concerned about that :(

Me too.

> Regarding STXXL presence - yep, i know it's optional, but it _may_ be an 
> issue for c++17 introduction ;)

If I was about to do it, I would do this:

1. Submit PR wiping out all traces of STXXL
2. Submit PR bumping required C++ version to C++17
with minimal code modernisation to enable compilation as C++17
3. Continue with series of manageable PRs modernising code to C++17

I honestly expect such PRs will be accepted as I see no practical
reasons to not to.
I should be able to offer my help in reviewing and testing the PRs,
as well as submitting some for the 3. part.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net

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


Re: [OSRM-talk] Is STXXL still used in the wild?

2020-06-15 Per discussione Denis Chapligin
Hello!



пн, 15 июн. 2020 г. в 12:40, Mateusz Loskot :

> On Sun, 14 Jun 2020 at 11:46, Denis Chapligin  wrote:
> >
> > I was building libraries for a windows build and discovered that STXXL
> is abandonware atm
>
> "OSRM is essentially abandonware at this point" too
> https://lists.openstreetmap.org/pipermail/osrm-talk/2020-March/001849.html
>
>
>
And I'm really concerned about that :(

Regarding STXXL presence - yep, i know it's optional, but it _may_ be an
issue for c++17 introduction ;)
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk


Re: [Talk-GB] Rockall

2020-06-15 Per discussione Gareth L
Probably? I am not familiar with the disputed territories process for Osm.

It’s a weird one as only the U.K. has claimed sovereignty. Others don’t accept 
the claim, but also haven’t made a sovereignty claim themselves. So at the 
moment, the U.K. is the administrator - and there is an absence of any others.

I’d say it should remain mapped as U.K. administrative boundary but also 
flagged as disputed.. if that can be done?

Gareth

On 15 Jun 2020, at 10:24, Colin Smale  wrote:



A new mapper has changed the status of Rockall, removing it from the UK admin 
boundaries. As I understand it Rockall is accepted as UK territory although it 
can't be used as a baseline to extend the EEZ. I contacted the mapper with a 
changeset comment and their motivation is based on "fixing the EEZ".

Wikipedia suggests that Rockall is considered (administratively speaking) part 
of the isle of Harris, in the Western Isles.

As Rockall has from time to time been the subject of a territorial dispute with 
Ireland, should we use the "disputed territories" process for Rockall?

https://www.openstreetmap.org/changeset/86624359


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


[Talk-it] Compresenza addr street e place

2020-06-15 Per discussione Cascafico Giovanni
Compresenza addr:street ed addr:place
Vorrei fare un mass-edit in provincia di BZ, rimuovendo addr:place
laddove ci sia anche un addr:street in base a questa query:

http://overpass-turbo.eu/s/V5A

Che ne dite?

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


Re: [talk-latam] Oportunidad de trabajo

2020-06-15 Per discussione Rebecca Firth
Hola a todxs,

Les quedan 6 días para aplicar. Quedo atenta ante cualquier pregunta o duda
- https://www.hotosm.org/jobs/partnerships-associate-americas/

Rebecca

On Thu, Jun 4, 2020 at 10:11 PM Rebecca Firth 
wrote:

> Hola a todxs!
>
> Espero que se encuentren bien. Les escribo para compartir una oportunidad
> laboral con HOT - seria un trabajo "remoto":
> https://www.hotosm.org/jobs/partnerships-associate-americas/ compartalo
> con sus contactos por fa!
>
> Quedo atenta ante cualquier pregunta o duda,
>
> Rebecca
>
> --
> *Rebecca Firth*
> Director, Community & Partnerships
> rebecca.fi...@hotosm.org
> @RebeccaFirthy
>
> *Humanitarian OpenStreetMap Team*
> *Using OpenStreetMap for Humanitarian Response & Economic Development*
> web  | twitter  | facebook
>  | donate 
>
>

-- 
*Rebecca Firth*
Director, Community & Partnerships
rebecca.fi...@hotosm.org
@RebeccaFirthy

*Humanitarian OpenStreetMap Team*
*Using OpenStreetMap for Humanitarian Response & Economic Development*
web  | twitter  | facebook
 | donate 
___
talk-latam mailing list
talk-latam@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-latam


Re: [OSRM-talk] C++17?

2020-06-15 Per discussione Mateusz Loskot
On Sun, 14 Jun 2020 at 11:45, Denis Chapligin  wrote:
>
> Looks like all major OSRM platforms have stable support for C++17.
> Are there any reasons to stay on C++14?
> Any objections against language version update?

+1 a vote from OSRM user, occasional contributor

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net

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


Re: [OSRM-talk] Is STXXL still used in the wild?

2020-06-15 Per discussione Mateusz Loskot
On Sun, 14 Jun 2020 at 11:46, Denis Chapligin  wrote:
>
> I was building libraries for a windows build and discovered that STXXL is 
> abandonware atm

"OSRM is essentially abandonware at this point" too
https://lists.openstreetmap.org/pipermail/osrm-talk/2020-March/001849.html

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net

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


Re: [OSRM-talk] Is STXXL still used in the wild?

2020-06-15 Per discussione Mateusz Loskot
On Sun, 14 Jun 2020 at 11:46, Denis Chapligin  wrote:
>
> i would like to ask, are there any actual users of STXXL left

Although it won't make for any useful statistics,
I have never built OSRM w/ STXXL enabled.

> and are the any objections of dropping STXXL support from the OSRM?

FYI, STXXL is optional, so you can already build OSRM
as if STXXL support was dropped.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net

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


[Talk-GB] Rockall

2020-06-15 Per discussione Colin Smale
A new mapper has changed the status of Rockall, removing it from the UK
admin boundaries. As I understand it Rockall is accepted as UK territory
although it can't be used as a baseline to extend the EEZ. I contacted
the mapper with a changeset comment and their motivation is based on
"fixing the EEZ". 

Wikipedia suggests that Rockall is considered (administratively
speaking) part of the isle of Harris, in the Western Isles. 

As Rockall has from time to time been the subject of a territorial
dispute with Ireland, should we use the "disputed territories" process
for Rockall? 

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


Re: [Talk-it] Aggiornamento civici comune di Fiè allo Sciliar BZ

2020-06-15 Per discussione Cascafico Giovanni
Aggiornata la mappa di audit con correzione segnalata:
"Blumauer Straße - Via Prato all'Isarco"

Per replicabilità, tutte le operazioni di conversione sono nella repo
[1] github.


[1] https://github.com/cascafico/civiciBZ

Il 13/06/20, Cascafico Giovanni ha scritto:
> Il sab 13 giu 2020, 23:21 Lorenzo Mastrogiacomi  ha
> scritto:
>
>> Riesci ad inserire una regola per correggere questo?
>> addr:street=Blumauer Straße - Via Prato All' Isarco
>>
>> preposizione in minuscolo e senza spazio dopo l'apostrofo.
>>
>
> Certo, me lo segno. Poi pubblicherò la repository dove ci sono tutte le
> operazioni fatte sulle stringhe e replicabili/aggiustabili.
>
>>
>

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


Re: [OSM-talk-fr] Comment orthographier un nombre ordinal

2020-06-15 Per discussione Yves P.
> Le terrain prime... mais cela a aussi des limites ;)
> 
> L’homogénéité dans les données ça ne fait pas de mal surtout quand sur le 
> terrain on a pris quelques libertés avec des règles communes.
+1

> Donc un "28ième" sur une plaque, je le mettrai en "28e" en name
+1

La page FR:Toponymes, odonymes 
 du wiki cite la 
charte de toponymie de l'IGN.
Elle ne détaille pas encore les ièmes…

Et elle n'est pas (encore) citée dans la page FR:Key:name 
 ;)

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


Re: [OSM-talk-fr] Cartopartie : comment relever efficacement les horaires des commerces ?

2020-06-15 Per discussione Georges Dutreix via Talk-fr



Le 15/06/2020 à 03:22, Julien Lepiller a écrit :

C'est aussi comme ça que je procède. OsmAnd a un greffon de prise de note 
audio/photo. Avec un appui long tu peux placer un point et choisir photo dans 
le menu contextuel. Ça te permet de placer la ou les photos avec précision sur 
la carte.

Si le poi existe déjà c'est rapide, on appuie dessus et on prend la photo 
depuis le menu. Ça peut être un peu plus long si le commerce n'est pas 
renseigné (prendre aussi le nom en photo et trouver l'emplacement est plus 
compliqué qu'appuyer sur le poi existant). Faut s'assurer aussi de prendre une 
ou deux photos pour se trouver le bon attribut à utiliser, ou une note.

Par contre ne pas en faire trop (pas plus d'une heure de sortie par exemple, 
sauf si on passe son temps à chercher des commerces dans une zone peu dense), 
parce que la saisie est beaucoup plus longue.

Bonjour,

J'approuve :-)   Le positionnement est extrêmement précis en passant par 
"Action rapide".


Comme l'interface Osmand est plutôt laborieuse, voici les étapes pour 
tester :


1) Activer le greffon "Notes audio/vidéo" dans le menu Gestionnaire de 
greffons
2) Choisir un profil (par exemple Piéton), puis dans le menu "Configuer 
l'écran", activer "Action rapide"
3) Une icône "Action rapide" apparaît sur l'écran (index appuyant sur la 
carte), cette icône est repositionnable après un appui long
4) Devant un POI, cliquer sur "Action rapide", on peut alors 
zoomer/dézoomer et repositionner la carte très précisément sous le 
pointeur AVANT de cliquer sur Nouvelle photo
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] et si c'était Nöel ? liste de souhait et d'intérêt des outils existant

2020-06-15 Per discussione Yves P.
> J'ai suggéré plusieurs fois de remplacer notre phpBB par Discourse
quel est le frein ? (car ça n'a pas abouti)

> , il y a en principe de quoi migrer le contenu du phpBB actuel (jamais testé).
:)

> A la base c'est un forum, mais très bien intégré côté mail et avec une forme 
> d'auto-administration intéressante (les utilisateurs gagnent des badges et 
> montent en compétence).
c'est bien pour motiver les utilisateurs. Tous le monde peut participer quelque 
soit soin niveau :)

> Les sujet peuvent se transformer en articles façon wiki
:)

> mais c'est plus limité pour de la discussion façon "chat" et pas prévu pour
est-ce un problème ? cf point suivant

> bien qu'on soit informé sans délai des nouveaux contenus.
:)

> J'en administre plusieurs instances et avec le recul c'est plutôt bien fichu 
> côté utilisateurs et administration.
:)

> Les upgrade se font assez proprement depuis l'interface web (c'est dockerisé) 
ça va plaire aux développeurs ET aux administrateurs :)
on on peut en retirer de l'expérience pour faire des conteneurs pour nos outils 
et applications OSM ?

> et le développement est bien actif.
:)

> C'est utilisé par :
Pleins d'exemples intéressants :)

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


Re: [OSM-talk-fr] Comment orthographier un nombre ordinal

2020-06-15 Per discussione Christian Quest

Le 13/06/2020 à 22:14, ph...@phyks.me a écrit :

À compléter avec la charte de toponymie de l'IGN également :

http://www.ign.fr/sites/all/files/charte_toponymie_ign.pdf

Souvent non respecté sur le terrain ceci dit, et le terrain prime...



Le terrain prime... mais cela a aussi des limites ;)

L’homogénéité dans les données ça ne fait pas de mal surtout quand sur 
le terrain on a pris quelques libertés avec des règles communes.


Donc un "28ième" sur une plaque, je le mettrai en "28e" en name, quitte 
à garder ce "ième" dans une autre variante de name...



--
Christian Quest - OpenStreetMap France


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


Re: [OSM-talk-fr] et si c'était Nöel ? liste de souhait et d'intérêt des outils existant

2020-06-15 Per discussione Christian Quest

Le 11/06/2020 à 16:39, Yves P. a écrit :
Je n'ai pas encore essayé Discourse, il semble avoir les avantages des 
discussions instantanées et des forums.



Ce n'est pas la première fois qu'on parle de Discourse (y compris en AG) !

J'ai suggéré plusieurs fois de remplacer notre phpBB par Discourse, il y 
a en principe de quoi migrer le contenu du phpBB actuel (jamais testé).


A la base c'est un forum, mais très bien intégré côté mail et avec une 
forme d'auto-administration intéressante (les utilisateurs gagnent des 
badges et montent en compétence). Les sujet peuvent se transformer en 
articles façon wiki, mais c'est plus limité pour de la discussion façon 
"chat" et pas prévu pour bien qu'on soit informé sans délai des nouveaux 
contenus.


J'en administre plusieurs instances et avec le recul c'est plutôt bien 
fichu côté utilisateurs et administration. Les upgrade se font assez 
proprement depuis l'interface web (c'est dockerisé) et le développement 
est bien actif.


C'est utilisé par:

https://forum.etalab.gouv.fr/

https://teamopendata.org/

https://forum.chatons.org/

et j'administre celles-ci:

https://forum.museeminitel.fr/

https://forum.parlement-ouvert.fr/

https://forum.datafin.fr/

--
Christian Quest - OpenStreetMap France


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


Re: [Talk-it] Importazione delle stazioni di ricarica per auto Enel

2020-06-15 Per discussione Nap Osm
Buongiorno a tutti! Ho provato io stesso a inviare una email a Enel per fargli 
sapere del progetto, vi riporto la loro risposta (anche se sembra molto 
standard)

Gentile Nap Osm,

grazie per l'interesse mostrato verso Enel X.

In merito alla tua richiesta, ti informiamo che puoi inviare la tua proposta 
accedendo al nostro sito https://sponsorship.enel.it/.

Continua a seguirci sul nostro sito enelx.com e tramite i nostri canali social.

A presto,
il team di Enel X


From: Nap Osm 
Sent: Wednesday, June 10, 2020 8:19 PM
To: OpenStreetMap List-It 
Subject: Re: [Talk-it] Importazione delle stazioni di ricarica per auto Enel

Ma è un lavorone! Complimenti!

From: Damjan Gerl 
Sent: Tuesday, June 9, 2020 4:15 PM
To: OpenStreetMap List-It 
Subject: Re: [Talk-it] Importazione delle stazioni di ricarica per auto Enel

Ciao! Nella mia provincia (Trieste) le ho inserite tutte io qualche tempo fa, 
sia le Enel sia le altre, almeno delle quali so l'esistenza :-) o sono riuscito 
a trovare info...

Ciao
Damjan


Nap Osm je 9.6.2020 ob 11:45 napisal:
Buongiorno, ragazzi, grazie mille per le numerose risposte. Quindi in passato 
hanno già inserito parte delle stazioni, questa è una buona notizia. Vedo di 
non essere l'unico a cui interessa la questione. Infatti anche a me 
interesserebbe avere le colonnine sia per una questione di completezza della 
mappa sia proprio perché potrei essere in futuro uno di quelli a cui questi 
dati potrebbero servire.
Infatti sono d'accordo con il contattare anche tutti gli altri provider di 
servizi simili.
Per caso si potrebbe azzardare un nuovo tweet, magari di WMI, per rompere il 
ghiaccio?

From: Maurizio Napolitano 
Sent: Monday, June 8, 2020 6:39 PM
To: openstreetmap list - italiano 

Subject: Re: [Talk-it] Importazione delle stazioni di ricarica per auto Enel

> Forse è compito del DWM di contattare Enel?

non serve.
Puoi contattare anche tu e chiedere.
Altrimenti può farlo WMI.

> Sarebbe anche a loro favore.
> Poi si potrebbero contattare gli altri fornitori...

Come ho già scritto lo avevano già fatto a suo tempo.
Sicuramente il management è cambiato.
Di mio posso contattare le persone che avevano fatto l'import a suo tempo.

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


Re: [Talk-lv] Adreses - 2-1, 2-2, 2-3

2020-06-15 Per discussione Rihards
On 14.06.20 19:49, Mārtiņš Bruņenieks wrote:
> Vai nav tā, ka pareizs šīs adreses pieraksts ir 2 k-1?
> 
> http://m.likumi.lv/doc.php?id=278402
> (Meklēt pēc "korpus")

Tā bija pirmā ideja, bet šķita dīvaini nelielu dzīvojamās ēkas daļu
saukt par "korpusu".
Likumā gan tas ir paredzēts kā vienīgais variants šādās situācijās.
Vispār likuma atbilstošie panti šķiet ļoti skaidri - paldies autoriem :)

Būs "k" tātad - liels paldies par likuma atsauci.

> Mārtiņš
> 
> Rihards mailto:riha...@nakts.net>> (šajā datumā: Sv,
> 2020. g. 14. jūn. 19:37) rakstīja:
> 
> Adreses 2-1, 2-2. 2-3 utt īsti nevar tieši tā likt OSM, jo tas norāda
> diapazonu.
> Atceros, ka bija izlemts, kā tādas pierakstīt.
> 
> Vai kāds atceras / var atrast, kur tas dokumentēts?
> -- 
>  Rihards-- 
 Rihards

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


[Talk-at] Zustellort NEU in Österreich

2020-06-15 Per discussione Johann Haag
In Österreich wird gerade das Gewerberegister überarbeitet. Dazu
beschäftigt man sich aktuell mit der Festlegung, der Begrifflichkeit
Zustellort.
Die Frage ist nun, ob wir diesen in OpenStreetMap erfassen können.
Details hierzu auch in meinem Weblink Verzeichnis, addresshistory.hxg.at

https://drive.google.com/drive/folders/1dntYbApmC7rvc3vaVrCZMHpJVp89tXgh?usp=sharing

-- 
Elektronikermeister Johann Haag
Innsbruckerstraße 42
6380 St. Johann in Tirol
ÖSTERREICH
Tel: +43 664/174 7414
Mailto:johannh...@hxg.at
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at


Re: [OSM-talk-fr] Cartopartie : comment relever efficacement les horaires des commerces ?

2020-06-15 Per discussione Yves P.
> la précision du gps qui ne tourne pas en continue est aussi catastrophique.
Il y a plusieurs logiciels qui font ça :
OSMand
OSMTracker : l'interface de saisie de POI est vieillotte, mais j'aime bien la 
trace GPX glissée/déplacée dans JOSM.
Mapillary ?
…

Penser à activer le WIFI. Certains service le géolocation s'en servent aussi 
(Google uniquement ?) pour améliorer la précision du GPS dans les "canyons 
urbains".
Lire How accurate is Mapillary and how to improve? 


> du coup maintenant je fais toujours 3 photos par poi : le no, son nom
> et l'horaire.
La photo d'ensemble est importante pour localiser le POI sur une "street view".

L'équipe photographe et secrétaire me parait un plus. Quand je fait des photos 
seul, j'ai le nez dans le guidon et je passe parfois à côté de pas mal de 
choses.

> -  des équipes chargées des relevés de noms, qui annoteront une carte papier 
> imprimée :
> http://linux-alpes.org/osmdigne/bd_gassendi_4_pages.pdf 
> 

Il manque les n° de rue ?

Tu ne veux/peux pas utiliser Field Papers  ?
Ou tu ne connais pas ?

Au retour c'est très pratique ça tu scanner les feuilles annotées/gribouillées, 
et tu as ça directement dans JOSM au bon endroit dans la carte.

__
Yves

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


Re: [OSM-talk-fr] « Faut-il/Pourquoi/Comment intéresser les POI à la présence/exactitude des leurs données dans OSM. »

2020-06-15 Per discussione Yves P.
> Et le flyer 
> https://wiki.openstreetmap.org/wiki/File:Flyer-Commerces-de-Nantes.pdf 
>  
> dispo en odt 
Avec le graphisme/mise en page de la plaquette d'OSM France ça serait très bien 
:)

Pour moi cette plaquette doit s'adresser aux commerçant, mais aussi 
associations, mairies…
Est-ce qu'une seule peut faire l'affaire, ou doit-elle être déclinée ?

Aux réponses de la question "Quelles informations collectez-vous ?" on peut 
rajouter :
les moyens de paiement
le SIRET
l'accessibilité (mais c'est un sujet complexe)
__
Yves


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


Re: [OSM-talk-be] Renderen van addr:flats

2020-06-15 Per discussione Sander Deryckere
Hmm,

it seems indeed that, according to the wiki, this should not be placed on
areas.
However, I expect that in all these cases, all flats are accessible behind
the same door.
So correcting the tag will have the same effect.

Op ma 15 jun. 2020 om 09:12 schreef Marc M. :

> Hello,
>
> Le 15.06.20 à 08:23, Sander Deryckere a écrit :
> > https://www.openstreetmap.org/#map=19/50.87528/4.69102
>
> https://www.openstreetmap.org/way/499694374
> this look like a mistake :
> wiki :  marking range of numbers of flats behind a door,
> but the object isn't a door, it's a building
>
> maybe osm.carto should avoid to render tagging mistake and target
> only node and maybe only with entrance or door tag
>
> Regards,
> Marc
>
> ___
> 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: [OSM-talk-be] Renderen van addr:flats

2020-06-15 Per discussione Marc M.
Hello,

Le 15.06.20 à 08:23, Sander Deryckere a écrit :
> https://www.openstreetmap.org/#map=19/50.87528/4.69102

https://www.openstreetmap.org/way/499694374
this look like a mistake :
wiki :  marking range of numbers of flats behind a door,
but the object isn't a door, it's a building

maybe osm.carto should avoid to render tagging mistake and target
only node and maybe only with entrance or door tag

Regards,
Marc

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


Re: [OSM-talk-fr] Cartopartie : comment relever efficacement les horaires des commerces ?

2020-06-15 Per discussione Marc M.
Bonjour,

Le 14.06.20 à 21:02, Arnaud Champollion a écrit :
> Je suis preneur de toutes vos expériences et conseils pour réaliser ces
> relevés sur le terrain de façon fiable et tenable dans le temps.

j'a d'abord fait comme toi : une série de photo de ce qui m’intéresse,
pensant pouvoir les assigner au retour devant un pc.
hélas, même en planifiant de faire la rue dans un ordre précis (par ex
toujours les impairs en premier), il y a toujours un cas tordu qui vient
mettre la pagaille (genre un poi au no3 dont l'entrée est après le poi
au no5). et tout s'écroule dans la série en cascade.
la précision du gps qui ne tourne pas en continue est aussi catastrophique.
du coup maintenant je fais toujours 3 photos par poi : le no, son nom
et l'horaire.
et si l'un des 3 n'est pas photographié, je fais une photo vide
pour garder la série de 3.

j'ai testé aussi l'éditeur sur le terrain, je le trouve trop chronophage
(le temps qu'on passe sur le terrain à encoder sur un clavier minuscule
n'est pas compensé par le temps gagné sur le pc, hormis pour des choses
très ponctuelle genre un no de borne incendie que j'encode tout en
continuant de marcher, idem pour des noms en zone très peu dense)

Cordialement,
Marc

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


Re: [OSM-talk-fr] Ajout d'un identifiant unique des cinémas en France

2020-06-15 Per discussione Francescu GAROBY
Bonjour,
En milieu-fin de semaine dernière, je me suis occupé de tous les cinémas du
Calvados. Je vais continuer par les autres départements de Normandie
(l'ex-Basse d'abord, l'ex-Haute ensuite).

Francescu

Le lun. 15 juin 2020 à 08:06, Florian LAINEZ  a écrit :

> Salut, avec quelques motivés dont moi et Yves, on avance bien pour
> répertorier les cinémas et les tagguer ref:FR:CNC.
> On en est déjà à 836 / 2045 soit ~*41 % des cinémas du fichier CNC* !
>
> On a terminé l'ile-de-France, la haute-savoie, le Jura et on a bien avancé
> l'Occitanie et la Bretagne cf.
> https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:CNC#Avancement
> Il reste pas mal de boulot, votre aide est donc la bienvenue.
>
> Le mer. 10 juin 2020 à 18:25, Yves P.  a écrit :
>
>> c'est une tautologie :) bof. cinéma itinérant est une description
>> consulter les horaires ? ok la clef opening_hours donc ? qui dit
>> de consulter les horaires :)
>>
>> Le *:D* à la fin de ma phrase indiquait une pointe d'humour. Je le
>> refais en couleur 
>>
>> opening_hours:url est plus utile. ou un début d'info.
>>
>> Oui.
>> Est-ce que c'est géré par des applications ?
>>
>> __
>> Yves
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> --
>
> *Florian Lainez*
> @overflorian 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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


[OSM-talk-be] Renderen van addr:flats

2020-06-15 Per discussione Sander Deryckere
Hi,

In December last year, the default map rendering started to display the
addr:flats tag.
In Belgium, this looks rather ugly as these tags can be very long.

In some cases, it even becomes hard to see the housenumbers.

See some examples:
https://www.openstreetmap.org/#map=19/50.87528/4.69102
https://www.openstreetmap.org/#map=19/51.04571/3.73000

I asked the OSM Carto project if they could revert that change, but they
say our tagging is an outlier and we should fix our tags.

To me, this sounds like tagging for the renderer, so I'm not very willing
to do that.

What are your opinions?

The issue can be found here:
https://github.com/gravitystorm/openstreetmap-carto/issues/4160

Kind regards,
Sander Deryckere
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be


Re: [OSM-talk-fr] « Faut-il/Pourquoi/Comment intéresser les POI à la présence/exactitude des leurs données dans OSM. »

2020-06-15 Per discussione Yves P.
> La réponse : gilet haute visibilité OpenStreetMap France. Tu dis que tu fais 
> un relevé, tu dis que c'est pour alimenter la base OSM.
> 
> S'il ne comprends pas, tu te retournes, lui dit de flasher le QR code.
> 
> Tu as raté le STOM 2017 ?
> 
Je n'y était pas :/


> Hum... La légion saute sur Kolwesi... no thanks ;)
> 
Le gilet à l'avantage d'attirer le regard et les questions, et de montrer le 
logo et le nom OpenStreetMap :)

Sur le bord des routes, le jaune fluo et utile aussi pour la sécurité ;)
Ok, vu l'actualité de 2019 le vert pourrait être plus adapté que le jaune ?

> Plutôt un argumentaire simple et une (jolie) petite plaquette ?
Je dirais "aussi" à la place de "plutôt" :)

La plaquette actuelle est utile pour quelqu'un qui connait le libre, qui 
souhaiterais contribuer…

Il manque une plaquette "end user" qui montrerait des utilisations concrètes 
d'OSM :
"ca reste ouvert" / OSMyBiz
application en ligne ou smartphone vélo / rando
…

Et/ou un simple carte de visite.

En fonction de la situation, on met ou pas le gilet.
Et selon les questions soulevées, on laisse l'une des plaquettes, la carte de 
visite ou des goodies.

__
Yves

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


Re: [OSM-talk-fr] Ajout d'un identifiant unique des cinémas en France

2020-06-15 Per discussione Florian LAINEZ
Salut, avec quelques motivés dont moi et Yves, on avance bien pour
répertorier les cinémas et les tagguer ref:FR:CNC.
On en est déjà à 836 / 2045 soit ~*41 % des cinémas du fichier CNC* !

On a terminé l'ile-de-France, la haute-savoie, le Jura et on a bien avancé
l'Occitanie et la Bretagne cf.
https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:CNC#Avancement
Il reste pas mal de boulot, votre aide est donc la bienvenue.

Le mer. 10 juin 2020 à 18:25, Yves P.  a écrit :

> c'est une tautologie :) bof. cinéma itinérant est une description
> consulter les horaires ? ok la clef opening_hours donc ? qui dit
> de consulter les horaires :)
>
> Le *:D* à la fin de ma phrase indiquait une pointe d'humour. Je le refais
> en couleur 
>
> opening_hours:url est plus utile. ou un début d'info.
>
> Oui.
> Est-ce que c'est géré par des applications ?
>
> __
> Yves
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 

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


Re: [Talk-at] Historische Hausnummern Österreich, weiterhin Online

2020-06-15 Per discussione Johann Haag
Danke für den Hinweis,
das hatte ich übersehen. Ich habe das Verzeichnis entfernt.
Respektlos finde ich lediglich den Umgang mit der gesellschaftlichen
Ressource Freiwilligenarbeit.

Grüsse Johann

Am So., 14. Juni 2020 um 21:50 Uhr schrieb grubernd :

> On 14.06.20 10:08, Johann Haag wrote:
> > Verzeichnis historische Hausnummern in Österreich weiter verfügbar.
>
>
> Genauso wie dein persönliches Adressbuch - das nichts in einem
> öffentlich verlinkten Dokument zu suchen hat.
>
> http://addresshistory.hxg.at/
> --> Verzeichnis der TALK Teilnehmer
> --> TALK dass Telefonbuch.xslx
>
> Es handelt sich dabei nicht - wie in dem xslx geschrieben - um eine
> Sicherheitslücke von TALK sondern um ein ziemlich respektloses Umgehen
> mit personenbezogenen Daten _deinerseits_.
>
> Ich fordere dich hiermit auf meinen Eintrag dort zu entfernen.
>
>
> grüsse,
> grubernd
>
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
>


-- 
Elektronikermeister Johann Haag
Innsbruckerstraße 42
6380 St. Johann in Tirol
ÖSTERREICH
Tel: +43 664/174 7414
Mailto:johannh...@hxg.at
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at