Re: [talk-cz] jak změnit barvu turistické trasy? (zní to triviálně, ale není)

[Ondřej Suchý]

Díky, vaše příspěvky mi pomohly se v tom zorientovat. Nakonec je to
jednoduché, vytvořil jsem novou relaci jako zelenou turistickou trasu
 (červenou přejmenovat
nešlo, tu už někdo smazal). Do mezinárodní trasy jsem nezasahoval, všiml
jsem si, že není totožná se žlutou KČT.

Hezký den, Ondra


-- 
Ondřej Suchý
videotip: Efektivnější porady nejen z karantény

m: +420 777 103 944, w: Tealmakers  + Prázdninová
škola Lipnice 
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-us] Underground railways, indoor mapping, and overlapping features

[Minh Nguyen]

Vào lúc 10:28 2020-05-05, Michael Reichert đã viết:

Using the same nodes (like mapping to adjacent landuse polygons) breaks
routing because routing engines would allow trains to switch between the
levels. Using duplicated nodes at the same location is likely to trigger
quality assurance services and therefore mappers trying to "repair" it
by merging them. Using two identical geometries in straight sections
with nodes at different locations, will likely provoke the same as
duplicated nodes.


Just as a double-decker bridge requires layer tags on each deck, so 
would a double-decker subway tunnel, whether the ways are coincident or 
offset by some arbitrarily small amount. Adding layer tags, as suggested 
in [1], would likely suppress any validator warnings about coincident 
ways. But it's true that mappers could still be confused by coincident 
ways if editors don’t provide intuitive ways to navigate among them.



Regarding option 2: GraphHopper assembles its routing graph by relying
on the node IDs in OSM. It would not suffer from using this option but I
doubt that it is safe for the future. If OSM adopts to drop its 64 bit
node IDs in favour of the location (32 bit latitude + 32 bit longitude),
such cases will cause difficulties.


This is an intriguing notion I had not come across before. Has it ever 
been seriously considered? It seems to me that distinguishing nodes only 
by their coordinates would be tantamount to merging all coincident nodes 
everywhere, which we probably would never allow as part of a mechanical 
edit, much less a history-less database schema update. (For one thing, 
everyone who dislikes joining borders to roadways would be appalled to 
see just about every CDP boundary consistently joined that way.)


[1] https://lists.openstreetmap.org/pipermail/talk-us/2020-May/020015.html

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-br] Nova proposta de classificação viária - Votação encerrada

[santamariense]

> Quando você iniciou a votação, você citou as regras do seguinte artigo
> em inglês como norteadoras do processo, em particular em relação ao
> período da votação (2 semanas):
> https://wiki.openstreetmap.org/wiki/Proposal_process

Sim, busquei alguma diretriz de votação que já estivesse em uso no
OSM, e foi ela que encontrei para usar como norteadora do processo.

> Neste mesmo artigo, diz que a proposta deve ter no mínimo 8 votos
> unânimes a favor para ser considerada aprovada, ou 10 com pelo menos
> 74% de aprovação, e que se isso não for atingido no período de 2
> semanas, o período de votação deveria ser estendido. Essas regras
> também vão valer? Me parece que o ideal seria estender o período de
> votação para tentar obter mais votos.
>

Esse processo no qual me baseei parece ser usado para tomada de
decisão acerca da criação de novas tags a nível mundial. Imagino que
como a nossa votação é a nível nacional, a quantidade mínima de votos
exigidos poderia ser menor. A mesma passagem do texto cita algo como
que outros fatores poderiam ser considerados, como o fato de já estar
em uso, o que não deixa de ser o caso em parte do que já está
classificado.

Penso ainda que essa exigência de mínimo de quorum seja para evitar
que grupos isolados criem tags por conta própria sem que outros tomem
conhecimento, o que eu concordo que deva ocorrer. No nosso caso de
votação da classificação viária, ela foi amplamente divulgada,
inclusive em grupos do Telegram, onde o pessoal parece se concentrar
tanto a nível nacional como a nível estadual. Logo, divulgado foi, e
portanto a maior parte do pessoal na verdade se abstém, só que sem
registrar votos.

Fica mais coerente com a realidade sobre que está sendo votado que,
para a aprovação, a maioria simples decida, já que é uma discussão a
respeito do que já está em uso e que sempre foi um assunto polêmico.

Mas enfim, acho justo que o prazo seja prorrogado por uma vez já que
foi pedido por membro diretamente envolvido nas discussões. A pedido e
para tentar obter mais votos, sugiro uma prorrogação de prazo por mais
2 semanas, encerrando o prorrogação de prazo em 29 de maio de 2020.
Nesse meio tempo o pessoal pode continuar a sugerir mudanças no texto,
bem como fazer seus testes aplicando a metodologia para tomar a
decisão do seu voto.

Creio que a maioria conheça o grupo de classificação de vias, mas caso
não conheça, junte-se a nós em
https://telegram.me/osm_classificacao_vias para debater o assunto.

O que acha(m)?

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

Re: [OSM-talk-fr] Point d'apport volontaire, point de collecte, point de regroupement

[osm . sanspourriel]

Le 15/05/2020 à 22:39, deuzeffe - opensm@deuzeffe.org a écrit :


Donc, si on essaie de résumer pour donner à Vincent une réponse
claire pour une première étape, ça donne ?

Et ton esprit de synthèse propose ? ;D

Son esprit de synthèse dispose^^.


Existe-t-il un tag qui décrit la réalité (genre amenity=waste_disposal
mais en plus gros) ?

Oui ? -> On l'utilise.
Non ? -> On en crée un (un gros, donc).

S'il faut raffiner (colonne, support, couleur, toussa), c'est dans un
2e temps. Non ?


J'en sens motivés pour proposer un changement de clé.

Je disais à Jérôme S. en message privé :

/Finalement collect n'est peut-être pas mal : on collecte le verre comme
on collecte l'amiante. Enfin pas exactement j'espère pour l'amiante !
/

/collecting_centre, collecting_station ?/

Car point d'apport volontaire, point de regroupent de "poubelles" ou
déchèterie, on collecte des matériaux, recyclables ou non.

Ce n'est ni un terme ésotérique (du jargon) ni un terme chargé sur la
partie aval (recyclage, enfouissement, incinération) mais un terme neutre.

Il semble possible de faire une proposition simple, à soumettre à
l'international. Portant donc juste sur cette clé majeure (avec mise à
jour des sous-clés si nécessaire).

De plus je vois que depuis David parle de 2 services qui ont comme point
commun de s'appeler collecte.

Bons soins David, mais tu vas avoir besoin d'années pour apprendre OSM
(on en apprend tous les jours). Notamment que pour changer une clé
largement utilisée c'est assez coton.

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

Re: [OSM-talk-fr] Evolution des règles pour les plages et la ligne de côte (limites des fleuves)

[osm . sanspourriel]

Bonjour,

le trait de côte en zone "normale" état trop simple, parlons maintenant
des limites fleuves/rivières.

TL;DR : prendre comme ailleurs la limite PMVE, la LTM étant un indice.
En distinguant les deux on évite les conflits d'édition à la con style
Rio Del Plata.

A priori pour paraphraser Jérôme : c'est simple, le DPM s'arrête à la
LTM, ça tombe bien c'est la LTM qui a été utilisée historiquement en
France... mais le DPM n'est pas le trait de côte.

Et pour paraphraser Yves, maintenant la traduction :

DPM = Domaine Public Maritime, à partir de là, le Préfet Maritime dit
aux Préfets Départementaux d'aller jouer ailleurs (*).

LTM = Limite Transversale de la Mer, ça sert aussi à déterminer si une
commune est une commune littorale ou pas, ce qui change pas mal de
règles d'urbanisme. C'est d'ailleurs ainsi que j'en ai pris
connaissance, trouvé un jeu de données
 et
que Thomas a trouvé la couche correspondante

au SHOM.

Sauf erreur Djo Man et nous deux sommes d'accord pour trouver la donnée
trop spécifique.

Ça permet de savoir pourquoi Landerneau est une commune littorale et pas
Quimperlé alors que les deux communes voient en aval le niveau varier en
fonction de la marée : Landerneau

est coupé en deux au niveau de L'Élorn
 Maritime dite rivière de
Landerneau alors que même à l'embouchure de la Laïta

(Ellé Maritime ou rivière de Quimperlé), les communes de Clohars-Carnoët
et de Guidel se touchent.

Donc on a des communes tracées en fonction des limites DPM/LTM, c'est
bon on n'y touche pas (sauf exception, merci Djo man !).

De plus les jeux de données sont incohérents. Selon le jeu de données de
data.gouv.fr, la limite pour la Laïta c'est l'embouchure mais selon
data.shom.fr c'est grosso modo Kerulo
...
entre Quimperlé et l'embouchure et la limite où l'on a naturellement
tendance à dire que c'est une rivière (.

Comme pour l'Odet

(rivière de Quimper), Thomas a fait remonter le trait de côte à une
marée de 95 ou 120 (comme les villes ont des quais à ces endroits, le
trait de côte est sensiblement le même).

Pour l'Odet il y a aussi incohérence sauf que là c'est le SHOM qui coupe
au niveau de l'embouchure
 et
data.gouv.fr remonte jusqu'au pont sud de Quimper.

Je dis data.gouv.fr mais le jeu de données est produit par... le SHOM.
Sachant que le trait semble issu... d'OpenStreetMap. En effet j'ai
regardé l'Aulne. L'Aulne Maritime ou rivière de Châteaulin commence au
niveau d'une écluse.
C'est le trait de côte.

data.gouv.fr donne comme LTM le Pont de Terenez : c'est la limite
communale telle qu'indiquée dans OpenStreetMap. Or d'après le cadastre
et data.shom.fr, la bonne limite est le Passage (un peu en aval, lieu
historique de passage).

Donc prendre la LTM est douteuse.

Il me semble au moins pour la Bretagne logique d'avoir une limite aux
marées de 95 éventuellement de 120, indépendamment de la LTM (mais
forcément en amont de la LTM si différente).

En effet cette partie est nommée XX maritime (Ellé Maritime=Laïta, Aulne
Maritime, Élorn Maritime).

Djo Man : pour la Vilaine le DPM vient bien jusqu'à Redon selon le
cadastre. Donc c'est sûrement historique (avant la construction du
barrage d'Arzal) mais la LTM actuelle

selon le SHOM est... l'embouchure de la Vilaine. En clair : le trait de
côte est bon, les limites des communes fausses mais je ne sais si c'est
de Redon à Arzal ou d'Arzal à l'embouchure.

Jean-Yvon

(*) Pour un terrien, il est moins dangereux de mettre conjoints et
enfants dans un même bateau. Pour un marin il vaut mieux avoir deux
personnes expérimentées même si elles ne sont pas de la même famille.

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

Re: [OSM-talk-be] privacy ed

[Marc Gemis]

Afaik,  Belgium changed the law  one or two years ago and you can now
publish pictures of art and buildings without problems.  Wikimedia changed
its policy for such pictures at that moment

m

Op vr 15 mei 2020 22:51 schreef Sander Deryckere :

> Taking a picture is usually not illegal indeed. But sharing it in many
> cases is. Next to the privacy regulations already mentioned, people can ask
> to take pictures of their property offline on Google Streetview.
>
> Google certainly has a good legal team, and blurring those pictures does
> cost some money. So there must be a good reason why they comply to the
> request (as opposed to blurring of areal imagery of military sites, which
> they refused for many years).
>
> And in Belgium, most buildings even have copyright on them: the architect
> who designed the building had complete copyright, including on any pictures
> taken from the roadside. A famous example of this is that spreading
> pictures of the Atomium is forbidden without paying a license fee.
>
> Luckily, most of these laws require the "victim" to request to take it
> offline. Certainly if you make no money from it, it's very unlikely this
> will have legal consequences. If there are legal consequences, they're even
> more likely for the platform hosting the images instead of the uploader.
>
> So if you just use common sense and blur faces and license plates,
> everything should be ok.
>
> Op vr 15 mei 2020 20:33 schreef Jo :
>
>> Not only their faces, also license plates. And if you're doing it
>> manually maybe also stickers with recognisable information.
>>
>> Jo
>>
>> On Fri, May 15, 2020, 19:38 Marc Gemis  wrote:
>>
>>> Hello,
>>>
>>> I see no difference between contributing to OpenStreetMap via JOSM and
>>> iD or StreetComplete.
>>> Mapping a house, street, waste bin, etc. will not break any privacy.
>>> We do not map the names of the inhabitants of a house. Mapping items
>>> from someone's garden based on aerial imagery might be on the
>>> borderline of what is allowed. However, I do map sheds, ponds and
>>> swimming pools.
>>>
>>> Taking pictures of people is not a problem, it's what you do with them
>>> afterwards that is important. If you use the image yourself and map
>>> the things you see on them from your PC, it doesn't matter that there
>>> are people.
>>> If you post the image on a public website (as you do via
>>> StreetComplete), you have to make sure that there are no people or
>>> that their faces are blurred (e.g. uploading to Mapillary is OK I
>>> think).
>>>
>>> Of course, you cannot enter private grounds.
>>>
>>> On Thu, May 14, 2020 at 3:49 PM wbrt  wrote:
>>> >
>>> > Hello,
>>> >
>>> > a question about privacy of people in general (not the mapper) (in
>>> Belgium)
>>> >
>>> > when contributing using for example streetcomplete:
>>> https://github.com/westnordost/StreetComplete
>>> > answering the questions, i suppose this is ok juridical?
>>> >
>>> > when taking pictures to make it clear for the mappers,
>>> > i guess this also ok, as long as people are not recognizable in it?
>>> >
>>> > or am i wrong?
>>> > and can you get in trouble for contributing to openstreetmap?
>>> >
>>> > The info i found:
>>> >
>>> https://wiki.openstreetmap.org/wiki/Limitations_on_mapping_private_information
>>> >
>>> > kr
>>> > ___
>>> > 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
>>>
>> ___
>> 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
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

[Talk-it] Buoni Spesa Covid & tagging

[Rossella Di Bari]

Ciao Lista, buonasera a tutti.
Sottopongo alla vostra attenzione il problema del tagging dei Buoni
Spesa erogati
dai Comuni a supporto delle famiglie in disagio economico a causa del
Covid. Diversi sono gli stati europei che hanno adottato misure
straordinarie riconducibili ai nostri Buoni Pasto per l'acquisto di beni di
prima necessità, ma non ne trovo traccia in osm.

Attualmente le pagine Wiki dedicate al Covid19 riportano tag sulla consegna
a domicilio, l'asporto, il numero massimo di avventori a cui è consetito
l'accesso, campo descrttivo specifico per il virus e poco altro, ma sui
metodi di pagamento ad hoc, correggetemi se sbaglio, nessuna menzione.

Facendo una ricerca su taginfo [1] avrei trovato
*payment:service_vouchers:covid19* ma è utilizzato solo 5 volte e non ha
una pagina wiki.

Rimanendo in un contesto più generale, avremmo a disposizione:

   - *payment:meal_vouchers* che però nascono come moneta di scambio per la
   somministrazione di un pasto, pertanto li escluderei;
   - un più generico *description:payment=** indicando ad esempio
   *food_voucher*;
   - oppure la possibilità di appoggiarci a tag che si riferiscono a
   provvedimenti governativi [2] che però col Covid hanno poco a che fare,
   tipo *payment:snap.*

Se dovessi scegliere, pensando al dato strutturato, probabilmente
utilizzerei la specifica del covid, e perchè no, accompagnato al
service_voucher [3], quale strumento finanziario di un ente pubblico volto
a supportare le necessità essenziali dei più bisognosi.

Che dite? Vale la pena disperdere un dato che (speriamo) non avrà tempo di
consolidarsi col covid?
Grazie

[1]
https://taginfo.openstreetmap.org/keys/payment%3Aservice_vouchers%3Acovid19#map
[2]
https://wiki.openstreetmap.org/wiki/Key:payment#Government_assistance_programs
[3] https://en.wikipedia.org/wiki/Service_voucher
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-us] admin_level and COGs, MPOs, SPDs, Home Rule

[stevea]

Due to some discussion between Minh, Martin and I on the Talk page of United 
States admin_level, we seemed to agree that restoring admin_level=6 to 
Connecticut counties is reasonable.  I did so, and made minor changes to the 
wiki to outline why.

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

Re: [Talk-us] admin_level and COGs, MPOs, SPDs, Home Rule

[Frederik Ramm]

Hi,

On 5/15/20 23:12, Joseph Eisenberg wrote:
> I also think that it makes sense to have counties as admin_level=6 in
> Connecticut and Rhode Island, if local people still know their counties
> and the governments still recognize them for geographic, statistical and
> some other legal purposes.

I didn't even want to weigh in on the discussion, mine was more a
comment on process. You shouldn't delete something that has been there
for 10 years and then say "btw let's discuss" ;)

Bye
Frederik

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

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

Re: [Talk-us] admin_level and COGs, MPOs, SPDs, Home Rule

[Joseph Eisenberg]

I also think that it makes sense to have counties as admin_level=6 in
Connecticut and Rhode Island, if local people still know their counties and
the governments still recognize them for geographic, statistical and some
other legal purposes.

-- Joseph Eisenberg

On Fri, May 15, 2020 at 1:42 PM Frederik Ramm  wrote:

> (3d attempt, apologies if you should get this several times)
>
> Hi,
>
> I am tempted to revert stevea's removal of the admin_level=6 from
> counties (where this was in place for the last 10 years or so, eg
> https://www.openstreetmap.org/relation/1839542/history) until a
> consensus is found that they should actually be removed.
>
> It is clear that there is a need for discussion, and I feel that such a
> discussion should take place *before* a change is made and not *after*.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> 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] Confini codice postanale

[Francesco Ansanelli]

Non è necessario che si arrivi al revert... E sicuramente non metto in
dubbio la tua buona fede.
Suggerisco di creare una pagina sul wiki in modo che ci sia una
testimonianza del tuo lavoro, puoi seguire questa come traccia:

https://wiki.openstreetmap.org/wiki/Friuli-Venezia_Giulia/Import_Civici_FVG

Che dici?

Francesco

Il ven 15 mag 2020, 22:41 Luigi Scuotto  ha
scritto:

> Scusa Francesco ma dici che questo non e il modo di porsi mi dici in che
> modo devo dire di revertare tutto quello che ho fatto?
> Si continua a discutere che non era il modo di importare dati. Come detto
> non mi sono letto un accidenti dei regolamenti che ci sono.
> Come detto se avessi saputo non lo avrei fatto non mi fa piacere mettere
> in difficoltà gli altri per dei miei errori.
> Sono andato a leggere una parte di quello che mi e stato suggerito prima
> di importare, ed effettivamente avevo detto che forse ci ripensavo, adesso
> doto ver letto solo una parte ti dico che non li importavo di sicure.
> Gigi
>
> Il giorno ven 15 mag 2020 alle ore 22:15 Francesco Ansanelli <
> franci...@gmail.com> ha scritto:
>
>> Buonasera Luigi,
>>
>> Perdonami, ma questo non è il modo giusto di porsi...
>> Nessuno ti sta attaccando, per favore, evitiamo di stare sulla difensiva.
>> Se lo hai già detto, lo ricopi su una pagina sul wiki e siamo tutti
>> contenti, in futuro, partirai dal wiki e farai l'import dopo e andrà bene.
>> 
>>
>> Francesco
>>
>> Il ven 15 mag 2020, 21:59 Luigi Scuotto  ha
>> scritto:
>>
>>> Andrea.
>>> Come già detto, in precedenza.
>>> 1 non saprei che scrivere, già detto come ho fatto
>>> 2 evitiamo tutte queste discussioni facciamo un revert di tutto e non
>>> se.ne parla più.
>>> Quando magari i dati si potranno importare lo farà qualcuno che si è
>>> letto il regolamento.
>>> Gigi
>>>
>>>
>>>
>>> Il Ven 15 Mag 2020, 18:06 Andrea Musuruane  ha
>>> scritto:
>>>
 Ciao,

 On Fri, May 15, 2020 at 1:37 PM Francesco Ansanelli <
 franci...@gmail.com> wrote:

> Buongiorno Luigi,
>
> devo dare anche io ragione a Cascafico, per gli import c'è tolleranza
> zero e vanno discussi su una mailing list a parte (internazionale in 
> lingua
> inglese).
> Io sono il primo a essere contro la procedura attuale, ma non ci
> possiamo fare nulla proprio nulla...
> Se qualcuno si dovesse lamentare perché il diritto sui generis
> (proprietà intellettuale del dato) non è rispettato, OSM dovrebbe mettersi
> degli avvocati ed, in ogni caso, se qualcuno si dovesse lamentare del tuo
> operato con il DWG (anche senza esserne titolare) si rischia di perdere
> tutto il tuo lavoro (revert e ban).
> Cascafico ha seguito molto da vicino diversi import e ti sa
> sicuramente consigliare bene, ma non ti può autorizzare da solo e, senza 
> un
> progetto pubblico in cui si spiega la procedura, non lo farà nessun altro.
>

 Francesco ha perfettamente ragione. Come ribadito più volte, per gli
 import bisogna seguire le apposite guidelines:
 https://wiki.openstreetmap.org/wiki/Import_guidelines

 Queste dovrebbero essere seguite fin dal momento in cui si pianifica un
 import. Noi ti stiamo chiedendo di rimediare e di documentare quanto hai
 già fatto prima di continuare. Non mi sembra un dramma. Certo che se
 continuassi ad evitare la cosa, diventerei anche io favorevole a un revert.

 Ciao,

 Andrea

 ___
 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
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-be] privacy ed

[Sander Deryckere]

Taking a picture is usually not illegal indeed. But sharing it in many
cases is. Next to the privacy regulations already mentioned, people can ask
to take pictures of their property offline on Google Streetview.

Google certainly has a good legal team, and blurring those pictures does
cost some money. So there must be a good reason why they comply to the
request (as opposed to blurring of areal imagery of military sites, which
they refused for many years).

And in Belgium, most buildings even have copyright on them: the architect
who designed the building had complete copyright, including on any pictures
taken from the roadside. A famous example of this is that spreading
pictures of the Atomium is forbidden without paying a license fee.

Luckily, most of these laws require the "victim" to request to take it
offline. Certainly if you make no money from it, it's very unlikely this
will have legal consequences. If there are legal consequences, they're even
more likely for the platform hosting the images instead of the uploader.

So if you just use common sense and blur faces and license plates,
everything should be ok.

Op vr 15 mei 2020 20:33 schreef Jo :

> Not only their faces, also license plates. And if you're doing it manually
> maybe also stickers with recognisable information.
>
> Jo
>
> On Fri, May 15, 2020, 19:38 Marc Gemis  wrote:
>
>> Hello,
>>
>> I see no difference between contributing to OpenStreetMap via JOSM and
>> iD or StreetComplete.
>> Mapping a house, street, waste bin, etc. will not break any privacy.
>> We do not map the names of the inhabitants of a house. Mapping items
>> from someone's garden based on aerial imagery might be on the
>> borderline of what is allowed. However, I do map sheds, ponds and
>> swimming pools.
>>
>> Taking pictures of people is not a problem, it's what you do with them
>> afterwards that is important. If you use the image yourself and map
>> the things you see on them from your PC, it doesn't matter that there
>> are people.
>> If you post the image on a public website (as you do via
>> StreetComplete), you have to make sure that there are no people or
>> that their faces are blurred (e.g. uploading to Mapillary is OK I
>> think).
>>
>> Of course, you cannot enter private grounds.
>>
>> On Thu, May 14, 2020 at 3:49 PM wbrt  wrote:
>> >
>> > Hello,
>> >
>> > a question about privacy of people in general (not the mapper) (in
>> Belgium)
>> >
>> > when contributing using for example streetcomplete:
>> https://github.com/westnordost/StreetComplete
>> > answering the questions, i suppose this is ok juridical?
>> >
>> > when taking pictures to make it clear for the mappers,
>> > i guess this also ok, as long as people are not recognizable in it?
>> >
>> > or am i wrong?
>> > and can you get in trouble for contributing to openstreetmap?
>> >
>> > The info i found:
>> >
>> https://wiki.openstreetmap.org/wiki/Limitations_on_mapping_private_information
>> >
>> > kr
>> > ___
>> > 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
>>
> ___
> 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-us] admin_level and COGs, MPOs, SPDs, Home Rule

[Frederik Ramm]

(3d attempt, apologies if you should get this several times)

Hi,

I am tempted to revert stevea's removal of the admin_level=6 from
counties (where this was in place for the last 10 years or so, eg
https://www.openstreetmap.org/relation/1839542/history) until a
consensus is found that they should actually be removed.

It is clear that there is a need for discussion, and I feel that such a
discussion should take place *before* a change is made and not *after*.

Bye
Frederik

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

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

Re: [Talk-it] Confini codice postanale

[Luigi Scuotto]

Scusa Francesco ma dici che questo non e il modo di porsi mi dici in che
modo devo dire di revertare tutto quello che ho fatto?
Si continua a discutere che non era il modo di importare dati. Come detto
non mi sono letto un accidenti dei regolamenti che ci sono.
Come detto se avessi saputo non lo avrei fatto non mi fa piacere mettere in
difficoltà gli altri per dei miei errori.
Sono andato a leggere una parte di quello che mi e stato suggerito prima di
importare, ed effettivamente avevo detto che forse ci ripensavo, adesso
doto ver letto solo una parte ti dico che non li importavo di sicure.
Gigi

Il giorno ven 15 mag 2020 alle ore 22:15 Francesco Ansanelli <
franci...@gmail.com> ha scritto:

> Buonasera Luigi,
>
> Perdonami, ma questo non è il modo giusto di porsi...
> Nessuno ti sta attaccando, per favore, evitiamo di stare sulla difensiva.
> Se lo hai già detto, lo ricopi su una pagina sul wiki e siamo tutti
> contenti, in futuro, partirai dal wiki e farai l'import dopo e andrà bene.
> 
>
> Francesco
>
> Il ven 15 mag 2020, 21:59 Luigi Scuotto  ha
> scritto:
>
>> Andrea.
>> Come già detto, in precedenza.
>> 1 non saprei che scrivere, già detto come ho fatto
>> 2 evitiamo tutte queste discussioni facciamo un revert di tutto e non
>> se.ne parla più.
>> Quando magari i dati si potranno importare lo farà qualcuno che si è
>> letto il regolamento.
>> Gigi
>>
>>
>>
>> Il Ven 15 Mag 2020, 18:06 Andrea Musuruane  ha
>> scritto:
>>
>>> Ciao,
>>>
>>> On Fri, May 15, 2020 at 1:37 PM Francesco Ansanelli 
>>> wrote:
>>>
 Buongiorno Luigi,

 devo dare anche io ragione a Cascafico, per gli import c'è tolleranza
 zero e vanno discussi su una mailing list a parte (internazionale in lingua
 inglese).
 Io sono il primo a essere contro la procedura attuale, ma non ci
 possiamo fare nulla proprio nulla...
 Se qualcuno si dovesse lamentare perché il diritto sui generis
 (proprietà intellettuale del dato) non è rispettato, OSM dovrebbe mettersi
 degli avvocati ed, in ogni caso, se qualcuno si dovesse lamentare del tuo
 operato con il DWG (anche senza esserne titolare) si rischia di perdere
 tutto il tuo lavoro (revert e ban).
 Cascafico ha seguito molto da vicino diversi import e ti sa sicuramente
 consigliare bene, ma non ti può autorizzare da solo e, senza un progetto
 pubblico in cui si spiega la procedura, non lo farà nessun altro.

>>>
>>> Francesco ha perfettamente ragione. Come ribadito più volte, per gli
>>> import bisogna seguire le apposite guidelines:
>>> https://wiki.openstreetmap.org/wiki/Import_guidelines
>>>
>>> Queste dovrebbero essere seguite fin dal momento in cui si pianifica un
>>> import. Noi ti stiamo chiedendo di rimediare e di documentare quanto hai
>>> già fatto prima di continuare. Non mi sembra un dramma. Certo che se
>>> continuassi ad evitare la cosa, diventerei anche io favorevole a un revert.
>>>
>>> Ciao,
>>>
>>> Andrea
>>>
>>> ___
>>> 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-fr] Point d'apport volontaire, point de collecte, point de regroupement

