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

[Stéphane Péneau]

Le 14/05/2020 à 18:05, Yves P. a écrit :
Je pensais importer des conteneurs : ça tombe bien, il y a pleins de 
PAV dans data.gouv.fr 

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 :

https://lists.openstreetmap.org/pipermail/talk-fr/2020-March/097360.html


J'ai l'impression que le fichier utilisé n'est plus disponible et 
qu'il ne traitait que les PAV d'ordures ménagères (avec ou sans clé 
électronique)


Il est ici :

https://github.com/osm-fr/osmose-backend/blob/master/merge_data/PAV_CSMA.csv.bz2

J'ai largement remanié celui d'origine pour qu'il soit utilisable dans 
Osmose. Entre autres, 1 ligne = 1 conteneur


Il y a 2 analyses pour lui :

- Une pour les conteneurs d'ordures ménagères

- Une autre pour les conteneurs "recyclage" (verre papier, etc..)

http://osmose.openstreetmap.fr/fr/map/#zoom=12=47.1357=-1.2961=8120=3==

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

Re: [OSM-talk] Relation: 1204546, polygon error.

[Wayne Emerson, Jr. via talk]

And that previous relation checker must have a display bug or something. 
I just loaded the relation in JOSM and the  relation editor shows no gaps.


On 5/14/2020 11:24 PM, Wayne Emerson, Jr. via talk wrote:
With large relations, if all the members are not yet downloaded in 
your browser, you will see "ghost lines" that will change every time a 
new section is downloaded.


On 5/14/2020 11:14 PM, 80hnhtv4agou--- via talk wrote:
i see ghosts lines in the ID editor, that keep on moving when i try 
to follow the line.

and as the other guy said somewhere there is a break.
​​​but i also see 300 + relations which all light up when clicked on.

Thursday, May 14, 2020 10:09 PM -05:00 from Joseph Eisenberg
:
Looking at
https://www.openstreetmap.org/relation/1204546#map=13/29.6738/-81.1861
- I don't see any visual problems currently. What are you seeing?
The only tagging problem I see is that the coastline here is not
tagged properly. This whole area looks like a salt water lagoon
system, which should be mapped with coastline, since it is marine
salt-water.
-- Joseph Eisenberg
On Thu, May 14, 2020 at 7:57 PM 80hnhtv4agou--- via talk
> wrote:

has a ghosts water multipolygon,
that keep moving over land.
https://wiki.openstreetmap.org/wiki/Nominatim/Polygons
i can not see the break, and every in the middle is a
relation ship.

___
talk mailing list
talk@openstreetmap.org

https://lists.openstreetmap.org/listinfo/talk

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


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




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



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

Re: [OSM-talk] Relation: 1204546, polygon error.

[Wayne Emerson, Jr. via talk]

With large relations, if all the members are not yet downloaded in your 
browser, you will see "ghost lines" that will change every time a new 
section is downloaded.


On 5/14/2020 11:14 PM, 80hnhtv4agou--- via talk wrote:
i see ghosts lines in the ID editor, that keep on moving when i try to 
follow the line.

and as the other guy said somewhere there is a break.
​​​but i also see 300 + relations which all light up when clicked on.

Thursday, May 14, 2020 10:09 PM -05:00 from Joseph Eisenberg
:
Looking at
https://www.openstreetmap.org/relation/1204546#map=13/29.6738/-81.1861
- I don't see any visual problems currently. What are you seeing?
The only tagging problem I see is that the coastline here is not
tagged properly. This whole area looks like a salt water lagoon
system, which should be mapped with coastline, since it is marine
salt-water.
-- Joseph Eisenberg
On Thu, May 14, 2020 at 7:57 PM 80hnhtv4agou--- via talk
> wrote:

has a ghosts water multipolygon,
that keep moving over land.
https://wiki.openstreetmap.org/wiki/Nominatim/Polygons
i can not see the break, and every in the middle is a
relation ship.

___
talk mailing list
talk@openstreetmap.org

https://lists.openstreetmap.org/listinfo/talk

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


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



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

Re: [OSM-talk] Relation: 1204546, polygon error.

[80hnhtv4agou--- via talk]

i see ghosts lines in the ID editor, that keep on moving when i try to follow 
the line. 
 
and as the other guy said somewhere there is a break.
 
​​​but i also see 300 + relations which all light up when clicked on.
  
>Thursday, May 14, 2020 10:09 PM -05:00 from Joseph Eisenberg 
>:
> 
>Looking at  
>https://www.openstreetmap.org/relation/1204546#map=13/29.6738/-81.1861 - I 
>don't see any visual problems currently. What are you seeing?
> 
>The only tagging problem I see is that the coastline here is not tagged 
>properly. This whole area looks like a salt water lagoon system, which should 
>be mapped with coastline, since it is marine salt-water.
> 
>-- Joseph Eisenberg  
>On Thu, May 14, 2020 at 7:57 PM 80hnhtv4agou--- via talk < 
>talk@openstreetmap.org > wrote:
>>>has a ghosts water multipolygon,
>>> 
>>>that keep moving over land.
>>> 
>>>https://wiki.openstreetmap.org/wiki/Nominatim/Polygons
>>> 
>>>i can not see the break, and every in the middle is a relation ship.
>>> 
>>>  
>> 
>> 
>> 
>>  ___
>>talk mailing list
>>talk@openstreetmap.org
>>https://lists.openstreetmap.org/listinfo/talk
>___
>talk mailing list
>talk@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk 
 
 
 
 ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Relation: 1204546, polygon error.

[Wayne Emerson, Jr. via talk]

This tool http://ra.osmsurround.org/analyzeMap?relationId=1204546 shows 
visually that there appears to be at least 2 sections missing. The 
relation editor in JOSM should show the gaps as well.


On 5/14/2020 10:55 PM, 80hnhtv4agou--- via talk wrote:


has a ghosts water multipolygon,
that keep moving over land.
https://wiki.openstreetmap.org/wiki/Nominatim/Polygons
i can not see the break, and every in the middle is a relation ship.


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



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

Re: [OSM-talk] Relation: 1204546, polygon error.

[Joseph Eisenberg]

Looking at
https://www.openstreetmap.org/relation/1204546#map=13/29.6738/-81.1861 - I
don't see any visual problems currently. What are you seeing?

The only tagging problem I see is that the coastline here is not tagged
properly. This whole area looks like a salt water lagoon system, which
should be mapped with coastline, since it is marine salt-water.

-- Joseph Eisenberg

On Thu, May 14, 2020 at 7:57 PM 80hnhtv4agou--- via talk <
talk@openstreetmap.org> wrote:

> has a ghosts water multipolygon,
>
> that keep moving over land.
>
> https://wiki.openstreetmap.org/wiki/Nominatim/Polygons
>
> i can not see the break, and every in the middle is a relation ship.
>
>
>
>
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Relation: 1204546, polygon error.

[80hnhtv4agou--- via talk]

>has a ghosts water multipolygon,
> 
>that keep moving over land.
> 
>https://wiki.openstreetmap.org/wiki/Nominatim/Polygons
> 
>i can not see the break, and every in the middle is a relation ship.
> 
>  
 
 
 
 ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Mateusz Konieczny via Talk-ie]

May 15, 2020, 00:04 by davecor...@gmail.com:

> 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.
>
> Saying that others can come along after and correct it is a totally
> avoidable requirement by using more appropriate tagging in the first place.
> Its also unlike to ever get corrected as evidenced by the volume of data in
> Ireland that was created and never improved upon.
>
If there is not enough mappers then likely mapping more building as building=yes
is more efficient than using specific building value anyway.

And anyone may map whatever (s)he wants, it is perfectly fine to 
map roads without mapping buildings, map trees instead of mapping roads,
map buildings as building=yes, map bicycle parkings and map no shops at all...

Note also that for example StreetComplete allows newbies and beginners to
build on build on initial not finished data and for example specify 
more exact building types.

> The logical approach should be to map it as house/garage/shed etc and ONLY
> use building=yes if you cannot make an educated guess.
>
> Doing otherwise puts this data on the level of the tiger import.
>
No. TIGER import had plenty of outright invalid, incorrect and insane data.
This is merely missing not very important part of info.

https://wiki.openstreetmap.org/wiki/File:TIGER_fixup_example_before.jpg
https://wiki.openstreetmap.org/wiki/File:Braided-streets-example.jpg
https://wiki.openstreetmap.org/wiki/TIGER_fixup

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

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

[Anthony Costanzo]

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

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

[Yves P.]

>>  * 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 ;)

> 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

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

Ces noms correspondent-ils à des rues, quartiers, lieu-dits ?

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

Re: [OSM-talk] Microgrants Committee call for review

[Mateusz Konieczny via talk]

BTW, if you never edited wiki
then you need to sign up at
https://wiki.openstreetmap.org/w/index.php?title=Special:CreateAccount=Microgrants%2FMicrogrants+2020

Your usual OSM account will now work (unfortunately).

And endorsement will be treated more seriously if made
from an account (for bonus points - edit your user page
on wiki and OSM to mention that both accounts are operated
by single user).

If you are confused by wiki feel free to ask for help
(it should be OK to do this also on a mailing list, right?).

If you want to to fix/improve/expand some documentation on wiki 
- it may be a good moment to do that :)

Even single fixed typo is helpful.
 
-

As one of proposal authors: please give feedback
even, and especially if, proposal seems confusing, pointless
and a waste of money.

It is likely that maybe proposal is actually a good idea, but
something is unclear, may be clarified or improved.

It applies at least to my proposal, in specific case of my
proposal I am also fine with a direct feedback without 
going around topic and excessive politeness.

If something is problematic, unclear, confusing then please let me know.

It is also explicitly noted in the first paragraph, 
of the proposal text.

I will not link proposal directly - it is better to avoid spam with 
authors linking to their own proposal under flimsy pretenses.

May 14, 2020, 23:53 by cliff...@snowandsnow.us:

> Greetings on behalf of the OSMF Microgrant Program Committee!
>
> We have closed the call for proposals for this first ever iteration of the 
> program. We are already beginning the evaluation process for the submitted 
> proposals, which consist of promising projects that aim to have a positive 
> impact in the OSM community.
>
> Now that all proposals are on the OSM Wiki, we invite the community to add 
> their endorsement in the endorsements section of each proposal they support, 
> and also click the "give feedback" button on the description to add any 
> questions or comments if they wish. The committee will bear this community 
> interaction in mind in our decision-making. 
>
> Feedback will be accepted until Thursday morning, 21 May 2020 (midnight 
> Pacific time US, 9am Central European Time, 7pm New Zealand time). After this 
> time the committee will make haste to arrive at a final decision.
>
> Please consult the OSM Wiki page here to see the project links: > 
> https://wiki.openstreetmap.org/wiki/Microgrants/Microgrants_2020
>
> We are pleased to receive community feedback on the proposals and look 
> forward to arriving at a decision as soon as possible in order to commence 
> the projects.
>
> Thanks and best,
>
> OSMF Microgrant Program Committee
>
> -- 
> @osm_washington
> www.snowandsnow.us 
> OpenStreetMap: Maps with a human touch
>

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

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

[Marc M.]

Le 13 Mai, Vincent Bergeot a écrit
> 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.

je fais un objet par contenant, du coup la notion de "site" [1]
est implicite par la présence de plusieurs objets rapproché.

le nom est autre chose qu'une description de sa localisation ?
la ref se lit sur le terrain ? les zones sont si proche
qu'un rapprochement basé sur la localisation n'est pas suffisant ?

[1] du coup relation type=site est une solution

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

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

[Dave Corley]

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.

Saying that others can come along after and correct it is a totally
avoidable requirement by using more appropriate tagging in the first place.
Its also unlike to ever get corrected as evidenced by the volume of data in
Ireland that was created and never improved upon.

The logical approach should be to map it as house/garage/shed etc and ONLY
use building=yes if you cannot make an educated guess.

Doing otherwise puts this data on the level of the tiger import.



On Thu, May 14, 2020 at 1:04 PM Colm Moore  wrote:

> Hi,
>
> Apologies, there was something else I meant to mention.
>
> Some locations have a very low number of building polygons per capita
> (i.e. implying high number of people per building). This may be
> **suggestive** of locations that are under-mapped. This bears out in some
> of suburbs on the Kilkenny side of Waterford city, where there are lots of
> unmappable (tree cover and fuzzy images) garden sheds, etc. There are other
> reasons for this, like apartment buildings, terraced houses mapped as
> building=terrace, etc.
>
> On Wed, 13 May 2020 at 14:38, Donie Kelly  wrote:
>
> > Don’t buildings have tags? Did I see a residential tag? Is it used in all
> > cases?
>
> Yes, buildings can be given detailed descriptions, e.g. building=house,
> building=apartments. However, about half of the buildings on the island
> just use building=yes. Only saying building=yes gets the building on the
> map quickly, makes them readily findable and lets other mappers fill in
> details later. Not all buildings are readily identifiable from aerial
> images and details like number of storeys can be even harder to determine.
>
> Note that building=residential can be used for buildings that
> are residential, but the type isn't readily identifiable, e.g. I saw some
> semi-detached houses in Kilkenny that were attached back-to-back instead of
> side-to-side.
>
> Interpreting the total number of buildings on the island from the total
> number of, say houses, would be more complicated than comparing number of
> buildings in Kilkenny to the number of buildings on the island.
>
> On Thu, 14 May 2020 11:47:29 Tadeusz Cantwell  wrote:
>
> > The residential tag should be used for an area not a house.
>
> Yes, landuse=residential should be used for residential sites / estates /
> neighbourhoods. The iD editor now supports additional sub-tags,
> e.g. residential=rural, residential=apartments and residential=halting_site
> You can also add name=* to the likes of housing estates, which can help
> detail the hierarchy of a town.
>
> Colm
>
>
>
> ---
>
>
> ___
> Talk-ie mailing list
> Talk-ie@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ie
>
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

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

[santamariense]

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

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

[deuzeffe]

Le 14/05/2020 à 10:22, Yves P. a écrit :


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


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

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


--
deuzeffe - TL;DR

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

[OSM-talk] Microgrants Committee call for review

[Clifford Snow]

Greetings on behalf of the OSMF Microgrant Program Committee!

We have closed the call for proposals for this first ever iteration of the
program. We are already beginning the evaluation process for the submitted
proposals, which consist of promising projects that aim to have a positive
impact in the OSM community.

Now that all proposals are on the OSM Wiki, we invite the community to add
their endorsement in the endorsements section of each proposal they
support, and also click the "give feedback" button on the description to
add any questions or comments if they wish. The committee will bear this
community interaction in mind in our decision-making.

Feedback will be accepted until Thursday morning, 21 May 2020 (midnight
Pacific time US, 9am Central European Time, 7pm New Zealand time). After
this time the committee will make haste to arrive at a final decision.

Please consult the OSM Wiki page here to see the project links:
https://wiki.openstreetmap.org/wiki/Microgrants/Microgrants_2020

We are pleased to receive community feedback on the proposals and look
forward to arriving at a decision as soon as possible in order to commence
the projects.

Thanks and best,

OSMF Microgrant Program Committee

-- 
@osm_washington
www.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-it] Confini codice postale

[Luigi Scuotto]

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

Re: [Talk-it] Confini codice postale

[Luigi Scuotto]

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

Re: [Talk-it] Confini codice postale

[Luigi Scuotto]

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

Re: [Talk-it] Confini codice postale

[Cascafico Giovanni]

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

Re: [Talk-it] Confini codice postale

[Luigi Scuotto]

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

Re: [Talk-it] Confini codice postale

[Cascafico Giovanni]

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

Re: [Talk-it] Confini codice postale

[totera]

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-gb-westmidlands] HS2footpath diversions

[Brian Prangle]

Hi everyone

Who is closest to this and wants to do a survey?

CubbingtonThe path known as 129d off Mill Lane has been temporarily
diverted at the edge of South Cubbington Wood. The diversion will be in
place while enabling works take place along 129d for site set-up,
archaeology, ground investigations, surveys and creating new wildlife
habitats for HS2’s green corridor. These activities involve heavy machinery
crossing parts of the 129d, requiring a diversion.The public right of way
known as W130 will be temporarily closed, with a diversion in place, from
early March 2020. HS2’s enabling works contractor will oversee the
construction of two diversionsfor W130 to create a safe walking loop around
our worksites
___
Talk-gb-westmidlands mailing list
Talk-gb-westmidlands@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands

[Talk-br] Formato de endereço no Brasil

[Ricardo Bigio]

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

Re: [OSM-talk-fr] Avancée de la carto des Ehpad (était : Osmose - Intégration Ehpad)