[deuzeffe]

Le 15/05/2020 à 01:55, Yves P. a écrit :



  * DASRI : Déchets d'activités de soins à risques infectieux

et assimilés -> DASRIA. Pas à disposition du grand public, donc.

Certes… mais les professionnels de santé doivent parfois s'y rendre pour jeter 
leur bacs jaunes ;)


De ce que j'ai compris, c'est le collecteur qui vient-t-a eux et non 
l'inverse. Un genre de Lagardère (d'il y a très très très longtemps).



Donc, si on essaie de résumer pour donner à Vincent une réponse claire pour une 
première étape, ça donne ?

Et ton esprit de synthèse propose ? ;D


Existe-t-il un tag qui décrit la réalité (genre amenity=waste_disposal 
mais en plus gros) ?


Oui ? -> On l'utilise.
Non ? -> On en crée un (un gros, donc).

S'il faut raffiner (colonne, support, couleur, toussa), c'est dans un 2e 
temps. Non ?


--
deuzeffe - carabiniera

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

Re: [talk-cz] Přírodní parky

[Jan Macura]

Ahoj

Možná by se mohly hodit reference z tohohle článku na WP:
https://cs.wikipedia.org/wiki/P%C5%99%C3%ADrodn%C3%AD_parky_v_%C4%8Cesku

On Fri, 15 May 2020 at 16:32, Miroslav Suchy  wrote:

> FYI
> https://lists.openstreetmap.org/pipermail/talk-cz/2018-January/018328.html
>

Dobrá připomínka, ale přírodní parky tam stejně nejsou, pokud dobře koukám.

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

[Talk-br] RES: Digest Talk-br, volume 140, assunto 15

[Reinaldo Neves]

 período de votação da nova proposta de
> classificação viária. Votaram 5 mapeadores, onde 3 concordaram, sendo
> que 1 fez algumas ressalvas; 1 discordou da proposta, fazendo alguns
> apontamentos, ainda dentro do conceito funcional da rodovia, os quais
> podem ir sendo explorados e discutidos; E 1 se absteve na votação,
> embora também concorde com o conceito funcional. Dos que votaram,
> portanto, mais de 50% concorda com a proposta apresentada, sendo
> considerada aprovada.
>
> Alguns comentários foram feitos que poderiam levar a votar casos
> pontuais da proposta, e não ficou claro para mim se teria algo a ser
> votado desde já. se você tiver algo pontual a ser votado, manifeste-se
> a qualquer momento pois ... Não menos importante, lembro aqui que o
> texto da regra pode ir sendo modificado no avançar do mapeamento
> conforme algumas questões pontuais forem surgindo, sendo discutidas e
> votadas como de praxe.
>
> Com a aprovação dessa proposta, a mesma terá seu texto ajustado para
> excluir o que está tachado (foi excluido do texto original ao longo da
> discussão), excluir a cor verde de parte do texto (foi incluido), e
> modificar parte do texto de "proposta" para "regra", ou outra sugestão
> que queiram dar.
>
> Também serão atualizadas paginas relacionadas a classificação viária
> que tratarem sobre o tema, na maior parte dos casos apenas com a
> inclusão de uma nota no topo da página, e sempre que possível linkando
> a página da atual regra de mapeamento. Paginas a serem atualizadas:
>
> A -
> https://wiki.openstreetmap.org/wiki/Pt:How_to_map_a#Classifica.C3.A7.C3.A3o_de_vias
> B -
> https://wiki.openstreetmap.org/wiki/Brazil/Classifica%C3%A7%C3%A3o_de_vias
> C - https://wiki.openstreetmap.org/wiki/Proposta_Top_05_BR_%2B_1
> D - https://wiki.openstreetmap.org/wiki/Pt:Key:highway
> E - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dmotorway
> F - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dtrunk
> G - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dprimary
> H - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dsecondary
> I - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dtertiary
> J - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dunclassified
> K - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dresidential
> L -
> https://wiki.openstreetmap.org/wiki/Pt:Highway:International_equivalence
> M - https://wiki.openstreetmap.org/wiki/Highway:International_equivalence
>
> Assim que as modificações forem feitas, a diferença entre antes e
> depois será apresentada num próximo e-mail, por meio de link para wiki
> contendo o que foi modificado.
>
>
>
> --
>
> Subject: Legenda do Digest
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
>
> --
>
> Fim da Digest Talk-br, volume 140, assunto 14
> *
>
-- Próxima Parte --
Um anexo em HTML foi limpo...
URL: 
<http://lists.openstreetmap.org/pipermail/talk-br/attachments/20200515/f06a18c5/attachment-0001.htm>

--

Message: 2
Date: Fri, 15 May 2020 14:13:51 +
From: Thierry Jean 
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br]  Nova proposta de classificação viária -
Votação encerrada
Message-ID:



Content-Type: text/plain; charset="iso-8859-1"

Concordo: Não votei antes por não me sentir capaz de entrar a fundo nas 
considerações técnicas da proposta. Entretanto, sei por ter conversado com 
Anderson (Santamariense) que esta proposta vai melhorar a navegação para 
pessoas que usam os navegadores em diferentes países, deixando a navegação no 
Brasil, harmonizada com a de outros países. Também, apesar de isto não ser um 
objetivo em si, creio que a visualização do mapa em níveis sucessíveis de zoom, 
permitindo mostrar primeiro a malha mais importante para navegação e 
sucessivamente as outras estradas e ruas, é muito importante para que o mapa 
seja considerado "organizado" pelos usuários. Os "concorrentes" fazem assim e é 
normal que OSM se comporte da mesma maneira.

Thierry Jean
M. +55 11 99607 1319




De: santamariense 
Enviado: quinta-feira, 14 de maio de 2020 19:03
Para: talk-br 
Assunto: [Talk-br] Nova proposta de classificação viária - Votação encerrada

Registro aqui a finalização do período de votação da nova proposta de
classificação viária. Votaram 5 mapeadores, onde 3 concordaram, sendo
que 1 fez algumas ressalvas; 1 discordou da proposta, fazendo alguns
apontamentos, ainda dentro do conceito funcional da rodovia, os quais
podem ir sendo explorados e discutidos; 

Re: [Talk-it] Confini codice postanale

[Francesco Ansanelli]

Buonasera Luigi,

Perdonami, ma questo non è il modo giusto di porsi...
Nessuno ti sta attaccando, per favore, evitiamo di stare sulla difensiva.
Se lo hai già detto, lo ricopi su una pagina sul wiki e siamo tutti
contenti, in futuro, partirai dal wiki e farai l'import dopo e andrà bene.


Francesco

Il ven 15 mag 2020, 21:59 Luigi Scuotto  ha
scritto:

> Andrea.
> Come già detto, in precedenza.
> 1 non saprei che scrivere, già detto come ho fatto
> 2 evitiamo tutte queste discussioni facciamo un revert di tutto e non
> se.ne parla più.
> Quando magari i dati si potranno importare lo farà qualcuno che si è letto
> il regolamento.
> Gigi
>
>
>
> Il Ven 15 Mag 2020, 18:06 Andrea Musuruane  ha
> scritto:
>
>> Ciao,
>>
>> On Fri, May 15, 2020 at 1:37 PM Francesco Ansanelli 
>> wrote:
>>
>>> Buongiorno Luigi,
>>>
>>> devo dare anche io ragione a Cascafico, per gli import c'è tolleranza
>>> zero e vanno discussi su una mailing list a parte (internazionale in lingua
>>> inglese).
>>> Io sono il primo a essere contro la procedura attuale, ma non ci
>>> possiamo fare nulla proprio nulla...
>>> Se qualcuno si dovesse lamentare perché il diritto sui generis
>>> (proprietà intellettuale del dato) non è rispettato, OSM dovrebbe mettersi
>>> degli avvocati ed, in ogni caso, se qualcuno si dovesse lamentare del tuo
>>> operato con il DWG (anche senza esserne titolare) si rischia di perdere
>>> tutto il tuo lavoro (revert e ban).
>>> Cascafico ha seguito molto da vicino diversi import e ti sa sicuramente
>>> consigliare bene, ma non ti può autorizzare da solo e, senza un progetto
>>> pubblico in cui si spiega la procedura, non lo farà nessun altro.
>>>
>>
>> Francesco ha perfettamente ragione. Come ribadito più volte, per gli
>> import bisogna seguire le apposite guidelines:
>> https://wiki.openstreetmap.org/wiki/Import_guidelines
>>
>> Queste dovrebbero essere seguite fin dal momento in cui si pianifica un
>> import. Noi ti stiamo chiedendo di rimediare e di documentare quanto hai
>> già fatto prima di continuare. Non mi sembra un dramma. Certo che se
>> continuassi ad evitare la cosa, diventerei anche io favorevole a un revert.
>>
>> Ciao,
>>
>> Andrea
>>
>> ___
>> 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] Confini codice postanale

[Luigi Scuotto]

Andrea.
Come già detto, in precedenza.
1 non saprei che scrivere, già detto come ho fatto
2 evitiamo tutte queste discussioni facciamo un revert di tutto e non se.ne
parla più.
Quando magari i dati si potranno importare lo farà qualcuno che si è letto
il regolamento.
Gigi



Il Ven 15 Mag 2020, 18:06 Andrea Musuruane  ha scritto:

> Ciao,
>
> On Fri, May 15, 2020 at 1:37 PM Francesco Ansanelli 
> wrote:
>
>> Buongiorno Luigi,
>>
>> devo dare anche io ragione a Cascafico, per gli import c'è tolleranza
>> zero e vanno discussi su una mailing list a parte (internazionale in lingua
>> inglese).
>> Io sono il primo a essere contro la procedura attuale, ma non ci possiamo
>> fare nulla proprio nulla...
>> Se qualcuno si dovesse lamentare perché il diritto sui generis (proprietà
>> intellettuale del dato) non è rispettato, OSM dovrebbe mettersi degli
>> avvocati ed, in ogni caso, se qualcuno si dovesse lamentare del tuo operato
>> con il DWG (anche senza esserne titolare) si rischia di perdere tutto il
>> tuo lavoro (revert e ban).
>> Cascafico ha seguito molto da vicino diversi import e ti sa sicuramente
>> consigliare bene, ma non ti può autorizzare da solo e, senza un progetto
>> pubblico in cui si spiega la procedura, non lo farà nessun altro.
>>
>
> Francesco ha perfettamente ragione. Come ribadito più volte, per gli
> import bisogna seguire le apposite guidelines:
> https://wiki.openstreetmap.org/wiki/Import_guidelines
>
> Queste dovrebbero essere seguite fin dal momento in cui si pianifica un
> import. Noi ti stiamo chiedendo di rimediare e di documentare quanto hai
> già fatto prima di continuare. Non mi sembra un dramma. Certo che se
> continuassi ad evitare la cosa, diventerei anche io favorevole a un revert.
>
> Ciao,
>
> Andrea
>
> ___
> 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] covid19 vert, covid19 rouge, CRO : natural=beach et cie

[osm . sanspourriel]

Bonjour,

on est bon pour ajouter sur les natural=
beach
 des
opening_hours:covid19 : c'est trop le b... pour que les gens y
retrouvent leurs petits. En effet certains noms de plages sont assez
génériques et les site indiquant les plages ouvertes ne donnent pas les
criques et il faut repérer l'arrêté préfectoral pour savoir.

Adrien, et sans doute des liens vers les règlements départementaux pour
que les gens puissent retrouver facilement les arrêtés préfectoraux.

De même pour leisure
=marina
 et
leisure
=slipway
. Et
natural =water
 + water=lake
.

hier j'ai dit une inexactitude ;-) : le terme de plage recouvre
l'ensemble des débris accumulés en bas de la côte, c'est à dire une
plage de sable mais aussi une grève (graviers ou galets) et même des
blocs de pierre. Brignogan

à marée haute, c'est toujours une plage pour la réglementation. Donc
c'est bien l'équivalent de beach. Par contre dans les arrêtés "plage"
signifie une plage de sable !

On a vu des maires demander et obtenir des ouvertures de grèves.

Les règles sont très différentes selon les départements. La préfère de
Bretagne avait demandé aux préfets bretons de se coordonner. Je ne sais
ce que ça aurait donné sans concertation.

Résultat : pour le Morbihan sur 64 communes littorales, 33 ouvrent
toutes leurs plages, les accès aux ports *sauf exceptions* sont
autorisés
.
Là au moins vous avez une commune, c'est facile.

Pour le Finistère, à l'opposé, les ouvertures ne concernent quecertaines
plages de certaines communes
.
Je n'ai pas vérifié pour les ports mais je suppose que certains sont
ouverts et d'autres pas. et actuellement l'info n'est pas en ligne sur
la page covid-19 dédiée
.
Là visiblement au moins deux communes ont jugé bon ne ne pas ouvrir les
plages proches d'un camping ou d'un bar. Allant jusqu’à inventer des
noms pour couper la plage en deux (une "plage des marais" n'existe sur
internet que depuis cet arrêté).

Et donc il est possible de faire des activités nautiques (au moins en
Manche/Atlantique : c'est le préfet maritime de Brest qui décide pour le
domaine public maritime) mais il est possible que les ports n'étant pas
ouverts vous puissiez pratiquer de jure mais pas de facto !

Sur la densité, évidemment Philippe a tort (je pense qu'il voulait dire
une rangée au moins) : ce n'est pas en agglutinant les personnes sur une
seule rangée qu'on améliore la situation, là où c'est possible c'est sur
plusieurs rangées. Mais pour le moment la serviette c'est juste le temps
de se changer pour piquer une tête (ou autres activités sportives), là
où c'est autorisé donc la question ne se posera pas avant le 1^er juin.

> je ne vois pas ce qui est choquant pour une personne agée de vouloir
s'asseoir au milieu de sa promenade.
Ce n'est pas choquant, ce n'est pas dangereux, c'est interdit. Et
suivant sur qui vous tombez vous pouvez avoir 88 ans, rentrer de la
plage à deux pas de chez vous et vous prendre une prune de 135 € parce
qu'un gendarme a décidé que pour rentrer vous n'auriez pas dû être entre
la route et la mer mais le long de la route et de l'autre côté (histoire
vécue par une connaissance). Route déserte précisons-le et ce n'est pas
un cas isolé (prune pour circulation sur une "continuité de sentier
littoral" (!) après avoir laissé le promeneur passer dans un sens). Il
est aussi des forces de l'ordre douées de bon sens.

La seule utilisation active autorisée est à ma connaissance les
activités nautiques (la plage n'étant ouverte qu'à la marche et à
l'accès aux activités nautiques).

>  Pour les ballades dans les grands parcs naturels ou dans la
campagne, il y a rarement beaucoup de monde, la distanciation est plus
facile à garantir même sans beaucoup de contrôle.

Tout dépend de la configuration et en n'ouvrant pas tout on augmente les
phénomènes de concentration.

Donc on est "bon" pour étiqueter les plages, les ports et les cales avec
des opening_hours:covid19 

Re: [Talk-br] Nova proposta de classificação viária - Votação encerrada

[Fernando Trebien]

On Thu, May 14, 2020 at 7:03 PM santamariense  wrote:
> Também serão atualizadas paginas relacionadas a classificação viária
> que tratarem sobre o tema, na maior parte dos casos apenas com a
> inclusão de uma nota no topo da página, e sempre que possível linkando
> a página da atual regra de mapeamento. Paginas a serem atualizadas:
>
> A - 
> https://wiki.openstreetmap.org/wiki/Pt:How_to_map_a#Classifica.C3.A7.C3.A3o_de_vias
> B - https://wiki.openstreetmap.org/wiki/Brazil/Classifica%C3%A7%C3%A3o_de_vias
> C - https://wiki.openstreetmap.org/wiki/Proposta_Top_05_BR_%2B_1
> D - https://wiki.openstreetmap.org/wiki/Pt:Key:highway
> E - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dmotorway
> F - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dtrunk
> G - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dprimary
> H - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dsecondary
> I - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dtertiary
> J - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dunclassified
> K - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dresidential
> L - https://wiki.openstreetmap.org/wiki/Pt:Highway:International_equivalence
> M - https://wiki.openstreetmap.org/wiki/Highway:International_equivalence

Eu entendo que o melhor tratamento para os artigos de highway=*, assim
como de qualquer outra tag, é traduzi-los do inglês de forma exata e
explicitar as diferenças ou especificidades do Brasil e de outros
países lusófonos sempre que necessário, ou, talvez ainda melhor, cada
um na sua própria seção. O prefixo Pt serve para Brasil, Portugal,
Angola, Moçambique, etc., não podemos escrever esses artigos como se
somente o sistema de classificação brasileiro estivesse valendo para
todos esses países. Isso foi combinado com essas comunidades no
momento que unificamos os prefixos Pt e Pt-br no wiki.

Entendo que os demais artigos podem ser alterados para refletir as
definições dessa nova proposta caso seja considerada aceita (ainda
tenho minhas dúvidas, conforme expus na mensagem anterior). O artigo
relativo à proposta da Top 5 no máximo teria o seu status alterado.

-- 
Fernando Trebien

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

Re: [OSM-talk-be] privacy ed

[Jo]

Not only their faces, also license plates. And if you're doing it manually
maybe also stickers with recognisable information.

Jo

On Fri, May 15, 2020, 19:38 Marc Gemis  wrote:

> Hello,
>
> I see no difference between contributing to OpenStreetMap via JOSM and
> iD or StreetComplete.
> Mapping a house, street, waste bin, etc. will not break any privacy.
> We do not map the names of the inhabitants of a house. Mapping items
> from someone's garden based on aerial imagery might be on the
> borderline of what is allowed. However, I do map sheds, ponds and
> swimming pools.
>
> Taking pictures of people is not a problem, it's what you do with them
> afterwards that is important. If you use the image yourself and map
> the things you see on them from your PC, it doesn't matter that there
> are people.
> If you post the image on a public website (as you do via
> StreetComplete), you have to make sure that there are no people or
> that their faces are blurred (e.g. uploading to Mapillary is OK I
> think).
>
> Of course, you cannot enter private grounds.
>
> On Thu, May 14, 2020 at 3:49 PM wbrt  wrote:
> >
> > Hello,
> >
> > a question about privacy of people in general (not the mapper) (in
> Belgium)
> >
> > when contributing using for example streetcomplete:
> https://github.com/westnordost/StreetComplete
> > answering the questions, i suppose this is ok juridical?
> >
> > when taking pictures to make it clear for the mappers,
> > i guess this also ok, as long as people are not recognizable in it?
> >
> > or am i wrong?
> > and can you get in trouble for contributing to openstreetmap?
> >
> > The info i found:
> >
> https://wiki.openstreetmap.org/wiki/Limitations_on_mapping_private_information
> >
> > kr
> > ___
> > 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
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] privacy ed

[Marc Gemis]

Hello,

I see no difference between contributing to OpenStreetMap via JOSM and
iD or StreetComplete.
Mapping a house, street, waste bin, etc. will not break any privacy.
We do not map the names of the inhabitants of a house. Mapping items
from someone's garden based on aerial imagery might be on the
borderline of what is allowed. However, I do map sheds, ponds and
swimming pools.

Taking pictures of people is not a problem, it's what you do with them
afterwards that is important. If you use the image yourself and map
the things you see on them from your PC, it doesn't matter that there
are people.
If you post the image on a public website (as you do via
StreetComplete), you have to make sure that there are no people or
that their faces are blurred (e.g. uploading to Mapillary is OK I
think).

Of course, you cannot enter private grounds.

On Thu, May 14, 2020 at 3:49 PM wbrt  wrote:
>
> Hello,
>
> a question about privacy of people in general (not the mapper) (in Belgium)
>
> when contributing using for example streetcomplete: 
> https://github.com/westnordost/StreetComplete
> answering the questions, i suppose this is ok juridical?
>
> when taking pictures to make it clear for the mappers,
> i guess this also ok, as long as people are not recognizable in it?
>
> or am i wrong?
> and can you get in trouble for contributing to openstreetmap?
>
> The info i found:
> https://wiki.openstreetmap.org/wiki/Limitations_on_mapping_private_information
>
> kr
> ___
> 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-fr] rendu de la mer et modèle de tag pour les cotes. Était : Evolution des règles pour les plages et la ligne de côte (zones et traits)

[Djo_man via Talk-fr]

Bonjour à tous, 

Le post initial de ce fil questionnait la justification d'une modification du 
wiki natural=beach unilatérale venant sans doute "d'en haut" pour prendre acte 
des nouvelles possibilités offertes par une reforme du rendu de la mer qui doit 
etre doublé par une reforme encore plus vaste du rendu de toutes couches d'eau 
y compris terrestres. 

https://github.com/gravitystorm/openstreetmap-carto/issues/3854

Merci Thomas pour le lien. 

En gros, le rendu de la mer est dorénavant gérée comme le reste des autres 
polygones et peut donc à ce titre acceuillir un mode de fusion avec les couches 
se trouvant en dessous. 

Ce Pull Request propose donc, carrément, d'inverser le sens d'empliement des 
couches. 

Avant et toujours maintenant la couche de mer était posée sur la carte en 
premier et les autres par dessus avec certains polygones comme tidalflat avec 
une transparence. 

Apres acceptation de ce PR, ils feraient le contraire et la couche de mer 
arriverait en dernier avec une transparence issu d'un mode de fusion avec ce 
qui se trouve en dessous (comme les calques sur photoshop). 

C'est un gros changement et comme tout gros changement les conséquences ne sont 
pas integralement anticipables. Pour décoincer ce PR, le contributeur principal 
Imagico propose de réaliser un moteur de rendu temporaire. Mais ce gros travail 
est en rade par manque de temps. 

Je trouve ce nouveau mode de fusion extrement prometteur et souple (et peut 
être un poil plus exigeant) . Cela devrait faire passer le rendu dans une autre 
monde de subtilité sans perte et donc permettrait par rebond de relancer 
l'envie de cartographier côtes, estran, zones de marais, mangroves, rivières et 
bancs de sables galets, zones intermittantes saisonnières, enfin énormément 
d'hectares d'espaces naturels sensibles.

Donc, je voudrais, ici lancer une petite hola pour les contributeurs Imagico et 
Jeisenbe pour les soutenir. 

Djo man 



Envoyé depuis mon smartphone Xperia de Sony

 osm.sanspourr...@spamgourmet.com a écrit 

>Bonjour,
>
>résumé : on a un carroyage plus qu'un code barre, mais pour donner une
>image il faut dessiner les lignes et pas les carreaux.
>
>/on a verticalement des natures de sol /(vase, sable, gravier,  galets,
>blocs, roche).
>
>avec potentiellement des couvertures (landcover ?) pour les dunes
>. Je connaissais les dunes blanches,
>grises, il faut ajouter les dunes vertes, les noires et les brunes.
>
>Typiquement on ne trouvera pas les dunes vertes dans OSM (trop mobiles :
>c'est le bas de dune comportant juste quelques plantes pionnières et le
>sable reste bien visible).
>
>/Et horizontalement du plus haut au plus bas des traits plus ou moins de
>côte/ (DPM, PMVE, 0 cartes terrestres, BMVE, 0 cartes marines, ligne de
>base) :
>
>- la limite théorique haute (pleine mer "maximale" de coefficient de
>120) correspond en théorie à la limite du domaine public maritime (DPM
>pour les intimes) et des communes. En théorie car des polders peuvent
>avoir changé la donne et placé - ou pas - des zones asséchées en zones
>terrestres,
>- la limite de trait de côté OSM (pleine mer de vive-eau moyenne de
>coefficient de 95) - PMVE,
>- la mi-marée (correspond au 0 des cartes terrestres même s'il est
>mesuré à partir de la mi-marée à Marseille) - MM,
>- la limite de basse mer de vive-eau moyenne (de coefficient de 95) -
>BMVE, c'est traditionnellement le 0 des cartes marines britanniques) !
>- la limite théorique basse (basse mer "maximale" dite astronomique, de
>coefficient de 120) correspond en zone rocheuse saillante à la ligne de
>base - ligne servant à la délimitation des zones en mer, ligne qui se
>tague boundary=administrative + boundary:type=baseline. C'est le 0 des
>cartes électroniques marines et actuellement aussi le 0 des cartes du
>SHOM et de ses équivalents britanniques et allemands.
>
>Ouf ;-).
>
>Les références sont toujours par pression atmosphérique normale et pour
>les cours d'eau avec un débit d'eau douce moyen. Et les coefficients
>calculés à partir du port de Brest. Oui une définition franco-française
>mais homogène avec les définitions internationales.
>
>95 ou 100 ? il n'y a guère de différence pratique, selon Wikipédia on
>devrait prendre 95 comme indiqué sur le wiki :
>
>*C = 95*, définit une vive-eau moyenne
>*C = 100*, définit une vive-eau équinoxiale moyenne
>
>Je serais pour ne pas découper plus que nécessaire en strates
>horizontales pour ne garder que des iso-lignes ou des isobathes :
>limites des communes, trait de côte, sans doute 0 des cartes terrestres
>et en plus 0 des cartes marines. Mais le wiki parle de BMVE et non du 0
>des cartes marines.
>
>Pour les beach (plages ou grèves - la distinction est importante puisque
>les plages sont interdites par défaut et les grèves pas sauf si elles
>servent d'accès à la mer(*)), on les met du DPM à quoi ? BMVE serait
>logique dans OSM, car on utilise PMVE. Et si quelqu'un veut mettre son

Re: [Talk-br] Nova proposta de classificação viária - Votação encerrada

[Fernando Trebien]

Quando você iniciou a votação, você citou as regras do seguinte artigo
em inglês como norteadoras do processo, em particular em relação ao
período da votação (2 semanas):
https://wiki.openstreetmap.org/wiki/Proposal_process

Neste mesmo artigo, diz que a proposta deve ter no mínimo 8 votos
unânimes a favor para ser considerada aprovada, ou 10 com pelo menos
74% de aprovação, e que se isso não for atingido no período de 2
semanas, o período de votação deveria ser estendido. Essas regras
também vão valer? Me parece que o ideal seria estender o período de
votação para tentar obter mais votos.

On Thu, May 14, 2020 at 7:03 PM santamariense  wrote:
>
> Registro aqui a finalização do período de votação da nova proposta de
> classificação viária. Votaram 5 mapeadores, onde 3 concordaram, sendo
> que 1 fez algumas ressalvas; 1 discordou da proposta, fazendo alguns
> apontamentos, ainda dentro do conceito funcional da rodovia, os quais
> podem ir sendo explorados e discutidos; E 1 se absteve na votação,
> embora também concorde com o conceito funcional. Dos que votaram,
> portanto, mais de 50% concorda com a proposta apresentada, sendo
> considerada aprovada.
>
> Alguns comentários foram feitos que poderiam levar a votar casos
> pontuais da proposta, e não ficou claro para mim se teria algo a ser
> votado desde já. se você tiver algo pontual a ser votado, manifeste-se
> a qualquer momento pois ... Não menos importante, lembro aqui que o
> texto da regra pode ir sendo modificado no avançar do mapeamento
> conforme algumas questões pontuais forem surgindo, sendo discutidas e
> votadas como de praxe.
>
> Com a aprovação dessa proposta, a mesma terá seu texto ajustado para
> excluir o que está tachado (foi excluido do texto original ao longo da
> discussão), excluir a cor verde de parte do texto (foi incluido), e
> modificar parte do texto de "proposta" para "regra", ou outra sugestão
> que queiram dar.
>
> Também serão atualizadas paginas relacionadas a classificação viária
> que tratarem sobre o tema, na maior parte dos casos apenas com a
> inclusão de uma nota no topo da página, e sempre que possível linkando
> a página da atual regra de mapeamento. Paginas a serem atualizadas:
>
> A - 
> https://wiki.openstreetmap.org/wiki/Pt:How_to_map_a#Classifica.C3.A7.C3.A3o_de_vias
> B - https://wiki.openstreetmap.org/wiki/Brazil/Classifica%C3%A7%C3%A3o_de_vias
> C - https://wiki.openstreetmap.org/wiki/Proposta_Top_05_BR_%2B_1
> D - https://wiki.openstreetmap.org/wiki/Pt:Key:highway
> E - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dmotorway
> F - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dtrunk
> G - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dprimary
> H - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dsecondary
> I - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dtertiary
> J - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dunclassified
> K - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dresidential
> L - https://wiki.openstreetmap.org/wiki/Pt:Highway:International_equivalence
> M - https://wiki.openstreetmap.org/wiki/Highway:International_equivalence
>
> Assim que as modificações forem feitas, a diferença entre antes e
> depois será apresentada num próximo e-mail, por meio de link para wiki
> contendo o que foi modificado.
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br



-- 
Fernando Trebien

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

Re: [Talk-br] Nova proposta de classificação viária - Votação encerrada

[Fernando Trebien]

Thierry, acho que seria importante colocar o seu "Concordo" lá no
wiki, para arquivamento.

On Fri, May 15, 2020 at 11:15 AM Thierry Jean  wrote:
>
> Concordo: Não votei antes por não me sentir capaz de entrar a fundo nas 
> considerações técnicas da proposta. Entretanto, sei por ter conversado com 
> Anderson (Santamariense) que esta proposta vai melhorar a navegação para 
> pessoas que usam os navegadores em diferentes países, deixando a navegação no 
> Brasil, harmonizada com a de outros países. Também, apesar de isto não ser um 
> objetivo em si, creio que a visualização do mapa em níveis sucessíveis de 
> zoom, permitindo mostrar primeiro a malha mais importante para navegação e 
> sucessivamente as outras estradas e ruas, é muito importante para que o mapa 
> seja considerado "organizado" pelos usuários. Os "concorrentes" fazem assim e 
> é normal que OSM se comporte da mesma maneira.
>
> Thierry Jean
> M. +55 11 99607 1319
>
>
>
> 
> De: santamariense 
> Enviado: quinta-feira, 14 de maio de 2020 19:03
> Para: talk-br 
> Assunto: [Talk-br] Nova proposta de classificação viária - Votação encerrada
>
> Registro aqui a finalização do período de votação da nova proposta de
> classificação viária. Votaram 5 mapeadores, onde 3 concordaram, sendo
> que 1 fez algumas ressalvas; 1 discordou da proposta, fazendo alguns
> apontamentos, ainda dentro do conceito funcional da rodovia, os quais
> podem ir sendo explorados e discutidos; E 1 se absteve na votação,
> embora também concorde com o conceito funcional. Dos que votaram,
> portanto, mais de 50% concorda com a proposta apresentada, sendo
> considerada aprovada.
>
> Alguns comentários foram feitos que poderiam levar a votar casos
> pontuais da proposta, e não ficou claro para mim se teria algo a ser
> votado desde já. se você tiver algo pontual a ser votado, manifeste-se
> a qualquer momento pois ... Não menos importante, lembro aqui que o
> texto da regra pode ir sendo modificado no avançar do mapeamento
> conforme algumas questões pontuais forem surgindo, sendo discutidas e
> votadas como de praxe.
>
> Com a aprovação dessa proposta, a mesma terá seu texto ajustado para
> excluir o que está tachado (foi excluido do texto original ao longo da
> discussão), excluir a cor verde de parte do texto (foi incluido), e
> modificar parte do texto de "proposta" para "regra", ou outra sugestão
> que queiram dar.
>
> Também serão atualizadas paginas relacionadas a classificação viária
> que tratarem sobre o tema, na maior parte dos casos apenas com a
> inclusão de uma nota no topo da página, e sempre que possível linkando
> a página da atual regra de mapeamento. Paginas a serem atualizadas:
>
> A - 
> https://wiki.openstreetmap.org/wiki/Pt:How_to_map_a#Classifica.C3.A7.C3.A3o_de_vias
> B - https://wiki.openstreetmap.org/wiki/Brazil/Classifica%C3%A7%C3%A3o_de_vias
> C - https://wiki.openstreetmap.org/wiki/Proposta_Top_05_BR_%2B_1
> D - https://wiki.openstreetmap.org/wiki/Pt:Key:highway
> E - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dmotorway
> F - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dtrunk
> G - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dprimary
> H - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dsecondary
> I - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dtertiary
> J - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dunclassified
> K - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dresidential
> L - https://wiki.openstreetmap.org/wiki/Pt:Highway:International_equivalence
> M - https://wiki.openstreetmap.org/wiki/Highway:International_equivalence
>
> Assim que as modificações forem feitas, a diferença entre antes e
> depois será apresentada num próximo e-mail, por meio de link para wiki
> contendo o que foi modificado.
>
> ___
> 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



-- 
Fernando Trebien

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

Re: [talk-cz] Přírodní parky

[r00t via talk-cz]

Ahoj,

> Hm, ten geoportalpraha vypadá moc dobře :) přírodní parky mají, nádhera.
> Jak mám oznacit ten zdroj? Je tu už nějaká konvence? Máme nějakou help
> page?
Kdyz jsem delal import trafostanic v Praze, pouzival jsem source=cz:IPRPraha
Jinak data se daji bud nahrat do JOSM a podle nich kreslit nebo primo 
importovat,
pripadne to prohnat pres QGIS pokud jsou souradnice v Krovakovi atd.
Pokud ale chces data primo importovat, budes muset jit pres OSM Import list,
nechat si to schvalit atd.

> Přijímám tipy pro další kraje :). Open data z krajů asi nikde centrálně
> agregovaná nejsou, že? Pokud vůbec existují tedy...
Podobny portal ma treba Ustecky kraj:
https://geoportal.kr-ustecky.cz/gs/
Ale pro pouziti v OSM je nejdrive potreba ziskat povoleni pro poskytovani dat
podle ODbL, coz zatim nemame. Pokud se toho ujmes, bude to jenom dobre, v tom
Geoportalu je hromada zajimavych dat :)



r00tcz


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

Re: [Talk-africa] [Trufi Association] Translation of bus route mapping documentation

[Sören Reinecke via Talk-africa]

Hi Nathalie and of course the others,nice to hear :-)Now I have two questions:1. Who wants to do the translation work? (I know one who could do this but I recommend a team of least three so the load is not too high on the shoulders of each of them. E.g. the current translation project in Spanish which we will finish soon for and with the Spanish speaking community of Latin America counts four translators.)2. Which platforms do you usea) usually for translation work orb) which you would like to use for translating (e.g. GitHub, e-mail communication (sharing docs around)The documentation is written in Markdown which allows translating without the lost of formatting. Translators see the formatting and know not to touch these e.g.**This is bold text** (en) --> **Esta el texto en negrita** (es) .Markdown is similiar to WhatsApp Codes or Telegram formatting but much more powerful.And they don't need to know how to work with Markdown but with plain text files. Markdown is a typewriting format and if needed (not for our purpose) really easy to learn.CheerioSören Reinecke alias Valor Naram Original Message Subject: Re: [Talk-africa] [Trufi Association] Translation of bus route mapping documentationFrom: Nathalie SIDIBE To: Enock Seth Nyamador CC: Jean-Marc Liotier ,talk-africa@openstreetmap.org,talk...@openstreetmap.org,talk...@openstreetmap.org,talk...@openstreetmap.org,Sören Reinecke Hi Sören, Jean-Marc, Enock Thank you Sören for the great job you are doing with Communities in terms of Public Transport Organization.My answer to your question "Does your community need a translation into French? If 
yes, I would set up the translation infrastructure and invite the onces 
wanting to do the translation work" is yes.Yes, a translation into French will be very useful for most of the West African OSM Communities and some of them including OSM Mali have been already working on Public Transport Mapping Projects.Thank you Jean-Marc, Enock for your comments and for looping in us in this emails !Best Regards,NathalieLe mer. 13 mai 2020 à 15:17, Enock Seth Nyamador  a écrit :Thanks Sören for sharing here, and JML for the comments, this post was initially shared on t.me/osmafrica where we have somehow diverse language representation and I recommended for it be posted here too, Looping in Talk-ML, CI and TG as well.Cordialement,Am Mi., 13. Mai 2020 um 15:02 Uhr schrieb Jean-Marc Liotier :On 5/12/20 10:40 PM, Sören Reinecke via Talk-africa wrote:
> I am Sören Reinecke from Trufi Association. We help communities in developing countries to organize their public transport (pt) e.g. we work with the community from Accra, Ghana. Aside from providing the pt navigation app and the infrastructure behind it (e.g. OTP server etc.) we also show mappers how to add bus routes to OpenStreetMap ( https://mapping-bus-routes.readthedocs.io/en/master/ ).
>
> My question is: Does your community need a translation into French? If yes, I would set up the translation infrastructure and invite the onces wanting to do the translation work.

Hello Sören. talk-africa@openstreetmap.org is English language only but, 
in French-speaking West Africa, the Openstreetmap contributors use 
French almost exclusively in their Openstreetmap practice. French 
translation proves valuable in including them.

cc: Nathalie Sidibe, from Openstreetmap Mali, who is fluent in English 
but very aware of how much French translations are required in her local 
community - she can give you the local perspective.



___
Talk-africa mailing list
Talk-africa@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-africa
-- -Enock
-- Nathalie SidibeHOTOSM Board MemberFounder OSM_MaliE-mail : nathalie.sid...@hotosm.orgsidibenathali...@gmail.comSkype : honorable260Twitter : @honorable_NathFacebook : Sidibe Nathalie Abraham'sTwitter  facebook    Web    donate
___
Talk-africa mailing list
Talk-africa@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-africa

Re: [Talk-it] Confini codice postale

[Andrea Musuruane]

Ciao,

On Fri, May 15, 2020 at 1:37 PM Francesco Ansanelli 
wrote:

> Buongiorno Luigi,
>
> devo dare anche io ragione a Cascafico, per gli import c'è tolleranza zero
> e vanno discussi su una mailing list a parte (internazionale in lingua
> inglese).
> Io sono il primo a essere contro la procedura attuale, ma non ci possiamo
> fare nulla proprio nulla...
> Se qualcuno si dovesse lamentare perché il diritto sui generis (proprietà
> intellettuale del dato) non è rispettato, OSM dovrebbe mettersi degli
> avvocati ed, in ogni caso, se qualcuno si dovesse lamentare del tuo operato
> con il DWG (anche senza esserne titolare) si rischia di perdere tutto il
> tuo lavoro (revert e ban).
> Cascafico ha seguito molto da vicino diversi import e ti sa sicuramente
> consigliare bene, ma non ti può autorizzare da solo e, senza un progetto
> pubblico in cui si spiega la procedura, non lo farà nessun altro.
>

Francesco ha perfettamente ragione. Come ribadito più volte, per gli import
bisogna seguire le apposite guidelines:
https://wiki.openstreetmap.org/wiki/Import_guidelines

Queste dovrebbero essere seguite fin dal momento in cui si pianifica un
import. Noi ti stiamo chiedendo di rimediare e di documentare quanto hai
già fatto prima di continuare. Non mi sembra un dramma. Certo che se
continuassi ad evitare la cosa, diventerei anche io favorevole a un revert.

Ciao,

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

Re: [OSM-talk-fr] Nouvel outil : od2osm

[osm . sanspourriel]

Bonjour, en fait Nicolas avait bien compris :
PDI = Point d'intérêt, POI en anglais
PDA = Point d'adresse

mais j'ai du retard dans mes messages, notamment sur le trait de côte !
Et je n'avais pas pris le temps de lui dire qu'il avait bien compris. Je
voulais et veux toujours essayer plus son logiciel.

Oui mettre des tickets sur github ça permet de ne pas surcharger cette
liste-ci et ne ne mettre que les points de discussion ici.

Comme la gestion (en France et ailleurs) de la fusion ou pas des
PDI/PDA. Et je crois qu'en France on préfère ne pas mélanger.

Jean-Yvon

Le 15/05/2020 à 12:12, Nicolas Bétheuil - nbethe...@free.fr a écrit :

Bonjour,

On m'avait parlé de PDI / PDA, de distance du bati pour la conflation
mais j'ai pas tout compris (même les acronymes).

On parlait du point
https://www.openstreetmap.org/node/3688329411
que j'ai créé en dev (parce qu'inexistant dans la conflation que
j'avais faite, à cause de la distance et du changement d'environnement
et que c'est pas ça que je testais)
https://master.apis.dev.openstreetmap.org/node/4319598216

L'échange en résumé
> Jean-Yvon
> Il ne me semble pas pertinent de placer le restaurant/traiteur (déjà
> Osmose va râler : restaurant ou traiteur ?) sur un point adresse.

> Moi :
> il y a beaucoup de points dans Osm ou le restaurant est à l'adresse.

> Jean-Yvon :
> Oui, à cause d'iD notamment qui incite à le faire ainsi.
> Pas forcément vigoureusement contre : il y a du positif et du négatif.
>Par contre "pourrir" la base en renforçant le cas ne va pas aider.

> Moi
> Le rapprochement se fait par tag principal : shop ou amenity pour
l'instant.
> Il n'y aura pas de "pourrissement supplémentaire", si le point
existe déjà à l'adresse ( ou un autre shop, amenity ...), les autres
tags seront rajoutés.
> Si le point n'existe pas, il sera créé.

Enfin :
J'ai trié mon ticket "améliorations"
https://github.com/wadouk/od2osm/issues/1

Je vais traiter 4 points avant de basculer sur le vrai OSM
- interdire de créer si requête des points à proximité à échoué
(surcharge overpass (quand sera en vrai) ou credentials OSM (pour le
test) par exemple)
- avertir si champ principal (pour l'instant shop ou amenity) contient
un point virgule
- ajouter ou supprimer un tag manuellement
- rajouter en source du changeset l'url du jeu de données OpenData

Il y en a d'autres dans l'issue mais que je considère moins important.
Une fois ces 4 points traités, je basculerais sur le vrai OSM.

Salutations


Le jeu. 14 mai 2020 à 12:18, Nicolas Bétheuil mailto:nbethe...@free.fr>> a écrit :

J'ai complété le readme avec plusieurs détails. à discuter.
Fait une issue sur les prochaines modifs en vrac.

Le mer. 13 mai 2020 à 19:00, Nicolas Bétheuil mailto:nbethe...@free.fr>> a écrit :

Bonjour,

Comme je vous l'avais annoncé, j'ai réalisé un nouvel outil :
OpenData2OpenStreetMap aka od2osm.

Vous pouvez aller jouer avec à l'adresse
https://od2osm.cleverapps.io

Il faut être authentifié sur l'environnement de dev OSM
https://master.apis.dev.openstreetmap.org en attendant vos
commentaires acerbes et votre jugement implacable pour le
mettre sur le vrai "OSM".

Vous pouvez en quelques clics ajouter de la données à OSM à
partir d'un jeu de données de test : les commerces parisiens
qui livrent pendant le confinement (oui c'est un peu parigo
centré et peut être un peu dépassé, mais c'est pour jouer aussi).

Ces données sont comparées avec l'environnement de dev d'OSM
qui est plutôt vide et incohérent avec le fond de carte, vous
allez donc faire beaucoup de création.
Rien n’empêche de faire plusieurs fois une création par
l'outil, charge au contributeur de vérifier si un point existe
déjà, l'outil aide à retrouver les éventuels points dèjà existant.
J'en ai moi même déjà ajouté pour tester et que vous puissiez
voir comment se passe une comparaison (même si du coup les
tags vont être identique).

J'attends vos commentaires, avec une certaine impatience, ici
ou en issue sur le repo github
https://github.com/wadouk/od2osm/issues.

Je cherche déjà à valider l'usage contributeur (ajout
communautaire et collaboratif) avant d'ajouté d'autres jeu de
données.

D'avance merci pour votre aide et vos critiques aiguisées.


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

Re: [OSM-talk-fr] Point d'apport volontaire, point de collecte, point de regroupement

[Yves P.]

> exemple d'une zone que je souhaitais définir indépendamment de ce qui est 
> déposé.
> 
> Actuellement SI je le fait avec un seul point je tend à un amenity=recycling, 
> recycling_type=contener et j'hésite sur waste, bin, recycling:waste
> 
recycling_type=container :  avec "ai" ;)
bin=yes : non. C'est pour une poubelle d'arrêt de bus (équivalent de 
amenity=waste_basket)
waste=* : non. C'est un tag secondaire de amenity=waste_disposal
recycling:waste=yes oui

Il y a une troisième façon de taguer ça dans OSM :D
amenity=waste_disposal
waste=trash;paper…
Outre le fait qu'elle soit minoritaire, elle utilise des valeurs multiples ce 
qui rend difficile les requêtes et la saisie.
> en plusieurs alors je fais 2 amenity=recycling, recycling_type=contener et un 
> amenity=waste_disposal
> 
2 POI sur un même "point de regroupement ou d'apport volontaire" : c'est 
contradictoire avec ton souhait de ne mettre qu'un seul POI par "point".

Le plus logique serait de mettre qu'un seul objet OSM et de choisir entre 
amenity=waste_disposal + waste=* ou amenity=recycling + 
recycling_type=container + recycling:*=*

> amenity=waste_disposal c'est la version moderne du bac à roulette 
> (https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dwaste_disposal 
> ) mais la 
> fonction est identique non ?
> 
C'est bien un bac à roulette; La version moderne est en plastique :D

__
Yves

(Au passage, je suis tombé sur ref:FR:SINOE 

 et sur une discussion de 2016 
 
concernant sa création. Il y en a 1020 dans OSM, et 4519 dans le fichier de 
2017).

PS: je tente de déterminer la volumétrie des tags :
Pas simple, car il ne faut compter que les conteneurs (avec les 3 façons de 
taguer) en excluant les déchèteries.

waste_disposal  98616   il faut retrancher les waste=recycling…
recycling   16733   il faut retrancher les déchèteries

Il y a aussi peut-être des sous-tags sans tags principaux ??

Si on compte les sous tags, on obtient grossièrement :

Sous tagNombre  
recycling:waste 15225   Il faut rajouter les conteneur sans clé recycling qui 
seraient des OMR ?!!
waste=trash 9707Il faut rajouter les amenity=waste_disposal sans clé 
waste

Voici les valeurs de waste pour amenity=waste_disposal :
J'ai tronqué le tableau, il y a 310 valeurs différentes au total !!

waste   Nombre
trash   9707
mixed   570
household   252
recycling   176
organic 121
Rubbish 107
plastic 82
Domestic76
grey_water  60
litter  58
glass   47
trash;mixed 47
Solied waste36
ash 35
trash;recycling 27
domestic_waste  25
Mixed   23
paper   23
dog_excrement   20
mixe19
unsorted16
compost pit 15
oil 14
trash;organic   13
trash;plastic   13
chemical_toilet 11
trash;recycling;glass   10


recycling:waste Nombre
yes 15225
no  1745
private 4
-1  1
1   1
brown   1
Calle de Francisco de Quevedo   1
container   1


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

Re: [Talk-se] Svenska riktlinjer för taggning för vandring & löpning

[Daniel Westergren]

Ja, highway=path används förstås för stig. Men den används även för gång-
och cykelvägar (med foot=designated och/eller bicycle=designated) och för
anlagda "stigar" som kan vara ett par meter breda (även om ingen
motortrafik är tillåten och därmed inte är highway=track). Så highway=path
kan användas ganska brett. I t.ex. JOSM:s förinställningar används det för
allt utom "Dedicated cycleway", "Dedicated footway" eller "Dedicated
bridleway".

highway=footway är ju då egentligen uteslutande avsedd för dedikerade
gångvägar (i stadsmiljö), som jag förstår det, liksom highway=cycleway för
dedikerade cykelvägar. Men på de flesta "paths" är ju normalt både
fotgängare och cyklister (MTB eller andra) välkomna.

Det jag är ute efter är ett sätt att särskilja så kallade "single-trail"
eller "single-tracks", alltså stigar där bara en person kan
gå/springa/cykla i bredd, från andra "paths" som är bredare och ofta
preparerade/anlagda. Därav behovet av kombination med andra taggar.

Vi bör ju dock inte använda foot=designated och bicycle=designated om de
inte uttryckligen är skyltade för detta (eller del av en kommuns officiella
gång- och cykelvägnät), även om OSM Mapnik använder det vid rendering.

Ett exempel är om jag planerar en löprunda där jag så mycket som möjligt
vill springa på skogsstigar/single-trails. highway=path kan visa även andra
"stigar", men om det används tillsammans med *surface *och *width *framför
allt så kan de åtminstone definitionsmässigt särskiljas (och därmed även i
renderare och ruttplanerare).

Att sedan skilja single-trails åt ännu mer genom mtb:scale,
trail_visibility osv.
känns lite som överkurs, men vore förstås i förlängningen en dröm för en
traillöpare. :D Då skulle man även kunna välja stigar av mer eller mindre
teknisk karaktär exempelvis.

Men om vi kan lista möjliga kombinationer av dessa taggar skulle det
underlätta inte minst för nya OSM:are. Även om det finns en engelsk
exempelsida kan det förekomma andra exempel i Sverige som vi kan lista och
visa bilder på.

MVH /Daniel



Den fre 15 maj 2020 kl 16:21 skrev Snusmumriken <
snusmumriken.map...@runbox.com>:

> On Fri, 2020-05-15 at 14:59 +0200, Tomas Marklund wrote:
> > highway=footway är nog tämligen meningslös ute i skogen och för de
> > typer av "stigar i skogen" du pratar om, där passar highway=path
> > bättre. Däremot så finns det ju preparerade gångbanor inne i stan där
> > highway=footway passar alldeles ypperligt.
>
> Instämmer. Nu karterar jag nästan bara i tätort och väldigt lite ute i
> skog och mark. highway=path använder jag för en icke-anlagd stig som
> uppstått spontant p.g.a. människor går där.
>
>
> ___
> Talk-se mailing list
> Talk-se@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-se
>
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [Talk-africa] [Trufi Association] Translation of bus route mapping documentation

[Nathalie SIDIBE]

Hi Sören, Jean-Marc, Enock

Thank you Sören for the great job you are doing with Communities in terms
of Public Transport Organization.
My *answer* to your *question *"Does your community need a translation into
French? If yes, I would set up the translation infrastructure and invite
the onces wanting to do the translation work" is *yes.*
*Yes, *a translation into French will be very useful for most of the West
African OSM Communities and some of them including *OSM Mali *have been
already working on Public Transport Mapping Projects.

Thank you Jean-Marc, Enock for your comments and for looping in us in this
emails !

Best Regards,
Nathalie

Le mer. 13 mai 2020 à 15:17, Enock Seth Nyamador  a
écrit :

> Thanks Sören for sharing here, and JML for the comments, this post was
> initially shared on t.me/osmafrica where we have somehow diverse language
> representation and I recommended for it be posted here too, Looping in
> Talk-ML, CI and TG as well.
>
> Cordialement,
>
> Am Mi., 13. Mai 2020 um 15:02 Uhr schrieb Jean-Marc Liotier <
> j...@liotier.org>:
>
>> On 5/12/20 10:40 PM, Sören Reinecke via Talk-africa wrote:
>> > I am Sören Reinecke from Trufi Association. We help communities in
>> developing countries to organize their public transport (pt) e.g. we work
>> with the community from Accra, Ghana. Aside from providing the pt
>> navigation app and the infrastructure behind it (e.g. OTP server etc.) we
>> also show mappers how to add bus routes to OpenStreetMap (
>> https://mapping-bus-routes.readthedocs.io/en/master/ ).
>> >
>> > My question is: Does your community need a translation into French? If
>> yes, I would set up the translation infrastructure and invite the onces
>> wanting to do the translation work.
>>
>> Hello Sören. talk-africa@openstreetmap.org is English language only but,
>> in French-speaking West Africa, the Openstreetmap contributors use
>> French almost exclusively in their Openstreetmap practice. French
>> translation proves valuable in including them.
>>
>> cc: Nathalie Sidibe, from Openstreetmap Mali, who is fluent in English
>> but very aware of how much French translations are required in her local
>> community - she can give you the local perspective.
>>
>>
>>
>> ___
>> Talk-africa mailing list
>> Talk-africa@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-africa
>>
>
>
> --
> -Enock
>


-- 
Nathalie Sidibe
HOTOSM  Board Member
Founder OSM_Mali 
E-mail : nathalie.sid...@hotosm.org
sidibenathali...@gmail.com
Skype : honorable260
Twitter : @honorable_Nath 
Facebook : Sidibe Nathalie Abraham's

Twitter   facebook 
   Web donate 
___
Talk-africa mailing list
Talk-africa@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-africa

Re: [talk-cz] Přírodní parky

[J Kozuch]

Hm, ten geoportalpraha vypadá moc dobře :) přírodní parky mají, nádhera.
Jak mám oznacit ten zdroj? Je tu už nějaká konvence? Máme nějakou help
page?

Přijímám tipy pro další kraje :). Open data z krajů asi nikde centrálně
agregovaná nejsou, že? Pokud vůbec existují tedy...

Koukám ještě do aktuálního CDDA, německé Naturparky tam jsou, ale snad je
vyhlašují centrálně... Pokud má někdo zájem, stahujte "CDDA (GeoPackage
file)" - já otevírám v QGISu:
https://www.eea.europa.eu/data-and-maps/data/nationally-designated-areas-national-cdda-14

Kozuch


pá 15. 5. 2020 v 16:43 odesílatel r00t via talk-cz <
talk-cz@openstreetmap.org> napsal:

> Ahoj,
>
> > Napadá mě třeba pražský magistrát, jestli neposkytuje volná mapová
> > data...
> Poskytuje a dokonce uz mame i schvaleno pouzivat data pro OSM. Muzes
> vybirat na webu IPR:
> https://www.geoportalpraha.cz/cs/data/otevrena-data/seznam
>
>
> r00tcz
>
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-us] Moderation?

[Ian Dees]

Yes, I enabled moderation to cool off the "home rule" thread a bit.

I also stopped getting notification emails from the mailing list system
that any messages had been moderated. I didn't notice until I checked the
web interface. I've disabled the moderation for now.

On Fri, May 15, 2020 at 10:04 AM Frederik Ramm  wrote:

> Hi,
>
> has someone switched on moderation for this list, and if so, why? I sent
> a message 6 hours ago and re-sent it one hour ago and neither seem to
> have gone through. Have I overlooked an announcement? Or is it just broken?
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> 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

[Talk-us] Moderation?

[Frederik Ramm]

Hi,

has someone switched on moderation for this list, and if so, why? I sent
a message 6 hours ago and re-sent it one hour ago and neither seem to
have gone through. Have I overlooked an announcement? Or is it just broken?

Bye
Frederik

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

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

Re: [Talk-us] admin_level and COGs, MPOs, SPDs, Home Rule

[Michael Patrick]

The divisions and subdivision definitions are an ISO Standard, like threads
on nuts and bolts. And the 'politics' are the very least important aspect
of making the distinctions, because vast amounts of networks ( computers,
logistics, air travel ) rely on common understanding of these. Also
correlation of statistics about pretty much everything. Even in failed
states where this no effective federal government, and warlords carve out
their own territories have this stand applied.
So just change the wiki to state that
https://en.wikipedia.org/wiki/ISO_3166-2 applies with the mappings to OSM
levels.

Michael Patrick
Data Ferret


Virus-free.
www.avast.com

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

Re: [Talk-us] admin_level and COGs, MPOs, SPDs, Home Rule

[Kerry Irons]

Having watched this discussion, I feel I can add a little bit.

There is a collection of "agencies" with different titles and different 
functions that GENERALLY fall into this category.  COG (council of 
governments), TPO (transportation planning organization), RPO (regional 
planning organization), RPA (regional planning authority), TPA (transportation 
planning authority), MPO (municipal planning organization), and more.  These 
are organized for various purposes and have varying functions, and Anthony is 
right: few citizens would even vaguely recognize their existence, let alone 
their function.  And of course their function varies widely.  There may well be 
specific rules (varying by state) for how each of these operate, though I am 
not familiar with any of that.