[Jean-Guilhem Cailton]

Bonjour,

Je ne l’avais pas fait sur le coup, mais je voulais remercier Georges
pour cette excellente question, et Frédéric et Marc pour la réponse.

Cela a sans doute été décisif pour l’avancée dans la cartographie des
Ehpad, qu’on peut donc ainsi visualiser, par exemple en se déplaçant à
partir de :
https://osmose.openstreetmap.fr/fr/map/#item=8340%2C8341=111%2C113=8=48.175=5.416=1%2C2%2C3=merge=

On voit ainsi apparaître des zones libres (de marqueurs d’Ehpad à
intégrer) qui s’étendent progressivement, dans le Grand-Est, dans les
Hauts-de-France, en Bretagne et dans les Pays de la Loire, … avec
notamment une percée du Grand-Est vers le Centre et le Limousin, qui
descend d’un côté vers l’Ouest via le Périgord jusqu’aux Landes, et de
l’autre via le Massif Central jusqu’à l’Occitanie et aux Alpes du Sud…

Il reste encore beaucoup à faire, bien sûr, mais j’ai trouvé
encourageant de visualiser géographiquement cette avancée globale dans
la cartographie des Ehpad.

Et un grand bravo donc aux mappeurs qui étendent ces zones libres !

Bien cordialement,

Jean-Guilhem


Le 27/04/2020 à 11:19, Frédéric Rodrigo a écrit :
> Le 27/04/2020 à 11:14, Georges Dutreix via Talk-fr a écrit :
>> Bonjour,
>>
>> Je reviens vous embêter encore avec les Ehpad.
>> J'essaie d'utiliser dans Osmose l'item 8340 "Structures sociales".
>> Mais les Ehpad et Ehpa sont noyés dans des centaines d'autres
>> structures sociales.
>>
>> Je vois qu'il existe une notion de Classe 111 "Ehpad", qu'on peut
>> obtenir sous forme de tableau :
>> http://osmose.openstreetmap.fr/fr/errors/?item=8340=111
>> J'ai donc bidouillé l'URL Osmose à la mano, pour voir, et ça marche :-)
>> http://osmose.openstreetmap.fr/fr/map/#zoom=12=44.8209=-0.5631=8340=111
>>
>>
>> Mais existe-t-il un moyen de filtrer la carte Osmose depuis
>> l'interface (frontend) pour n'avoir que ces signalements "111" ?
>
> Il y a plein d'options que l'on peut ajouter directement dans l'URL
> (voir la doc de l'API).
>
> Mais tu y étais presque. Depuis
>
> http://osmose.openstreetmap.fr/fr/errors/?item=8340=111
>
> il faut cliquer sur carte. 

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

[Talk-at] AGIT 2020 Virtuell

[scubbx]

Hallo, Leute!

Die AGIT 2020 wird dieses Jahr virtuell stattfinden! Diejenigen, die
einen Beitrag eingereicht hatten, hatten bereits die Möglichkeit, einem
Online-Vortrag zuzustimmen.
Wir haben fast alle Beiträge auch Online mit an Bord! :-D

Die AGIT Organisation plant anstatt der EXPO (dort, wo wir immer unseren
Messestand hatten), eine "virtuelle" EXPO. Das bedeutet, dass sich jede
Firma/Organisation auf einer Seite präsentieren kann und virtuelle
Besucher dieser Seite mit den Ausstellern via einem Chat-Fenster
interagieren können.

Ob und wie genau OpenStreetMap und OSGeo dort vertreten sein werden,
wird noch überlegt.
Für die Abschätzung hätte ich dazu die Frage, ob sich jemand von euch
vorstellen könnte, einen Teil der "Chat-Duty" zu übernehmen? Wenn wir
mit ein paar Personen uns das aufteilen, sollten wir den Chat eigentlich
den ganzen Zeitraum über (6.-10.Juli) bedienen können.

Beste Grüße,
Markus (ScubbX)


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

Re: [Talk-it] Confini codice postale

[Martin Koppenhoefer]

sent from a phone

> On 14. May 2020, at 18:17, 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)


anch’io ricordo così, nelle grandi città ci sono più codici 

Penso che il tag vada bene anche come area (1 way), ma solo sulle isole dove 
non ci sono cap vicini.

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

Re: [Talk-it] Confini codice postale

[Marcello]

Il 14/05/20 19:22, Marcello ha scritto:

Il 14/05/20 18:41, Andrea Musuruane ha scritto:

Ciao,
    le città italiane con il CAP legato allo stradario e non al 
comune sono 41, tra cui Bergamo, che è il caso in oggetto:

https://it.wikipedia.org/wiki/Codice_di_avviamento_postale

I confini comunali presenti in OSM (presi, se ricordo bene, da ISTAT) 
sono spesso approssimativi. 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).


Ciao,

Andrea


Andrea,

dalla pagina wiki 
https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dpostal_code leggo:
"When a way is being shared as an administrative boundary relation 
(boundary 
=administrative 
), 
*and* a postal code boundary relation, tag that member way with 
boundary 
=administrative 
. 
Both boundaries types are implied"


Mi sembra di capire che se il boundary del postal_code corrisponde al 
boundary administrative si usa lo stesso boundary taggandolo come 
administrative per entrambe le funzioni, non è così?


Mi rispondo da solo, forse è più corretto usare le stesse way del 
boundary=administrative e inserirle in una nuova relazione 
boundary=postal_code, comunque ci sono 54.348 relazioni 
boundary=administrative con il tag postal_code=*, quindi mi sembra una 
pratica molto diffusa.


--
Ciao
Marcello

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

Re: [Talk-it] Confini codice postale

[Marcello]

Il 14/05/20 18:41, Andrea Musuruane ha scritto:

Ciao,
    le città italiane con il CAP legato allo stradario e non al comune 
sono 41, tra cui Bergamo, che è il caso in oggetto:

https://it.wikipedia.org/wiki/Codice_di_avviamento_postale

I confini comunali presenti in OSM (presi, se ricordo bene, da ISTAT) 
sono spesso approssimativi. 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).


Ciao,

Andrea


Andrea,

dalla pagina wiki 
https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dpostal_code leggo:
"When a way is being shared as an administrative boundary relation 
(boundary 
=administrative 
), 
*and* a postal code boundary relation, tag that member way with boundary 
=administrative 
. 
Both boundaries types are implied"


Mi sembra di capire che se il boundary del postal_code corrisponde al 
boundary administrative si usa lo stesso boundary taggandolo come 
administrative per entrambe le funzioni, non è così?


--
Ciao
Marcello

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

Re: [Talk-it] Confini codice postale

[Lorenzo Stucchi]

L’ID indicato da Luigi fa riferimento al changeset: 
https://www.openstreetmap.org/changeset/85199286

Ciao,
Lorenzo Stucchi

Il giorno 14 mag 2020, alle ore 18:46, Luigi Scuotto 
mailto:luigiscuott...@gmail.com>> ha scritto:

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

Il giorno gio 14 mag 2020 alle ore 18:40 Ivo Reano 
mailto:reano...@gmail.com>> ha scritto:
Pardon!
https://www.openstreetmap.org/node/85199286 --> esiste ma è di 10 anni fa
Come relation non esiste.

Il giorno gio 14 mag 2020 alle ore 18:39 Ivo Reano 
mailto:reano...@gmail.com>> ha scritto:
Luigi sarebbe stato meglio se avessi specificato meglio!
Andando per tentativi ho provato:
https://www.openstreetmap.org/way/85199286 --> esiste ma è roba i 9 anni fa
https://www.openstreetmap.org/node/85199286 --> non esiste
e finalmente:
https://www.openstreetmap.org/changeset/85199286
Che è quello che intendeva!

Il giorno gio 14 mag 2020 alle ore 18:35 Marcello 
mailto:arca...@gmail.com>> ha scritto:
Il 14/05/20 18:03, Andrea Musuruane ha scritto:
Ciao,
Non sono un esperto di postal_code, però i boundary dovrebbero essere 
relazioni. Quella che hai creato tu è un'area e come puoi leggere qui, questo 
tag non si applica alle aree:
https://wiki.openstreetmap.org/wiki/Tag:boundary=postal%20code?uselang=it

Inoltre, ricavare l'area di applicazione dei postal_code dai civici esistenti 
mi sembra una forzatura che può creare problemi.

Quando il comune creerà un nuovo civico, il suo CAP questo dovrebbe essere 
automaticamente identificabile tramite il boundary  esistente. Se questo è 
stato dedotto (e non si è seguita la regola di definizione dal CAP stesso) 
allora questa proprietà non vale.

In conclusione, credo sia meglio avere il dato (puntuale) sul singolo civico 
che una approssimazione che non rispecchia la realtà.

Ciao,

Andrea


On Thu, May 14, 2020 at 4:47 PM Luigi Scuotto 
mailto:luigiscuott...@gmail.com>> wrote:
Ciao e dagli con ste fonti. Ricalcato i numeri con codoce postale, se non serve 
lo cancello ed evito ti fare anche gli altri.
Ciao Gigi


Il giorno gio 14 mag 2020 alle ore 16:08 Cascafico Giovanni 
mailto:cascaf...@gmail.com>> ha scritto:
Fonti?
Credo siano comunque sufficienti quelli sugli addr:postcode

Il gio 14 mag 2020, 14:09 Luigi Scuotto 
mailto:luigiscuott...@gmail.com>> 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

Non riesco a capire a cosa fa riferimento l'ID 85199286, comunque nella grande 
maggioranza dei comuni il CAP è univoco per tutto il territorio comunale, 
dovrebbero essere meno di 50 i comuni italiani suddivisi in più aree postali, 
quindi nella maggior parte dei casi alla relazione dei confini comunali può 
essere aggiunto il tag postal_code=*. Per i comuni suddivisi in più aree dubito 
che ci sia qualche possibilità di avere i confini in formato compatibile con 
OSM.

Gigi, quali confini hai inserito e quali altri vorresti inserire? Grazie

--
Ciao
Marcello



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

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

Il giorno gio 14 mag 2020 alle ore 18:40 Ivo Reano  ha
scritto:

> Pardon!
> https://www.openstreetmap.org/node/85199286 --> esiste ma è di 10 anni fa
> Come relation non esiste.
>
> Il giorno gio 14 mag 2020 alle ore 18:39 Ivo Reano 
> ha scritto:
>
>> Luigi sarebbe stato meglio se avessi specificato meglio!
>> Andando per tentativi ho provato:
>> https://www.openstreetmap.org/way/85199286 --> esiste ma è roba i 9 anni
>> fa
>> https://www.openstreetmap.org/node/85199286 --> non esiste
>> e finalmente:
>> https://www.openstreetmap.org/changeset/85199286
>> Che è quello che intendeva!
>>
>> Il giorno gio 14 mag 2020 alle ore 18:35 Marcello  ha
>> scritto:
>>
>>> Il 14/05/20 18:03, Andrea Musuruane ha scritto:
>>>
>>> Ciao,
>>> Non sono un esperto di postal_code, però i boundary dovrebbero
>>> essere relazioni. Quella che hai creato tu è un'area e come puoi leggere
>>> qui, questo tag non si applica alle aree:
>>> https://wiki.openstreetmap.org/wiki/Tag:boundary=postal%20code?uselang=it
>>>
>>> Inoltre, ricavare l'area di applicazione dei postal_code dai civici
>>> esistenti mi sembra una forzatura che può creare problemi.
>>>
>>> Quando il comune creerà un nuovo civico, il suo CAP questo dovrebbe
>>> essere automaticamente identificabile tramite il boundary  esistente. Se
>>> questo è stato dedotto (e non si è seguita la regola di definizione dal CAP
>>> stesso) allora questa proprietà non vale.
>>>
>>> In conclusione, credo sia meglio avere il dato (puntuale) sul singolo
>>> civico che una approssimazione che non rispecchia la realtà.
>>>
>>> Ciao,
>>>
>>> Andrea
>>>
>>>
>>> On Thu, May 14, 2020 at 4:47 PM Luigi Scuotto 
>>> wrote:
>>>
 Ciao e dagli con ste fonti. Ricalcato i numeri con codoce postale, se
 non serve lo cancello ed evito ti fare anche gli altri.
 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

>>> Non riesco a capire a cosa fa riferimento l'ID 85199286, comunque nella
>>> grande maggioranza dei comuni il CAP è univoco per tutto il territorio
>>> comunale, dovrebbero essere meno di 50 i comuni italiani suddivisi in più
>>> aree postali, quindi nella maggior parte dei casi alla relazione dei
>>> confini comunali può essere aggiunto il tag postal_code=*. Per i comuni
>>> suddivisi in più aree dubito che ci sia qualche possibilità di avere i
>>> confini in formato compatibile con OSM.
>>>
>>> Gigi, quali confini hai inserito e quali altri vorresti inserire? Grazie
>>>
>>> --
>>> Ciao
>>> Marcello
>>>
>>>
>>> ___
>>> 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

[Andrea Musuruane]

Ciao,
le città italiane con il CAP legato allo stradario e non al comune sono
41, tra cui Bergamo, che è il caso in oggetto:
https://it.wikipedia.org/wiki/Codice_di_avviamento_postale

I confini comunali presenti in OSM (presi, se ricordo bene, da ISTAT) sono
spesso approssimativi. 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).

Ciao,

Andrea


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)
>
> Damjan
>
>
> Andrea Musuruane je 14.5.2020 ob 18:03 napisal:
>
> Ciao,
> Non sono un esperto di postal_code, però i boundary dovrebbero essere
> relazioni. Quella che hai creato tu è un'area e come puoi leggere qui,
> questo tag non si applica alle aree:
> https://wiki.openstreetmap.org/wiki/Tag:boundary=postal%20code?uselang=it
>
> Inoltre, ricavare l'area di applicazione dei postal_code dai civici
> esistenti mi sembra una forzatura che può creare problemi.
>
> Quando il comune creerà un nuovo civico, il suo CAP questo dovrebbe essere
> automaticamente identificabile tramite il boundary  esistente. Se questo è
> stato dedotto (e non si è seguita la regola di definizione dal CAP stesso)
> allora questa proprietà non vale.
>
> In conclusione, credo sia meglio avere il dato (puntuale) sul singolo
> civico che una approssimazione che non rispecchia la realtà.
>
> Ciao,
>
> Andrea
>
>
> On Thu, May 14, 2020 at 4:47 PM Luigi Scuotto 
> wrote:
>
>> Ciao e dagli con ste fonti. Ricalcato i numeri con codoce postale, se non
>> serve lo cancello ed evito ti fare anche gli altri.
>> 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

Re: [Talk-it] Confini codice postale

[Ivo Reano]

Pardon!
https://www.openstreetmap.org/node/85199286 --> esiste ma è di 10 anni fa
Come relation non esiste.

Il giorno gio 14 mag 2020 alle ore 18:39 Ivo Reano  ha
scritto:

> Luigi sarebbe stato meglio se avessi specificato meglio!
> Andando per tentativi ho provato:
> https://www.openstreetmap.org/way/85199286 --> esiste ma è roba i 9 anni
> fa
> https://www.openstreetmap.org/node/85199286 --> non esiste
> e finalmente:
> https://www.openstreetmap.org/changeset/85199286
> Che è quello che intendeva!
>
> Il giorno gio 14 mag 2020 alle ore 18:35 Marcello  ha
> scritto:
>
>> Il 14/05/20 18:03, Andrea Musuruane ha scritto:
>>
>> Ciao,
>> Non sono un esperto di postal_code, però i boundary dovrebbero essere
>> relazioni. Quella che hai creato tu è un'area e come puoi leggere qui,
>> questo tag non si applica alle aree:
>> https://wiki.openstreetmap.org/wiki/Tag:boundary=postal%20code?uselang=it
>>
>> Inoltre, ricavare l'area di applicazione dei postal_code dai civici
>> esistenti mi sembra una forzatura che può creare problemi.
>>
>> Quando il comune creerà un nuovo civico, il suo CAP questo dovrebbe
>> essere automaticamente identificabile tramite il boundary  esistente. Se
>> questo è stato dedotto (e non si è seguita la regola di definizione dal CAP
>> stesso) allora questa proprietà non vale.
>>
>> In conclusione, credo sia meglio avere il dato (puntuale) sul singolo
>> civico che una approssimazione che non rispecchia la realtà.
>>
>> Ciao,
>>
>> Andrea
>>
>>
>> On Thu, May 14, 2020 at 4:47 PM Luigi Scuotto 
>> wrote:
>>
>>> Ciao e dagli con ste fonti. Ricalcato i numeri con codoce postale, se
>>> non serve lo cancello ed evito ti fare anche gli altri.
>>> 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
>>>
>> Non riesco a capire a cosa fa riferimento l'ID 85199286, comunque nella
>> grande maggioranza dei comuni il CAP è univoco per tutto il territorio
>> comunale, dovrebbero essere meno di 50 i comuni italiani suddivisi in più
>> aree postali, quindi nella maggior parte dei casi alla relazione dei
>> confini comunali può essere aggiunto il tag postal_code=*. Per i comuni
>> suddivisi in più aree dubito che ci sia qualche possibilità di avere i
>> confini in formato compatibile con OSM.
>>
>> Gigi, quali confini hai inserito e quali altri vorresti inserire? Grazie
>>
>> --
>> Ciao
>> Marcello
>>
>>
>> ___
>> 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