In at least some states, these agencies form once the population of a 
contiguous area reaches a threshold.  There is often some funding flowing to 
the agencies as a result.  Their boundaries can cross many jurisdictional 
boundaries.  They cross state lines, county lines, township lines, and city 
lines.  In denser population areas, they often butt up against one another.  In 
more rural regions, there are significant gaps between them.

Their ability to actually control things varies.  As an example, our local TPO 
(actually called a Coordinating Council) has an active transportation plan that 
shows a 4-foot paved shoulder on a county road that is popular with bicyclists. 
 The county transportation plan shows the same thing.  But the road commission, 
whose members are appointed by the county board but are otherwise essentially 
independent (somewhat analogous to judges appointed for life), would not have 
added the 4-foot shoulders to the road without extra money contributed by the 
county, affected townships, and citizen donations.  The TPO plan was of 
interest to the road commission and nothing more.

I'll leave it to others as to whether the boundaries of the agencies should be 
mapped, but I thought it would be useful to help in understanding them.


Kerry Irons
Adventure Cycling Association

-Original Message-
From: Anthony Costanzo  
Sent: Thursday, May 14, 2020 1:15 AM
To: OpenStreetMap talk-us list 
Subject: Re: [Talk-us] admin_level and COGs, MPOs, SPDs, Home Rule

Going to chime in here as someone who has lived the majority of his life in CT.

I am quite familiar with CT's 8 counties and their geographic forms.
But I only have a vague idea what a COG is and couldn't have told you offhand 
anything about where the boundaries between them are.

I support the idea that counties in CT should be tagged the same as they are in 
other states. On the most basic level, this is simply consistent - why should 
CT be tagged differently than elsewhere?
But even on a more nuanced level... the average person isn't concerned about 
what government functions are or aren't associated with a county. CT's counties 
have no associated government (anymore) but they are still commonly used for 
statistical purposes and they still have cultural relevance as well - you will 
hear references in casual conversations to Fairfield and Litchfield counties. 
Meanwhile ask any Connecticutter what COG they live in and most of them will 
probably answer "what's a COG".

Great current example of this, look at the state's reporting on covid
cases: 
https://portal.ct.gov/-/media/Coronavirus/CTDPHCOVID19summary5132020.pdf?la=en
Page 2 shows current hospitalizations by county. No reference to COGs to be 
found.

Thus, counties should retain their admin level tags, and COGs should be tagged 
less prominently.

___
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: [OSM-talk-fr] covid19 vert, covid19 rouge

[GarenKreiz]

En fait pour les plages, les décideurs se sont basé sur l'ancienne
définition du wiki OSM avec une plage qui est au dessus de la ligne de
côte! Comme en plus ils ne fréquentent que les bords de la Méditerranée en
été, ils ont une vision de la densité de population sur les plages qui peut
effectivement faire craindre une propagation forte du virus. Mais s'il
fréquentaient le littoral de la Bretagne nord en mars et avril, peut-être
auraient-ils assoupli les consignes!



On Fri, 15 May 2020 at 16:02, Philippe Verdy  wrote:

> Les plages seront ouvertes mais sans la possibilité de s'y installer.
> C'est l'installation sur les plages qui pose problème car elle en augmente
> fortement la densité, la distanciation sociale est alors impossible avec la
> circulation permanente autour des carrés de serviettes. Mais il aurait pu
> être prévu une installation possible sur une seule rangée  avec des
> emplacements marqués, et des contraintes de durée pour laisser la place aux
> autres (par exemple un système de ticket donnant le droit de s'installer
> pour au maximum 1 heure), ainsi que des lieux de repos surveillés réservés
> aux personnes à mobilité réduite ou difficile, qui eux n'auront toujours
> aucun accès: je ne vois pas ce qui est choquant pour une personne agée de
> vouloir s'asseoir au milieu de sa promenade.
>
> Pour elles, un dispositif avec des accompagnateurs pourraient les aider à
> tenir compte de leurs difficultés, et la plage pourraient leur confier le
> temps de la promenade un tabouret de plage (consigné) à rendre en fin de
> promenade mais assez léger pour être porté.
>
> En revanche je vois plus de problèmes avec l'utilisation "active" si ceux
> qui y vont vont courir ou jouer au ballon pendant des heures et halleter et
> éventuellement bousculer les autres. De même la proximité n'est pas exclue
> dans certaines activités nautiques sur de petites embarcations. Cela ne va
> donc laisser que les sportifs confirmés faire leur sport sans trop de
> risque (sauf les sports d'équipe dont les sports de ballons ou raquettes),
> ou les seuls joggeurs (donc pas tout le monde: c'est très physique de
> courir sur une plage, et on a aussi besoin de moments de pause).
>
> En tout état de cause, la promenade sur une plage publique avec des chiens
> ne peut être autorisée sans laisse et masque pour eux aussi, on ne peut pas
> contrôler où ils vont et qui ils iront "visiter" sur une plage un peut trop
> fréquentée. Même chose pour les parcs et jardins public urbains. Pour les
> ballades dans les grands parcs naturels ou dans la campagne, il y a
> rarement beaucoup de monde, la distanciation est plus facile à garantir
> même sans beaucoup de contrôle.
>
>
> Mais ça doit être possible sur les parcs privés à accès réglementé et
> surveillé (où le nombre de visiteurs peut être limité, avec aussi des
> limites horaires pour la durée de l'entrée payante): Center Parcs, Parcs
> Astérix, Disney, fêtes foraines, etc. où les grands espaces peuvent aussi
> être segmentés en sous-zones et avec des tickets de réservation horaire,
> pour éviter un trop grand attroupement et les files d'attente autour de
> certaines attractions. Le ticket d'entrée de ces parcs peut comporter un
> code barre/QR-code permettant aux visiteurs de s'inscrire sur les listes
> d'attente pour certaines attraction et ne plus faire la queue. Il faut
> juste quelques bornes pour chaque attraction, la borne édite un ticket avec
> l'heure de passage et un numéro d'ordre (comme dans les salles d'attente
> des services publics) affiché sur un panneau compteur. Le ticket mentionne
> la durée limite...
>
> Si un visiteur n'a pu profiter d'un nombre d'attractions suffisant, avec
> son ticket d'entrée payant, il pourrait recevoir un ticket pour une autre
> visite plus tard, ou un remboursement partiel ou une autre compensation au
> choix du visiteur (exemple: un bon repas, un ticket de transport public,
> des cadeaux pour enfants dans la boutique locale, un bon d'achat pour des
> médias en ligne, des minutes ou Gigaoctets pour mobiles, un bon d'achat
> dans un hypermarché, un ticket d'entrée pour un autre parc/musée, etc.).
>
> Pour cela un système de "points" minimum est remis avec le ticket
> d'entrée, les points non utilisés (du fait d'une trop forte fréquentation
> ou parce que l'heure de réservation de l'attraction dépasse le délai que
> s'était donné le visiteur) sont compensés à la sortie du parc: le visiteur
> remet son ticket d'entrée, les points utilisés sont décomptés (les bornes
> de réservation de chaque attraction transmettent le décompte des points
> utilisés sur chaque ticket numéroté), s'il reste des points à utiliser, le
> visiteur peut aller la boutique locale pour se faire remettre les
> compensations ou autre bons ou remboursements partiels des points
> inutilisés.
>
> Dans ces conditions, les grands parcs (Center Parcs, Parcs Astérix,
> Disney, fêtes foraines) peuvent rouvrir, car ils peuvent assurer la
> distanciation sociale (qui malgré 

Re: [talk-cz] Přírodní parky

[r00t via talk-cz]

Ahoj,

> Napadá mě třeba pražský magistrát, jestli neposkytuje volná mapová
> data...
Poskytuje a dokonce uz mame i schvaleno pouzivat data pro OSM. Muzes vybirat na 
webu IPR:
https://www.geoportalpraha.cz/cs/data/otevrena-data/seznam


r00tcz


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

Re: [Talk-br] Digest Talk-br, volume 140, assunto 15

[Ricardo Bigio]

cional. Dos que votaram,
> > portanto, mais de 50% concorda com a proposta apresentada, sendo
> > considerada aprovada.
> >
> > Alguns comentários foram feitos que poderiam levar a votar casos
> > pontuais da proposta, e não ficou claro para mim se teria algo a ser
> > votado desde já. se você tiver algo pontual a ser votado, manifeste-se
> > a qualquer momento pois ... Não menos importante, lembro aqui que o
> > texto da regra pode ir sendo modificado no avançar do mapeamento
> > conforme algumas questões pontuais forem surgindo, sendo discutidas e
> > votadas como de praxe.
> >
> > Com a aprovação dessa proposta, a mesma terá seu texto ajustado para
> > excluir o que está tachado (foi excluido do texto original ao longo da
> > discussão), excluir a cor verde de parte do texto (foi incluido), e
> > modificar parte do texto de "proposta" para "regra", ou outra sugestão
> > que queiram dar.
> >
> > Também serão atualizadas paginas relacionadas a classificação viária
> > que tratarem sobre o tema, na maior parte dos casos apenas com a
> > inclusão de uma nota no topo da página, e sempre que possível linkando
> > a página da atual regra de mapeamento. Paginas a serem atualizadas:
> >
> > A -
> >
> https://wiki.openstreetmap.org/wiki/Pt:How_to_map_a#Classifica.C3.A7.C3.A3o_de_vias
> > B -
> >
> https://wiki.openstreetmap.org/wiki/Brazil/Classifica%C3%A7%C3%A3o_de_vias
> > C - https://wiki.openstreetmap.org/wiki/Proposta_Top_05_BR_%2B_1
> > D - https://wiki.openstreetmap.org/wiki/Pt:Key:highway
> > E - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dmotorway
> > F - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dtrunk
> > G - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dprimary
> > H - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dsecondary
> > I - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dtertiary
> > J - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dunclassified
> > K - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dresidential
> > L -
> > https://wiki.openstreetmap.org/wiki/Pt:Highway:International_equivalence
> > M -
> https://wiki.openstreetmap.org/wiki/Highway:International_equivalence
> >
> > Assim que as modificações forem feitas, a diferença entre antes e
> > depois será apresentada num próximo e-mail, por meio de link para wiki
> > contendo o que foi modificado.
> >
> >
> >
> > --
> >
> > Subject: Legenda do Digest
> >
> > ___
> > Talk-br mailing list
> > Talk-br@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-br
> >
> >
> > --
> >
> > Fim da Digest Talk-br, volume 140, assunto 14
> > *
> >
> -- Próxima Parte --
> Um anexo em HTML foi limpo...
> URL: <
> http://lists.openstreetmap.org/pipermail/talk-br/attachments/20200515/f06a18c5/attachment-0001.htm
> >
>
> --
>
> Message: 2
> Date: Fri, 15 May 2020 14:13:51 +
> From: Thierry Jean 
> To: OpenStreetMap no Brasil 
> Subject: Re: [Talk-br]  Nova proposta de classificação viária -
> Votação encerrada
> Message-ID:
> <
> cp2pr80mb4403bf1b7ecf536131916ebcc7...@cp2pr80mb4403.lamprd80.prod.outlook.com
> >
>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Concordo: Não votei antes por não me sentir capaz de entrar a fundo nas
> considerações técnicas da proposta. Entretanto, sei por ter conversado com
> Anderson (Santamariense) que esta proposta vai melhorar a navegação para
> pessoas que usam os navegadores em diferentes países, deixando a navegação
> no Brasil, harmonizada com a de outros países. Também, apesar de isto não
> ser um objetivo em si, creio que a visualização do mapa em níveis
> sucessíveis de zoom, permitindo mostrar primeiro a malha mais importante
> para navegação e sucessivamente as outras estradas e ruas, é muito
> importante para que o mapa seja considerado "organizado" pelos usuários. Os
> "concorrentes" fazem assim e é normal que OSM se comporte da mesma maneira.
>
> Thierry Jean
> M. +55 11 99607 1319
>
>
>
> 
> De: santamariense 
> Enviado: quinta-feira, 14 de maio de 2020 19:03
> Para: talk-br 
> Assunto: [Talk-br] Nova proposta de classificação viária - Votação
> encerrada
>
> Registro aqui a finalização do período de votação da nova proposta de
> classificação viá

Re: [talk-cz] Přírodní parky

[Miroslav Suchy]

Dne 15. 05. 20 v 16:23 J Kozuch napsal(a):
> Zdravím,
> 
> mám chuť přidat do OSM přírodní parky (chráněná území) v Česku. Bohužel, tyto 
> parky vyhlašují kraje a tak nejsou k
> dispozici v datech od EEA (resp. AOPK), aby šly jednoduše naimportovat. 
> Nepodařilo se mi najít na wiki žádnou stránku s
> možnými zdroji ze státní správy či samosprávy - nevítě někdo, zda nějaké 
> kraje poskytují mapová data pod přijatelnou
> licencí?

FYI
https://lists.openstreetmap.org/pipermail/talk-cz/2018-January/018328.html

M.

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

[talk-cz] Přírodní parky

[J Kozuch]

Zdravím,

mám chuť přidat do OSM přírodní parky (chráněná území) v Česku. Bohužel,
tyto parky vyhlašují kraje a tak nejsou k dispozici v datech od EEA (resp.
AOPK), aby šly jednoduše naimportovat. Nepodařilo se mi najít na wiki
žádnou stránku s možnými zdroji ze státní správy či samosprávy - nevítě
někdo, zda nějaké kraje poskytují mapová data pod přijatelnou licencí?

Začal jsem zatím v jižhích Čechách, mají hezký geoportál pro hrubou
kontrolu a hlavně jsem našel linky na nařízení kraje, která vyhlašují ty
parky... Napadá mě třeba pražský magistrát, jestli neposkytuje volná mapová
data...

Jižní Čechy:
http://jiznicechy.ochranaprirody.cz/obecna-ochrana-prirody-a-krajiny/ochrana-krajinneho-razu/prirodni-parky/

Zatím vytvořeny 2 parky:
https://www.openstreetmap.org/relation/11101322

To probírání těmi krajskými úřady bude asi trochu mravenčí práce... Bohužel
regionální weby pod AOPK (ochranaprirody.cz) nemají standardizovaný formát
a přírodní parky tak nejsou jednoduše dohledatelné na jednom webu...

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

Re: [Talk-se] Svenska riktlinjer för taggning för vandring & löpning

[Snusmumriken]

On Fri, 2020-05-15 at 14:59 +0200, Tomas Marklund wrote:
> highway=footway är nog tämligen meningslös ute i skogen och för de
> typer av "stigar i skogen" du pratar om, där passar highway=path
> bättre. Däremot så finns det ju preparerade gångbanor inne i stan där
> highway=footway passar alldeles ypperligt. 

Instämmer. Nu karterar jag nästan bara i tätort och väldigt lite ute i
skog och mark. highway=path använder jag för en icke-anlagd stig som
uppstått spontant p.g.a. människor går där.


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

Re: [Talk-br] Nova proposta de classificação viária - Votação encerrada

[Thierry Jean]

Concordo: Não votei antes por não me sentir capaz de entrar a fundo nas 
considerações técnicas da proposta. Entretanto, sei por ter conversado com 
Anderson (Santamariense) que esta proposta vai melhorar a navegação para 
pessoas que usam os navegadores em diferentes países, deixando a navegação no 
Brasil, harmonizada com a de outros países. Também, apesar de isto não ser um 
objetivo em si, creio que a visualização do mapa em níveis sucessíveis de zoom, 
permitindo mostrar primeiro a malha mais importante para navegação e 
sucessivamente as outras estradas e ruas, é muito importante para que o mapa 
seja considerado "organizado" pelos usuários. Os "concorrentes" fazem assim e é 
normal que OSM se comporte da mesma maneira.

Thierry Jean
M. +55 11 99607 1319




De: santamariense 
Enviado: quinta-feira, 14 de maio de 2020 19:03
Para: talk-br 
Assunto: [Talk-br] Nova proposta de classificação viária - Votação encerrada

Registro aqui a finalização do período de votação da nova proposta de
classificação viária. Votaram 5 mapeadores, onde 3 concordaram, sendo
que 1 fez algumas ressalvas; 1 discordou da proposta, fazendo alguns
apontamentos, ainda dentro do conceito funcional da rodovia, os quais
podem ir sendo explorados e discutidos; E 1 se absteve na votação,
embora também concorde com o conceito funcional. Dos que votaram,
portanto, mais de 50% concorda com a proposta apresentada, sendo
considerada aprovada.

Alguns comentários foram feitos que poderiam levar a votar casos
pontuais da proposta, e não ficou claro para mim se teria algo a ser
votado desde já. se você tiver algo pontual a ser votado, manifeste-se
a qualquer momento pois ... Não menos importante, lembro aqui que o
texto da regra pode ir sendo modificado no avançar do mapeamento
conforme algumas questões pontuais forem surgindo, sendo discutidas e
votadas como de praxe.

Com a aprovação dessa proposta, a mesma terá seu texto ajustado para
excluir o que está tachado (foi excluido do texto original ao longo da
discussão), excluir a cor verde de parte do texto (foi incluido), e
modificar parte do texto de "proposta" para "regra", ou outra sugestão
que queiram dar.

Também serão atualizadas paginas relacionadas a classificação viária
que tratarem sobre o tema, na maior parte dos casos apenas com a
inclusão de uma nota no topo da página, e sempre que possível linkando
a página da atual regra de mapeamento. Paginas a serem atualizadas:

A - 
https://wiki.openstreetmap.org/wiki/Pt:How_to_map_a#Classifica.C3.A7.C3.A3o_de_vias
B - https://wiki.openstreetmap.org/wiki/Brazil/Classifica%C3%A7%C3%A3o_de_vias
C - https://wiki.openstreetmap.org/wiki/Proposta_Top_05_BR_%2B_1
D - https://wiki.openstreetmap.org/wiki/Pt:Key:highway
E - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dmotorway
F - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dtrunk
G - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dprimary
H - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dsecondary
I - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dtertiary
J - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dunclassified
K - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dresidential
L - https://wiki.openstreetmap.org/wiki/Pt:Highway:International_equivalence
M - https://wiki.openstreetmap.org/wiki/Highway:International_equivalence

Assim que as modificações forem feitas, a diferença entre antes e
depois será apresentada num próximo e-mail, por meio de link para wiki
contendo o que foi modificado.

___
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-it] Confini codice postale

[Maurizio Napolitano]

Il vettoriale di quello che chiedi lo si trova qui in formato json
https://www.arcgis.com/sharing/rest/content/items/af640e6ae214490c93c29119e64f7681/data?f=json
Bisogna lavorarci sopra per sistemare il sistema di riferimento ed
altre cosucce.
La questione comunque rimane sempre la stessa:
ci sono i permessi per farlo?
Ci si potrebbe appellare al codice digitlae dell'amministrazione
pubblica per cui, se la licenza non è segnata, allora i dati sono
aperti.
Solo che la licenza implicita è  la cc-by e quindi poi bisogna
chiedere il permesso.
In sintes:
(come già scritto) chiedere al Comune i dati in formato vettoriale con
il permesso di importazione in openstreetmap e poi seguirei le linee
guida per l'importazione.
Quello che non capisco è se c'è una relazione 1 a 1 fra quartieri
comunali e cap.



On Fri, May 15, 2020 at 12:15 PM Luigi Scuotto  wrote:
>
> la mappa dei quartieri lo scaricata da qui dimmi se si può usare, senò non mi 
> ci metto neanche a referenziare.
> https://www.arcgis.com/apps/webappviewer/index.html?id=f79b62f848404d43837b6946bf20f967
> Gigi
>
> Il giorno ven 15 mag 2020 alle ore 12:09 Luigi Scuotto 
>  ha scritto:
>>
>> io ho provato con qgis a referenziare una mappa scaricata in pdf lo allegata 
>> a un messagio ma e stato bloccato era troppo grande non so se lo 
>> sbloccheranno.
>> non sono capace con qgis creare poligoni senò usavo i cap.
>> Gigi
>>
>>
>> Il giorno ven 15 mag 2020 alle ore 11:01 Martin Koppenhoefer 
>>  ha scritto:
>>>
>>>
>>>
>>> sent from a phone
>>>
>>> > On 15. May 2020, at 10:50, Cascafico Giovanni  wrote:
>>> >
>>> > Se proprio volete fare dei poligoni che delimitino i vari CAP di Bergamo, 
>>> > esiste (e lo sto provando) un plugin per Qgis che si chiama concavehull.
>>>
>>>
>>> io direi di non rimuovere per ora i CAP dai singoli indirizzi anche quando 
>>> si ha già messo un tag per un poligono.
>>>
>>> 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



-- 
Maurizio "Napo" Napolitano
http://de.straba.us

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

Re: [OSM-talk-be] La rencontre d'hier avec Marcel Shabani de OpenStreetMap à Bukavu

[Nicolas Pettiaux]

Bonjour

Merci pour ton mail. Je me réjouis de la rencontre.

Je rajoute à la conversation la liste des contributeurs belges de
OpenStreetMap (OSM) (and sorry, I go on in French because the team in
south Kivu speak French, very few English and not Flemish) pour leur
aide. Je continue aussi par email car riot est pour le moment difficile
pour nos amis du Kivu qui ont surtout accès au peu d'internet dont ils
disposent par smartphones.

@osm-be friends : could you help the team of very motivated young people
around Alain to map Bukavu and south Kivu, to

 1. have the best possible map of the country
 2. use the map to build a good community-based internet network

They have access to smartphones and apparently hardly to any desktops or
laptops, nor to good and cheap internet access ... that we want to help
achieve.

À toi Alain et les membres de la liste k...@educode.be, 

Ce qui est nécessaire c'est que vous appreniez à faire le travail de
cartographie qui peut être fait avec des smartphones en ayant que de
temps en temps une connexion au web. Les membres de OSM-be peuvent vous
aider à apprendre les outils sur smartphone et les bonnes méthodes, et
nous pouvons aussi vous aider en cartographiant certains morceaux d'ici
avec les photos aériennes, mais votre travail sur place reste essentiel
dans la philosophe de OSM.

Et une des contributions de Gaël sera de vous aider à avoir le matériel
pour construire les réseaux locaux dont vous avez besoin en vous
inspirant de http://hand.team/#la-methode avec notre support et si
possible nos soutiens financiers et logistiques aussi.

Bonne journée et à très bientôt,

Nicolas

Le 14/05/20 à 13:04, CHAVEZ CIKURU a écrit :
> Bonjour Professeur Nicolas, 
> Bonjour à tous.
>
> J'espère que vous allez mieux.
> Hier, aux environs de 17h (heure de Bukavu) nous nous sommes
> rencontrés (/ALAIN, VICTOR et MARCEL/) à l'ISDR Bukavu avec Marcel de
> OpenStreetMap à Bukavu.
>
> Il nous a clairement dit qu'il est prêt à faire pour nous la
> cartographie des ressources existantes (pylônes de 4G, lieux qui
> fournissent le Wifi, Points d'accès, etc.). 
> C'est selon lui, ça c'est un moment (moment de confinement) profitable
> pour faire ça car il ne reste pas beaucoup de temps à Bukavu.
> Mais il nous a vraiment expliqué le problème qui est presque commun
> (en RDC), qui ne peux pas lui permettre de faire la cartographie vite
> et bien. Le problème c'est l'accès à la connexion internet. Pour y
> accéder il faut des moyens (acheter des forfaits).  Voilà donc le
> problème. La connexion internet il doit acheter.  Mais il est vraiment
> prêt à le faire pour nous.
>
> Bon après midi.
> Bien à vous.
> Alain CHAVEZ KAMERA
>
> -- 
> *CIKURU KAMERA Alain Chavez*
> *Technicien en Développement Rural et Consultant en Matières de
> Développement.*
> *Tél: +243 97 57 57 359, +243 85 23  36 465*
-- 
*Nicolas Pettiaux, phd* - gsm +32 496 24 55 01 - nico...@pettiaux.be
Avenue du Pérou 29 à 1000 Bruxelles


0xA9920C887AF627FD.asc
Description: application/pgp-keys


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

Re: [OSM-talk-fr] covid19 vert, covid19 rouge

[Philippe Verdy]

Les plages seront ouvertes mais sans la possibilité de s'y installer. C'est
l'installation sur les plages qui pose problème car elle en augmente
fortement la densité, la distanciation sociale est alors impossible avec la
circulation permanente autour des carrés de serviettes. Mais il aurait pu
être prévu une installation possible sur une seule rangée  avec des
emplacements marqués, et des contraintes de durée pour laisser la place aux
autres (par exemple un système de ticket donnant le droit de s'installer
pour au maximum 1 heure), ainsi que des lieux de repos surveillés réservés
aux personnes à mobilité réduite ou difficile, qui eux n'auront toujours
aucun accès: je ne vois pas ce qui est choquant pour une personne agée de
vouloir s'asseoir au milieu de sa promenade.

Pour elles, un dispositif avec des accompagnateurs pourraient les aider à
tenir compte de leurs difficultés, et la plage pourraient leur confier le
temps de la promenade un tabouret de plage (consigné) à rendre en fin de
promenade mais assez léger pour être porté.

En revanche je vois plus de problèmes avec l'utilisation "active" si ceux
qui y vont vont courir ou jouer au ballon pendant des heures et halleter et
éventuellement bousculer les autres. De même la proximité n'est pas exclue
dans certaines activités nautiques sur de petites embarcations. Cela ne va
donc laisser que les sportifs confirmés faire leur sport sans trop de
risque (sauf les sports d'équipe dont les sports de ballons ou raquettes),
ou les seuls joggeurs (donc pas tout le monde: c'est très physique de
courir sur une plage, et on a aussi besoin de moments de pause).

En tout état de cause, la promenade sur une plage publique avec des chiens
ne peut être autorisée sans laisse et masque pour eux aussi, on ne peut pas
contrôler où ils vont et qui ils iront "visiter" sur une plage un peut trop
fréquentée. Même chose pour les parcs et jardins public urbains. Pour les
ballades dans les grands parcs naturels ou dans la campagne, il y a
rarement beaucoup de monde, la distanciation est plus facile à garantir
même sans beaucoup de contrôle.


Mais ça doit être possible sur les parcs privés à accès réglementé et
surveillé (où le nombre de visiteurs peut être limité, avec aussi des
limites horaires pour la durée de l'entrée payante): Center Parcs, Parcs
Astérix, Disney, fêtes foraines, etc. où les grands espaces peuvent aussi
être segmentés en sous-zones et avec des tickets de réservation horaire,
pour éviter un trop grand attroupement et les files d'attente autour de
certaines attractions. Le ticket d'entrée de ces parcs peut comporter un
code barre/QR-code permettant aux visiteurs de s'inscrire sur les listes
d'attente pour certaines attraction et ne plus faire la queue. Il faut
juste quelques bornes pour chaque attraction, la borne édite un ticket avec
l'heure de passage et un numéro d'ordre (comme dans les salles d'attente
des services publics) affiché sur un panneau compteur. Le ticket mentionne
la durée limite...

Si un visiteur n'a pu profiter d'un nombre d'attractions suffisant, avec
son ticket d'entrée payant, il pourrait recevoir un ticket pour une autre
visite plus tard, ou un remboursement partiel ou une autre compensation au
choix du visiteur (exemple: un bon repas, un ticket de transport public,
des cadeaux pour enfants dans la boutique locale, un bon d'achat pour des
médias en ligne, des minutes ou Gigaoctets pour mobiles, un bon d'achat
dans un hypermarché, un ticket d'entrée pour un autre parc/musée, etc.).

Pour cela un système de "points" minimum est remis avec le ticket d'entrée,
les points non utilisés (du fait d'une trop forte fréquentation ou parce
que l'heure de réservation de l'attraction dépasse le délai que s'était
donné le visiteur) sont compensés à la sortie du parc: le visiteur remet
son ticket d'entrée, les points utilisés sont décomptés (les bornes de
réservation de chaque attraction transmettent le décompte des points
utilisés sur chaque ticket numéroté), s'il reste des points à utiliser, le
visiteur peut aller la boutique locale pour se faire remettre les
compensations ou autre bons ou remboursements partiels des points
inutilisés.

Dans ces conditions, les grands parcs (Center Parcs, Parcs Astérix, Disney,
fêtes foraines) peuvent rouvrir, car ils peuvent assurer la distanciation
sociale (qui malgré tout nécessite un personnel de surveillance réparti,
mais c'est déjà le cas des grands parcs)


Le mer. 6 mai 2020 à 23:17,  a écrit :

> Bonjour,
>
> concernant l'OpenData, le Ministère des Solidarités et de la Santé a des
> progrès à faire : les cartes sont publiées sous forme d'images
> 
> !
>
> On parlait de 3 critères mais seuls deux sont publiés. Si le troisième
> c'est l'humeur de ou vis-à-vis de de Castagner, les Bretons sont mal
> barrés^^.
>
> Peu importe devraient rester deux 

Re: [Talk-it] Confini codice postale

[Maurizio Napolitano]

On Fri, May 15, 2020 at 10:50 AM Cascafico Giovanni  wrote:
>
> Ho dato un'occhiata, non trovo nessuna licenza definita e per quanto riguarda 
> il link [1] citato da bergamonews, la mappa mi da errore. Se proprio volete 
> fare dei poligoni che delimitino i vari CAP di Bergamo, esiste (e lo sto 
> provando) un plugin per Qgis che si chiama concavehull.


Io userei un approccio diverso partendo dai voronoi, come vedi qui
https://metashapes.com/blog/reconstruction-postal-code-areas-using-openstreetmap/

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

Re: [Talk-it] Confini codice postale

[Maurizio Napolitano]

On Thu, May 14, 2020 at 10:47 PM Luigi Scuotto  wrote:
>
> Come faccio a tirare fuori i poligoni da questa mappa?
> https://www.bergamonews.it/2017/08/12/riperimetrazione-della-citta-lamministrazione-rivaluta-i-confini-dei-quartieri/262317/

Guardando il sito vedo che rimanda ad un servizio su arcgis, quindi,
sicuramente il comune ha i dati in questione.
Guarderei se sono sul sito opendata del comune, oppure farei una
valutazione di richiesta per poi seguire le regole di import.
https://www.dati.lombardia.it/comune-bergamo

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

Re: [OSM-talk-fr] Point d'apport volontaire, point de collecte, point de regroupement

[Vincent Bergeot]

Le 15/05/2020 à 14:48, Yves P. a écrit :
>Des photos seraient les bienvenues pour différencier les 2 types de 
conteneurs/déchets.


Comme ça ?

Parfait pour comprendre ce qu'il y a sur le terrain, merci :)


merci pour les exemples Stéphane


https://www.mapillary.com/map/im/r3-7eaUqvjER2K6KQCbIPg
3 colonnes enfouies, dont une contenant des OM.
Le tambour se déverrouille avec la badge RFID.


exemple d'une zone que je souhaitais définir indépendamment de ce qui 
est déposé.


Actuellement SI je le fait avec un seul point je tend à un 
amenity=recycling, recycling_type=contener et j'hésite sur waste, bin, 
recycling:waste


en plusieurs alors je fais 2 amenity=recycling, recycling_type=contener 
et un amenity=waste_disposal






https://www.mapillary.com/map/im/Ml__GIf3g3bbILsmEWglsQ
2 colonnes bois avec 3 types de déchets. Celle de droite semble être 
pour le papier.


amenity=recycling, recycling_type=contener



https://www.mapillary.com/map/im/lKjOCV-HlhHMnpFHH1tEYQ` 


1 colonne OM. Le tambour se déverrouille avec la clé (contenant des piles)


amenity=waste_disposal c'est la version moderne du bac à roulette 
(https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dwaste_disposal) mais 
la fonction est identique non ?




--
Vincent Bergeot

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

Re: [OSM-talk-fr] Bosch eBike Charging Stations in France

[Philippe Verdy]

La localisation manuelle point par point, basée sur la consultation de
l'adresse, et une vérification sur la carte OSM existante (où des objets
vont être ajoutés et où la précision peut aussi être améliorée localement
si nécessaire en se basant sur les sources d'imagerie libres proposées ne
pose aucun problème (même si une première approximation automatique a été
faite avec une géolocalisation quelconque uniquement à titre d'aide pour
situer sommairement une adresse dont la position exacte sera effectuée
manuellement).

A ce titre ce n'est pas différent des contributions faites par des mappeurs
OSM individuels qui s'appuient eux aussi sur diverses sources et utilisent
leur propre jugement pour voir ce qui convient le mieux, et non une données
prise directement et automatiquement d'une base, surtout si on sait qu'elle
est non libre et peut contenir des erreurs volontairement ajoutées comme
des "oeufs de Pâques" (note: la simple randomisation automatique n'est pas
convenable non plus car elle ne tient pas compte du reste autour du point,
ce qu'un controibuteur humain voit instantanément par une vue globale.

Je ne vois donc pas de problème à des ajouts point par point par un humain
qui doit traiter une liste de propositions: c'est exactement le même
processus que les propositions d'imports sur Osmose, qu'on n'est jamais
obligé de prendre à la lettre, chacune étant évaluée par un humain sous sa
responsabilité et en fonction des connaissances et recommandations locales
(parfois aussi des choix difficiles à faire et des ambiguités à résoudre en
utilisant d'autres sources à titre de comparaison si cela permet de mieux
évaluer les solutions possibles, car il y a rarement une seule solution,
toujours une marge d'interprétation et très souvent ajustements locaux à
faire autour en plus du point importé)


Le lun. 11 mai 2020 à 17:21, Marc M.  a écrit :

> Bonjour,
>
> Le 11.05.20 à 16:46, Alznauer Florian (EB/MKB2) via Talk-fr a écrit :
> > Serait-il possible / acceptable d’importer les positions des stations de
> > recharge Bosch manuellement, une par une directement dans OSM sans
> > utiliser un import de masse ? Cela nous permettrait de positionner les
> > Powerstations à l'endroit précis où elles se trouvent sans utiliser la
> > géolocalisation de Google ou les coordonnées GPS du fichier Excel que
> > chaque lieu ou partenaire nous a fourni avec l’emplacement exact de la
> > borne de recharge.
>
> comment allez-vous les positionner sans utiliser la géolocalisation ?
> how are you going to position them without using geolocation?
>
> Cordialement,
> Marc
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Point d'apport volontaire, point de collecte, point de regroupement

[Yves P.]

@Vincent
>> Il n'y a pas vraiment de distinguo. cette carte n'affiche que ce qui est 
>> recyclable, donc ne montre pas amenity=waste_disposal, ni amenity= recycling 
>> + recycling:waste=yes
>> (la requête overpass 
>> 
>>  remonte les tout)
> si cela montre amenity=waste_disposal
> 
> Cela correspond à ce qui a été traduit par Traitement de Déchets, à droite du 
> menu horizontal à droite en bas https://openrecyclemap.org/map 
>  (selon l'écran il faut cliquer sur see more)
> 
Ok, je me suis embrouillé avec cette mauvaise traduction :D (Avec l'interface 
en anglais c'est plus clair)

Cette carte affiche aussi les amenity=recycling + recycling:waste=yes :
https://openrecyclemap.org/map/21/46.51744/6.02056 


L'interface serait plus claire si l'icône waste disposal affichait l'un ou 
l'autre des tags.

@David
>> Moi aussi, mais à gérer dans le temps et dans les softs ça complique :
>> KISS -> amenity= recycling  + recycling:waste=yes seulement :)
> C'est le plus simple effectivement mais du coup waste_disposal ne sert plus
> ? Ou quel serait son usage ?
Si l'alternative KISS est retenue, ce tag devrait disparaitre… un jour.

> Le "risque" c'est qu'à la fin on ne puisse pas
> faire une carte de france avec toutes les données OSM pour dire où on peut
> apporter ses déchets si on utilise pas tous les même nomenclature…
Ce n'est pas vraiment un problème.

Dans OSM (comme dans la vie), il y a des synonymes ;)
Les outils (éditeurs et rendus) doivent être souples à minima.

De facto, il y a 2 façon de taguer. Si les producteurs de données ouvertes se 
mettent d'accord sur un standard (et donc une méthode pour taguer les 
"poubelles") c'est une grande avancée.
On pourra (au moins pour la France) faire une édition de masse pour transformer 
les waste_disposal en recycling:waste=yes (ou le contraire).
Ou… laisser les tags en l'état (car ce qui est vrai en France, ne l'est 
peut-être pas ailleurs dans le monde).

Pendant la période de transition, les outils devront être souples en lecture et 
si un consensus aboutit, ne proposer qu'une seule façon de taguer en écriture.


Autre argument pour le KISS :
En cartogaphiant depuis son canapé, il est parfois impossible de savoir quel 
détritus est dans le conteneur (pas de Mapillary, Orthophoto pas assez 
détaillée…).
On ne tag pas pour ne pas froisser les "partisans" d'un solution ou d'une autre 
?
Les tags amenity=recycling + recycling_type=container fonctionnent. Une 
observation de terrain (quête StreetComplete par exemple) ou une intégration OD 
permettront de préciser le contenu.

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

Re: [Talk-it] Confini codice postale

[Martin Koppenhoefer]

Am Fr., 15. Mai 2020 um 12:48 Uhr schrieb Cascafico Giovanni <
cascaf...@gmail.com>:

> Scusa Luigi, ma vorrei chiarire alcune cose:
>
> da due mesi per Bergamo hai importato oltre 20k civici, hai importato le
> fermate degli autobus, hai importato centinaia di parcheggi in formato
> poligono, credo che tu sappia sia quali sono i requisiti di una licenza,
> sia usare gli strumenti GIS più adatti agli import. Il punto è che sembra
> ti dia fastidio documentare tutto ciò.
>
> Indubbiamente è molto utile ciò che hai fatto (sopra gli addr ci ho
> costruito un centinaio di punti di interesse delivery:covid19), ma a me in
> questa mailing list hanno fatto il pelo per molto meno per documentazione e
> licenza e mi sorprende che ora sia solo io a fare la figura del pignolo
> rompiballe.
>
>

ti vengo in supporto, per gli import bisogna seguire la procedura import,

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

Re: [Talk-GB] Tagging showgrounds

[Mark Goodge]

On 15/05/2020 13:50, Andy Townsend wrote:

The problem is that they're not necessary "all the same fundamental 
object".  Ashover Showground is "a patch of grass with some nice gates 
where something happens one a year".  Stoneleigh is essentially an 
agricultural business park.


Yes, and in between that you have ones like Stafford and Bakewell which, 
most of the year, are essentially grass-surface car parks adjacent to 
some exhibition halls.


Mark

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

Re: [Talk-GB] Tagging showgrounds

[Andy Townsend]

On 13/05/2020 12:28, Paul Berry wrote:
Not sure about the tagging/proposal politics but since there are a 
small number of showgrounds, is there anything to stop a UK-specific 
page being set up on the Wiki for visibility?


As Jez has already said that sounds like an excellent idea.


Then if anyone wants to harmonise the tags they can use that as a 
guide to do so.


There's nothing to say we can't tag in any way we want—and again for 
this small collection of entities which are clearly all the same 
fundamental object



The problem is that they're not necessary "all the same fundamental 
object".  Ashover Showground is "a patch of grass with some nice gates 
where something happens one a year".  Stoneleigh is essentially an 
agricultural business park.


Best Regards,

Andy



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

Re: [OSM-talk-fr] Point d'apport volontaire, point de collecte, point de regroupement

[Yves P.]

> >Des photos seraient les bienvenues pour différencier les 2 types de 
> >conteneurs/déchets.
> 
> Comme ça ?
Parfait pour comprendre ce qu'il y a sur le terrain, merci :)

> https://www.mapillary.com/map/im/r3-7eaUqvjER2K6KQCbIPg 
> 
3 colonnes enfouies, dont une contenant des OM.
Le tambour se déverrouille avec la badge RFID.

> https://www.mapillary.com/map/im/Ml__GIf3g3bbILsmEWglsQ 
> 
2 colonnes bois avec 3 types de déchets. Celle de droite semble être pour le 
papier.

> https://www.mapillary.com/map/im/lKjOCV-HlhHMnpFHH1tEYQ` 
> 
1 colonne OM. Le tambour se déverrouille avec la clé (contenant des piles)

Pour moi, les deux conteneurs à ordures ménagères sont identiques. (au verrou 
et à la localisation près).
Ils se taguent donc avec la clé amenity=recycling. C'est KISS, non ?
;)

> Pour les types de "clés" je n'en ai aucune idée. Je n'en possède pas moi-même.
NFC c'est un type de RFID. Celui qui est dans nos cartes bancaires et nos 
ordiphones.


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

Re: [OSM-talk-fr] Point d'apport volontaire, point de collecte, point de regroupement

[Jérôme Seigneuret]

https://www.mapillary.com/map/im/r3-7eaUqvjER2K6KQCbIPg
colonne enterrée à préhension par simple crochet


https://www.mapillary.com/map/im/Ml__GIf3g3bbILsmEWglsQ
  colonne aérienne à préhension par simple crochet

https://www.mapillary.com/map/im/lKjOCV-HlhHMnpFHH1tEYQ
colonne OM (j'en avait pas encore vu en aérien)  à préhension par simple
crochet

Et tous comme les camions peuvent être multi flux; les bacs de collecte et
les colonnes peuvent être multi-flux
https://www.elkoplast.fr/media/photos/catalog/item/gallery/images-218/p3091140-1024-t2.jpg

Le ven. 15 mai 2020 à 14:31, Stéphane Péneau  a
écrit :

> Le 15/05/2020 à 13:09, Yves P. a écrit :
>
>  >Des photos seraient les bienvenues pour différencier les 2 types de
> conteneurs/déchets.
>
> Comme ça ?
> https://www.mapillary.com/map/im/r3-7eaUqvjER2K6KQCbIPg
>
> https://www.mapillary.com/map/im/Ml__GIf3g3bbILsmEWglsQ
>
> https://www.mapillary.com/map/im/lKjOCV-HlhHMnpFHH1tEYQ
>
>
> Pour les types de "clés" je n'en ai aucune idée. Je n'en possède pas
> moi-même.
>
> Stf
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Point d'apport volontaire, point de collecte, point de regroupement

[Stéphane Péneau]

Le 15/05/2020 à 13:09, Yves P. a écrit :

>Des photos seraient les bienvenues pour différencier les 2 types de 
conteneurs/déchets.


Comme ça ?
https://www.mapillary.com/map/im/r3-7eaUqvjER2K6KQCbIPg

https://www.mapillary.com/map/im/Ml__GIf3g3bbILsmEWglsQ

https://www.mapillary.com/map/im/lKjOCV-HlhHMnpFHH1tEYQ


Pour les types de "clés" je n'en ai aucune idée. Je n'en possède pas 
moi-même.


Stf


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

Re: [Talk-it] Confini codice postale

[Maurizio Napolitano]

On Thu, May 14, 2020 at 9:48 PM Cascafico Giovanni  wrote:
>
> I confini dei CAP sono sicuramente utili, ma se derivano da un contorno di 
> addr:postcode omogenei appena importati (per questo chiedevo a Luigi le 
> fonti)  non aggiungono informazione.
> Se inserisco un nuovo civico in una zona di confine, a chi apparterrà?

devi proprio avere la sfiga di avere il punto di ingresso in quella zona.
Anche se, ammetto, ci sono casi di questo genere, ma si può benissimo
gestire il punto.

> Se ne aggiungo uno in mezzo ad altri, non servirà una relazione per sapere 
> che postcode dovrà avere.

In ogni caso c'è chi si ricosruisce le aree dei cap usando i punti dei
numeri civici attraverso la creazione di voronoi

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

Re: [OSM-talk-fr] Point d'apport volontaire, point de collecte, point de regroupement

[Vincent Bergeot]

Le 15/05/2020 à 13:09, Yves P. a écrit :


@Vincent


j'ai l'impression aujourd'hui que majoritairement (donc sans parler 
"métier") si je me retrouve avec des gens nous allons distinguer le 
"tri, recyclable" des "déchets, ordures ménagères", qui à mon avis 
aujourd'hui est la distinction entre :


  * amenity=waste_disposal
  * amenity=recycling

au passage ce distingo est aussi utilisé par exemple par 
https://openrecyclemap.org


Il n'y a pas vraiment de distinguo. cette carte n'affiche que ce qui 
est recyclable, donc ne montre pas amenity=waste_disposal, ni amenity= 
recycling + recycling:waste=yes
(la requête overpass 
 remonte 
les tout)


si cela montre amenity=waste_disposal

https://openrecyclemap.org/way/761477096 correspond à ceci 
https://www.openstreetmap.org/node/6486361595


Cela correspond à ce qui a été traduit par Traitement de Déchets, à 
droite du menu horizontal à droite en bas https://openrecyclemap.org/map 
(selon l'écran il faut cliquer sur see more)



--
Vincent Bergeot

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

Re: [Talk-se] Svenska riktlinjer för taggning för vandring & löpning

[Christoffer Holmstedt]

Jag har mappat Nasaleden uppe i norr mellan Glommersträsk och Abborträsk
och ytterligare en bit mot Arvidsjaurtrakterna. Jag sprang sträckan för
några år sedan och hade samma dilemma som dig. Vad är vad? Jag använde om
jag minns rätt mestadels highway=path och sedan la jag in
"trail_visibility" enligt egen uppfattning. Att hålla sig till highway=path
tror jag är rätt förutom där bilar kan köra då har jag använt highway=track.

PS. Diskussion om detta förs helst på mailinglistan för min del ;) DS.

Den fre 15 maj 2020 kl 10:16 skrev Daniel Westergren :

> Jag tycker vidare att vi skulle ha svenska översättningar med egna
> bildexempel av
> https://wiki.openstreetmap.org/wiki/Highway_tagging_samples/out_of_town
>  och https://wiki.openstreetmap.org/wiki/Highway_tagging_samples/urban.
>
> Där skulle vi väldigt konkret med bildexempel kunna visa hur olika
> "highway" bör taggas. *Håller ni med om taggningen av
> bildexemplen på 
> https://wiki.openstreetmap.org/wiki/Highway_tagging_samples/out_of_town
> ?*
>
> Tänker då på hur vi använder taggarna:
>
>- *surface *(gravel vs fine_gravel vs compacted t.ex. och ground vs
>dirt vs earth)
>- *tracktype *(även på path om det är en preparerad "path" som inte är
>en "track", för att därigenom skilja ut mot skogsstigar. grade2 och sämre
>implicerar någon form av unpaved)
>- *smoothness *("bad" eller sämre för skogsstigar)
>- *width *(typ 0,5-1 m för skogsstigar och normalt 2-3 m för
>preparerade "paths")
>- *mtb:scale *(enbart för singletrail, alltså det vi normalt menar med
>stig på svenska)
>- *trail_visibility* (enbart för stigar)
>
> Det finns ju även "informal=yes|no", men frågan är om den är värd att
> använda? Möjligen i städer för så kallade "desire paths".
>
> Skulle också vilja höra med er *om vi överhuvudtaget ska använda
> highway=footway i Sverige? *Footway implicerar ju att den egentligen bara
> är avsedd för fotgängare, vilket vi lika gärna kan använda highway=path,
> foot=designated för. Dessutom är ju skogsstigar normalt även möjliga att
> cykla MTB på, varför footway i min mening är meningslös och inte bör
> användas alls.
>
> highway=cycleway kan möjligen användas för cykelvägar där fotgängare inte
> är tillåtna (alt. att man använder foot=yes|designated). Men det kan lika
> gärna åstadkommas med highway=path och olika access-taggar för foot,
> bicycle, horses osv.
>
> /Daniel
>
>
> Den fre 15 maj 2020 kl 09:07 skrev Daniel Westergren :
>
>> Tjenare,
>>
>> En nackdel med OSM är att det inte finns någon självklar central plats
>> för allmänna diskussioner och förslag. Är mailinglistan, FB-gruppen, wikin
>> eller annat att föredra?
>>
>> Då jag ny har gjort ett par videoguider om kartläggning av stigar för
>> löpning (
>> https://www.youtube.com/playlist?list=PLZjc6PXbNOLJK3yCR0wsn0RHxqhUn2sCa,
>> vilket förstås också kan användas för vandring & MTB) skulle jag vilja se
>> att vi tar fram tydligare riktlinjer för taggning av stigar,
>> vandringsleder, motionsspår och naturstigar (och i förlängningen även
>> natur/markanvändning och infrastruktur)
>>
>> Till exempel skulle det underlätta inte minst för nya karterare om vi
>> hade en svensk översättning av https://wiki.openstreetmap.org/wiki/Hiking och
>> de viktigaste av de sidor som länkas till där (t.ex. för ways och
>> attributes of ways, liksom taggning av walking and hiking route networks).
>>
>> Jag kan förstås påbörja en sådan svensk sida. Men en del i det handlar ju
>> också om hur vi ska tagga sådant som inte är självklart. Jag tänker fr.a.
>> på highway=path och hur vi använder olika attribut för att skilja på
>> skogsstigar, preparerade stigar, gång- och cykelvägar osv., men även en
>> tydlig svensk översättning av network=*. Var förs lämpligast en diskussion
>> om detta?
>>
>> MVH /Daniel Westergren
>>
>
> Den fre 15 maj 2020 kl 09:07 skrev Daniel Westergren :
>
>> Tjenare,
>>
>> En nackdel med OSM är att det inte finns någon självklar central plats
>> för allmänna diskussioner och förslag. Är mailinglistan, FB-gruppen, wikin
>> eller annat att föredra?
>>
>> Då jag ny har gjort ett par videoguider om kartläggning av stigar för
>> löpning (
>> https://www.youtube.com/playlist?list=PLZjc6PXbNOLJK3yCR0wsn0RHxqhUn2sCa,
>> vilket förstås också kan användas för vandring & MTB) skulle jag vilja se
>> att vi tar fram tydligare riktlinjer för taggning av stigar,
>> vandringsleder, motionsspår och naturstigar (och i förlängningen även
>> natur/markanvändning och infrastruktur)
>>
>> Till exempel skulle det underlätta inte minst för nya karterare om vi
>> hade en svensk översättning av https://wiki.openstreetmap.org/wiki/Hiking och
>> de viktigaste av de sidor som länkas till där (t.ex. för ways och
>> attributes of ways, liksom taggning av walking and hiking route networks).
>>
>> Jag kan förstås påbörja en sådan svensk sida. Men en del i det handlar ju
>> också om hur vi ska tagga 

Re: [OSM-talk-ie] Talk-ie Digest, Vol 132, Issue 5

[Colm Moore]

Hi,

From: Dave Corley 
Subject: Re: [OSM-talk-ie] Estimate of number of building=* in Ireland

> The fact that so many buildings are being mapped as building=yes
> when more accurate tagging is plainly obvious makes this an utterly
> frustrating project.

Yes, it can be frustrating for some people. However, realise that the majority 
of contributors are people who only make a few dozens edits or less. These 
contributors can provide good local information, but might not know how to 
precisely tag many things.

Other people revel in adding detail - in terms of nodes half of all my 
contribution to OSM is fleshing-out things with tags that other people have 
mapped. In terms of tags, it is possible it is much higher.

Then there are others that like to go back and standardise things, e.g. many 
mobile phone masts get mapped as man_made=tower instead of man_made=mast. I did 
an exercise recently to correct and flesh out many of these, adding the 
landuse, site boundary, buildings, etc. In a  few months, I'll do another 
exercise.

Much of my editing has been in power, railways, pipelines, post, police, 
man_made objects, bus stops, speed limits (where I will also add surface=* and 
lanes=*) and the places I have lived or visited because those are things I have 
at least some knowledge about. However, in some cases, it has taken years to 
build up that knowledge. The only relations I have mapped are junction turn 
restrictions. I have never mapped a townland - but I'm currently going through 
them to add logainm references.

We are all contributing.

Colm

---
Never doubt that a small group of thoughtful, committed citizens can change the 
world. Indeed, it is the only thing that ever has. Margaret Mead

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

Re: [Talk-it] Confini codice postale

[Maurizio Napolitano]

> I confini dei codici postali sono previsti in OSM [1], Germania e Austria
> sono completamente coperte da relazioni di questo tipo, non capisco perché
> in Italia non dovremmo inserirle.
> Tanto più che c'è chi paga 26 € + IVA per avere mappe statiche dei confini
> dei CAP cittadini su sfondo OSM [2], quindi si tratta sicuramente di dati di
> un certo interesse.

Poste Italiane non rilascia i CAP in open data proprio perchè sono un
prodotto in vendita.
https://business.poste.it/professionisti-imprese/prodotti/cap-professional-dati-toponomastici-localita-italiane.html

> Se tu hai voglia di fare questo lavoro ti invito a ripristinare il percorso
> cancellato, trasformandolo però in multipoligono, in modo di avere un solo
> percorso ogni due CAP confinanti e poter sfruttare i confini comunali già
> presenti.

A monte farei una verifica se questo è concesso.
Per assurdo potremmo aprire un crowdfunding per comprare i CAP da
Poste Italiane e rilasciarli in opendata, ma se i termini del riuso
del dataset dicono che questo non è possibile, allora non si può fare.

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

Re: [Talk-it] Confini codice postale

[Maurizio Napolitano]

On Thu, May 14, 2020 at 6:46 PM Luigi Scuotto  wrote:
>
> Il Comune di bergamo e suddiviso in tante zone quello generico e il 24100.
> Le zone sono 24121,24122,24123,241224,fino al 129.
> Avevo ricalcato il limite del cap 24122 me stato detto che bastava quello del 
> numero e così lo cacellato.

Per curiosità: da quale sorgente hai fatto il ricalco?

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

Re: [Talk-it] Confini codice postale

[Maurizio Napolitano]

> I confini comunali presenti in OSM (presi, se ricordo bene, da ISTAT) sono 
> spesso approssimativi.

Se non erro è un import del 2011.
Sarebbero anche da sistemare.
Da quello che so in Italia ci sono circa 300 cause di problemi di
confine fra amministrazioni di vario livello.

> Spesso non consentono di identificare correttamente se un civico appartiene a 
> un determinato comune (e di conseguenza neppure il CAP).
> Quindi secondo me non vale la pena di creare dei nuovi boundary di tipo 
> postal_code ad hoc (non si può aggiungere questo tag al boundary di tipo 
> administrative, perché questo è un altro tipo di boundary).
A me non spiacerebbe avere boundary che contengono i CAP perchè,
quando cambiano, poi bisogna rincorrere tutti i punti inseriti.
Su Trento (dove vivo) ogni tanto trovo ancora numeri civici con il vecchio cap.

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

Re: [OSM-talk-fr] Point d'apport volontaire, point de collecte, point de regroupement

[David Pédehourcq]

@yves

>Comme les couleurs doivent être normalisées en France
Malheureusement non, si on pousse même un peu le sujet les consignes de tri,
le nom des déchets et même les picto de représentation ne sont pas les mêmes
d'une ville à l'autre ... ça devrait s’harmoniser, c'est en cours et ça
avance bien, mais la couleur y en a pour 10 ans :) 

>@David
>> on en bouge environ 10 par jour pour la maintenance ou autre
>>J'interprète ça plutôt comme on enlève (pour une maintenance) la colonne
ref=xxx qu'on remplace par la ref=yyy

oui, ma réflexion portait surtout sur l’intérêt limité de référencer les
numéros de série

>@Vincent
>> j'ai l'impression aujourd'hui que majoritairement (donc sans parler
>> "métier") si je me retrouve avec des gens nous allons distinguer le "tri,
>> recyclable" des "déchets, ordures ménagères"

Aujourd'hui, nous notre besoin c'est même encore plus basique c'est : j'ai
un déchet, où je peux le mettre ? Que ce soit un bac, une déchetterie ou une
colonne les gens s'en fichent, notre intérêt à nous (SITCOM) c'est que ça
finisse pas dans la forêt :) Ensuite *si* Mme Michou voit que pour jeter son
verre elle doit faire 50m de plus que pour jeter les Ordures Ménagères, on
espère qu'elle va faire un effort et trier ses déchets. L’intérêt de la
démarche c'est que chacun puisse visualiser les différents points de
collecte et les flux qui y sont acceptés et les différentes infrastructures
à sa disposition afin d’encourager le Tri.

>Moi aussi, mais à gérer dans le temps et dans les softs ça complique : KISS
-> amenity= recycling  + recycling:waste=yes seulement :)
C'est le plus simple effectivement mais du coup waste_disposal ne sert plus
? Ou quel serait son usage ? Le "risque" c'est qu'à la fin on ne puisse pas
faire une carte de france avec toutes les données OSM pour dire où on peut
apporter ses déchets si on utilise pas tous les même nomenclature...