[Ivo Reano]

Luigi sarebbe stato meglio se avessi specificato meglio!
Andando per tentativi ho provato:
https://www.openstreetmap.org/way/85199286 --> esiste ma è roba i 9 anni fa
https://www.openstreetmap.org/node/85199286 --> non esiste
e finalmente:
https://www.openstreetmap.org/changeset/85199286
Che è quello che intendeva!

Il giorno gio 14 mag 2020 alle ore 18:35 Marcello  ha
scritto:

> Il 14/05/20 18:03, Andrea Musuruane ha scritto:
>
> Ciao,
> Non sono un esperto di postal_code, però i boundary dovrebbero essere
> relazioni. Quella che hai creato tu è un'area e come puoi leggere qui,
> questo tag non si applica alle aree:
> https://wiki.openstreetmap.org/wiki/Tag:boundary=postal%20code?uselang=it
>
> Inoltre, ricavare l'area di applicazione dei postal_code dai civici
> esistenti mi sembra una forzatura che può creare problemi.
>
> Quando il comune creerà un nuovo civico, il suo CAP questo dovrebbe essere
> automaticamente identificabile tramite il boundary  esistente. Se questo è
> stato dedotto (e non si è seguita la regola di definizione dal CAP stesso)
> allora questa proprietà non vale.
>
> In conclusione, credo sia meglio avere il dato (puntuale) sul singolo
> civico che una approssimazione che non rispecchia la realtà.
>
> Ciao,
>
> Andrea
>
>
> On Thu, May 14, 2020 at 4:47 PM Luigi Scuotto 
> wrote:
>
>> Ciao e dagli con ste fonti. Ricalcato i numeri con codoce postale, se non
>> serve lo cancello ed evito ti fare anche gli altri.
>> 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
>>
> Non riesco a capire a cosa fa riferimento l'ID 85199286, comunque nella
> grande maggioranza dei comuni il CAP è univoco per tutto il territorio
> comunale, dovrebbero essere meno di 50 i comuni italiani suddivisi in più
> aree postali, quindi nella maggior parte dei casi alla relazione dei
> confini comunali può essere aggiunto il tag postal_code=*. Per i comuni
> suddivisi in più aree dubito che ci sia qualche possibilità di avere i
> confini in formato compatibile con OSM.
>
> Gigi, quali confini hai inserito e quali altri vorresti inserire? Grazie
>
> --
> Ciao
> Marcello
>
>
> ___
> 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

[Marcello]

Il 14/05/20 18:03, Andrea Musuruane ha scritto:

Ciao,
    Non sono un esperto di postal_code, però i boundary dovrebbero 
essere relazioni. Quella che hai creato tu è un'area e come puoi 
leggere qui, questo tag non si applica alle aree:

https://wiki.openstreetmap.org/wiki/Tag:boundary=postal%20code?uselang=it

Inoltre, ricavare l'area di applicazione dei postal_code dai civici 
esistenti mi sembra una forzatura che può creare problemi.


Quando il comune creerà un nuovo civico, il suo CAP questo dovrebbe 
essere automaticamente identificabile tramite il boundary esistente. 
Se questo è stato dedotto (e non si è seguita la regola di definizione 
dal CAP stesso) allora questa proprietà non vale.


In conclusione, credo sia meglio avere il dato (puntuale) sul singolo 
civico che una approssimazione che non rispecchia la realtà.


Ciao,

Andrea


On Thu, May 14, 2020 at 4:47 PM Luigi Scuotto 
mailto:luigiscuott...@gmail.com>> wrote:


Ciao e dagli con ste fonti. Ricalcato i numeri con codoce postale,
se non serve lo cancello ed evito ti fare anche gli altri.
Ciao Gigi


Il giorno gio 14 mag 2020 alle ore 16:08 Cascafico Giovanni
mailto:cascaf...@gmail.com>> ha scritto:

Fonti?
Credo siano comunque sufficienti quelli sugli addr:postcode

Il gio 14 mag 2020, 14:09 Luigi Scuotto
mailto:luigiscuott...@gmail.com>>
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

Non riesco a capire a cosa fa riferimento l'ID 85199286, comunque nella 
grande maggioranza dei comuni il CAP è univoco per tutto il territorio 
comunale, dovrebbero essere meno di 50 i comuni italiani suddivisi in 
più aree postali, quindi nella maggior parte dei casi alla relazione dei 
confini comunali può essere aggiunto il tag postal_code=*. Per i comuni 
suddivisi in più aree dubito che ci sia qualche possibilità di avere i 
confini in formato compatibile con OSM.


Gigi, quali confini hai inserito e quali altri vorresti inserire? Grazie

--
Ciao
Marcello

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

Re: [Talk-it] Confini codice postale

[Damjan Gerl]

  
  
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)
  
  Damjan
  
  
  Andrea Musuruane je 14.5.2020 ob 18:03 napisal:


  
  

  Ciao,
      Non sono un esperto di postal_code, però i boundary
dovrebbero essere relazioni. Quella che hai creato tu è
un'area e come puoi leggere qui, questo tag non si applica
alle aree:
  https://wiki.openstreetmap.org/wiki/Tag:boundary=postal%20code?uselang=it
  
  
  Inoltre, ricavare l'area di applicazione dei postal_code
dai civici esistenti mi sembra una forzatura che può creare
problemi. 
  
  
  
  Quando il comune creerà un nuovo civico, il suo CAP
questo dovrebbe essere automaticamente identificabile
tramite il boundary 
esistente. Se questo è stato dedotto (e non si è seguita la
regola di definizione dal CAP stesso) allora questa
proprietà non vale.
  
  
  In conclusione, credo sia meglio avere il dato (puntuale)
sul singolo civico che una approssimazione che non
rispecchia la realtà.
  
  
  
  Ciao,
  
  
  Andrea
  
  



  On Thu, May 14, 2020 at 4:47
PM Luigi Scuotto 
wrote:
  
  

  Ciao e dagli con ste fonti. Ricalcato i numeri con
codoce postale, se non serve lo cancello ed evito ti
fare anche gli altri.
  Ciao Gigi
  
  



  Il giorno gio 14 mag
2020 alle ore 16:08 Cascafico Giovanni  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

Re: [Talk-it] Confini codice postale

[Luigi Scuotto]

Eliminato se basta il CP del numero
Gigi


Il giorno gio 14 mag 2020 alle ore 18:09 Alessandro Vitali <
vitoplu...@gmail.com> ha scritto:

> Grazie! E grazie Manuel!
>
> Il giorno gio 14 mag 2020 alle ore 17:49 Martin Koppenhoefer <
> dieterdre...@gmail.com> ha scritto:
>
>>
>>
>> Am Do., 14. Mai 2020 um 17:36 Uhr schrieb Alessandro Vitali <
>> vitoplu...@gmail.com>:
>>
>>> Ne approfitto per chiedere... come posso ricercare gli elementi tramite
>>> ID? Se lo scrivo nella riga di ricerca di osm non lo trova. Devo inserire
>>> qualche carattere speciale prima o dopo?
>>>
>>
>>
>> io uso i link diretti:
>> https://osm.org/node/123
>> https://osm.org/way/123
>> https://osm.org/relation/123
>>
>> Ciao
>> Martin
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Confini codice postale

[Alessandro Vitali]

Grazie! E grazie Manuel!

Il giorno gio 14 mag 2020 alle ore 17:49 Martin Koppenhoefer <
dieterdre...@gmail.com> ha scritto:

>
>
> Am Do., 14. Mai 2020 um 17:36 Uhr schrieb Alessandro Vitali <
> vitoplu...@gmail.com>:
>
>> Ne approfitto per chiedere... come posso ricercare gli elementi tramite
>> ID? Se lo scrivo nella riga di ricerca di osm non lo trova. Devo inserire
>> qualche carattere speciale prima o dopo?
>>
>
>
> io uso i link diretti:
> https://osm.org/node/123
> https://osm.org/way/123
> https://osm.org/relation/123
>
> Ciao
> Martin
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Yves P.]

> Je pensais importer des conteneurs : ça tombe bien, il y a pleins de PAV dans 
> data.gouv.fr 
> Il
>  y a déjà un fichier traité dans Osmose : Clisson Sèvre et Maine Agglo 
> 

__
Yves

Tags utilisés :
amenity=waste_disposal
operator=Clisson Sèvre et Maine Agglo
fee=yes
authentication:membership_card=yes (pour tous ? alors qu'il n'y en a que 14 
verrouillés)
authentication:none=no
location=underground (pour les Colonnes enterrées)
opening_hours=24/7 (pour les PAV qui ne sont pas dans un centre)

J'ai l'impression que le fichier utilisé n'est plus disponible et qu'il ne 
traitait que les PAV d'ordures ménagères (avec ou sans clé électronique)

Celui sur data.gouv.fr 

 à les champs suivants :
type
Colonne aérienne
Colonne enterrée
Ordure ménagère (A clé intelligente)
Vêtements
detail contient des infos intéressantes en texte libre et  "mélangées" :
2 Ordures ménagères (Accès clé)
2 Ordures ménagères-Papier
2 Ordures ménagères-Papier-Verre
2 Papiers + 2 Verres
2 Papiers + 3 Verres
2 Papiers + Verre
2 Verres
4 Ordures ménagères
Ordure ménagère
Ordure ménagère - Papier
Ordure ménagère (Accès clé)
Ordure ménagère-Papier-Verre
Papier
Papier + 2 Verres
Papier + Verre
Verre
Vêtements___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Confini codice postale

[Andrea Musuruane]

Ciao,
Non sono un esperto di postal_code, però i boundary dovrebbero essere
relazioni. Quella che hai creato tu è un'area e come puoi leggere qui,
questo tag non si applica alle aree:
https://wiki.openstreetmap.org/wiki/Tag:boundary=postal%20code?uselang=it

Inoltre, ricavare l'area di applicazione dei postal_code dai civici
esistenti mi sembra una forzatura che può creare problemi.

Quando il comune creerà un nuovo civico, il suo CAP questo dovrebbe essere
automaticamente identificabile tramite il boundary  esistente. Se questo è
stato dedotto (e non si è seguita la regola di definizione dal CAP stesso)
allora questa proprietà non vale.

In conclusione, credo sia meglio avere il dato (puntuale) sul singolo
civico che una approssimazione che non rispecchia la realtà.

Ciao,

Andrea


On Thu, May 14, 2020 at 4:47 PM Luigi Scuotto 
wrote:

> Ciao e dagli con ste fonti. Ricalcato i numeri con codoce postale, se non
> serve lo cancello ed evito ti fare anche gli altri.
> 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-it] Confini codice postale

[Alessandro Sarretta]

Non capisco di cosa si sta parlando...

Ale

On 14/05/20 16:46, Luigi Scuotto wrote:
Ciao e dagli con ste fonti. Ricalcato i numeri con codoce postale, se 
non serve lo cancello ed evito ti fare anche gli altri.

Ciao Gigi


Il giorno gio 14 mag 2020 alle ore 16:08 Cascafico Giovanni 
mailto:cascaf...@gmail.com>> ha scritto:


Fonti?
Credo siano comunque sufficienti quelli sugli addr:postcode

Il gio 14 mag 2020, 14:09 Luigi Scuotto mailto:luigiscuott...@gmail.com>> 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-it] Confini codice postale

[Manuel]

Se intendi cercare, mentre hai ID aperto, un elemento conoscendo la sua 
tipologia e codice numerico, basta inserire nella casella di ricerca x con 
x che può valere w, n, r (way, node, relation) e  è il codice numerico.


Il 14/05/2020 17:49, Martin Koppenhoefer ha scritto:



Am Do., 14. Mai 2020 um 17:36 Uhr schrieb Alessandro Vitali mailto:vitoplu...@gmail.com>>:

Ne approfitto per chiedere... come posso ricercare gli elementi tramite ID? 
Se lo scrivo nella riga di ricerca di osm non lo trova. Devo inserire qualche 
carattere speciale prima o dopo?



io uso i link diretti:
https://osm.org/node/123
https://osm.org/way/123
https://osm.org/relation/123

Ciao
Martin


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


--
Manuel Tassi

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

Re: [Talk-it] Confini codice postale

[Martin Koppenhoefer]

Am Do., 14. Mai 2020 um 17:36 Uhr schrieb Alessandro Vitali <
vitoplu...@gmail.com>:

> Ne approfitto per chiedere... come posso ricercare gli elementi tramite
> ID? Se lo scrivo nella riga di ricerca di osm non lo trova. Devo inserire
> qualche carattere speciale prima o dopo?
>


io uso i link diretti:
https://osm.org/node/123
https://osm.org/way/123
https://osm.org/relation/123

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

Re: [Talk-it] Confini codice postale

[Alessandro Vitali]

Ne approfitto per chiedere... come posso ricercare gli elementi tramite ID?
Se lo scrivo nella riga di ricerca di osm non lo trova. Devo inserire
qualche carattere speciale prima o dopo?

Grazie!

Il giorno gio 14 mag 2020 alle ore 16:47 Luigi Scuotto <
luigiscuott...@gmail.com> ha scritto:

> Ciao e dagli con ste fonti. Ricalcato i numeri con codoce postale, se non
> serve lo cancello ed evito ti fare anche gli altri.
> 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: [OSM-talk-fr] Point d'apport volontaire, point de collecte, point de regroupement

[Yves P.]

> En fait ce crocher permet de matérialiser le mode d'enlèvement et donc on 
> sait d'office que l'on est sur ce que l'on appel un PAV (Point d'Apport 
> Volontaire) et pour l'OMR on est surement sur un abus de langage.
Diogène parle à l'infirmier psy mais je ne vois pas le rapport entre le support 
d'enlèvement et un PAV…

Le type de support, ce qu'on met dans un bac en fonction de sa couleur, la 
présence ou non d'un tag RFID… sont-ils identiques pour tous les bacs d'une 
même "agglomération" ?
Si oui, est-ce que ça peut être décrit une fois pour toute au niveau de la 
relation ?

> Oui vu qu'Yves a aussi bien avancer sur le sujet je vais voir avec lui pour y 
> faire par d'un doc que l'on proposera à la communauté pour essayer de 
> compléter au mieux
On peut continuer l'inventaire à la Prévert ;) et si possible, essayer de voir 
ce qui existe à l'international.

> 
> Pour certains cas (les défibrillateurs par exemple) on met marque et
> modèle, ça c'est peut être facile à trouver et permet de compléter les
> autres attributs techniques a priori.
J'ai photographié 2 conteneurs à verre croisé sur ma route. Je n'ai pas vu de 
marque, ni de n° de série.

> C'est possible mais dans ce cas il faudrait peut-être faire le lien avec les 
> fournisseurs (catalogue sur une page d'exemple) et avoir des photos ouvertes 
> faites par des contributeurs sur le terrain.
Oui. En gros, il en existe combien en France ?

> Même chose aussi sur les poteaux incendies.
En plus de la localisation, ce qui est important pour le pompier c'est le 
diamètre et savoir si le POI est fonctionnel (débit et volume suffisant, état).
Avoir le fabriquant et le modèle est un plus. Sur les poteaux récent c'est 
visible.

> Je prends aussi l'exemple des bornes incendies en exemple car il y a bien une 
> richesse d'information que tous le monde ne mettra pas. Les interco en ont la 
> gestion et les SDIS les exploitent.

> Quel intérêt pour le publique aujourd'hui ? Aucun sauf pour un point de RDV? 
> ;-)
Si, savoir si ton domicile, ton entreprise… sont bien "défendus."
Si le PEI est à moins de 200 m, c'est bien.
Si il est aux normes, utilisable c'est mieux. Parfois il y a un beau poteau 
tout neuf, relié à une canalisation trop petite : bof.