--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [Talk-it] Confini codice postale

[Maurizio Napolitano]

Il gio 14 mag 2020, 16:47 Luigi Scuotto  ha
scritto:

> Ciao e dagli con ste fonti.
>

Perdonami ma mi sembra una domanda più che legittima


Ricalcato i numeri con codoce postale,
>


Cosa intendi dire?

se non serve lo cancello ed evito ti fare anche gli altri.
>

Il dato che descrive le aree geografiche dei codice postali serve
tantissimo ed è una delle risorse più difficili da trovare in opendata


Ciao Gigi
>
>
> Il giorno gio 14 mag 2020 alle ore 16:08 Cascafico Giovanni <
> cascaf...@gmail.com> ha scritto:
>
>> Fonti?
>> Credo siano comunque sufficienti quelli sugli addr:postcode
>>
>> Il gio 14 mag 2020, 14:09 Luigi Scuotto  ha
>> scritto:
>>
>>> Buongiorno
>>> Volevo sapere se i confini da me segnati vanno bene.
>>> Prima di fare anche gli altri.
>>> ID 85199286
>>> Ciao Gigi
>>> ___
>>> 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: [Talk-br] 1. Formato de endereço no Brasil (Ricardo Bigio)

[Ao Vivo]

Bom dia Ricardo.

Você poderia especificar  melhor a sua dúvida sobre os endereços?

O que você não está conseguindo fazer no openstreetmap?

 Seria mapear endereço?

 Inserir endereço em lojas?

Ou não tem a camada de endereços na região onde se quer mapear?

Ou você está querendo os dados de órgão público  ou Seria outra dúvida?

Poderia ajudar nos a entender a sua dúvida e tentar lhe ajudar.

Aguardo resposta.

Raphael de  Ássis.

Em Sex, 15 de mai de 2020 08:05, 
escreveu:

> Enviar submissões para a lista de discussão Talk-br para
> talk-br@openstreetmap.org
>
> Para se cadastrar ou descadastrar via WWW, visite o endereço
> https://lists.openstreetmap.org/listinfo/talk-br
> ou, via email, envie uma mensagem com a palavra 'help' no assunto ou
> corpo da mensagem para
> talk-br-requ...@openstreetmap.org
>
> Você poderá entrar em contato com a pessoa que gerencia a lista pelo
> endereço
> talk-br-ow...@openstreetmap.org
>
> Quando responder, por favor edite sua linha Assunto assim ela será
> mais específica que "Re: Contents of Talk-br digest..."
>
>
> Tópicos de Hoje:
>
>1. Formato de endereço no Brasil (Ricardo Bigio)
>2. Nova proposta de classificação viária - Votação
>   encerrada (santamariense)
>
>
> --
>
> Message: 1
> Date: Thu, 14 May 2020 16:08:42 -0300
> From: Ricardo Bigio 
> To: Talk-br@openstreetmap.org
> Subject: [Talk-br] Formato de endereço no Brasil
> Message-ID:
> <
> cae_invot0pqo2p2s+wrdu7hicugayyjwbzhdv1rcducxd79...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Estou tendo dificuldades para endereços no Brasil.
> Qual é o formato de para pesquisa ?
> --
> ... Ricardo Bigio
> Cel: +55 (24) 9.8804.8777
> www.taugan.com
> -- Próxima Parte --
> Um anexo em HTML foi limpo...
> URL: <
> http://lists.openstreetmap.org/pipermail/talk-br/attachments/20200514/84b95e92/attachment-0001.htm
> >
>
> --
>
> Message: 2
> Date: Thu, 14 May 2020 19:03:08 -0300
> From: santamariense 
> To: talk-br 
> Subject: [Talk-br] Nova proposta de classificação viária -
> Votação encerrada
> Message-ID:
> <
> caazabt4jsql1j5xtxaempvjpg5aer162phybusqkgae2abh...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Registro aqui a finalização do período de votação da nova proposta de
> classificação viária. Votaram 5 mapeadores, onde 3 concordaram, sendo
> que 1 fez algumas ressalvas; 1 discordou da proposta, fazendo alguns
> apontamentos, ainda dentro do conceito funcional da rodovia, os quais
> podem ir sendo explorados e discutidos; E 1 se absteve na votação,
> embora também concorde com o conceito funcional. Dos que votaram,
> portanto, mais de 50% concorda com a proposta apresentada, sendo
> considerada aprovada.
>
> Alguns comentários foram feitos que poderiam levar a votar casos
> pontuais da proposta, e não ficou claro para mim se teria algo a ser
> votado desde já. se você tiver algo pontual a ser votado, manifeste-se
> a qualquer momento pois ... Não menos importante, lembro aqui que o
> texto da regra pode ir sendo modificado no avançar do mapeamento
> conforme algumas questões pontuais forem surgindo, sendo discutidas e
> votadas como de praxe.
>
> Com a aprovação dessa proposta, a mesma terá seu texto ajustado para
> excluir o que está tachado (foi excluido do texto original ao longo da
> discussão), excluir a cor verde de parte do texto (foi incluido), e
> modificar parte do texto de "proposta" para "regra", ou outra sugestão
> que queiram dar.
>
> Também serão atualizadas paginas relacionadas a classificação viária
> que tratarem sobre o tema, na maior parte dos casos apenas com a
> inclusão de uma nota no topo da página, e sempre que possível linkando
> a página da atual regra de mapeamento. Paginas a serem atualizadas:
>
> A -
> https://wiki.openstreetmap.org/wiki/Pt:How_to_map_a#Classifica.C3.A7.C3.A3o_de_vias
> B -
> https://wiki.openstreetmap.org/wiki/Brazil/Classifica%C3%A7%C3%A3o_de_vias
> C - https://wiki.openstreetmap.org/wiki/Proposta_Top_05_BR_%2B_1
> D - https://wiki.openstreetmap.org/wiki/Pt:Key:highway
> E - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dmotorway
> F - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dtrunk
> G - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dprimary
> H - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dsecondary
> I - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dtertiary
> J - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dunclassified
> K - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dresidential
> L -
> https://wiki.openstreetmap.org/wiki/Pt:Highway:International_equivalence
> M - https://wiki.openstreetmap.org/wiki/Highway:International_equivalence
>
> Assim que as modificações forem feitas, a diferença entre antes e
> depois será apresentada num próximo e-mail, por meio de link para wiki
> contendo 

Re: [Talk-it] Confini codice postale

[Maurizio Napolitano]

On Thu, May 14, 2020 at 6:17 PM Damjan Gerl  wrote:
>
> Correggetemi se sbaglio, ma credo che i cap valgono per il comune intero, 
> quindi da applicare alla relazione del comune. Solamente alcune città in 
> Italia hanno più cap per il territorio comunale (tra queste Trieste, le altre 
> non so, ma non ci sono tante)

Non sono tante e nemmeno poche (circa la metà dei capoluoghi di
provincia) e a spanne quindi anche una buona fetta della popolazione
(ragionando in termini di dimensioni delle città)
http://www.comuni-italiani.it/cap/multicap.html

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

Re: [Talk-it] Confini codice postale

[Francesco Ansanelli]

Buongiorno Luigi,

devo dare anche io ragione a Cascafico, per gli import c'è tolleranza zero
e vanno discussi su una mailing list a parte (internazionale in lingua
inglese).
Io sono il primo a essere contro la procedura attuale, ma non ci possiamo
fare nulla proprio nulla...
Se qualcuno si dovesse lamentare perché il diritto sui generis (proprietà
intellettuale del dato) non è rispettato, OSM dovrebbe mettersi degli
avvocati ed, in ogni caso, se qualcuno si dovesse lamentare del tuo operato
con il DWG (anche senza esserne titolare) si rischia di perdere tutto il
tuo lavoro (revert e ban).
Cascafico ha seguito molto da vicino diversi import e ti sa sicuramente
consigliare bene, ma non ti può autorizzare da solo e, senza un progetto
pubblico in cui si spiega la procedura, non lo farà nessun altro.

Francesco


Il ven 15 mag 2020, 13:11 cuno Scuotto  ha
scritto:

> Scusa non riesco a capire, dici che devo rivolgermi a qualcunaltro?
> Non so era una domanda che pensavo potessi rispondermi, non sono per le
> cose licenze diritti e cose varie se voglio fare una cosa la faccio.
> Le fermate dei pulma non li ho importati ma bensì le ho caricate se non
> sbaglio circa 10 anni fa da gpx tutte fatte da me.
> Cosa intendi revoca?
> Gigi
>
>
> Il giorno ven 15 mag 2020 alle ore 12:48 Cascafico Giovanni <
> cascaf...@gmail.com> ha scritto:
>
>> Scusa Luigi, ma vorrei chiarire alcune cose:
>>
>> da due mesi per Bergamo hai importato oltre 20k civici, hai importato le
>> fermate degli autobus, hai importato centinaia di parcheggi in formato
>> poligono, credo che tu sappia sia quali sono i requisiti di una licenza,
>> sia usare gli strumenti GIS più adatti agli import. Il punto è che sembra
>> ti dia fastidio documentare tutto ciò.
>>
>> Indubbiamente è molto utile ciò che hai fatto (sopra gli addr ci ho
>> costruito un centinaio di punti di interesse delivery:covid19), ma a me in
>> questa mailing list hanno fatto il pelo per molto meno per documentazione e
>> licenza e mi sorprende che ora sia solo io a fare la figura del pignolo
>> rompiballe. A meno che non vogliamo fare una revoca per la situazione, che
>> per me va benissimo.
>>
>> Per i CAP non mi sbatterei su tecniche di conversione e licenze: ogni
>> nodo-indirizzo importato lo ha già.
>>
>>
>> Il giorno ven 15 mag 2020 alle ore 12:15 Luigi Scuotto <
>> luigiscuott...@gmail.com> ha scritto:
>>
>>> la mappa dei quartieri lo scaricata da qui dimmi se si può usare, senò
>>> non mi ci metto neanche a referenziare.
>>>
>>> https://www.arcgis.com/apps/webappviewer/index.html?id=f79b62f848404d43837b6946bf20f967
>>> Gigi
>>>
>>> Il giorno ven 15 mag 2020 alle ore 12:09 Luigi Scuotto <
>>> luigiscuott...@gmail.com> ha scritto:
>>>
 io ho provato con qgis a referenziare una mappa scaricata in pdf lo
 allegata a un messagio ma e stato bloccato era troppo grande non so se lo
 sbloccheranno.
 non sono capace con qgis creare poligoni senò usavo i cap.
 Gigi


 Il giorno ven 15 mag 2020 alle ore 11:01 Martin Koppenhoefer <
 dieterdre...@gmail.com> ha scritto:

>
>
> sent from a phone
>
> > On 15. May 2020, at 10:50, Cascafico Giovanni 
> wrote:
> >
> > Se proprio volete fare dei poligoni che delimitino i vari CAP di
> Bergamo, esiste (e lo sto provando) un plugin per Qgis che si chiama
> concavehull.
>
>
> io direi di non rimuovere per ora i CAP dai singoli indirizzi anche
> quando si ha già messo un tag per un poligono.
>
> 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
>>
> ___
> 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] Confini codice postale

[Luigi Scuotto]

Scusa non riesco a capire, dici che devo rivolgermi a qualcunaltro?
Non so era una domanda che pensavo potessi rispondermi, non sono per le
cose licenze diritti e cose varie se voglio fare una cosa la faccio.
Le fermate dei pulma non li ho importati ma bensì le ho caricate se non
sbaglio circa 10 anni fa da gpx tutte fatte da me.
Cosa intendi revoca?
Gigi


Il giorno ven 15 mag 2020 alle ore 12:48 Cascafico Giovanni <
cascaf...@gmail.com> ha scritto:

> Scusa Luigi, ma vorrei chiarire alcune cose:
>
> da due mesi per Bergamo hai importato oltre 20k civici, hai importato le
> fermate degli autobus, hai importato centinaia di parcheggi in formato
> poligono, credo che tu sappia sia quali sono i requisiti di una licenza,
> sia usare gli strumenti GIS più adatti agli import. Il punto è che sembra
> ti dia fastidio documentare tutto ciò.
>
> Indubbiamente è molto utile ciò che hai fatto (sopra gli addr ci ho
> costruito un centinaio di punti di interesse delivery:covid19), ma a me in
> questa mailing list hanno fatto il pelo per molto meno per documentazione e
> licenza e mi sorprende che ora sia solo io a fare la figura del pignolo
> rompiballe. A meno che non vogliamo fare una revoca per la situazione, che
> per me va benissimo.
>
> Per i CAP non mi sbatterei su tecniche di conversione e licenze: ogni
> nodo-indirizzo importato lo ha già.
>
>
> Il giorno ven 15 mag 2020 alle ore 12:15 Luigi Scuotto <
> luigiscuott...@gmail.com> ha scritto:
>
>> la mappa dei quartieri lo scaricata da qui dimmi se si può usare, senò
>> non mi ci metto neanche a referenziare.
>>
>> https://www.arcgis.com/apps/webappviewer/index.html?id=f79b62f848404d43837b6946bf20f967
>> Gigi
>>
>> Il giorno ven 15 mag 2020 alle ore 12:09 Luigi Scuotto <
>> luigiscuott...@gmail.com> ha scritto:
>>
>>> io ho provato con qgis a referenziare una mappa scaricata in pdf lo
>>> allegata a un messagio ma e stato bloccato era troppo grande non so se lo
>>> sbloccheranno.
>>> non sono capace con qgis creare poligoni senò usavo i cap.
>>> Gigi
>>>
>>>
>>> Il giorno ven 15 mag 2020 alle ore 11:01 Martin Koppenhoefer <
>>> dieterdre...@gmail.com> ha scritto:
>>>


 sent from a phone

 > On 15. May 2020, at 10:50, Cascafico Giovanni 
 wrote:
 >
 > Se proprio volete fare dei poligoni che delimitino i vari CAP di
 Bergamo, esiste (e lo sto provando) un plugin per Qgis che si chiama
 concavehull.


 io direi di non rimuovere per ora i CAP dai singoli indirizzi anche
 quando si ha già messo un tag per un poligono.

 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
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Point d'apport volontaire, point de collecte, point de regroupement

[Yves P.]

@Marc

>> -"recycling" avec uniquement waste=yes
>> C'est bizarre de dire qu'on a un point de collecte de tri ou on prend pas 
>> le tri (uniquement les ordures ménagères) 
> 
> cette solution n'est pas préconisée par la page anglaise qui sert
> souvent de référence.
En soit le(s) wiki(s) ne font pas forcément consensus ;)

> elle n'est portée que par 2 personnes ici.
> elle n'était pas non plus la solution retenue lors de la discussion
> précédente en mars.
Je n'ai pas suivi cette discussion à l'époque. Je ne crois pas qu'il y ait eu 
non plus de consensus. Chacun à donné son point de vue.

Certes, Stéphane à choisi la version amenity=waste_disposal pour son import 
Osmose.
Reste à savoir comment ça va être intégré ;)

@David
> on en bouge environ 10 par jour pour la maintenance ou autre
J'interprète ça plutôt comme on enlève (pour une maintenance) la colonne 
ref=xxx qu'on remplace par la ref=yyy

@ Stéphane
> Il y a déjà un fichier traité dans Osmose : Clisson Sèvre et Maine Agglo 
> Yep,
>  j'en suis à l'origine, et on en a discuté un peu ici :
> 

Merci pour les infos :)

Des photos seraient les bienvenues pour différencier les 2 types de 
conteneurs/déchets.

Aussi concernant le système de clés électroniques.
Heureusement, c'est disponible ici :
Conteneurs collectifs à clé ou à badge 

Colonnes à déchets ménagers 

 — avec clé modèle 1875 :D
Colonnes enfouies 

 — avec badge RFID (NFC ?)

@Vincent
> j'ai l'impression aujourd'hui que majoritairement (donc sans parler "métier") 
> si je me retrouve avec des gens nous allons distinguer le "tri, recyclable" 
> des "déchets, ordures ménagères", qui à mon avis aujourd'hui est la 
> distinction entre :
> 
> amenity=waste_disposal
> amenity=recycling
> au passage ce distingo est aussi utilisé par exemple par 
> https://openrecyclemap.org 
Il n'y a pas vraiment de distinguo. cette carte n'affiche que ce qui est 
recyclable, donc ne montre pas amenity=waste_disposal, ni amenity= recycling + 
recycling:waste=yes
(la requête overpass 

 remonte les tout)
> après que le waste disposal ou le recycling soit en colonne, enterré c'est 
> des tags "secondaires" je pense. 
> 
Concernant les nuisances visuelles, olfactives, sonore? et l'accessibilité ça 
fait une différence ;)
Concernant l'évolution aussi (les semi/enterrées ne se déplacent plus).

> Aujourd'hui, j'ai tendance à penser que amenity="waste_disposal" c'est 
> "seulement" quand il y a des déchets non triés par l'habitant, c'est à dire 
> ce que l'on nomme communément la poubelle, les poches noires, les ordures 
> ménagères, "tout ce qui n'est pas triés".
Moi aussi, mais à gérer dans le temps et dans les softs ça complique : KISS -> 
amenity= recycling  + recycling:waste=yes seulement :)
__
Yves___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Nouvel outil : od2osm

[Marc M.]

Le 15.05.20 à 12:12, Nicolas Bétheuil a écrit :
> On m'avait parlé de PDI / PDA, de distance du bati pour la conflation
> mais j'ai pas tout compris (même les acronymes).

pour essayer de faire simple :
si un noeud ne contient qu'une addr en tag principal (cad
sans compter source=* created_by=* et autres bruits de fond),
il ne faut pas le squatter pour y mettre un poi shop amenity craft etc

dans ton cas :
ceci est une adresse https://www.openstreetmap.org/node/1300983804
il ne faut pas la transformer en restaurant
https://master.apis.dev.openstreetmap.org/node/4319598216
mais au besoin créer un 2ieme objet pour le restaurant (et là tu
vas vouloir renseigner l'addr du resto, et c'est le drame pour
lequel on va te proposer une usine à gaz fr-fr supporté par aucune app)

En passant, pour aider le rendu, c'est bien de "rentrer" le POI
un peu + loin dans le bati, après tout le resto n'est pas sur la facade

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

Re: [Talk-it] Confini codice postale

[Cascafico Giovanni]

Scusa Luigi, ma vorrei chiarire alcune cose:

da due mesi per Bergamo hai importato oltre 20k civici, hai importato le
fermate degli autobus, hai importato centinaia di parcheggi in formato
poligono, credo che tu sappia sia quali sono i requisiti di una licenza,
sia usare gli strumenti GIS più adatti agli import. Il punto è che sembra
ti dia fastidio documentare tutto ciò.

Indubbiamente è molto utile ciò che hai fatto (sopra gli addr ci ho
costruito un centinaio di punti di interesse delivery:covid19), ma a me in
questa mailing list hanno fatto il pelo per molto meno per documentazione e
licenza e mi sorprende che ora sia solo io a fare la figura del pignolo
rompiballe. A meno che non vogliamo fare una revoca per la situazione, che
per me va benissimo.

Per i CAP non mi sbatterei su tecniche di conversione e licenze: ogni
nodo-indirizzo importato lo ha già.


Il giorno ven 15 mag 2020 alle ore 12:15 Luigi Scuotto <
luigiscuott...@gmail.com> ha scritto:

> la mappa dei quartieri lo scaricata da qui dimmi se si può usare, senò non
> mi ci metto neanche a referenziare.
>
> https://www.arcgis.com/apps/webappviewer/index.html?id=f79b62f848404d43837b6946bf20f967
> Gigi
>
> Il giorno ven 15 mag 2020 alle ore 12:09 Luigi Scuotto <
> luigiscuott...@gmail.com> ha scritto:
>
>> io ho provato con qgis a referenziare una mappa scaricata in pdf lo
>> allegata a un messagio ma e stato bloccato era troppo grande non so se lo
>> sbloccheranno.
>> non sono capace con qgis creare poligoni senò usavo i cap.
>> Gigi
>>
>>
>> Il giorno ven 15 mag 2020 alle ore 11:01 Martin Koppenhoefer <
>> dieterdre...@gmail.com> ha scritto:
>>
>>>
>>>
>>> sent from a phone
>>>
>>> > On 15. May 2020, at 10:50, Cascafico Giovanni 
>>> wrote:
>>> >
>>> > Se proprio volete fare dei poligoni che delimitino i vari CAP di
>>> Bergamo, esiste (e lo sto provando) un plugin per Qgis che si chiama
>>> concavehull.
>>>
>>>
>>> io direi di non rimuovere per ora i CAP dai singoli indirizzi anche
>>> quando si ha già messo un tag per un poligono.
>>>
>>> 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] Point d'apport volontaire, point de collecte, point de regroupement

[Yves P.]

—
Yves Pratter




> Le 15 mai 2020 à 11:34, David Pédehourcq  a écrit :
> 
> 
>> 
>> Ce qui serait bien pour les contributeurs OSM, c'est de normaliser les
>> fichiers de données (un peu comme les parking).
>> On pourrait ainsi avoir à terme un seul fichier national sur data.gouv.fr
>> :)
>> 
>> Pour tous le monde car on aurait enfin un standard exploitable!
> Avant d'avoir un seul fichier on peut définir une trame d'import et un
> outil d'import comme pour le géocodeur data.gouv.fr
Effectivement (notez le "à terme" qui modère mon ardeur :D)

> En fait nous on souhaiterai utiliser https://geodatamine.fr/ pour faire
> l'extraction depuis OSM => data.gouv.fr 
Les données OSM sont probablement très hétérogènes. De plus dans OSM il y a un 
aspect international qui dépasse éventuellement le cadre franco-français.

> 
> D'où l’intérêt d'avoir la même anthologie pour décrire un point d'apport
> volontaire qui ne contient que des Ordures Ménagères.

J'ai fait un export à Besançon avec geodatamine : il sort toutes les colonnes 
concernant le type de déchets.
glass;glass_bottles;paper;clothes;cans;plastic_bottles;plastic;waste;cardboard;plastic_packaging;batteries;metal;newspaper;paper_packaging;green_waste;shoes;organic;books;electrical_appliances;beverages_cartons;small_appliances;wood;aluminium;computers;toys

Comme les couleurs doivent être normalisées en France, pour faciliter la saisie 
et être cohérent avec cette (future) normalisation, il faut aussi le faire pour 
ces tags.
Une fois un consensus trouvé, on pourra adapté le greffon de JOSM pour cliquer 
sur les couleurs des bacs plutôt que sur le détail de ce qu'il contient 
effectivement.

Vert (Verre)
glass_bottles
glass ?
Bleu
paper
cardboard ?
newspaper
paper_packaging
books ??
beverages_cartons
Jaune (dans le Jura le bleu va dans le bac jaune en l'absence de bac bleu)
cans
plastic_bottles
plastic
plastic_packaging
metal ?
aluminium
Noir
waste
Blanc (ce n'est pas une couleur normalisée ? les bacs chez moi sont plutôt 
blanc)
clothes
shoes ?
"composte"
green_waste
organic ???
En déchèterie (dans dans bacs séparés)
batteries
metal
green_waste + organic ?
electrical_appliances
small_appliances
wood
computers
toys
pas définis dans OSM ?
huiles (vidange, frites)
produits toxiques (peintures, solvants…)
lampes basse consommation
gravats

> Je suis en contact avec d'autres collectivités, j'aimerai bien que le projet 
> "fasse des petits" :)
Nous aussi :)

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

Re: [OSM-talk-fr] Point d'apport volontaire, point de collecte, point de regroupement

[Vincent Bergeot]

Le 15/05/2020 à 08:55, Jérôme Seigneuret a écrit :


Deux solutions s'offrent donc à nous pour les caractériser :

-"recycling" avec uniquement waste=yes
C'est bizarre de dire qu'on a un point de collecte de tri ou on
prend pas le
tri (uniquement les ordures ménagères)

C'est comme tu le disais "recycling" est employé faute d'avoir mis le 
processus métier en avant. ducoup c'est la même chose que dans les 
appels d'offre: on utilise Point d'Apport Volontaire Ordure Ménagère 
alors que c'est en rien de l’apport volontaire
C'est de l'évacuation de déchets trié en recyclable et non recyclable. 
conteneurisé ou non avec un mode de regroupement ou pas et un mode 
d'enlèvement
waste =yes c'est justement le fait d'exploiter des format de conteneur 
associé à des colonnes de recyclable.



-"waste_disposal"
Si je me réfère au wiki on a pas tous les tags pour caractériser
le type de
colonne, mais c'est pas le plus embêtant. Le plus embêtant c'est
de dire que
le type principal du point est différent alors que sur le terrain,
visuellement c'est comme un point tri, collecté par le même type
de camion



disons que j'ai l'impression qu'il y a la friction entre la vision 
métier et la vision "madame Michu".


j'ai l'impression aujourd'hui que majoritairement (donc sans parler 
"métier") si je me retrouve avec des gens nous allons distinguer le 
"tri, recyclable" des "déchets, ordures ménagères", qui à mon avis 
aujourd'hui est la distinction entre :


 * amenity=waste_disposal
 * amenity=recycling

au passage ce distingo est aussi utilisé par exemple par 
https://openrecyclemap.org


après que le waste disposal ou le recycling soit en colonne, enterré 
c'est des tags "secondaires" je pense.





Je connais pas très bien OSM (mais j'me soigne ;)), mais si on suit la
logique historique j’aurais tendance à dire :
-amenity="recycling" : point tri qui maintenant s'appelle plutôt Point
d'apport volontaire (justement parce qu'un a des points colonnes
où on ne
trie pas)
-amenity="waste_disposal" : point de regroupement, qui
historiquement ne
concernait que les ordures ménagères mais maintenant peut contenir
des bacs
de tri sélectif

C'est tous le dilemme... Où l'on va mettre la séparation...



ce dilemme est la raison pour laquelle j'ai démarré au départ sur une 
notion de zone où un être humain amène quelques choses pour cela soit 
traité et évacué.


Aujourd'hui, j'ai tendance à penser que amenity="waste_disposal" c'est 
"seulement" quand il y a des déchets non triés par l'habitant, c'est à 
dire ce que l'on nomme communément la poubelle, les poches noires, les 
ordures ménagères, "tout ce qui n'est pas triés".


Dès qu'il y a du tri (au sens commun de ce que je fais dans ma maison, 
pas de ce qui est fait par les pros en terme de tri derrière, n'oublions 
pas qu'osm n'est *pas* une base métier) il me semble que c'est de 
l'amenity=recycling, sans doute avec un waste=yes (à creuser) quand on 
peut amener aussi son sac poubelle.



--
Vincent Bergeot

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

Re: [OSM-talk-fr] Point d'apport volontaire, point de collecte, point de regroupement

[Marc M.]

Bonjour, bienvenue, je suis content de voir que vous
avez trouvé la porte d'entrée :)

Le 15.05.20 à 08:10, David Pédehourcq a écrit :
> au Sitcom Côte Sud des Landes, un syndicat mixte qui gère la
> collecte des déchets sur tout le sud des Landes.

génial !