> Veolia, Sita, Paprec, Pizzorno, Bronzo, Urbaser, Sepur, Onyx, Brangeon et 
> (leurs filiales) et autres opérateurs privés locaux
Merci. Je ne connaissais de nom que le premier.

> Est-ce qu'il y a un besoin/intérêt à saisir ça dans OSM ?
> De même que la référence du conteneur (visible sur le bac) ?
> Mettre les bacs RFID dans OSM non car ça serait vraiment comme mettre les 
> compteurs d'eau dans OSM (qui plus est on est sur le l'information 
> individuelle donc RGPD …)
Je ne parlais pas du n° de série du tag, seulement de sa présence.

Et pour les n° de série des conteneurs ?

Je pensais importer des conteneurs : ça tombe bien, il y a pleins de PAV dans 
data.gouv.fr 


Bémols :
Les formats ne sont pas tous disponibles, parfois il n'y a pas de fichier à 
télécharger mais une API, et surtout ils ne sont pas homogènes / normalisés ;)

Quelques exemples :
Grand Besançon 

 :  pas dispo.
Montpellier Méditerranée Métropole 

 : 
type=Ordures ménagères, Tri sélectif, Papier, Verre
St Malo-Agglomération 

 :
type=colonne verre, verre enterrée, EMR enterrée, compacteur, OM enterrée, 
colonne EMR, colonne papier
Grenoble-Alpes Métropole 
 :
type_conteneur=aérien, enterré, semi-enterré type_dechet=collecte sélective, 
emballages, ordures ménagères résiduelles, papier, verre
Versailles Grand Parc 

 :
API REST ESRI (plusieurs couches : Déchets Recyclables, Déchets Végétaux, 
Ordures Ménagères, Verre, Verre en projet).
prehension
type_pav2 : Aérien, Enterré, Semi-enterré
m_cube
Le Havre Seine Métropole 
 :
TYPE_FLUX=EMBALLAGES, ORDURES MENAGERES, TEXTILE, VERRE, (blank)
__
Yves___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Confini codice postale

[Luigi Scuotto]

Ciao e dagli con ste fonti. Ricalcato i numeri con codoce postale, se non
serve lo cancello ed evito ti fare anche gli altri.
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

Re: [Talk-it] Confini codice postale

[Cascafico Giovanni]

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

[OSM-talk-be] privacy ed

[wbrt]

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

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

[European Water Project]

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

[OSM-talk-fr] URL de chaque point de vente d'une enseigne

[Florian LAINEZ]

Hello,
Avec "ça reste ouvert" est apparu plus clairement le besoin d'identifier
les enseignes et leurs points de vente.
C'est le travail qui a été commencé dans "covid-enseignes" cf.
https://github.com/PanierAvide/Covid_enseignes

Pour aller plus loin, il serait intéressant d'*afficher l'URL exact pour
chacun des points de vente*.
Cette information est utile aux utilisateurs directement : en cliquant, ils
obtiennent toutes les infos détaillées. C'est aussi intéressant pour les
contributeurs OSM qui ont un accès direct notamment pour obtenir les
horaires d'ouverture.
Exemple pour un magasin Picard
 : website=
https://magasins.picard.fr/892-picard-st-marcel

Je me pose la question de la meilleure manière de systématiser cela.
J'imagine bien un outil qui crawle mensuellement le site web de toutes les
grandes enseignes et qui :
1. Propose d'associer une URL pour chaque point de vente sur la base de son
nom, de son adresse et de sa localisation. Un contributeur OSM n'aurait
alors qu'à valider manuellement l'ajout d'URL pour chaque point de vente.
2. Identifie les points de vente manquants et nourrisse OMOSE avec cette
info
3. Identifie les points de vente qui ferment et nourrisse OSMOSE avec cette
info
4. Identifie les changements de structuration d'URL sur les sites web qui
rendent potentiellement obsolète toutes les URLs d'une marque en particulier

Il faudra en effet s'adapter à la structuration d'URL unique pour chaque
site, par exemple :
https://magasins.picard.fr/892-picard-st-marcel
https://www.franprix.fr/magasins/4085
https://www.carrefour.fr/magasin/market-abbeville-amiens
https://www.citroen.fr/rechercher-un-point-de-vente/049816/paris-st-didier.html
https://www.ikea.com/fr/fr/stores/mulhouse
Pour d'autres, il n'y a pas d'URL pour chaque point de vente, exemple
https://www.marionnaud.fr/magasins et là, c'est le drame.

On pourrait commencer sur une enseigne en particulier, puis étoffer ça au
fur-et-à-mesure, avec des projets du mois spécifiques à certains types de
points de vente (voir élargir au delà du commerce).
Je me demande si la licence "tout droits réservés" de ces sites n'est pas
un blocage à réaliser ces opérations. Peut-être est-ce le cas uniquement
pour la réutilisation des géoloc des lieux, ce qui bloquerait uniquement la
réutilisation par OSMOSE.

Avec les points 2. et 3. on pourrait avoir le taux de complétion de
présence des lieux de vente de chaque marque dans OSM. Ces infos me
paraissent déjà être un énorme pas en avant.

PS : certains seront sûrement tentés de proposer ref=892 en complément ou
en remplacement de website=https://magasins.picard.fr/892-picard-st-marcel
Autant pour les points géodésiques nous avons décidé

de renseigner de renseigner A LA FOIS le tag REF et le tag URL (vers la
fiche PDF du point géodésique), autant pour les lieux de vente je pense que
ce n'est pas pertinent car 1. nous ne disposons pas de jeu de données
mentionnant la référence de chaque point de vente 2. la pérennité de cet
identifiant pose autant question que celle de l'URL.
En l’occurrence, l'URL d'un point de vente deviendrait son identifiant
unique de-facto, ce qui semble un compromis intéressant.

-- 

*Florian Lainez*
@overflorian 
___
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]

Hi Martin,

Thank you for the feedback.

The popup and the popup images are  currently dimensioned in pixels. I will
adjust them to be responsive and a percentage of the viewport width and the
viewport height.

Let me consider how to add a photo upload option ? You are the third person
who has suggested that.

Best regards,

Stuart

On Thu, 14 May 2020 at 14:07, Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 14. May 2020, at 13:09, European Water Project <
> europeanwaterproj...@gmail.com> wrote:
> >
> > I would appreciate if you and others can take a couple of pictures of
> fountains in Italy for us with the app ! and help test this new feature
> (which seems to work so far on most modern smart phones).
>
>
>
> the css can result in unfortunate layout on a small screen (667x1200)
> because the link on the popup ended offscreen in my case, maybe the
> fountain symbol is the issue because it was huge. Try putting the link
> before the icon and make the icon smaller.
>
> It could maybe also be useful to allow upload of photos?
>
> 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-GB] Rights of way mapping - making it easy for newcomers to OSM (perhaps!)

[SK53]

It's worth pointing out that the same can be done with the following
editors: iD, Potlatch2, and Vespucci. The actual formats (gpx, kml, shape,
geojson) vary a bit, but all have the capability.

For some years I've loaded KMLs onto Maps.Me so I can actually check the
line in the field (I've made Garmin files too, but this is easier &
quicker).

Jerry

On Thu, 14 May 2020 at 12:26, Tony OSM  wrote:

> Hi
>
> I had the Lancashire KML file handy (as you do),  looked up JOSM import
> and found the OpenData plug in. Dropped the KML file onto the plug in and
> it created a lancashire.kml layer with all of the ways on the layer and the
> kml fields as tags.
>
> When combined with OSM data and ESRI imagery it provides a really useful
> view of the footpaths. I have a paint style which picks out some PROW types
> which allows me to see what is in osm and what isn't. So I can do some
> manual editing.
>
> From the kml layer I have all the data to determine the Parish, Type &
> PROW ref - that is manual tag editing.
>
>
> This view does allow me to see existing paths and PROW's and manually
> determine what mapping I can do.
>
>
> Overlaying kml onto the imagery has already helped me to see a path I was
> confused about - where it actually went. I'll be able to go out and survey
> soon.
>
> JOSM in the Edit dropdown has a Merge layer capability - I think this
> should be avoided at all costs as that would constitute an unmanaged data
> import of the whole of the KML file - an OSM disaster.
>
>
> Adding a GPS layer will make this an awesome toolkit.
>
>
> Tony
>
>
> On 14/05/2020 11:45, Nick Whitelegg wrote:
>
> Hello Tony and Gareth,
>
> Thanks for your thoughts.
>
> My main thought was a specialised JOSM plugin - I did take a look at OSM's
> main GPX trace facility but it appears not to preserve tags in the uploaded
> trace. Some versions of the MapThePaths app (the first version, and the
> current version on Gitlab) allow GPX upload to OSM but the tags are removed.
>
> So I'm thinking that my own storage (I have quite a bit of available
> storage) and a custom JOSM plugin, which, for example, creates colour-coded
> and clickable traces showing the ROW designation, surface and highway tags
> might be the way to go.
>
> Thanks,
> Nick
> --
> *From:* Gareth L  
> *Sent:* 14 May 2020 09:56
> *To:* Tony OSM  
> *Cc:* talk-gb@openstreetmap.org 
> 
> *Subject:* Re: [Talk-GB] Rights of way mapping - making it easy for
> newcomers to OSM (perhaps!)
>
> I wonder if it would be possible to use the GPS trace feature on OSM for
> this? Maybe format the name in a way to make it easier to retrieve?
>
> Takes care of the storage of the traces.
>
>
> On 14 May 2020, at 09:22, Tony OSM 
>  wrote:
>
> 
>
> Hi Nick
>
> I like the two stage approach - surveying then mapping. It would work well
> - some of my friends like walking but can't map to save their life, whereas
> I can't walk far but love mapping - Win Win for us all.
>
>
> May I suggest that a layer be created for JOSM with all the paths and
> their details as provided for MapThePaths. Personally I find it easier to
> work with JOSM and I have learnt to create a style to highlight PROW's, but
> I don't know how to create a JOSM layer.
>
> Separate layers would allow us to manually transfer from PROW layer to MAP
> layer thus avoiding the mechanical import rules, and would allow us to
> manually conflate where a path is already mapped but PROW data is absent.
>
> A layer containing the surveyed GPS data so that all the sources we need
> are available would be awesome.
>
>
> I may be asking for a workflow that is close to existing, if that is the
> case I am able to test and document the workflow for the UK wiki if that
> would be helpful.
>
>
> Tony Shield
>
> TonyS999
>
>
> On 13/05/2020 18:11, Nick Whitelegg wrote:
>
>
> Oops... sorry one or two editing errors in the last paragraph.
>
> I meant to say:
>
> "They [the non-expert user] select ROW type and path surface via a nice
> interface, and then a tagged GPX trace is generated, *with trksegs tagged
> with ROW designation and surface* (which was done by the first version of
> the app anyway). This is then uploaded to the MapThePaths server, and
> volunteer expert users *are alerted*. Said expert user then downloads the
> GPX trace and, *using the tags in the trksegs of the GPX* then edits in
> JOSM, perhaps via a JOSM plugin - or even directly in the MapThePaths web
> app. (I am possibly thinking of adding way creation into the MapThePaths
> web app anyway, time depending)."
>
> Nick
>
> --
> *From:* Nick Whitelegg
> *Sent:* 13 May 2020 18:08
> *To:* talk-gb@openstreetmap.org 
> 
> *Subject:* Rights of way mapping - making it easy for newcomers to OSM
> (perhaps!)
>
> Hi,
>
> Just to continue with the theme of rights of way mapping, I've been
> noticing that there are still large tracts of England and Wales away from
> the 'honeypot' areas with little or now ROW 

Re: [OSM-talk-fr] Piétonisation ponctuelle du Vieux-Lille

[Florimond Berthoux]

Salut,

À Paris on a des voies piétonisées le dimanche taggué en :
motor_vehicle:conditional=destination @ (Oct-Mar Su,PH 10:00-18:00;Apr-Sep
Su,PH 10:00-20:00;Jul 23-Aug 21 Sa 14:00-20:00)

Le 'destination' est plus juste que le 'no' si c'est une zone piétonne
suivant la réglementation française.

Après je me suis déjà dit que ça serait peut-être plus juste et simple de
tagguer ça :
highway:conditional=pedestrian @ ([dates])
plutôt que d'interpréter et tagguer le code de la route, car sinon il
faudrait aussi ajouter le maxspeed, la priorité piétonne...

Cordialement,

Le jeu. 14 mai 2020 à 12:25, Carto_ADAV  a écrit :

> Bonjour à tous,
>
> Ce samedi de 10h à 19h, le Vieux Lille sera piétonnisé et cette situation
> devrait être pérennisé.
>
> Article de presse : https://tinyurl.com/yc32l4sq
>
> Je m’apprête à taguer les rues piétonnisés ponctuellement de cette
> manière, je voulais juste avoir votre avis sur l'ajout des tags ci-dessous :
>
> motor_vehicle = yes
> motor_vehicle:conditional = no@(sa10:00-19:00)
> description:covid19 = piétonisation du Vieux Lille, le samedi de 10h à 19h
>
> Merci pour votre retour !
>
> Mathias
>
> --
> Mathias Vadot
> Droit au vélo - ADAV
> 5 rue Jules de Vicq
> 59800 LILLE
> Tél : 03 62 27 51 86
> mail : mathias.va...@droitauvelo.org
>
>
>
> --
> [image: Avast logo] 
>
> L'absence de virus dans ce courrier électronique a été vérifiée par le
> logiciel antivirus Avast.
> www.avast.com 
>
> <#m_3494586290215169330_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Florimond Berthoux
___
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]

Le jeu. 14 mai 2020 à 13:09,  a écrit :

> Je ne crois pas qu'il faut y voir un parti pris idéologique : recycling
> suppose qu'il y a recyclage et mettre reycling et waste ensemble forme
> un oxymore. Et oui il y a de l'écoblanchiment pour certains à parler de
> recyclage là où il n'y en a pas.
>
Ok. C'est pour cela que je parle plus de conteneur dans un process
d'enlèvement pouvant rentrer dans un process de recyclage. Je pense
particulièrement à l'Amiante qui n'est pas recyclé mais qui peut pour les
particulier être admis en centre

>
> Je ne connais pas l'équivalent de répurgation en anglais. DeepL dit
> repurgation.
>
 Je ne te suis pas sur le sujet. Peux-tu me préciser tes pensées?

end of life ? Mais changer une clé très utilisée... avec en plus le
> problème que EOL a plusieurs significations et pas spécialement
> celle-là. Alors un avertissement sur le wiki pour signaler qu'il s'agit
> de la fin de vie en général, que le produit collecté soit effectivement
> recyclé ou pas ?
>
En fait dans le cycle de traitement c'est plutôt du oui non. C'est
recyclable ou pas. On a d'autre produit qui rentre dans des processus de
retraitement. On a par exemple à certains endroit des produits plastique
avec consigne de tri étendu prenant dans les plastique souple. Par contre
c'est une politique des fois des communes sans pour autant que les centres
soit en capacité de traiter et donc ça engendre un tri supplémentaire avec
un retour à l'enfouissement ou l’incinération. Bref la consigne de tri
étendu c'est pour 2022. On verra si tous les centres se sont adaptés

>
> Si ça vous sert de savoir quel système de préhension, pourquoi ne pas
> grip=hook, sucsion ... mais il faut se mettre d'accord sur la partie
> qu'on modélise : est-ce l'outil pour appréhender ou le côté statique.
>
En fait ce crocher permet de matérialiser le mode d'enlèvement et donc on
sait d'office que l'on est sur ce que l'on appel un PAV (Point d'Apport
Volontaire) et pour l'OMR on est surement sur un abus de langage. Bref dans
tous les cas c'est pas de l'apport volontaire mais du tri volontaire pour
une évacuation forcé (sauf pour les gens atteint du syndrome de Diogène)

>
> Décrire le côté statique c'est simple (la personne le voit, ici un
> anneau) ou pas (savoir comment est récupéré ce que j'aurais appelé une
> benne et que tu appelles un caisson, ce n'est pas évident).
>
On peut définir en effet le coté statique quand au mode de récupération
c'est par l'exemple sur le wiki que l'on peut le présenter ou à renseigner
par les gestionnaire public qui en ont la charge

>
> Tu nous fais une traduction jargon / noms pour béotiens francophones
> ou/et anglophones (Yves a bien commencé) et une proposition de schéma de
> tags "à la François" ?
>
Oui vu qu'Yves a aussi bien avancer sur le sujet je vais voir avec lui pour
y faire par d'un doc que l'on proposera à la communauté pour essayer de
compléter au mieux sans pour autant tous remettre en question

>
> Pour certains cas (les défibrillateurs par exemple) on met marque et
> modèle, ça c'est peut être facile à trouver et permet de compléter les
> autres attributs techniques a priori.
>
C'est possible mais dans ce cas il faudrait peut-être faire le lien avec
les fournisseurs (catalogue sur une page d'exemple) et avoir des photos
ouvertes faites par des contributeurs sur le terrain. Même chose aussi sur
les poteaux incendies.

>
> --
Cordialement,
Jérôme Seigneuret
___
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

[Martin Koppenhoefer]

sent from a phone

> On 14. May 2020, at 13:09, European Water Project 
>  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] Confini codice postale

[Luigi Scuotto]

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

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

[Martin Koppenhoefer]

sent from a phone

> On 14. May 2020, at 13:09, European Water Project 
>  wrote:
> 
> I would appreciate if you and others can take a couple of pictures of 
> fountains in Italy for us with the app ! and help test this new feature 
> (which seems to work so far on most modern smart phones). 



the css can result in unfortunate layout on a small screen (667x1200) because 
the link on the popup ended offscreen in my case, maybe the fountain symbol is 
the issue because it was huge. Try putting the link before the icon and make 
the icon smaller.

It could maybe also be useful to allow upload of photos?

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

[OSM-talk-ie] Estimate of number of building=* in Ireland

[Colm Moore]

Hi,

Apologies, there was something else I meant to mention.

Some locations have a very low number of building polygons per capita (i.e. 
implying high number of people per building). This may be **suggestive** of 
locations that are under-mapped. This bears out in some of suburbs on the 
Kilkenny side of Waterford city, where there are lots of unmappable (tree cover 
and fuzzy images) garden sheds, etc. There are other reasons for this, like 
apartment buildings, terraced houses mapped as building=terrace, etc.

On Wed, 13 May 2020 at 14:38, Donie Kelly  wrote:

> Don’t buildings have tags? Did I see a residential tag? Is it used in all
> cases?

Yes, buildings can be given detailed descriptions, e.g. building=house, 
building=apartments. However, about half of the buildings on the island just 
use building=yes. Only saying building=yes gets the building on the map 
quickly, makes them readily findable and lets other mappers fill in details 
later. Not all buildings are readily identifiable from aerial images and 
details like number of storeys can be even harder to determine.

Note that building=residential can be used for buildings that are residential, 
but the type isn't readily identifiable, e.g. I saw some semi-detached houses 
in Kilkenny that were attached back-to-back instead of side-to-side.

Interpreting the total number of buildings on the island from the total number 
of, say houses, would be more complicated than comparing number of buildings in 
Kilkenny to the number of buildings on the island.

On Thu, 14 May 2020 11:47:29 Tadeusz Cantwell  wrote:

> The residential tag should be used for an area not a house.

Yes, landuse=residential should be used for residential sites / estates / 
neighbourhoods. The iD editor now supports additional sub-tags, e.g. 
residential=rural, residential=apartments and residential=halting_site You can 
also add name=* to the likes of housing estates, which can help detail the 
hierarchy of a town.

Colm


---


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

Re: [Talk-GB] Rights of way mapping - making it easy for newcomers to OSM (perhaps!)

[Tony OSM]

Hi

I had the Lancashire KML file handy (as you do),  looked up JOSM import 
and found the OpenData plug in. Dropped the KML file onto the plug in 
and it created a lancashire.kml layer with all of the ways on the layer 
and the kml fields as tags.


When combined with OSM data and ESRI imagery it provides a really useful 
view of the footpaths. I have a paint style which picks out some PROW 
types which allows me to see what is in osm and what isn't. So I can do 
some manual editing.


From the kml layer I have all the data to determine the Parish, Type & 
PROW ref - that is manual tag editing.



This view does allow me to see existing paths and PROW's and manually 
determine what mapping I can do.



Overlaying kml onto the imagery has already helped me to see a path I 
was confused about - where it actually went. I'll be able to go out and 
survey soon.


JOSM in the Edit dropdown has a Merge layer capability - I think this 
should be avoided at all costs as that would constitute an unmanaged 
data import of the whole of the KML file - an OSM disaster.



Adding a GPS layer will make this an awesome toolkit.


Tony


On 14/05/2020 11:45, Nick Whitelegg wrote:

Hello Tony and Gareth,

Thanks for your thoughts.

My main thought was a specialised JOSM plugin - I did take a look at 
OSM's main GPX trace facility but it appears not to preserve tags in 
the uploaded trace. Some versions of the MapThePaths app (the first 
version, and the current version on Gitlab) allow GPX upload to OSM 
but the tags are removed.


So I'm thinking that my own storage (I have quite a bit of available 
storage) and a custom JOSM plugin, which, for example, creates 
colour-coded and clickable traces showing the ROW designation, surface 
and highway tags might be the way to go.


Thanks,
Nick

*From:* Gareth L 
*Sent:* 14 May 2020 09:56
*To:* Tony OSM 
*Cc:* talk-gb@openstreetmap.org 
*Subject:* Re: [Talk-GB] Rights of way mapping - making it easy for 
newcomers to OSM (perhaps!)
I wonder if it would be possible to use the GPS trace feature on OSM 
for this? Maybe format the name in a way to make it easier to retrieve?


Takes care of the storage of the traces.



On 14 May 2020, at 09:22, Tony OSM  wrote:



Hi Nick

I like the two stage approach - surveying then mapping. It would work 
well - some of my friends like walking but can't map to save their 
life, whereas I can't walk far but love mapping - Win Win for us all.



May I suggest that a layer be created for JOSM with all the paths and 
their details as provided for MapThePaths. Personally I find it 
easier to work with JOSM and I have learnt to create a style to 
highlight PROW's, but I don't know how to create a JOSM layer.


Separate layers would allow us to manually transfer from PROW layer 
to MAP layer thus avoiding the mechanical import rules, and would 
allow us to manually conflate where a path is already mapped but PROW 
data is absent.


A layer containing the surveyed GPS data so that all the sources we 
need are available would be awesome.



I may be asking for a workflow that is close to existing, if that is 
the case I am able to test and document the workflow for the UK wiki 
if that would be helpful.



Tony Shield

TonyS999


On 13/05/2020 18:11, Nick Whitelegg wrote:


Oops... sorry one or two editing errors in the last paragraph.

I meant to say:

"They [the non-expert user] select ROW type and path surface via a 
nice interface, and then a tagged GPX trace is generated, *with 
trksegs tagged with ROW designation and surface* (which was done by 
the first version of the app anyway). This is then uploaded to the 
MapThePaths server, and volunteer expert users *are alerted*. Said 
expert user then downloads the GPX trace and, *using the tags in the 
trksegs of the GPX* then edits in JOSM, perhaps via a JOSM plugin - 
or even directly in the MapThePaths web app. (I am possibly thinking 
of adding way creation into the MapThePaths web app anyway, time 
depending)."


Nick


*From:* Nick Whitelegg
*Sent:* 13 May 2020 18:08
*To:* talk-gb@openstreetmap.org  
 
*Subject:* Rights of way mapping - making it easy for newcomers to 
OSM (perhaps!)

Hi,

Just to continue with the theme of rights of way mapping, I've been 
noticing that there are still large tracts of England and Wales away 
from the 'honeypot' areas with little or now ROW mapping at all 
meaning there's still quite a big job to be done.


As you may remember I have been developing a companion app to 
MapThePaths. In the first version of this (around two years ago) I 
experimented with auto-converting GPX traces to OSM ways. However I 
was dissatisfied with the results, the ways generated were really 
rather nasty and I ended up having to prettify them significantly in 
JOSM 

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

[Mateusz Konieczny via Talk-ie]

both building=residential and landuse=residential
are valid tagging

(though, if possible then building=house
or other more specific value is preferable)


May 14, 2020, 12:47 by t4d...@gmail.com:

> The residential tag should be used for an area not a house.
>
> On Wed, 13 May 2020 at 14:38, Donie Kelly  wrote:
>
>> Don’t buildings have tags? Did I see a residential tag? Is it used in all
>> cases?
>>
>> > On 13 May 2020, at 13:24, Colm Moore  wrote:
>> >
>> > Hi,
>> >
>> > Inspired by seeing the estimate in the Microgrant application of 5.5
>> million buildings on the island of Ireland, I did some number crunching.
>> >
>> > I downloaded the populations of Kilkenny townlands (1,500+) from the CSO
>> and analysed the population against the number of buildings per civil
>> parish (100+) for County Kilkenny. This is assuming Kilkenny has all or
>> nearly all buildings mapped. Based on my inspections, this is largely true.
>> >
>> > The CSO data is somewhat distorted for the Kilkenny city area (100+
>> townlands), due to the way the CSO have arranged the townlands and civil
>> parishes. I could look at this in more detail, but there would be a few
>> hours of effort (unless someone has a simple way of calculating number of
>> buildings per area, for a large number of areas).
>> >
>> > I calculated the 'number of buildings per civil parish' using the
>> Overpass Turbo query [building=* in "civilparishname, Kilkenny"]. Overpass
>> Turbo gives a summary of the data in the bottom right corner of the screen,
>> e.g.
>> >
>> > Loaded – nodes: 4261, ways: 867, relations: 2
>> > Displayed – pois: 0, lines: 0, polygons: 866
>> >
>> > I took the number of polygons to mean the number of buildings (this
>> might not be perfect - I don't know how those numbers add up).
>> Additionally, some polygons, e.g. building=terrace represent several
>> buildings, while in other cases buildings may have been crudely split or
>> joined-up.
>> >
>> > Depending on the civil parish, we're looking at 0.32-2.29 polygons per
>> capita (0.44-3.15 people per building). Rural areas ten to have more
>> polygons per capita, especially due to farm outbuildings, while urban areas
>> have fewer polygons per capita, due to apartments buildings and
>> semi-detached buildings (e.g. two square houses joined together might have
>> only six nodes).
>> >
>> > I also calculated 4.40-5.83 nodes per polygon. This means some civil
>> parishes have predominantly rectangular polygons / buildings, whereas
>> others have many L-shaped or other-shaped polygons / buildings.
>> >
>> > As I wasn't able to immediately get some 'number of buildings per civil
>> parish' numbers (Overpass Turbo had problems returning them, possibly due
>> to duplicate names and variations in name spellings), I had to calculate
>> them from their component townlands, using the Overpass Turbo query
>> [building=* in "townlandname, civilparishname, Kilkenny"].
>> >
>> > Depending on the townland, we're looking at 0.23-8.00 polygons per
>> capita (0.13-4.37 people per building) and 3.91-6.45 nodes per polygon
>> (i.e. some townlands have large numbers of semi-detached or terraced
>> buildings, whereas others have a high number of complicated-shape polygons
>> / buildings or buildings with too many mapped nodes). It is usual to see
>> more extreme spreads when looking at smaller areas.
>> >
>> > I'm coming up with about 5.4 million (close enough!) buildings for the
>> whole island, assuming the pattern is the same everywhere. However, as
>> shown by analysing the smaller areas, there is variation and the 'final'
>> number will vary from that. Of course, given that OSM is an ongoing
>> project, there will never be a final number.
>> >
>> > Colm
>> > VictorIE
>> > ___
>> > Talk-ie mailing list
>> > Talk-ie@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-ie
>>
>> ___
>> Talk-ie mailing list
>> Talk-ie@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ie
>>
> ___
> Talk-ie mailing list
> Talk-ie@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ie
>

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

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

[European Water Project]

Dear Andrea and Francesco,

I have taken on board your suggestions to streamline the photo image
capture process and to consider Mapillary as an alternative to Wikimedia
Commons.

We have added the ability to capture images directly within the European
Water Project Web App by clicking on "Aggiungi/aggiorna questa immagine
"
link in the popup for a fountain.

The photo initially gets stored on our server and shows up immediately in
the application. https://europeanwaterproject.org?lang=IT

After manual curation, we load the images to Mapillary and link them to
OpenStreetMap objects. 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.

I would appreciate if you and others can take a couple of pictures of
fountains in Italy for us with the app ! and help test this new feature
(which seems to work so far on most modern smart phones).

We had to postpone our Rome and Milan fountain hunts due to Covid, but I
hope they can be rescheduled soon.

best regards,

Stuart

On Mon, 20 Jan 2020 at 11:40, Andrea Musuruane  wrote:

> Hi Stuart,
>  I think that the proposed workflow to add drinking water POIs is not
> easy for the casual user who is not already an OpenStreetMap contributor
> (and OSM contributors already add these POIs :-)). You require a casual
> user to register on both OSM and Wikimedia Commons. You require to upload a
> photo of the POI which gives very little added value per se.
>
> A simplified workflow with a specialized focus on drinking water POIs
> would be better. For example, let the user take a photo using the smart
> phone. The photo will already have EXIF data. Among the EXIF data there are
> the coordinates where the photo has been taken (latitude/longitude). Check
> if a POI is already present nearby. If not, position a marker on these
> coordinate with a satellite map as background. Let the user move it to
> better place the POI. When the user is happy, he can submit the info and
> automatically the POI should be imported in OSM and the photo in Wikimedia
> Commons.
>
> Best Regards,
>
> Andrea
>
>
> On Mon, Jan 20, 2020 at 8:13 AM European Water Project <
> europeanwaterproj...@gmail.com> wrote:
>
>> Dear Giovanni,
>>
>> A bit of feedback on the genesis of the project - I am sorry if this
>> email rambles and is off topic. I promise not to repeat as this forum is
>> for OSM.
>>
>> In Divonne-les-bains, France, our mayor and a developer from Perpignan
>> had a project to build a water bottling project to bottle 400 million
>> bottles of water in PET for export to Asia.  About 1-year ago, I got very
>> involved and with a couple of others we created a non-profit association
>> called StopEmbouteillage. Initally, the vast majority of Divonnais and
>> everyone from the municipal council supported the project.
>>
>> After months of hard work by a large group of active members (more than
>> 7000 flyers passed out), legal action from Swiss authorities just
>> across the border, and a media presence (TV, radio, press, social media) we
>> were successful in changing the opinion dramatically. The mayor had no
>> choice but to kill the project or deal with a riot among the citizens and
>> council members.
>>
>> Through the process of managing the FB page for the association, I
>> learned how critical the plastic situation on our planet really is. I won't
>> go on too long on this subject, but in addition to multiple 7th continents
>> of plastic in the Pacific which everyone talks about, the micro-plastics in
>> the Mediterranean are rivers and lakes is incredibly high. According to
>> recent studies, on average everyone of us is ingesting about 5 grams of
>> plastic per week, in our fish, meat, vegetables and water. I decided to try
>> to help make a difference with this project  ... even in a small symbolic
>> way.
>>
>> In September, when visiting my son graduating from the University of
>> Bristol, inn the UK, we noticed water fountains everywhere with a Refill
>> label and many cafés which had the same. After many discussions, we decided
>> not to partner with Refill due to their insistence on keeping all data
>> proprietary and being obliged to sell Chilly bottles. I believe that an
>> open data collaborative model is better suited for the task of building and
>> maintaining a global database of potable water bottle refill stations.
>>
>> On the 8th of January, we had the chance to be able to launch our project
>> and application at the United Nations in front of 800 students for 32
>> countries in the presence of Fabrizio Hochshild, Assistant
>> Secretary-General of the United Nations and Doreen Bogdan-Martin, Doreen
>> Bogdan-Martin, Director of the Telecommunication Development Bureau of the
>> ITU.
>>
>> Now, to answer your question 

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

[osm . sanspourriel]

Je ne crois pas qu'il faut y voir un parti pris idéologique : recycling
suppose qu'il y a recyclage et mettre reycling et waste ensemble forme
un oxymore. Et oui il y a de l'écoblanchiment pour certains à parler de
recyclage là où il n'y en a pas.

Je ne connais pas l'équivalent de répurgation en anglais. DeepL dit
repurgation.

end of life ? Mais changer une clé très utilisée... avec en plus le
problème que EOL a plusieurs significations et pas spécialement
celle-là. Alors un avertissement sur le wiki pour signaler qu'il s'agit
de la fin de vie en général, que le produit collecté soit effectivement
recyclé ou pas ?

Si ça vous sert de savoir quel système de préhension, pourquoi ne pas
grip=hook, sucsion ... mais il faut se mettre d'accord sur la partie
qu'on modélise : est-ce l'outil pour appréhender ou le côté statique.