> -"recycling" avec uniquement waste=yes
> C'est bizarre de dire qu'on a un point de collecte de tri ou on prend pas 
> le tri (uniquement les ordures ménagères) 

cette solution n'est pas préconisée par la page anglaise qui sert
souvent de référence. elle n'est portée que par 2 personnes ici.
elle n'était pas non plus la solution retenue lors de la discussion
précédente en mars.

> -"waste_disposal"
> Si je me réfère au wiki on a pas tous les tags pour caractériser le type de
> colonne, mais c'est pas le plus embêtant. Le plus embêtant c'est de dire que
> le type principal du point est différent alors que sur le terrain,
> visuellement c'est comme un point tri, collecté par le même type de camion

la page anglaise est bien plus simple : elle dit que cela sert à mettre
des déchets non recylclable dans un contenant de taille moyen à grand
(par opposition à la poubelle de rue amenity=waste_backet)

> -amenity="recycling" : point tri qui maintenant s'appelle plutôt Point
> d'apport volontaire (justement parce qu'un a des points colonnes où on 
> ne trie pas)

point tri est réducteur. le tag s'applique tout aussi bien du contenant
individuel (le contributeur qui renseigne qu'à tel endroit c'est le
verre et que 1m à côté c'est le papier), qu'au "point tri" (un objet
contenant la liste des différents matérieux), qu'à la déchetterie

> -amenity="waste_disposal" : point de regroupement, qui historiquement ne
> concernait que les ordures ménagères mais maintenant peut contenir des bacs
> de tri sélectif

je ne ferrais pas cette différence.

> A noter que pour l'instant nous ne souhaitions pas aller au niveau de détail
> de la colonne mais bien de l’emplacement des points.

c'est une très très bonne idée de faire un premier pas simple
qui se concentre sur l'essentiel et le plus utile.

> J'attire votre attention sur le fait que sur 8000 point environ

un tel volume nécessitera la procédure d'import, c'est un peu long,
mais cela permet de faire tout en une fois.

> on en bouge environ 10 par jour pour la maintenance ou autre

par maintenance, voulez-vous dire que parmi ces 10, certains
sont absent pour la journée en vue par exemple de leur lavage ?
si oui, ce genre de modif ultra courte ne se renseigne généralement
pas dans osm.

Cordialement,
Marc

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

Re: [OSM-talk-fr] Nouvel outil : od2osm

[Nicolas Bétheuil]

Bonjour,

On m'avait parlé de PDI / PDA, de distance du bati pour la conflation mais
j'ai pas tout compris (même les acronymes).

On parlait du point
https://www.openstreetmap.org/node/3688329411
que j'ai créé en dev (parce qu'inexistant dans la conflation que j'avais
faite, à cause de la distance et du changement d'environnement et que c'est
pas ça que je testais)
https://master.apis.dev.openstreetmap.org/node/4319598216

L'échange en résumé
> Jean-Yvon
> Il ne me semble pas pertinent de placer le restaurant/traiteur (déjà
> Osmose va râler : restaurant ou traiteur ?) sur un point adresse.

> Moi :
> il y a beaucoup de points dans Osm ou le restaurant est à l'adresse.

> Jean-Yvon :
> Oui, à cause d'iD notamment qui incite à le faire ainsi.
> Pas forcément vigoureusement contre : il y a du positif et du négatif.
>Par contre "pourrir" la base en renforçant le cas ne va pas aider.

> Moi
> Le rapprochement se fait par tag principal : shop ou amenity pour
l'instant.
> Il n'y aura pas de "pourrissement supplémentaire", si le point existe
déjà à l'adresse ( ou un autre shop, amenity ...), les autres tags seront
rajoutés.
> Si le point n'existe pas, il sera créé.

Enfin :
J'ai trié mon ticket "améliorations"
https://github.com/wadouk/od2osm/issues/1

Je vais traiter 4 points avant de basculer sur le vrai OSM
- interdire de créer si requête des points à proximité à échoué (surcharge
overpass (quand sera en vrai) ou credentials OSM (pour le test) par exemple)
- avertir si champ principal (pour l'instant shop ou amenity) contient un
point virgule
- ajouter ou supprimer un tag manuellement
- rajouter en source du changeset l'url du jeu de données OpenData

Il y en a d'autres dans l'issue mais que je considère moins important.
Une fois ces 4 points traités, je basculerais sur le vrai OSM.

Salutations


Le jeu. 14 mai 2020 à 12:18, Nicolas Bétheuil  a écrit :

> J'ai complété le readme avec plusieurs détails. à discuter.
> Fait une issue sur les prochaines modifs en vrac.
>
> Le mer. 13 mai 2020 à 19:00, Nicolas Bétheuil  a
> écrit :
>
>> Bonjour,
>>
>> Comme je vous l'avais annoncé, j'ai réalisé un nouvel outil :
>> OpenData2OpenStreetMap aka od2osm.
>>
>> Vous pouvez aller jouer avec à l'adresse https://od2osm.cleverapps.io
>>
>> Il faut être authentifié sur l'environnement de dev OSM
>> https://master.apis.dev.openstreetmap.org en attendant vos commentaires
>> acerbes et votre jugement implacable pour le mettre sur le vrai "OSM".
>>
>> Vous pouvez en quelques clics ajouter de la données à OSM à partir d'un
>> jeu de données de test : les commerces parisiens qui livrent pendant le
>> confinement (oui c'est un peu parigo centré et peut être un peu dépassé,
>> mais c'est pour jouer aussi).
>>
>> Ces données sont comparées avec l'environnement de dev d'OSM qui est
>> plutôt vide et incohérent avec le fond de carte, vous allez donc faire
>> beaucoup de création.
>> Rien n’empêche de faire plusieurs fois une création par l'outil, charge
>> au contributeur de vérifier si un point existe déjà, l'outil aide à
>> retrouver les éventuels points dèjà existant.
>> J'en ai moi même déjà ajouté pour tester et que vous puissiez voir
>> comment se passe une comparaison (même si du coup les tags vont être
>> identique).
>>
>> J'attends vos commentaires, avec une certaine impatience, ici ou en issue
>> sur le repo github https://github.com/wadouk/od2osm/issues.
>>
>> Je cherche déjà à valider l'usage contributeur (ajout communautaire et
>> collaboratif) avant d'ajouté d'autres jeu de données.
>>
>> D'avance merci pour votre aide et vos critiques aiguisées.
>>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Confini codice postale

[Luigi Scuotto]

la mappa dei quartieri lo scaricata da qui dimmi se si può usare, senò non
mi ci metto neanche a referenziare.
https://www.arcgis.com/apps/webappviewer/index.html?id=f79b62f848404d43837b6946bf20f967
Gigi

Il giorno ven 15 mag 2020 alle ore 12:09 Luigi Scuotto <
luigiscuott...@gmail.com> ha scritto:

> io ho provato con qgis a referenziare una mappa scaricata in pdf lo
> allegata a un messagio ma e stato bloccato era troppo grande non so se lo
> sbloccheranno.
> non sono capace con qgis creare poligoni senò usavo i cap.
> Gigi
>
>
> Il giorno ven 15 mag 2020 alle ore 11:01 Martin Koppenhoefer <
> dieterdre...@gmail.com> ha scritto:
>
>>
>>
>> sent from a phone
>>
>> > On 15. May 2020, at 10:50, Cascafico Giovanni 
>> wrote:
>> >
>> > Se proprio volete fare dei poligoni che delimitino i vari CAP di
>> Bergamo, esiste (e lo sto provando) un plugin per Qgis che si chiama
>> concavehull.
>>
>>
>> io direi di non rimuovere per ora i CAP dai singoli indirizzi anche
>> quando si ha già messo un tag per un poligono.
>>
>> Ciao Martin
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Confini codice postale

[Luigi Scuotto]

io ho provato con qgis a referenziare una mappa scaricata in pdf lo
allegata a un messagio ma e stato bloccato era troppo grande non so se lo
sbloccheranno.
non sono capace con qgis creare poligoni senò usavo i cap.
Gigi


Il giorno ven 15 mag 2020 alle ore 11:01 Martin Koppenhoefer <
dieterdre...@gmail.com> ha scritto:

>
>
> sent from a phone
>
> > On 15. May 2020, at 10:50, Cascafico Giovanni 
> wrote:
> >
> > Se proprio volete fare dei poligoni che delimitino i vari CAP di
> Bergamo, esiste (e lo sto provando) un plugin per Qgis che si chiama
> concavehull.
>
>
> io direi di non rimuovere per ora i CAP dai singoli indirizzi anche quando
> si ha già messo un tag per un poligono.
>
> 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

[OSM-talk-fr] Webinaire Saisir des aménagements cyclables (temporaires) dans OSM Mercredi 20 mai 12h30

[Laurence P]

Bonjour,


Après le succès du webinaire *OpenStreetMap et le vélo* que nous vous 
avons proposé le 7 mai dernier, auquel *107* d'entre vous ont 
participé, et pour faire suite aux nombreuses demandes... d'avoir une 
suite... nous vous proposons un deuxième webinaire sur un sujet 
brûlant : les Aménagements Cyclables Temporaires.


Ce deuxième webinaire *Saisir des aménagements cyclables (temporaires) 
dans OSM* aura lieu le *mercredi 20 mai, de 12h30* à 14h, en visio 
conférence (logiciel Big Blue Button, qui ne nécessite pas 
d'installation).


L'essentiel de ce webinaire portera sur la création d'aménagements 
cyclables dans OSM, avec l'éditeur JOSM.


Ce webinaire sera d'un niveau plus technique que le 1er, mais il est 
bien sûr ouvert à tout le monde. Il sera orienté pour des personnes 
contribuant à OpenStreetMap pour la première fois.


Voici ce que nous vous proposons de faire (facultatif, vous pouvez 
bien sûr y assister en simple auditeur) avant d'assister au webinaire :
- installez le logiciel JOSM sur votre ordinateur : 
https://josm.openstreetmap.de/

- installez l'application Mapillary sur votre smarphone
- prenez en photo, via l'application Mapillary, des Aménagements 
Cyclables Temporaires autour de chez vous (cf tutoriel Mapillary : 
https://wiki.openstreetmap.org/wiki/File:MapillaryTutoAppli.pdf )
=> idéalement parcourez l'aménagement dans les 2 sens en le prenant en 
photo.

- envoyez les photos sur Mapillary (toujours via l'appli)
- dès que vous obtenez un lien de la part de Mapillary, vous vous 
inscrivez en fournissant 1 lien mapillary vers vos photos


=> Pendant le webinaire, Charles prendra exemple sur les photos qui 
auront été envoyées, dans l'ordre d'arrivée, pour traiter 4 ou 5 cas.


*Formulaire* pour vous inscrire (dernier délai pour s'inscrire = mardi 
19 mai 23h59 !) : 
https://framaforms.org/inscription-webinaire-saisir-des-amenagements-cyclables-temporaires-dans-osm-1589488748


Cordialement,

Laurence
laupic...@posteo.net
07 83 15 49 07




 Message transféré 
Sujet : 	[vélo-écoles FUB] Webinaire OpenStreetMap et le vélo - jeudi 
7 mai à 13h

Date :  Mon, 4 May 2020 16:59:27 +0200
De :Laurence Picado 
Répondre à :Laurence Picado 
Pour :  veloec...@sympa.fub.fr, echangememb...@sympa.fub.fr
Copie à :   Carto'CITÉ 



Bonjour,

en tant que cycliste, il y a de fortes chances que vous ayez déjà 
entendu parler d'*OpenStreetMap*, et même que vous ayez déjà utilisé 
(même sans le savoir) cette carte mondiale, libre, gratuite, et 
participative qui fonctionne comme peut le faire Wikipédia, avec des 
contributions citoyennes.


J'ai proposé à Charles Millet (dont vous trouverez une petite bio 
ci-dessous) de vous présenter un


*webinaire *sur le sujet*OpenStreetMap et le vélo
Ce jeudi 7 mai à 13h.*
Nous utiliserons le*logiciel BibBlueButton *
qui fonctionne avec votre navigateur (donc il n'y a rien à
installer, si vous souhaitez vous assurer que cela fonctionne
bien chez vous, contactez-moi _avant_ jeudi pour faire un test).

*Durée : *40 min de présentation + 40 min d'échange-discussion*
*

*Inscription (_avant_ jeudi) : *complétez le formulaire
ci-après

https://framaforms.org/inscription-visio-conference-openstreetmap-et-le-velo-1588166853

**

/_*Présentation du webinaire : *_/

Quand il est question de données géographiques pour décrire les 
aménagements cyclables, c'est de plus en plus souvent le projet 
OpenStreetMap qui est cité et utilisé. Son caractère universel et plus 
de 16 ans de développement collaboratif de la donnée et du modèle de 
description des aménagement font qu'aujourd’hui, la plupart des 
acteurs et des outils ont recours à OpenStreetMap pour les projets 
autour du vélo.
La présentation tentera de répondre à la question générale : Qu'est-ce 
que je peux en faire ? À travers des exemples et des démonstrations, 
je vous propose donc de découvrir les éléments majeurs de la 
thématique vélo de l'écosystème OpenStreetMap.


_*/Présentation de l'intervenant : /*_

Charles MILLET – Carto’Cité
Géomaticien en environnement et mobilité – Expert OpenStreetMap
Nombreux travaux sur la production de données, la maintenance des 
données et l'exploitation des données des aménagements cyclables et 
des itinéraires cyclables dans le domaine de la mobilité.

Formateur OpenStreetMap - QGIS - Grass Gis
Utilisateur intensif d'OpenStreetMap pour la mobilité et le tourisme

Très bonne semaine sous le signe du vélo !

Cordialement,

--
Laurence Picado
laupic...@posteo.net
07 83 15 49 07
www.veloetmarche.fr
/Dernier article de blog : Réécoutez 2 webinaires sur le code de la 
route à vélo et sur le code de la rue 
/


___
Talk-fr mailing list
Talk-fr@openstreetmap.org

[OSM-talk-fr] webinaire osm et les vélo : le replay, un document d'infos, et une liste de diffusion

[Laurence P]

Bonjour,

vous trouverez ci-après :

- le lien vers la vidéo du *replay du webinaire OpenStreetMap et le 
vélo* que nous vous avons proposé le 7 mai dernier au réseau de la FUB 
et auquel étaient présents *107* curieux.ses :

https://peertube.openstreetmap.fr/videos/watch/c27adaa2-8e26-4b49-8aad-a724ba0a406d


- le lien vers un fichier rassemblant l'ensemble des *questions qui se 
sont posées pendant ce webinaire*, les réponses qui ont pu y être 
apportées (merci à celles et ceux qui ont participé à la rédaction de 
ces réponses) et enfin les liens qui ont été présentés pendant la 
webinaire, ou ajoutés suite à vos questions.

https://wiki.openstreetmap.org/wiki/File:Pad_WebinaireOSM%26Velo20200507.pdf

/Vous pouvez retrouver l'ensemble de ces documents sur cette page :
https://wiki.openstreetmap.org/wiki/User:Paysages/Webinaires
/


Par ailleurs, Mathias Vadot de l'ADAV a créé une *liste de diffusion 
OpenStreetMap et le vélo*.
Vous pouvez vous y abonner si vous le souhaitez, pour y aborder des 
sujets mêlant ces 2 thématiques.
Vous abonner à la liste OpenStreetMap et le vélo : 
https://framalistes.org/sympa/subscribe/velo_osm


Et je vous prie de nous excuser, nous n'avons communiqué pour ce premier 
webinaire que vers le réseau de la FUB car nous avions des craintes 
quand à la résistance de l'outil à la charge... mais nous proposons un 
2e webinaire ce mercredi 20 mai (je vous envoie un 2e email) maintenant 
que nous sommes rassurés sur ce point.


Cordialement,

Laurence
laupic...@posteo.net
07 83 15 49 07



 Message transféré 
Sujet : 	[vélo-écoles FUB] Webinaire OpenStreetMap et le vélo - jeudi 7 
mai à 13h

Date :  Mon, 4 May 2020 16:59:27 +0200
De :Laurence Picado 
Répondre à :Laurence Picado 
Pour :  veloec...@sympa.fub.fr, echangememb...@sympa.fub.fr
Copie à :   Carto'CITÉ 



Bonjour,

en tant que cycliste, il y a de fortes chances que vous ayez déjà 
entendu parler d'*OpenStreetMap*, et même que vous ayez déjà utilisé 
(même sans le savoir) cette carte mondiale, libre, gratuite, et 
participative qui fonctionne comme peut le faire Wikipédia, avec des 
contributions citoyennes.


J'ai proposé à Charles Millet (dont vous trouverez une petite bio 
ci-dessous) de vous présenter un


   *webinaire *sur le sujet*OpenStreetMap et le vélo
   Ce jeudi 7 mai à 13h.*
   Nous utiliserons le*logiciel BibBlueButton *
   qui fonctionne avec votre navigateur (donc il n'y a rien à
   installer, si vous souhaitez vous assurer que cela fonctionne
   bien chez vous, contactez-moi _avant_ jeudi pour faire un test).

   *Durée : *40 min de présentation + 40 min d'échange-discussion*
   *

   *Inscription (_avant_ jeudi) : *complétez le formulaire ci-après
   
https://framaforms.org/inscription-visio-conference-openstreetmap-et-le-velo-1588166853

**

/_*Présentation du webinaire : *_/

Quand il est question de données géographiques pour décrire les 
aménagements cyclables, c'est de plus en plus souvent le projet 
OpenStreetMap qui est cité et utilisé. Son caractère universel et plus 
de 16 ans de développement collaboratif de la donnée et du modèle de 
description des aménagement font qu'aujourd’hui, la plupart des acteurs 
et des outils ont recours à OpenStreetMap pour les projets autour du vélo.
La présentation tentera de répondre à la question générale : Qu'est-ce 
que je peux en faire ? À travers des exemples et des démonstrations, je 
vous propose donc de découvrir les éléments majeurs de la thématique 
vélo de l'écosystème OpenStreetMap.


_*/Présentation de l'intervenant : /*_

Charles MILLET – Carto’Cité
Géomaticien en environnement et mobilité – Expert OpenStreetMap
Nombreux travaux sur la production de données, la maintenance des 
données et l'exploitation des données des aménagements cyclables et des 
itinéraires cyclables dans le domaine de la mobilité.

Formateur OpenStreetMap - QGIS - Grass Gis
Utilisateur intensif d'OpenStreetMap pour la mobilité et le tourisme

Très bonne semaine sous le signe du vélo !

Cordialement,

--
Laurence Picado
laupic...@posteo.net
07 83 15 49 07
www.veloetmarche.fr
/Dernier article de blog : Réécoutez 2 webinaires sur le code de la 
route à vélo et sur le code de la rue 
/


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

Re: [Talk-GB] Quarterly Project Suggestion - drink_water:refill

[European Water Project]

Dear CJ et al.,

I have added the ability to take pictures directly in the app of drinking
water fountains and refill cafés which are already in OSM and showing in
the European Water Project Web App.

https://europeanwaterproject.org?lang=EN

Capturing an image from the webrtc camera and adding the users geo
coordinates to the exif meta data was a challenge.  The user takes the
geolocalized picture within the app and it shows up immediately within the
app after getting stored on an AWS  S3 storage (with the exif meta data).
 After that, the images are semi-manually copied to Mapillary and linked to
OpenStreetMap objects. I am separately in discussions with Wikimedia about
seeing if there is streamlined way to add the images on Commons as well.

Here is a video of how the image capture process works:

https://drive.google.com/open?id=1XbYC1xwsjCySv1g9LPHx3zX07SNtCeuI

Best regards,

Stuart

PS : It's great to see so many refill cafés showing up on the map. We are
almost at 300 refill establishments !



On Fri, 20 Mar 2020 at 14:01, European Water Project <
europeanwaterproj...@gmail.com> wrote:

> Dear CJ,
>
> I agree with your opinion of how open data Refill really is.
>
> The idea of contacting chains in Q3 or Q4 (or early next year depending on
> how the current crisis unfolds) makes a lot of sense.
>
> Best regards,
>
> Stuart
>
>
> On Fri, Mar 20, 2020, 13:55 Cj Malone  wrote:
>
>> "You can download our proprietary app, that uses our proprietary data, on
>> 2 proprietary app stores, on 2 proprietary platforms. The app is open."
>>
>> Doesn't make much sense to me, but oh well.
>>
>> Seriously though, I added the only local place I know about. But would it
>> be appropriate to contact some of the corporate chains involved, like Costa
>> and Starbucks, see if it is 100% universal across there UK stores and then
>> talk about an bulk import?
>>
>> Cj
>>
>> On 20 March 2020 10:55:39 GMT, European Water Project <
>> europeanwaterproj...@gmail.com> wrote:
>>>
>>> Dear All,
>>>
>>> Just got off a long conversation with Rebecca Burgess, CEO of Refill.
>>>
>>> Unsurprisingly, Refill has no plans to share any of their proprietary
>>> data, but their App is open because anybody can use it  :)
>>>
>>> Refill has plans to use more and more OpenStreetMap data to populate
>>> their network over time without re-contributing ...   Just a shame everyone
>>> can't just use the Refill App (sarcasm) !
>>>
>>> Best regards,
>>>
>>> Stuart
>>>
>>> PS: Stay safe !
>>>
>>> On Sat, 14 Mar 2020 at 23:59, European Water Project <
>>> europeanwaterproj...@gmail.com> wrote:
>>>
 Dear Andy,

 If Refill.org.uk  were to "license" their data to OSM, under what
 terms would that be concretely?  I don't want to misspeak (not show my
 total ignorance on the subject) when I talk to Rebecca Burgess, the Refill
 CEO on Tuesday.

 In the unlikely event that Refill's position changes, with whom can I
 put her in contact with?

 Best regards,

 Stuart

 On Sat, Mar 14, 2020, 21:10 Andy Mabbett 
 wrote:

> On Thu, 12 Mar 2020 at 11:27, Jake Edmonds via Talk-GB
>  wrote:
> >
> >  I understand Refill.org.uk are unwilling to license their data.
>
> They said this in July 2017:
>
>https://twitter.com/Refill/status/31637345234945
>
> I've been pressing them on the point of open licensing, recently:
>
>https://twitter.com/pigsonthewing/status/1216689988357718018
>
> and have again today chased them for a response:
>
>https://twitter.com/pigsonthewing/status/1238919492568260609
>
> --
> Andy Mabbett
> @Pigsonthewing
> http://pigsonthewing.org.uk
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>

>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>> ___
>> Talk-GB mailing list
>> Talk-GB@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb
>>
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] Point d'apport volontaire, point de collecte, point de regroupement

[David Pédehourcq]

>
> Ce qui serait bien pour les contributeurs OSM, c'est de normaliser les
> fichiers de données (un peu comme les parking).
> On pourrait ainsi avoir à terme un seul fichier national sur data.gouv.fr
>  :)
>
> Pour tous le monde car on aurait enfin un standard exploitable!
Avant d'avoir un seul fichier on peut définir une trame d'import et un
outil d'import comme pour le géocodeur data.gouv.fr


En fait nous on souhaiterai utiliser https://geodatamine.fr/ pour faire
l'extraction depuis OSM => data.gouv.fr

D'où l’intérêt d'avoir la même anthologie pour décrire un point d'apport
volontaire qui ne contient que des Ordures Ménagères. Je suis en contact
avec d'autres collectivités, j'aimerai bien que le projet "fasse des petits"
:)



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [Talk-it] European Water Project -- Rome April 24th Fountain Hunt

[European Water Project]

I have made a short video demonstrating how the app works for adding photos
of fountains

https://drive.google.com/open?id=148VdJLUROLsFAQlZ4mgxHFVmnjrMxpiM

Maybe we can get a photo of a Milanese Vedovelle  as part of the test ..

Have a nice weekend,

Stuart

https://europeanwaterproject.org?lang=IT

On Thu, 14 May 2020 at 15:40, European Water Project <
europeanwaterproj...@gmail.com> wrote:

> Hi Martin,
>
> Most of our uses don't know heads or tails about wikimedia commons and
> don't have a wiki commons account, so I think it is preferable not to
> introduce a wikimedia commons login interface. The user barrrier is in
> addition to the technical difficulties of implementation and maintenance. .
>
> Ulrich Lantermann from Wikimedia is looking into whether or not European
> Water Project can load images via an API with multiple author
> attributions.
>
> All the image uploads should be uploaded CC0 under the name of the
> project, so the name attribution may not be such a big deal.
>
> Best regards,
>
> Stuart
>
>
>
> On Thu, 14 May 2020 at 14:11, Martin Koppenhoefer 
> wrote:
>
>>
>>
>> sent from a phone
>>
>> > On 14. May 2020, at 13:09, European Water Project <
>> europeanwaterproj...@gmail.com> wrote:
>> >
>> > Wikimedia Switzerland has asked us if we would consider storing the
>> images on Commons which of course we would be happy to do if we can find a
>> solution for bulk uploading the images via an API
>>
>>
>> maybe it could be a link to commons upload with some values
>> preconfigured, so that the user would be the photo uploader to commons but
>> you would get the link to it (and the  association with a fountain in
>> OpenStreetMap)?
>>
>> Cheers Martin
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-es] Formación para geovoluntarios.org

[Jo]

Hola,

El español no es mi idioma maternal, pero soy bastante fluente. Hablo ambas
variaciones, porqué he aprendido el español en España y pués me fui a Perú.
De GIS solo conozco QGIS, pero de OpenStreetMap conozco muy bien el editor
JOSM.

Tienen alguna preferencia del tema? Edificios, rutas/itinerarios,
transporte público? No me conozco super bien en 3D, puedo explicar el
básico.

Polyglot

On Fri, May 15, 2020 at 10:57 AM Santiago Crespo 
wrote:

> Hola!
>
> Desde geovoluntarios.org están interesados en colaborar con OSM. El
> problema que tienen es que a pesar de que la inmesa mayoría de personas
> de esa comunidad son profesionales que usan ArcGIS, apenas tienen
> experiencia aportando a OSM.
>
> Les veo bastante motivados y con ganas de colaborar. La mayoría están en
> España pero hay también en América Latina y otros países, por lo que la
> formación tendría que ser en Español y por la tarde.
>
> ¿Hay alguien interesado en ofrecer formación online, mediante
> videollamada, a esta buena gente?
>
> Por favor que responda por aquí o por privado y nos organizamos.
>
> Recuerdo que alguna vez alguien compartió documentación útil para este
> tipo de formación. ¿Os importaría compartirla de nuevo?
>
> Gracias!
> Santiago
>
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [OSM-talk-fr] Ajouter des photos uniques de POI dans Mapillary

[European Water Project]

Bonjour à tous,



Pour ceux qui recevez ce message en double … désolé.



Je viens d’ajouter dans notre Web App la possibilité de prendre et ajouter
des photos directement dans notre App des cafés participants et des
fontaines où vous pouvez remplir votre gourde gratuitement sans créer du
déchet à usage unique.



C’était assez compliqué d’utiliser la caméra du téléphone et surtout
d’ajouter des coordonnées géographiques dans l’EXIF. Car l’image jpeg
capturée par l’élément html Canvas n’a pas d’Exif au départ.



Voici le lien vers la Web App https://europeanwaterproject.org/?lang=FR



Il suffit d’appuyer sur Ajouter/mettre à jour cette image … après que vous
appuyez pour avoir le popup d’une fontaine individuelle.

Et puis prendre une photo d’une fontaine qui apparaît immédiatement sur la
carte.



Voici une vidéo de l’App en action:
https://drive.google.com/open?id=1XbYC1xwsjCySv1g9LPHx3zX07SNtCeuI



Les photos sont stockées initialement sur un AWS S3 et puis transférer,
après curation manuelle, vers Mapillary et liées aux objets d’OSM. Les
étapes après le stockage sont toujours trop manuelles, mais le workflow est
acceptable.