Décrire le côté statique c'est simple (la personne le voit, ici un
anneau) ou pas (savoir comment est récupéré ce que j'aurais appelé une
benne et que tu appelles un caisson, ce n'est pas évident).

Tu nous fais une traduction jargon / noms pour béotiens francophones
ou/et anglophones (Yves a bien commencé) et une proposition de schéma de
tags "à la François" ?

Pour certains cas (les défibrillateurs par exemple) on met marque et
modèle, ça c'est peut être facile à trouver et permet de compléter les
autres attributs techniques a priori.

Jean-Yvon

Le 14/05/2020 à 11:12, Jérôme Seigneuret - jerome.seigneu...@gmail.com a
écrit :


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

[talk-cz] WeeklyOSM CZ 510

[Tom Ka]

Ahoj, je dostupné vydání 510 týdeníku WeeklyOSM:


https://weeklyosm.eu/cz/archives/13108

* Úklid board_number.
* Výměra bazénů.
* Data od úřadů.
* Pozdrav z Ukrajiny.
* Komplexní školy.
* Pošty v Rusku.
* Discord OSM.
* Rozdíly výškových dat.
* Byrokracie OSM.
* Esoterické lékárny.
* Požáry v Černobylu.
* Jak na heatmapy?
* Generátor měst.
* OSM mappeři OSN.
* Lidar a stav silnic.
* Koncovky v Německu.
* Protesty v Rusku.

Pěkné počtení ...
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

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

[Tadeusz Cantwell]

The residential tag should be used for an area not a house.

On Wed, 13 May 2020 at 14:38, Donie Kelly  wrote:

> Don’t buildings have tags? Did I see a residential tag? Is it used in all
> cases?
>
> > On 13 May 2020, at 13:24, Colm Moore  wrote:
> >
> > Hi,
> >
> > Inspired by seeing the estimate in the Microgrant application of 5.5
> million buildings on the island of Ireland, I did some number crunching.
> >
> > I downloaded the populations of Kilkenny townlands (1,500+) from the CSO
> and analysed the population against the number of buildings per civil
> parish (100+) for County Kilkenny. This is assuming Kilkenny has all or
> nearly all buildings mapped. Based on my inspections, this is largely true.
> >
> > The CSO data is somewhat distorted for the Kilkenny city area (100+
> townlands), due to the way the CSO have arranged the townlands and civil
> parishes. I could look at this in more detail, but there would be a few
> hours of effort (unless someone has a simple way of calculating number of
> buildings per area, for a large number of areas).
> >
> > I calculated the 'number of buildings per civil parish' using the
> Overpass Turbo query [building=* in "civilparishname, Kilkenny"]. Overpass
> Turbo gives a summary of the data in the bottom right corner of the screen,
> e.g.
> >
> > Loaded – nodes: 4261, ways: 867, relations: 2
> > Displayed – pois: 0, lines: 0, polygons: 866
> >
> > I took the number of polygons to mean the number of buildings (this
> might not be perfect - I don't know how those numbers add up).
> Additionally, some polygons, e.g. building=terrace represent several
> buildings, while in other cases buildings may have been crudely split or
> joined-up.
> >
> > Depending on the civil parish, we're looking at 0.32-2.29 polygons per
> capita (0.44-3.15 people per building). Rural areas ten to have more
> polygons per capita, especially due to farm outbuildings, while urban areas
> have fewer polygons per capita, due to apartments buildings and
> semi-detached buildings (e.g. two square houses joined together might have
> only six nodes).
> >
> > I also calculated 4.40-5.83 nodes per polygon. This means some civil
> parishes have predominantly rectangular polygons / buildings, whereas
> others have many L-shaped or other-shaped polygons / buildings.
> >
> > As I wasn't able to immediately get some 'number of buildings per civil
> parish' numbers (Overpass Turbo had problems returning them, possibly due
> to duplicate names and variations in name spellings), I had to calculate
> them from their component townlands, using the Overpass Turbo query
> [building=* in "townlandname, civilparishname, Kilkenny"].
> >
> > Depending on the townland, we're looking at 0.23-8.00 polygons per
> capita (0.13-4.37 people per building) and 3.91-6.45 nodes per polygon
> (i.e. some townlands have large numbers of semi-detached or terraced
> buildings, whereas others have a high number of complicated-shape polygons
> / buildings or buildings with too many mapped nodes). It is usual to see
> more extreme spreads when looking at smaller areas.
> >
> > I'm coming up with about 5.4 million (close enough!) buildings for the
> whole island, assuming the pattern is the same everywhere. However, as
> shown by analysing the smaller areas, there is variation and the 'final'
> number will vary from that. Of course, given that OSM is an ongoing
> project, there will never be a final number.
> >
> > Colm
> > VictorIE
> > ___
> > Talk-ie mailing list
> > Talk-ie@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-ie
>
> ___
> Talk-ie mailing list
> Talk-ie@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ie
>
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

Re: [Talk-GB] Rights of way mapping - making it easy for newcomers to OSM (perhaps!)

[Nick Whitelegg]

Hello Tony and Gareth,

Thanks for your thoughts.

My main thought was a specialised JOSM plugin - I did take a look at OSM's main 
GPX trace facility but it appears not to preserve tags in the uploaded trace. 
Some versions of the MapThePaths app (the first version, and the current 
version on Gitlab) allow GPX upload to OSM but the tags are removed.

So I'm thinking that my own storage (I have quite a bit of available storage) 
and a custom JOSM plugin, which, for example, creates colour-coded and 
clickable traces showing the ROW designation, surface and highway tags might be 
the way to go.

Thanks,
Nick

From: Gareth L 
Sent: 14 May 2020 09:56
To: Tony OSM 
Cc: talk-gb@openstreetmap.org 
Subject: Re: [Talk-GB] Rights of way mapping - making it easy for newcomers to 
OSM (perhaps!)

I wonder if it would be possible to use the GPS trace feature on OSM for this? 
Maybe format the name in a way to make it easier to retrieve?

Takes care of the storage of the traces.


On 14 May 2020, at 09:22, Tony OSM  wrote:



Hi Nick

I like the two stage approach - surveying then mapping. It would work well - 
some of my friends like walking but can't map to save their life, whereas I 
can't walk far but love mapping - Win Win for us all.


May I suggest that a layer be created for JOSM with all the paths and their 
details as provided for MapThePaths. Personally I find it easier to work with 
JOSM and I have learnt to create a style to highlight PROW's, but I don't know 
how to create a JOSM layer.

Separate layers would allow us to manually transfer from PROW layer to MAP 
layer thus avoiding the mechanical import rules, and would allow us to manually 
conflate where a path is already mapped but PROW data is absent.

A layer containing the surveyed GPS data so that all the sources we need are 
available would be awesome.


I may be asking for a workflow that is close to existing, if that is the case I 
am able to test and document the workflow for the UK wiki if that would be 
helpful.


Tony Shield

TonyS999


On 13/05/2020 18:11, Nick Whitelegg wrote:

Oops... sorry one or two editing errors in the last paragraph.

I meant to say:

"They [the non-expert user] select ROW type and path surface via a nice 
interface, and then a tagged GPX trace is generated, *with trksegs tagged with 
ROW designation and surface* (which was done by the first version of the app 
anyway). This is then uploaded to the MapThePaths server, and volunteer expert 
users *are alerted*. Said expert user then downloads the GPX trace and, *using 
the tags in the trksegs of the GPX* then edits in JOSM, perhaps via a JOSM 
plugin - or even directly in the MapThePaths web app. (I am possibly thinking 
of adding way creation into the MapThePaths web app anyway, time depending)."

Nick


From: Nick Whitelegg
Sent: 13 May 2020 18:08
To: talk-gb@openstreetmap.org 

Subject: Rights of way mapping - making it easy for newcomers to OSM (perhaps!)

Hi,

Just to continue with the theme of rights of way mapping, I've been noticing 
that there are still large tracts of England and Wales away from the 'honeypot' 
areas with little or now ROW mapping at all meaning there's still quite a big 
job to be done.

As you may remember I have been developing a companion app to MapThePaths. In 
the first version of this (around two years ago) I experimented with 
auto-converting GPX traces to OSM ways. However I was dissatisfied with the 
results, the ways generated were really rather nasty and I ended up having to 
prettify them significantly in JOSM afterwards, rendering the auto-creation 
facility a little pointless. Consequently later versions of the app have 
focused on merely presenting the council and OSM data overlaid (like the 
website),  with only limited editing facilities, to change the designation of a 
path.

However (and I may have mentioned this before, it's been a while) I am 
wondering about a 'two-user' approach in which a new user merely does the GPX 
survey, using an easy to use UI (a refined version of the MapThePaths app with 
the UI re-designed by someone more versed in UX than myself).

They select ROW type and path surface via a nice interface, and then a tagged 
GPX trace is generated (which was done by the first version of the app anyway). 
This is then uploaded to the MapThePaths server, and volunteer expert users. 
Said expert user then downloads the GPX trace and then edits in JOSM, perhaps 
via a JOSM plugin - or even directly in the MapThePaths web app. (I am possibly 
thinking of adding way creation into the MapThePaths web app anyway, time 
depending).

Any thoughts?

Thanks,
Nick




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

Re: [OSM-talk] Proposed mechanical edit - remove tracking parameters

[Mateusz Konieczny via talk]

May 14, 2020, 01:32 by dieterdre...@gmail.com:

>
>
> sent from a phone
>
>
>> On 13. May 2020, at 13:44, Mateusz Konieczny via talk 
>>  wrote:
>>
>> It means that it is beneficial to turn tag
>> website=>> 
>> http://paris.intersquat.org/les-lieux/le-satellite/?fbclid=de58e340d6aa79a584552a2055042d004b9b19454bc0d7a6046fc81fc90f51
>> into
>> website=>> http://paris.intersquat.org/les-lieux/le-satellite/
>>
>> This urls can be often fixed using an automated script, allowing to
>> use human time on something more productive.
>>
>
>
> I agree with removing tracking information. In the example above it seems 
> that “url” would be a better key than “website”.
>
It is possible, it is not intended as an example of good tagging.

I used this example as it had an OSM map that was correctly attributed, also on 
mobile devices.

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

[OSM-talk-fr] Piétonisation ponctuelle du Vieux-Lille

[Carto_ADAV]

Bonjour à tous,

Ce samedide 10h à 19h, le Vieux Lille sera piétonnisé et cette situation 
devrait être pérennisé.


Article de presse : https://tinyurl.com/yc32l4sq

Je m’apprête à taguer les rues piétonnisés ponctuellement de cette 
manière, je voulais juste avoir votre avis sur l'ajout des tags ci-dessous :


motor_vehicle = yes
motor_vehicle:conditional = no@(sa10:00-19:00)
description:covid19 = piétonisation du Vieux Lille, le samedi de 10h à 19h

Merci pour votre retour !

Mathias

--
Mathias Vadot
Droit au vélo - ADAV
5 rue Jules de Vicq
59800 LILLE
Tél : 03 62 27 51 86
mail : mathias.va...@droitauvelo.org



--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus
___
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]

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: [OSM-talk-fr] Point d'apport volontaire, point de collecte, point de regroupement

[Jérôme Seigneuret]

> Le Groupe Nicollin  a une
>> page wikipedia.
>> Qui sont les autres sur les marches du podium ?
>>
>
Veolia, Sita, Paprec, Pizzorno, Bronzo, Urbaser, Sepur, Onyx, Brangeon et
(leurs filiales) et autres opérateurs privés locaux
Reste comme je disais plus haut tous les EPCI qui souhaitent utiliser OSM
comme outils de diffusion et d'exploitation de données publique comme c'est
le cas sur Montpellier Méditerranée Métropole

Je prends aussi l'exemple des bornes incendies en exemple car il y a bien
une richesse d'information que tous le monde ne mettra pas. Les interco en
ont la gestion et les SDIS les exploitent. Quel intérêt pour le publique
aujourd'hui ? Aucun sauf pour un point de RDV? ;-)
___
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]

Le jeu. 14 mai 2020 à 11:38, Yves P.  a écrit :

>
> A ben @yves on peut dire que tu rebondis rapidement.
>
> Je ne suis pas fan de foot, mais je fais des efforts pour m'intégrer :D
>

> Pour le moment Nicollin donc environ une 50 aines de clients dans la
> collecte des déchets des particuliers avec autant de contraintes et de
> typicités en fonction des territoires.
>
> Le Groupe Nicollin  a une
> page wikipedia.
> Qui sont les autres sur les marches du podium ?
>
Je ne parle pas pour les autres mais je pense que tout organisme publique
dont l'intérêt et de présenter son parc et qui fait de OpenData a un
intérêt. Métropole de Montpellier, Toulouse, Nice, Paris ?!

>
>
> Bref si l'on si l'on veut exploiter correctement les données sur OSM
>>
>> qui ?
>>
> Je pense pas être le seul à chercher mes données sur OSM. C'est le cas de
> plein de métropole et la complétude des données fait que l'on peut
> exploiter ou non le système correctement pour le maintenir et pas avoir 3
> bases (client, opérateur, et prestataire GPS) pour fournir ces informations
>
>
> prestataire GPS : c'est quoi cette bête là ?
>
Aujourd'hui pour cité les principaux Simpliciti, Axians-Sysoco, Sulo, pro
tracking, Sinaps, Novacom sont des sociétés proposant de la géolocalisation
avec des informations enrichies pour l'exploitation du métiers de la
collecte et du nettoiement

>
> En Suisse et probablement ailleurs, il existe des conteneurs fermés. Il
> faut un badge ou un code pour y jeter son sac.
>
ça sert à calculer la taxe.
>
  Même principe en France dans certains contrats incluant la
redevance incitative

>
> Il existe aussi des sacs taxés. ils s'achètent dans les supérettes.
> Si on jette ses déchets avec un sac normal (non taxé) on peut-être dénoncé
> ;)
>
C'est bien la suisse ça ducoup ils viennent en France vider leurs ordures!

>
> En France, il y a des pesées lors de l'enlèvement du bac (le poids est
> associé au "tag" RFID collé sur le bac).
>
Oui est non. Il y a très peu de contrat basé sur le poids à la levé. ça
marche pas bien  il faut un temps plus important à la levé il faut taré les
pesons plus régulièrement. En clair ça a le mérite d'exister car il y a eu
une demande. çà augmente le nombre de dépôt sauvage et le vrac (sac mis
hors du bac

>
> Le revers de la médaille est que les "citoyens" jettent leurs déchets dans
> le bac du voisin, dans la nature et/ou de l'autre côté de la frontière.
>
Ben voilà
pour info :
https://www.ademe.fr/sites/default/files/assets/documents/tarification-incitative-conseils-et-retours-experience-8057.pdf

>
> Est-ce qu'il y a un besoin/intérêt à saisir ça dans OSM ?
> De même que la référence du conteneur (visible sur le bac) ?
>
Mettre les bacs RFID dans OSM non car ça serait vraiment comme mettre les
compteurs d'eau dans OSM (qui plus est on est sur le l'information
individuelle donc RGPD ...)


>
> __
> Yves
>
>
> ___
> 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] Proposed mechanical edit - remove tracking parameters

[Steve Doerr]

On 13/05/2020 17:21, Mateusz Konieczny via talk wrote:

May 13, 2020, 17:31 by doerr.step...@gmail.com:

 Will you limit individual changesets to fairly small geographical
units?

max changeset size in degrees (latitude): 0.3
max changeset size in degrees (longitude): 0.3


That's about twice the size of the local area I monitor, so that seems 
satisfactory.


Thanks,
Steve


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Jérôme Seigneuret]

>
>
>
> si un pro du domaine a envie de faire une proposition pour des tags
> renseignant le type exact de conteneur, leur crochet et leur mécanisme
> d'ouverture, j'ai rien contre, mais je crois que là on dépasse
> la capacité et surtout l'envie de la majorité d'entre nous.
>
> Un pro a déjà l'information dans son SIG ?
>
Oui comme tous les EPCI et syndicat ayant la gestion de ces informations!!!
c'est d'ailleurs à cela que l'on répond aux appels d'offre pour
dimensionner les moyens humains et matériels pour faire la collecte des
déchets

>
> Quel serait l'intérêt pour un pro, une collectivité, les citoyens que les
> contributeurs OSM référencent ça ?
>
Tous simplement la gestion du parc d'une part et la diffusion des
informations au usagers sans faire une couche dans une carte Google. Faire
un contrôle terrain en cas de changement d'opérateur de collecte lors des
renouvellement. Faire des cartes d'isochrones pour définir l'accessibilité
des colonnes aux usagers de manière à les répartir uniformément sur le
territoire. Faire une symbologie sur une Umap pour observer les
volumétries, comparer ça avec les fréquences de levées fourni par les
opérateurs de collecte etc. les usages sont sans fin comme pour chaque
métiers dont l'on fait une intégration dans OSM. Bref chacun voit midi à sa
porte et arrivera à en définir les besoins comme pour les PMR et
l’accessibilité aux colonnes.
Faire du PAV c'est aussi un investissement dans le temps.Evaluer son
implantation dans des conditions où il ne risque pas de tomber en panne
tous les mois faute de pluies c'est important (surtout pour des colonnes
OMR enterré) Pour reprendre tes arguments vers le PAV @Yves. Ma réaction
est plutôt simple : la volonté c'est bien mais la faisabilité c'est autre
chose (que ce soit des contraintes économiques car le parc de bacs est en
place et neuf ou parce que les réseaux enterrés ou les éléments naturelles
empêchent simple l'implantation de tel éléments) d'où la collecte en sac
qui existe encore en centre ville (Montpellier, Nîmes, Lunel et autres),
quartier huppé dans la ville de Le Chenay

__
> Yves
>
> Quelques photos dans Wikimedia Commons :
>
>- France :
>   - Category:Waste containers in Fontenay-sous-Bois
>   
> 
>   - Category:Waste containers in Yonne
>   
>- Suisse :
>   - Category:Sorted waste containers in Switzerland
>   
> 
>- Belgique :
>   - Category:Sorted waste containers in Belgium
>   
> 
>- Canada :
>   - Category:Sorted waste containers in Canada
>   
> 
>   - Category:Dumpsters in Canada
>   
>
> Sympa. Il y a de quoi compléter
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [talk-cz] Role pro relace (nejen) naucnych stezek

[majkaz]

Osobně to beru taky tak, dokonce i role=guidepost je dáno podle mě jen zvykem. 
Používá se podle mě výhradně u nás, všude jinde je to bez role, pokud je vůbec 
zmapováno. Už několikrát k tomu byla debata nebo dotazy odjinud.
 
Ještě nedávno na to upozorňovaly i automatické kontroly u JOSM, že se jedná o 
neznámou roli. Jak je to momentálně, to netuším - tuhle kontrolu jsem vypínala 
mezi prvními. Jiná věc je, že samozřejmě nelze brát program pro editaci za 
etalon pravdy - i když k tomu postupně situace spěje. To, co ukazuje program se 
mnohdy bere za to jediné správné řešení, přestože jde zpravidla jen o postoj 
autora k mapování. U JOSM je to třeba hodně ovlivněné německými zvyklostmi - a 
jak víme, Němci si jedou po svém a nic moc se na ostatní neohlíží.
 
Majka
__

Od: "Martin Ždila" 
Komu: "OpenStreetMap Czech Republic" 
Datum: 14.05.2020 10:18
Předmět: Re: [talk-cz] Role pro relace (nejen) naucnych stezek


osobne nevidim dvovod k tomu davat role. ak je tabula v relacii naucneho 
chodnika, tak to uplne staci na vyjadrenie, ze tabula patri k nauc. 
chodniku.rola sa v relacii pouziva, ak dany prvok moze v inej relacii znamenat 
nieco ine a preto nan neviem dat priamo tag, kedze by bol konflikt. alebo ak by 
tag na prvku nemal bez relacie zmysel.

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

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

[Yves P.]

> A ben @yves on peut dire que tu rebondis rapidement.
Je ne suis pas fan de foot, mais je fais des efforts pour m'intégrer :D

> Pour le moment Nicollin donc environ une 50 aines de clients dans la collecte 
> des déchets des particuliers avec autant de contraintes et de typicités en 
> fonction des territoires.
Le Groupe Nicollin  a une page 
wikipedia.
Qui sont les autres sur les marches du podium ?


>> Bref si l'on si l'on veut exploiter correctement les données sur OSM
> qui ?
> Je pense pas être le seul à chercher mes données sur OSM. C'est le cas de 
> plein de métropole et la complétude des données fait que l'on peut exploiter 
> ou non le système correctement pour le maintenir et pas avoir 3 bases 
> (client, opérateur, et prestataire GPS) pour fournir ces informations

prestataire GPS : c'est quoi cette bête là ?

En Suisse et probablement ailleurs, il existe des conteneurs fermés. Il faut un 
badge ou un code pour y jeter son sac.
ça sert à calculer la taxe.

Il existe aussi des sacs taxés. ils s'achètent dans les supérettes.
Si on jette ses déchets avec un sac normal (non taxé) on peut-être dénoncé ;)

En France, il y a des pesées lors de l'enlèvement du bac (le poids est associé 
au "tag" RFID collé sur le bac).

Le revers de la médaille est que les "citoyens" jettent leurs déchets dans le 
bac du voisin, dans la nature et/ou de l'autre côté de la frontière.

Est-ce qu'il y a un besoin/intérêt à saisir ça dans OSM ?
De même que la référence du conteneur (visible sur le bac) ?

__
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

[Jérôme Seigneuret]

A ben @yves on peut dire que tu rebondis rapidement.

OM ou OMR ordures ménagères (résiduelles) ;-)



Le jeu. 14 mai 2020 à 10:23, Yves P.  a écrit :

>
> amenity=recycling + recycling_type=container + location=underground
>>
> C'est donc bien ce que je dis dans l'exemple que tu cites en exemple ce
> n'est pas une colonnes en enterrée mais des bacs enterrés à
> levé hydraulique qui se lève avec une BOM classique
> les types c'est : bacs roulant, caisson, colonnes.
>
>
> Bim, bam boum :D
>
> Difficile de suivre avec ce jargon :
>
>- BOM
>
> 
>  :
>bennes à ordures ménagères
>- OMR
>
> 
>  :
>ordures ménagères résiduelles
>- BID
> 
> :
>Borne d’Introduction des Déchets
>- DIB
>
> 
>  : Déchet
>industriel banal
>- OM: Olympique de Marseille
>- DMA : déchets ménagers et assimilés
>- DV : déchets verts
>- DID : déchets industriels dangereux
>- DASRI : Déchets d'activités de soins à risques infectieux
>
>
> Ce sont des dénominations données à des typologies plus précises qui sont
> en lien avec un mode de levage également
> C'est ces données que l'on exploite dans nos référentiels.
>
> Tu bosses pour une (ou plusieurs) métropoles ?
>

Pour le moment Nicollin donc environ une 50 aines de clients dans la
collecte des déchets des particuliers avec autant de contraintes et de
typicités en fonction des territoires.


>
> Peut-on considérer dans recycling tous les flux? La réponse est oui!
> d'ailleur l’incinération des déchets rentre dans le process de recyclage
> mais pas dans le recyclage circulaire comme certains peuvent l'entendre.
>
> ouf :)
>
Ben oui même si certains penses au greenwashing.

>
> Bref si l'on si l'on veut exploiter correctement les données sur OSM
>
> qui ?
>
Je pense pas être le seul à chercher mes données sur OSM. C'est le cas de
plein de métropole et la complétude des données fait que l'on peut
exploiter ou non le système correctement pour le maintenir et pas avoir 3
bases (client, opérateur, et prestataire GPS) pour fournir ces informations

>
> il va falloir arrêter de vouloir faire ça avec des clés différentes pour
> des gisements qui sont normalement traités et collectés avec des contenants
> et du matériel qui lui est similaire.
>
> +1
>
> Sinon c'est que la clé principale elle n'est plus adaptées à nos besoins.
>
> +1
>
> Aujourd'hui si l'on accepte pas l'OM dans dans recycling_type=container je
> vois pas à quoi sert cette clé
>
> +1
> (d'autant plus que le recycling:waste=yes existe et que la page
> francophone du wiki
>  
> est
> plus "tolérante" que la page anglophone
> .
>
C'est ok pour moi

>
> . vaudra mieux tous mettre en waste_disposal
>
> ça serait un retour en arrière ?
>
Je repondrais simplement qu'en model objet si l'on veut définir un objet
dans lequel on mes des déchets qu'ils soient recyclable ou non c'est un
container qu'il contienne du recyclable c'est secondaire. On est sur un
point de dépôt d'un flux quel qu'il soit (recyclable ou non).

>
> Des villes comme Avignon
> 
>  prônent
> la disparition des conteneurs à roulette au profit des conteneurs enfouis
> (cf. arguments
> ). De plus
> ils sont accessibles
> 
>  aux
> personnes handicapées et limitent les risques d'incendie
> .
>

C'est une politique de gestion et de prix. Le cout de la mise à disposition
des bacs c'est pas négligeable. En parallèle, certains invite à l'incitatif
avec un calcul de la taxe basé à la lévé comme le Pays de Lunel, CC Oléron
et d'autres de nos clients dont le modèle est de mettre des bacs avec des
moyens d'identification de ces bacs individuels en RFID (courte ou longue
portée en terme de fréquence)

>
> et dire que le type de contenant est un bac une colonne ou un caison avec
> sa volumétrie en m3 ou en litres comme c'est déjà défini sur nos sites de
> commandes de produits et sur les catalogues de nos fournisseurs.
>
> La plupart des contributeurs OSM ne sont pas des professionnels du
> traitement des déchets ;)
>
C'est pareil pour l'electricité et l'eau... mais je suis d'accord qu'il
faut pas empécher de décrire les choses ou tous du moins on peut aussi
améliorer le wiki pour apporter 

Re: [Talk-GB] Rights of way mapping - making it easy for newcomers to OSM (perhaps!)

[Gareth L]

I wonder if it would be possible to use the GPS trace feature on OSM for this? 
Maybe format the name in a way to make it easier to retrieve?

Takes care of the storage of the traces.


On 14 May 2020, at 09:22, Tony OSM  wrote:



Hi Nick

I like the two stage approach - surveying then mapping. It would work well - 
some of my friends like walking but can't map to save their life, whereas I 
can't walk far but love mapping - Win Win for us all.


May I suggest that a layer be created for JOSM with all the paths and their 
details as provided for MapThePaths. Personally I find it easier to work with 
JOSM and I have learnt to create a style to highlight PROW's, but I don't know 
how to create a JOSM layer.

Separate layers would allow us to manually transfer from PROW layer to MAP 
layer thus avoiding the mechanical import rules, and would allow us to manually 
conflate where a path is already mapped but PROW data is absent.

A layer containing the surveyed GPS data so that all the sources we need are 
available would be awesome.


I may be asking for a workflow that is close to existing, if that is the case I 
am able to test and document the workflow for the UK wiki if that would be 
helpful.


Tony Shield

TonyS999


On 13/05/2020 18:11, Nick Whitelegg wrote:

Oops... sorry one or two editing errors in the last paragraph.

I meant to say:

"They [the non-expert user] select ROW type and path surface via a nice 
interface, and then a tagged GPX trace is generated, *with trksegs tagged with 
ROW designation and surface* (which was done by the first version of the app 
anyway). This is then uploaded to the MapThePaths server, and volunteer expert 
users *are alerted*. Said expert user then downloads the GPX trace and, *using 
the tags in the trksegs of the GPX* then edits in JOSM, perhaps via a JOSM 
plugin - or even directly in the MapThePaths web app. (I am possibly thinking 
of adding way creation into the MapThePaths web app anyway, time depending)."

Nick


From: Nick Whitelegg
Sent: 13 May 2020 18:08
To: talk-gb@openstreetmap.org 

Subject: Rights of way mapping - making it easy for newcomers to OSM (perhaps!)

Hi,

Just to continue with the theme of rights of way mapping, I've been noticing 
that there are still large tracts of England and Wales away from the 'honeypot' 
areas with little or now ROW mapping at all meaning there's still quite a big 
job to be done.

As you may remember I have been developing a companion app to MapThePaths. In 
the first version of this (around two years ago) I experimented with 
auto-converting GPX traces to OSM ways. However I was dissatisfied with the 
results, the ways generated were really rather nasty and I ended up having to 
prettify them significantly in JOSM afterwards, rendering the auto-creation 
facility a little pointless. Consequently later versions of the app have 
focused on merely presenting the council and OSM data overlaid (like the 
website),  with only limited editing facilities, to change the designation of a 
path.

However (and I may have mentioned this before, it's been a while) I am 
wondering about a 'two-user' approach in which a new user merely does the GPX 
survey, using an easy to use UI (a refined version of the MapThePaths app with 
the UI re-designed by someone more versed in UX than myself).

They select ROW type and path surface via a nice interface, and then a tagged 
GPX trace is generated (which was done by the first version of the app anyway). 
This is then uploaded to the MapThePaths server, and volunteer expert users. 
Said expert user then downloads the GPX trace and then edits in JOSM, perhaps 
via a JOSM plugin - or even directly in the MapThePaths web app. (I am possibly 
thinking of adding way creation into the MapThePaths web app anyway, time 
depending).

Any thoughts?

Thanks,
Nick




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


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

Re: [Talk-it] Village / Town

[Fra00]

Io in realtà stavo chiedendo delucidazioni sul town di San Martino e
Campomarino, perché le altre tre in realtà sono cittadine a tutti gli
effetti.



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

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

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

[Yves P.]

> . amenity=waste_basket : poubelle de rue faite pour jeter ce
> que tu tenais en main genre un emballage d'une barre de chocolat.
> ce n'est pas fait (et souvent même interdit) de tenter d'y
> mettre son sac poubelle ménager. c'est à l'échelle d'un piéton.
ok

> - amenity=waste_disposal : tu y met ton sac poubelle et ceci
> à l'échelle d'un bâtiment ou d'une usine, c'est souvent privé
après mon "inventaire" (non exhaustif) dans mon message précédent et ma 
compréhension du wiki après plusieurs relectures, je comprends les choses comme 
cela :

amenity=waste_disposal
Gros "conteneur" sur roulettes pour tous les déchets (il n'y a pas plusieurs 
"bacs" de couleurs différentes côte à côte).

amenity=recycling + recycling_type=container
Gros "conteneurs" côte à côtes de couleurs différentes (bacs sur roulettes, 
colonnes aériennes, semi-enfouies, enfouies) 

> si un pro du domaine a envie de faire une proposition pour des tags
> renseignant le type exact de conteneur, leur crochet et leur mécanisme
> d'ouverture, j'ai rien contre, mais je crois que là on dépasse
> la capacité et surtout l'envie de la majorité d'entre nous.
Un pro a déjà l'information dans son SIG ?

Quel serait l'intérêt pour un pro, une collectivité, les citoyens que les 
contributeurs OSM référencent ça ?
__
Yves

Quelques photos dans Wikimedia Commons :
France :
Category:Waste containers in Fontenay-sous-Bois 

Category:Waste containers in Yonne 

Suisse :
Category:Sorted waste containers in Switzerland 

Belgique :
Category:Sorted waste containers in Belgium 

Canada :
Category:Sorted waste containers in Canada 

Category:Dumpsters in Canada 

…___
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.]

> amenity=recycling + recycling_type=container + location=underground
> C'est donc bien ce que je dis dans l'exemple que tu cites en exemple ce n'est 
> pas une colonnes en enterrée mais des bacs enterrés à levé hydraulique qui se 
> lève avec une BOM classique
> les types c'est : bacs roulant, caisson, colonnes.

Bim, bam boum :D

Difficile de suivre avec ce jargon :
BOM 

 : bennes à ordures ménagères
OMR 

 : ordures ménagères résiduelles
BID  
: Borne d’Introduction des Déchets
DIB 

 : Déchet industriel banal
OM: Olympique de Marseille
DMA : déchets ménagers et assimilés
DV : déchets verts
DID : déchets industriels dangereux
DASRI : Déchets d'activités de soins à risques infectieux

> Ce sont des dénominations données à des typologies plus précises qui sont en 
> lien avec un mode de levage également
> C'est ces données que l'on exploite dans nos référentiels.
Tu bosses pour une (ou plusieurs) métropoles ?

> Peut-on considérer dans recycling tous les flux? La réponse est oui! 
> d'ailleur l'insinération des déchets rentre dans le process de recyclage mais 
> pas dans le recyclage circulaire comme certains peuvent l'entendre.
ouf :)

> Bref si l'on si l'on veut exploiter correctement les données sur OSM
qui ?

> il va falloir arrêter de vouloir faire ça avec des clés différentes pour des 
> gisements qui sont normalement traités et collectés avec des contenants et du 
> matériel qui lui est similaire.
+1

> Sinon c'est que la clé principale elle n'est plus adaptées à nos besoins.
+1