J’ai testé cette nouvelle fonctionnalité sur une dizaine téléphones
modernes (Android et IOS) avec browserstack, mais je serai très
reconnaissant si quelques-uns parmi vous pourriez prendre une photo (avec
un téléphone récent) d’une fontaine près de chez vous qui apparaît déjà sur
l'App pour m’aider à la mieux tester … et surtout de me dire si vous avez
rencontré un problème.



Bien cordialement,



Stuart


On Fri, 17 Apr 2020 at 12:23, European Water Project <
europeanwaterproj...@gmail.com> wrote:

>
> *Je pensais plus à système de leur côté pour regrouper des photos
> ayant un point (un sujet) commun .*
> *C'est en fait très similaire aux catégories de Wikimedia Commons.*
>
> *Ça pourrait être un tag #Arc-de-Triomphe (ça existe peut-être déjà ?)*
>
> Il y a très peu de tags dans Mapillary et, basé sur mes conversations,
> Mapillary ne veut pas de tout développer une base de données de tags ou de
> catégoriser leurs images à la Wikimedia - pas de business case, donc pas
> de catégorie d'Arc de Triomphe.
>
> A bientot,
>
> Stuart
>
>
>
>
>
>
>
> On Fri, 17 Apr 2020 at 11:27, Yves P.  wrote:
>
>> le lien avec mapilary est il obligatoire ?
>>
>>
>> L'avantage de Mapillary c'est que ses photos sont visualisable dans
>> OsmAnd, iD, JOSM…
>> Qu'il y a une IA pour flouter ce qui doit l'être,
>> Que le stockage est pérenne
>> …
>>
>>  ils ont l'air de préférer les séquences, du coup ce n'est pas l'usage.
>>
>> On peut argumenter pour les aider à évoluer 
>> *Merci Stuart* à ce propos 
>>
>> Mapillary ne va pas garder une trace dans leur base de données de quel
>> objet OSM est présent dans l'image,
>>
>> Effectivement.
>> Je pensais plus à système de leur côté pour regrouper des photos ayant un
>> point (un sujet) commun .
>> C'est en fait très similaire aux catégories de Wikimedia Commons.
>>
>> Ça pourrait être un tag #Arc-de-Triomphe (ça existe peut-être déjà ?)
>>
>> Ou comme je le suggérait une "série" dédiée à un objet réel (qu'il soit
>> dans OSM, wikidata… ou non).
>>
>> donc c'est plutôt à nous de lier les images keys de Mapillary (qui sont
>> uniques et immuables) aux objets d'OSM.
>>
>> Effectivement, on peut utiliser une clé *image=http://xxx *
>> ou mieux dans ce cas, une clé *mapillary=** (sans URL )
>> C'est ce que l'on fait déjà.
>>
>> Peut-être ça serait mieux avec un wikidata item ? Ou les images key de
>> Mapillary pourraient être délimitées par des semicolons sur le key:mapillary
>>
>> Les valeurs multiples sont souvent pas ou mal gérées dans OSM 
>> Dans ce cas tu sélectionnes quelque photos à un moment donné, pour un
>> projet donné.
>>
>> Avec une série dédié à un sujet physique, on pourrais voir toutes les
>> photos.
>> Utile pour voir un bâtiment sous plusieurs angles, pour cartographier.
>> Ou pratique pour voir la plus "belle" photos réutilisable dans un autre
>> projet (wikipedia, osmhydrant…)
>>
>> , comme avec des images de wikimedia commons.
>>
>> Oui, cf. supra.
>>
>> __
>> 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: [OSM-talk-fr] Point d'apport volontaire, point de collecte, point de regroupement

[Jérôme Seigneuret]

>
> Ce qui serait bien pour les contributeurs OSM, c'est de normaliser les
> fichiers de données (un peu comme les parking).
> On pourrait ainsi avoir à terme un seul fichier national sur data.gouv.fr
>  :)
>
> Pour tous le monde car on aurait enfin un standard exploitable!
Avant d'avoir un seul fichier on peut définir une trame d'import et un
outil d'import comme pour le géocodeur data.gouv.fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Confini codice postale

[Martin Koppenhoefer]

sent from a phone

> On 15. May 2020, at 10:50, Cascafico Giovanni  wrote:
> 
> Se proprio volete fare dei poligoni che delimitino i vari CAP di Bergamo, 
> esiste (e lo sto provando) un plugin per Qgis che si chiama concavehull.


io direi di non rimuovere per ora i CAP dai singoli indirizzi anche quando si 
ha già messo un tag per un poligono.

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

Re: [OSM-talk-fr] Point d'apport volontaire, point de collecte, point de regroupement

[Yves P.]

> Je me présente rapidement, je suis David Pédehourcq
Bienvenue :)

> Sauf que maintenant, pour différentes raisons politiques et logistiques on
> peut collecter du tri en BAC et collecter des ordures ménagères en colonne.
> (j'évite volontairement le débat recyclage VS Tri VS valorisation qui ne me
> semble pas lié à OSM).
+1

> -"recycling" avec uniquement waste=yes
> C'est bizarre de dire qu'on a un point de collecte de tri ou on prend pas le
> tri (uniquement les ordures ménagères) 
> 
> -"waste_disposal"
> Si je me réfère au wiki on a pas tous les tags pour caractériser le type de
> colonne, mais c'est pas le plus embêtant.

> Le plus embêtant c'est de dire que
> le type principal du point est différent alors que sur le terrain,
> visuellement c'est comme un point tri, collecté par le même type de camion

C'est pour cela que je disais que même conteneur, même tag.

La tendance générale est à la réduction des déchets, qui passe (parfois) par le 
tri.
Aujourd'hui un "conteneur" contient uniquement des ordures ménagères, "demain" 
il pourra contenir des déchets triés…

> Là aussi on penserait dans un premier temps à un waste_disposal, mais
> finalement si y a du tri on va le passer en recycling, mais si j'ai qu'un
> bac jaune et un bac ordures ménagères on peut pas vraiment considéré que
> c'est un point tri.
La clé amenity=waste_disposal n'ayant pas de tags 
waste_disposal:plastic=yes/no… il me parait plus simple et plus logique 
d'utiliser amenity=recycling + …

> Je connais pas très bien OSM (mais j'me soigne ;)), mais si on suit la
> logique historique j’aurais tendance à dire : 
> -amenity="recycling" : point tri qui maintenant s'appelle plutôt Point
> d'apport volontaire (justement parce qu'un a des points colonnes où on ne
> trie pas) 
oui :)

> -amenity="waste_disposal" : point de regroupement, qui historiquement ne
> concernait que les ordures ménagères mais maintenant peut contenir des bacs
> de tri sélectif
non, KISS  (cf. supra)

> A noter que pour l'instant nous ne souhaitions pas aller au niveau de détail
> de la colonne mais bien de l’emplacement des points.
Un rendu peut "fusionner" les différents conteneurs.

> On aimerait faire la même chose pour la collecte
> en recensant tous les points de collecte avec les flux de déchets que l'on
> peut y amener. L'idée étant de maintenir ces données à jours très
> fréquemment on va rester sur le point de collecte et on ne va pas descendre
> au niveau du contenant.
Qu'il y ai un objet OSM par conteneur ou un pour un groupe, le tag ref permet 
d' "identifier" le point de regroupement.

> 
> J'attire votre attention sur le fait que sur 8000 point environ on en bouge
> environ 10 par jour pour la maintenance ou autre. Dans ce contexte
> référencer les numéros de série me semble peu pertinent.
Dans le Jura, il y en a peut-être 8000 au total. Ça doit bouger moins vite ;)
Ok, l'info "stable" est la référence (ID) du point d'apport volontaire ou de 
regroupement.

Ce qui serait bien pour les contributeurs OSM, c'est de normaliser les fichiers 
de données (un peu comme les parking).
On pourrait ainsi avoir à terme un seul fichier national sur data.gouv.fr 
 :)

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

Re: [Talk-it] Confini codice postale

[Cascafico Giovanni]

Ho dato un'occhiata, non trovo nessuna licenza definita e per quanto
riguarda il link [1] citato da bergamonews, la mappa mi da errore. Se
proprio volete fare dei poligoni che delimitino i vari CAP di Bergamo,
esiste (e lo sto provando) un plugin per Qgis che si chiama concavehull.

[1] http://arcg.is/2wASotq

Il giorno ven 15 mag 2020 alle ore 08:15 Luigi Scuotto <
luigiscuott...@gmail.com> ha scritto:

> Questa forse e meglio si puo usare?
> Gigi
>
> Il giorno gio 14 mag 2020 alle ore 22:47 Luigi Scuotto <
> luigiscuott...@gmail.com> ha scritto:
>
>> Come faccio a tirare fuori i poligoni da questa mappa?
>>
>> https://www.bergamonews.it/2017/08/12/riperimetrazione-della-citta-lamministrazione-rivaluta-i-confini-dei-quartieri/262317/
>>
>> Il giorno gio 14 mag 2020 alle ore 22:44 Luigi Scuotto <
>> luigiscuott...@gmail.com> ha scritto:
>>
>>>
>>> https://www.openstreetmap.org/search?query=Via%20palma%20il%20Vecchio%20Bergamo#map=16/45.6905/9.6620=T
>>>
>>> Il giorno gio 14 mag 2020 alle ore 22:42 Luigi Scuotto <
>>> luigiscuott...@gmail.com> ha scritto:
>>>
 La via e giusta perchè il Comune la Chiama coì sono stato io a inserire
 alt_name visto che non volete che cambi il nome della strada.
 Gigi

 Il giorno gio 14 mag 2020 alle ore 22:34 Cascafico Giovanni <
 cascaf...@gmail.com> ha scritto:

> Evidentemente la via Jacopo Palma il Vecchio segna il confine tra le
> due aree: 24128 a sinistra e 24121 a destra. Nel caso che hai citato i
> civici hanno un problema di altra natura: il nome delle strada è
> differente, gli addr:street trascurano "Jacopo".
>
> Il giorno gio 14 mag 2020 alle ore 22:12 Luigi Scuotto <
> luigiscuott...@gmail.com> ha scritto:
>
>> https://www.openstreetmap.org/node/7465010794
>> https://www.openstreetmap.org/node/7392320836
>> Queta e la stessa strada il 24121 a chi appartiene? e 24128?
>> Gigi
>>
>> Il giorno gio 14 mag 2020 alle ore 21:48 Cascafico Giovanni <
>> cascaf...@gmail.com> ha scritto:
>>
>>> I confini dei CAP sono sicuramente utili, ma se derivano da un
>>> contorno di addr:postcode omogenei appena importati (per questo 
>>> chiedevo a
>>> Luigi le fonti)  non aggiungono informazione.
>>> Se inserisco un nuovo civico in una zona di confine, a chi
>>> apparterrà?
>>> Se ne aggiungo uno in mezzo ad altri, non servirà una relazione per
>>> sapere che postcode dovrà avere.
>>>
>>> Il giorno gio 14 mag 2020 alle ore 21:34 totera 
>>> ha scritto:
>>>
 Luigi Scuotto wrote
 > Avevo ricalcato il limite del cap 24122 me stato detto che
 bastava quello
 > del numero e così lo cacellato.

 I confini dei codici postali sono previsti in OSM [1], Germania e
 Austria
 sono completamente coperte da relazioni di questo tipo, non capisco
 perché
 in Italia non dovremmo inserirle.
 Tanto più che c'è chi paga 26 € + IVA per avere mappe statiche dei
 confini
 dei CAP cittadini su sfondo OSM [2], quindi si tratta sicuramente
 di dati di
 un certo interesse.
 Se tu hai voglia di fare questo lavoro ti invito a ripristinare il
 percorso
 cancellato, trasformandolo però in multipoligono, in modo di avere
 un solo
 percorso ogni due CAP confinanti e poter sfruttare i confini
 comunali già
 presenti.
 Ciao,
 Gianluca

 [1] =
 https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dpostal_code
 [2] =

 https://www.edimapstore.com/cap-citta-jpeg/737-2152-mappa-cap-bergamo-jpg.html



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

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

>>> ___
>>> Talk-it mailing list
>>> Talk-it@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-it
>>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
 ___
> 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-se] Svenska riktlinjer för taggning för vandring & löpning

[Daniel Westergren]

Jag tycker vidare att vi skulle ha svenska översättningar med egna
bildexempel av
https://wiki.openstreetmap.org/wiki/Highway_tagging_samples/out_of_town och
https://wiki.openstreetmap.org/wiki/Highway_tagging_samples/urban.

Där skulle vi väldigt konkret med bildexempel kunna visa hur olika
"highway" bör taggas. *Håller ni med om taggningen av
bildexemplen på
https://wiki.openstreetmap.org/wiki/Highway_tagging_samples/out_of_town
?*

Tänker då på hur vi använder taggarna:

   - *surface *(gravel vs fine_gravel vs compacted t.ex. och ground vs dirt
   vs earth)
   - *tracktype *(även på path om det är en preparerad "path" som inte är
   en "track", för att därigenom skilja ut mot skogsstigar. grade2 och sämre
   implicerar någon form av unpaved)
   - *smoothness *("bad" eller sämre för skogsstigar)
   - *width *(typ 0,5-1 m för skogsstigar och normalt 2-3 m för preparerade
   "paths")
   - *mtb:scale *(enbart för singletrail, alltså det vi normalt menar med
   stig på svenska)
   - *trail_visibility* (enbart för stigar)

Det finns ju även "informal=yes|no", men frågan är om den är värd att
använda? Möjligen i städer för så kallade "desire paths".

Skulle också vilja höra med er *om vi överhuvudtaget ska använda
highway=footway i Sverige? *Footway implicerar ju att den egentligen bara
är avsedd för fotgängare, vilket vi lika gärna kan använda highway=path,
foot=designated för. Dessutom är ju skogsstigar normalt även möjliga att
cykla MTB på, varför footway i min mening är meningslös och inte bör
användas alls.

highway=cycleway kan möjligen användas för cykelvägar där fotgängare inte
är tillåtna (alt. att man använder foot=yes|designated). Men det kan lika
gärna åstadkommas med highway=path och olika access-taggar för foot,
bicycle, horses osv.

/Daniel


Den fre 15 maj 2020 kl 09:07 skrev Daniel Westergren :

> Tjenare,
>
> En nackdel med OSM är att det inte finns någon självklar central plats för
> allmänna diskussioner och förslag. Är mailinglistan, FB-gruppen, wikin
> eller annat att föredra?
>
> Då jag ny har gjort ett par videoguider om kartläggning av stigar för
> löpning (
> https://www.youtube.com/playlist?list=PLZjc6PXbNOLJK3yCR0wsn0RHxqhUn2sCa,
> vilket förstås också kan användas för vandring & MTB) skulle jag vilja se
> att vi tar fram tydligare riktlinjer för taggning av stigar,
> vandringsleder, motionsspår och naturstigar (och i förlängningen även
> natur/markanvändning och infrastruktur)
>
> Till exempel skulle det underlätta inte minst för nya karterare om vi hade
> en svensk översättning av https://wiki.openstreetmap.org/wiki/Hiking och
> de viktigaste av de sidor som länkas till där (t.ex. för ways och
> attributes of ways, liksom taggning av walking and hiking route networks).
>
> Jag kan förstås påbörja en sådan svensk sida. Men en del i det handlar ju
> också om hur vi ska tagga sådant som inte är självklart. Jag tänker fr.a.
> på highway=path och hur vi använder olika attribut för att skilja på
> skogsstigar, preparerade stigar, gång- och cykelvägar osv., men även en
> tydlig svensk översättning av network=*. Var förs lämpligast en diskussion
> om detta?
>
> MVH /Daniel Westergren
>

Den fre 15 maj 2020 kl 09:07 skrev Daniel Westergren :

> Tjenare,
>
> En nackdel med OSM är att det inte finns någon självklar central plats för
> allmänna diskussioner och förslag. Är mailinglistan, FB-gruppen, wikin
> eller annat att föredra?
>
> Då jag ny har gjort ett par videoguider om kartläggning av stigar för
> löpning (
> https://www.youtube.com/playlist?list=PLZjc6PXbNOLJK3yCR0wsn0RHxqhUn2sCa,
> vilket förstås också kan användas för vandring & MTB) skulle jag vilja se
> att vi tar fram tydligare riktlinjer för taggning av stigar,
> vandringsleder, motionsspår och naturstigar (och i förlängningen även
> natur/markanvändning och infrastruktur)
>
> Till exempel skulle det underlätta inte minst för nya karterare om vi hade
> en svensk översättning av https://wiki.openstreetmap.org/wiki/Hiking och
> de viktigaste av de sidor som länkas till där (t.ex. för ways och
> attributes of ways, liksom taggning av walking and hiking route networks).
>
> Jag kan förstås påbörja en sådan svensk sida. Men en del i det handlar ju
> också om hur vi ska tagga sådant som inte är självklart. Jag tänker fr.a.
> på highway=path och hur vi använder olika attribut för att skilja på
> skogsstigar, preparerade stigar, gång- och cykelvägar osv., men även en
> tydlig svensk översättning av network=*. Var förs lämpligast en diskussion
> om detta?
>
> MVH /Daniel Westergren
>
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

[Talk-se] Svenska riktlinjer för taggning för vandring & löpning

[Daniel Westergren]

Tjenare,

En nackdel med OSM är att det inte finns någon självklar central plats för
allmänna diskussioner och förslag. Är mailinglistan, FB-gruppen, wikin
eller annat att föredra?

Då jag ny har gjort ett par videoguider om kartläggning av stigar för
löpning (
https://www.youtube.com/playlist?list=PLZjc6PXbNOLJK3yCR0wsn0RHxqhUn2sCa,
vilket förstås också kan användas för vandring & MTB) skulle jag vilja se
att vi tar fram tydligare riktlinjer för taggning av stigar,
vandringsleder, motionsspår och naturstigar (och i förlängningen även
natur/markanvändning och infrastruktur)

Till exempel skulle det underlätta inte minst för nya karterare om vi hade
en svensk översättning av https://wiki.openstreetmap.org/wiki/Hiking och de
viktigaste av de sidor som länkas till där (t.ex. för ways och attributes
of ways, liksom taggning av walking and hiking route networks).

Jag kan förstås påbörja en sådan svensk sida. Men en del i det handlar ju
också om hur vi ska tagga sådant som inte är självklart. Jag tänker fr.a.
på highway=path och hur vi använder olika attribut för att skilja på
skogsstigar, preparerade stigar, gång- och cykelvägar osv., men även en
tydlig svensk översättning av network=*. Var förs lämpligast en diskussion
om detta?

MVH /Daniel Westergren
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [OSM-talk-fr] Point d'apport volontaire, point de collecte, point de regroupement

[Jérôme Seigneuret]

> Mais je n'ai pas trouvé comment cartographier ces zones "génériques" qui,
de plus en plus fréquemment, ont un nom affiché et une référence
géographiquement stable dans le temps.
Dans les données que j'ai observées, le PAV est un regroupement de 2 ou
plusieurs conteneurs.

Vincent, as-tu des exemples ?
Jérôme, est-ce que tes clients ont des zones nommées ?
Sur ce sujet il y a les deux écoles:
- identification du site (référence) + information d'adresse d'implantation
et complément d'information mais dans coordonnées GPS. un PAV regroupe un
ensemble de colonnes par flux à collecter ex: 1 OM, 2 CS, 2 VE (Om: Ordure
ménagère, CS Collecte Sélective, VE: Verre)
- identification des colonnes + le plus souvent une géolocalisation ou une
adresse
- cumul des deux

De mon coté les opérateurs de collecte on une identification à la colonne
ce qui permet de faire des stat individuel de levé (et tonnage) et de
suivre le cycle de vie de la colonne si elle est remplacé ou déplacé le cas
échéant. C'est la même chose sur la gestion de bacs et on est trop souvent
confronté à des clients qui ont une méconnaissance de ce qu'il ont sur leur
territoire.
La référence du site va plus donner des stat sur le site d’implantation.
C'est plus intéressant de savoir si la colonne est utiliser en sou régime
alors qu'il y a une autre colonne à proximité dans la même situation. Cela
permet de choisir de revoir l'implantation pour un emplacement plus
pertinent.

Ces noms correspondent-ils à des rues, quartiers, lieu-dits ?
Oui et non il n'y a que rarement un nommage des sites. On n'est pas sur des
arrêt de bus. Mais ça peut arriver pour des petit territoire ex: Stade de
Foot, Mairie, Place ... Quartier A 1 (les numéro sont principalement mis en
cas d'implantation de site multiple) ou plus généralement {ville}{numéro du
site pour la commune} (un peu comme les borne incendie)


>
> Le problème vient du fait qu'historiquement, en France, on collectait les
> ordures ménagères en bac et le tri en colonnes. Donc un point de
> regroupement de bacs à ordures ménagères "waste_disposal" et un point tri
> en
> colonne : "recycling"
>
C'est un comme ça que je vois les choses. Mais en aucun cas   recycling
stypule que c'est pour les colonnes uniquement  waste_disposal également.
D'où le fait de dire qu'un conteneur quelque soit ça forme et sa taille et
un contenant pour de la collecte quelque soit le flux et qu'il peut être
associé à un processus de "recyclage" et pas seulement d'enlèvement.

>
>
> Notre problème au Sitcom c'est que l'on a des points de collecte en colonne
> ou il n'y a que des ordures ménagères (front de mer pour faire plus joli
> avec des point enterrés, camping, points très isolés,...).
>
> Deux solutions s'offrent donc à nous pour les caractériser :
>
> -"recycling" avec uniquement waste=yes
> C'est bizarre de dire qu'on a un point de collecte de tri ou on prend pas
> le
> tri (uniquement les ordures ménagères)
>
C'est comme tu le disais "recycling" est employé faute d'avoir mis le
processus métier en avant. ducoup c'est la même chose que dans les appels
d'offre: on utilise Point d'Apport Volontaire Ordure Ménagère alors que
c'est en rien de l’apport volontaire
C'est de l'évacuation de déchets trié en recyclable et non recyclable.
conteneurisé ou non avec un mode de regroupement ou pas et un mode
d'enlèvement
waste =yes c'est justement le fait d'exploiter des format de conteneur
associé à des colonnes de recyclable.

>
> -"waste_disposal"
> Si je me réfère au wiki on a pas tous les tags pour caractériser le type de
> colonne, mais c'est pas le plus embêtant. Le plus embêtant c'est de dire
> que
> le type principal du point est différent alors que sur le terrain,
> visuellement c'est comme un point tri, collecté par le même type de camion
>


>
> A noter que certaines collectivité vont avoir le même problème inverse, à
> savoir des points de regroupements (gros bacs en bout de rue) ou ils
> collectent des flux triés (gros bac jaune pour le plastique mais je connais
> aussi des endroits où il y a des gros bacs de verre ou de carton).
>
Exemple CC Golf de Saint-Tropez quasiment tout est géré en point de
regroupement

Là aussi on penserait dans un premier temps à un waste_disposal, mais
> finalement si y a du tri on va le passer en recycling, mais si j'ai qu'un
> bac jaune et un bac ordures ménagères on peut pas vraiment considéré que
> c'est un point tri.
>
> Je connais pas très bien OSM (mais j'me soigne ;)), mais si on suit la
> logique historique j’aurais tendance à dire :
> -amenity="recycling" : point tri qui maintenant s'appelle plutôt Point
> d'apport volontaire (justement parce qu'un a des points colonnes où on ne
> trie pas)
> -amenity="waste_disposal" : point de regroupement, qui historiquement ne
> concernait que les ordures ménagères mais maintenant peut contenir des bacs
> de tri sélectif
>
C'est tous le dilemme... Où l'on va mettre la séparation...

>
> A noter que pour l'instant nous ne souhaitions pas aller au niveau 

Re: [OSM-talk-fr] Point d'apport volontaire, point de collecte, point de regroupement

[David Pédehourcq]

Bonjour,
 
Je me présente rapidement, je suis David Pédehourcq je suis chef de projet
informatique au Sitcom Côte Sud des Landes, un syndicat mixte qui gère la
collecte des déchets sur tout le sud des Landes. Avant ce poste j'ai
travaillé pendant 15 ans en tant que chef de projet pour un éditeur de
logiciel spécialisé dans des solutions de géolocalisation pour la collecte
des déchets, j'ai donc pu voir comment se déroule la collecte un peu partout
en France (plus de 200 clients).
 
Nous souhaitons intégrer tous nos points de collecte dans OSM et on a
commencé à travailler avec Vincent sur ce sujet. D'où émergence de cette
discussion :)
 
Je pense que vous avez parfaitement saisi le "problème" à savoir que
l'anthologie caractérise le point par rapport à un processus métier (à
savoir comment on traite le flux) alors que nous souhaiterions caractériser
le point par rapport à ces caractéristiques techniques sur le terrain.
 
Le problème n'est pas que sur OSM, chez nous en interne on a encore un
service qui s'appelle "collecte Ordure ménagères" et qui collecte du carton
en bac (qui n'est pas de l'ordure ménagère) et un service collecte
sélective, qui collecte des ordures ménagères en colonne (qui n'est pas du
tri sélectif).
 
Le problème vient du fait qu'historiquement, en France, on collectait les
ordures ménagères en bac et le tri en colonnes. Donc un point de
regroupement de bacs à ordures ménagères "waste_disposal" et un point tri en
colonne : "recycling"
 
Sauf que maintenant, pour différentes raisons politiques et logistiques on
peut collecter du tri en BAC et collecter des ordures ménagères en colonne.
(j'évite volontairement le débat recyclage VS Tri VS valorisation qui ne me
semble pas lié à OSM).
 
Notre problème au Sitcom c'est que l'on a des points de collecte en colonne
ou il n'y a que des ordures ménagères (front de mer pour faire plus joli
avec des point enterrés, camping, points très isolés,...). 
 
Deux solutions s'offrent donc à nous pour les caractériser : 

-"recycling" avec uniquement waste=yes
C'est bizarre de dire qu'on a un point de collecte de tri ou on prend pas le
tri (uniquement les ordures ménagères) 

-"waste_disposal"
Si je me réfère au wiki on a pas tous les tags pour caractériser le type de
colonne, mais c'est pas le plus embêtant. Le plus embêtant c'est de dire que
le type principal du point est différent alors que sur le terrain,
visuellement c'est comme un point tri, collecté par le même type de camion
 
A noter que certaines collectivité vont avoir le même problème inverse, à
savoir des points de regroupements (gros bacs en bout de rue) ou ils
collectent des flux triés (gros bac jaune pour le plastique mais je connais
aussi des endroits où il y a des gros bacs de verre ou de carton).
Là aussi on penserait dans un premier temps à un waste_disposal, mais
finalement si y a du tri on va le passer en recycling, mais si j'ai qu'un
bac jaune et un bac ordures ménagères on peut pas vraiment considéré que
c'est un point tri.
 
Je connais pas très bien OSM (mais j'me soigne ;)), mais si on suit la
logique historique j’aurais tendance à dire : 
-amenity="recycling" : point tri qui maintenant s'appelle plutôt Point
d'apport volontaire (justement parce qu'un a des points colonnes où on ne
trie pas) 
-amenity="waste_disposal" : point de regroupement, qui historiquement ne
concernait que les ordures ménagères mais maintenant peut contenir des bacs
de tri sélectif

A noter que pour l'instant nous ne souhaitions pas aller au niveau de détail
de la colonne mais bien de l’emplacement des points. Si on positionne une
station service on va pas positionner pompe par pompe avec n° de référence
de la pompe et type d'essence distribué, l’intérêt du POI station service
c'est qu'un utilisateur puisse savoir où sont les stations services et quel
essence il peut y trouver. On aimerait faire la même chose pour la collecte
en recensant tous les points de collecte avec les flux de déchets que l'on
peut y amener. L'idée étant de maintenir ces données à jours très
fréquemment on va rester sur le point de collecte et on ne va pas descendre
au niveau du contenant.

J'attire votre attention sur le fait que sur 8000 point environ on en bouge
environ 10 par jour pour la maintenance ou autre. Dans ce contexte
référencer les numéros de série me semble peu pertinent.
 
A bientôt,
 
David 




--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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