> Aujourd'hui si l'on accepte pas l'OM dans dans recycling_type=container je 
> vois pas à quoi sert cette clé
+1
(d'autant plus que le recycling:waste=yes existe et que la page francophone du 
wiki 
 
est plus "tolérante" que la page anglophone 
.

> . vaudra mieux tous mettre en waste_disposal 
ça serait un retour en arrière ?

Des villes comme Avignon 

 prônent la disparition des conteneurs à roulette au profit des conteneurs 
enfouis (cf. arguments 
). De plus ils 
sont accessibles 

 aux personnes handicapées et limitent les risques d'incendie 
.

> et dire que le type de contenant est un bac une colonne ou un caison avec sa 
> volumétrie en m3 ou en litres comme c'est déjà défini sur nos sites de 
> commandes de produits et sur les catalogues de nos fournisseurs.
La plupart des contributeurs OSM ne sont pas des professionnels du traitement 
des déchets ;)

> les bacs se lèves avec des chaises 
> les colonnes avec un crochet par levé verticale
> les caisson avec un cochet à traction horizontale
> le mode de collecte est différents mais le contenu peut être similaire.

J'ai essayé d'e trouver des exemples de ce qui existe.
Je m'y perd un peu entre les termes français, canadiens.
Si je comprends bien, une colonne peut-être en surface/aérienne, semi 
enterrées/enfouies ou enterrées/enfouies.

colonne (appelé contenant de surface 

 au Canada) :
plastique : Citybulle 
,
 Hubl’O 
…  
3 ㎥, 4 ㎥
métallique (anti feu !!) : C600 
 2 
㎥ à 5 ㎥
bois : PolyTri 
 2 ㎥ 
à 7 ㎥

caisson :
standard 

 6 x 2.3 m - 8 à 35 ㎥
bac Ecobac 

 5 à 10 ㎥ (c'est une colonne ?)

conteneur semi enfoui (avec toujours un sac souple de levage ?) :
Totem  1.3 
㎥, 3 ㎥, 5 ㎥   - Canada
Molok - France, Finlande, Canada
MolokClassic  0.8 ㎥, 1.3 
㎥, 2 ㎥, 3 ㎥, 5 ㎥
MolokDomino  2 ㎥, 3 ㎥, 5 ㎥
Urbin 

Re: [Talk-GB] Rights of way mapping - making it easy for newcomers to OSM (perhaps!)

[Tony OSM]

Hi Nick

I like the two stage approach - surveying then mapping. It would work 
well - some of my friends like walking but can't map to save their life, 
whereas I can't walk far but love mapping - Win Win for us all.



May I suggest that a layer be created for JOSM with all the paths and 
their details as provided for MapThePaths. Personally I find it easier 
to work with JOSM and I have learnt to create a style to highlight 
PROW's, but I don't know how to create a JOSM layer.


Separate layers would allow us to manually transfer from PROW layer to 
MAP layer thus avoiding the mechanical import rules, and would allow us 
to manually conflate where a path is already mapped but PROW data is absent.


A layer containing the surveyed GPS data so that all the sources we need 
are available would be awesome.



I may be asking for a workflow that is close to existing, if that is the 
case I am able to test and document the workflow for the UK wiki if that 
would be helpful.



Tony Shield

TonyS999


On 13/05/2020 18:11, Nick Whitelegg wrote:


Oops... sorry one or two editing errors in the last paragraph.

I meant to say:

"They [the non-expert user] select ROW type and path surface via a 
nice interface, and then a tagged GPX trace is generated, *with 
trksegs tagged with ROW designation and surface* (which was done by 
the first version of the app anyway). This is then uploaded to the 
MapThePaths server, and volunteer expert users *are alerted*. Said 
expert user then downloads the GPX trace and, *using the tags in the 
trksegs of the GPX* then edits in JOSM, perhaps via a JOSM plugin - or 
even directly in the MapThePaths web app. (I am possibly thinking of 
adding way creation into the MapThePaths web app anyway, time depending)."


Nick


*From:* Nick Whitelegg
*Sent:* 13 May 2020 18:08
*To:* talk-gb@openstreetmap.org 
*Subject:* Rights of way mapping - making it easy for newcomers to OSM 
(perhaps!)

Hi,

Just to continue with the theme of rights of way mapping, I've been 
noticing that there are still large tracts of England and Wales away 
from the 'honeypot' areas with little or now ROW mapping at all 
meaning there's still quite a big job to be done.


As you may remember I have been developing a companion app to 
MapThePaths. In the first version of this (around two years ago) I 
experimented with auto-converting GPX traces to OSM ways. However I 
was dissatisfied with the results, the ways generated were really 
rather nasty and I ended up having to prettify them significantly in 
JOSM afterwards, rendering the auto-creation facility a little 
pointless. Consequently later versions of the app have focused on 
merely presenting the council and OSM data overlaid (like the 
website),  with only limited editing facilities, to change the 
designation of a path.


However (and I may have mentioned this before, it's been a while) I am 
wondering about a 'two-user' approach in which a new user merely does 
the GPX survey, using an easy to use UI (a refined version of the 
MapThePaths app with the UI re-designed by someone more versed in UX 
than myself).


They select ROW type and path surface via a nice interface, and then a 
tagged GPX trace is generated (which was done by the first version of 
the app anyway). This is then uploaded to the MapThePaths server, and 
volunteer expert users. Said expert user then downloads the GPX trace 
and then edits in JOSM, perhaps via a JOSM plugin - or even directly 
in the MapThePaths web app. (I am possibly thinking of adding way 
creation into the MapThePaths web app anyway, time depending).


Any thoughts?

Thanks,
Nick


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

Re: [talk-cz] Role pro relace (nejen) naucnych stezek

[Martin Ždila]

osobne nevidim dvovod k tomu davat role. ak je tabula v relacii naucneho
chodnika, tak to uplne staci na vyjadrenie, ze tabula patri k nauc.
chodniku.

rola sa v relacii pouziva, ak dany prvok moze v inej relacii znamenat nieco
ine a preto nan neviem dat priamo tag, kedze by bol konflikt. alebo ak by
tag na prvku nemal bez relacie zmysel.

On Thu, May 14, 2020 at 10:12 AM Miroslav Suchý  wrote:

> Dne 14. 05. 20 v 8:36 Tom Ka napsal(a):
> > https://wiki.openstreetmap.org/wiki/Cs:Tag:information%3Dboard
> >
> > Rad bych to bud nekde nasel, nebo doplnil at se to da standardizovat a
> > pri kontrolach rovnou rozumne opravovat.
> >
> > Ma nekdo nejake info/zkusenosti apod?
>
> Já dávám
>
> role=board
>
> a do te board dávám
>
> ref=1
>
> kde to číslo je pořadí zastávky.
>
> Ale zdokumentované to asi nikde není.
>
> --
>  ,,,
> (o o)
>=oOO==(_)==OOo===
>   )  mailto:miros...@suchy.cz  tel:+420-603-775737
> (   One picture is worth 128K words.
>   )Oooo.
>   .oooO   (   )
>   (   )) /
>\ ((_/
> \_)
>
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>


-- 
Ing. Martin Ždila 
OZ Freemap Slovakia
tel:+421-908-363-848
mailto:martin.zd...@freemap.sk
http://www.freemap.sk/
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] Role pro relace (nejen) naucnych stezek

[<0174]

 Ahoj,
já jim dávám roli board. Je to asi tak trochu zbytečné (podobně jako u role
guidepost), protože to jde odvodit z dalších dat (a nenapadá mě případ, kdy
by informační tabule mohla mít jinou roli), ale ničemu to snad nevadí a je
to přehlednější ve výpisu relace.
Dokumentaci jsem k tomu nenašel, jen 1419 použití na taginfo (a 36 pro
information_board).
https://taginfo.openstreetmap.org/relations/route#roles

<0174

čt 14. 5. 2020 v 8:37 odesílatel Tom Ka  napsal:

> Ahoj,
>
> pri opravach z Fody a OsmHiCheck narazim posledni dobou hodne na naucne
> stezky. Co se tyka ceduli na NS, tak nektere nejsou ani v relaci stezky,
> nektere jsou ale bez role, nektere maji roli stop, jine roli stop:REF a
> jine roli board. Kdyz jsem hledal, kde by to mohlo byt na wiki popsane, nic
> jsem nenasel, jedina zminka o roli u rozcestniku je zde:
>
>
> https://wiki.openstreetmap.org/wiki/Cs:%C4%8Cesko/Edita%C4%8Dn%C3%AD_standardy_a_konvence#Za.C4.8Dlen.C4.9Bn.C3.AD_rozcestn.C3.ADk.C5.AF_a_sm.C4.9Brn.C3.ADk.C5.AF
>
> Nicmene na strankach, kde bych cekal info nebo odkaz na info nic neni:
>
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/hiking_trail_relation_roles
> (role pouze o smeru apod. trasy)
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Recreational_route_relation_roles
> (typ useku trasy)
>
> https://wiki.openstreetmap.org/wiki/Cs:Tag:route%3Dhiking
> https://wiki.openstreetmap.org/wiki/Cs:Tag:information%3Dguidepost
> https://wiki.openstreetmap.org/wiki/Cs:Tag:information%3Dboard
>
> Rad bych to bud nekde nasel, nebo doplnil at se to da standardizovat a pri
> kontrolach rovnou rozumne opravovat.
>
> Ma nekdo nejake info/zkusenosti apod?
>
> Diky moc, tom.k
> ___
> 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-cz] Role pro relace (nejen) naucnych stezek

[Miroslav Suchý]

Dne 14. 05. 20 v 8:36 Tom Ka napsal(a):

https://wiki.openstreetmap.org/wiki/Cs:Tag:information%3Dboard

Rad bych to bud nekde nasel, nebo doplnil at se to da standardizovat a 
pri kontrolach rovnou rozumne opravovat.


Ma nekdo nejake info/zkusenosti apod?


Já dávám

role=board

a do te board dávám

ref=1

kde to číslo je pořadí zastávky.

Ale zdokumentované to asi nikde není.

--
,,,
   (o o)
  =oOO==(_)==OOo===
 )  mailto:miros...@suchy.cz  tel:+420-603-775737
(   One picture is worth 128K words.
 )Oooo.
 .oooO   (   )
 (   )) /
  \ ((_/
   \_)


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

Re: [talk-cz] Role pro relace (nejen) naucnych stezek

[Martin Ždila]

On Thu, May 14, 2020 at 10:09 AM Tom Ka  wrote:

> A mate to nekde zdokumentovane?
>

je to tak logicke, ze to (asi) ani nie je zdokumentovane ;-)

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

Re: [talk-cz] Role pro relace (nejen) naucnych stezek

[Tom Ka]

A mate to nekde zdokumentovane?

Diky tom.k

čt 14. 5. 2020 v 9:15 odesílatel Martin Ždila 
napsal:

> On Thu, May 14, 2020 at 8:38 AM Tom Ka  wrote:
>
>>
>> Ma nekdo nejake info/zkusenosti apod?
>>
>
> ja na SK ich davam do relacie bez role
>
>
> --
> Ing. Martin Ždila 
> OZ Freemap Slovakia
> tel:+421-908-363-848
> mailto:martin.zd...@freemap.sk
> http://www.freemap.sk/
> ___
> 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: [OSM-talk-fr] Point d'apport volontaire, point de collecte, point de regroupement

[Marc M.]

Bonjour,

Le 14.05.20 à 00:40, Jérôme Seigneuret a écrit :
> On est sur un problème de connaissance et d'identification 
> terrain faute de détails ou de connaissance métier.

heu quand même, faut pas exagérer ! tout le monde sait probablement
faire la différence entre l'endroit où il met ses ordures (but de la
filière : faire disparaître cela par incinération et/ou enfouissement)
et l'endroit où il met des matières à recycler (but de la filière :
récupérer de la matière).
le fait qu'un mauvais tri entraîne un refus de recyclage ne vient
rien faire dans le but de l'objet renseigné dans osm.
c'est du greenwhasing de dire "recycler par incinération".
voilà pourquoi à mon sens, il est pertinent d'avoir un tag différent.

quand à la question du contenant, osm pour l'instant
ne fait à mon avis qu'une différence sommaire et non pas
en fonction du mot technique, de sa forme ou composition,
ou le type de crocher pour soulever ou ouvrir.

. amenity=waste_basket : poubelle de rue faite pour jeter ce
que tu tenais en main genre un emballage d'une barre de chocolat.
ce n'est pas fait (et souvent même interdit) de tenter d'y
mettre son sac poubelle ménager. c'est à l'échelle d'un piéton.
- amenity=waste_disposal : tu y met ton sac poubelle et ceci
à l'échelle d'un bâtiment ou d'une usine, c'est souvent privé
même si en zone rurale, on trouve parfois des compacteuses
publiques ayant cette taille, destinée à remplacer la tournée
du camion poubelle (et l'avantage c'est qu'on réalise mieux
le volume de déchet qu'on produit)

si un pro du domaine a envie de faire une proposition pour des tags
renseignant le type exact de conteneur, leur crochet et leur mécanisme
d'ouverture, j'ai rien contre, mais je crois que là on dépasse
la capacité et surtout l'envie de la majorité d'entre nous.

Cordialement,
Marc

___
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

[Frantz]

Bonjour,13 mai 2020 17:35 "Georges Dutreix via Talk-fr" 
 a écrit:> Le 13/05/2020 à 13:36, Vincent Bergeot a 
écrit :
> 
>>> On est donc à mi-chemin entre le container simple (amenity=recycling + 
>>> recycling_type=container) et
>>> la déchetterie (amenity=recycling + recycling_type=centre). Je vois sur 
>>> Taginfo
>>> "recycling_type=station" (13 usages dans le monde), ça me semblerait bien 
>>> décrire cette situation ?
>> 
>> couci-couça car cela parle "recycling", ce qui dans le cas des ordures 
>> ménagères ne fonctionnent
>> pas !
> Une déchetterie (amenity=recycling + recycling_type=centre) accepte aussi 
> bien du recyclable, de
> l'incinérable que des gravas à enterrer. Donc si c'est bon pour une 
> déchetterie, pourquoi le
> refuser pour un point de collecte ?
> 
> Le terme recycling devrait sans doute être remplacé par waste, que ce soit 
> recyclable ou non, mais
> là, ce serait une autre histoire ;-)

D'accord avec ces 2 points, les lieux de collecte ne sont pas des lieux de 
recyclage et donc devraient être en waste_disposal, et le contournement actuel 
le plus simple est de tout faire passer en recycling.

Avec les recycling_type=* et les capacity=*, on devrait couvrir les besoins ? 
(en complétant le wiki pour aider les non spécialistes à distinguer !)

-- 
Frantz

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

Re: [talk-cz] Role pro relace (nejen) naucnych stezek

[Martin Ždila]

On Thu, May 14, 2020 at 8:38 AM Tom Ka  wrote:

>
> Ma nekdo nejake info/zkusenosti apod?
>

ja na SK ich davam do relacie bez role


-- 
Ing. Martin Ždila 
OZ Freemap Slovakia
tel:+421-908-363-848
mailto:martin.zd...@freemap.sk
http://www.freemap.sk/
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

[talk-cz] Role pro relace (nejen) naucnych stezek

[Tom Ka]

Ahoj,

pri opravach z Fody a OsmHiCheck narazim posledni dobou hodne na naucne
stezky. Co se tyka ceduli na NS, tak nektere nejsou ani v relaci stezky,
nektere jsou ale bez role, nektere maji roli stop, jine roli stop:REF a
jine roli board. Kdyz jsem hledal, kde by to mohlo byt na wiki popsane, nic
jsem nenasel, jedina zminka o roli u rozcestniku je zde:

https://wiki.openstreetmap.org/wiki/Cs:%C4%8Cesko/Edita%C4%8Dn%C3%AD_standardy_a_konvence#Za.C4.8Dlen.C4.9Bn.C3.AD_rozcestn.C3.ADk.C5.AF_a_sm.C4.9Brn.C3.ADk.C5.AF

Nicmene na strankach, kde bych cekal info nebo odkaz na info nic neni:

https://wiki.openstreetmap.org/wiki/Proposed_features/hiking_trail_relation_roles
(role pouze o smeru apod. trasy)
https://wiki.openstreetmap.org/wiki/Proposed_features/Recreational_route_relation_roles
(typ useku trasy)

https://wiki.openstreetmap.org/wiki/Cs:Tag:route%3Dhiking
https://wiki.openstreetmap.org/wiki/Cs:Tag:information%3Dguidepost
https://wiki.openstreetmap.org/wiki/Cs:Tag:information%3Dboard

Rad bych to bud nekde nasel, nebo doplnil at se to da standardizovat a pri
kontrolach rovnou rozumne opravovat.

Ma nekdo nejake info/zkusenosti apod?

Diky moc, tom.k
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz