[talk-cz] WeeklyOSM CZ 518

[Tom Ka]

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

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

* Missing Maps v Praze.
* Fotky na freemap.sk.
* Mapy.cz a SK.
* Editace velkých oblastí.
* Mapování naživo.
* Cíl týdne v DE.
* Slušné chování.
* Mapillary a Facebook.
* Virtuální SotM se blíží.
* Historie i cíle HOT.
* Nelegální továrny.
* Aktualizace QGIS.
* OSM pro Mozillu.
* Etika v geo.
* Mapování mořského dna.
* Mapy pro samořiditelná auta.

Pěkné počtení ...

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

[Talk-GB] Virtual meeting: New open data and towards more UK addresses

[Nick]

Hi

I have just joined this list so apologies. I am really interested in the 
issue of UPRNs (Unique Property Reference Number) having worked for a 
local authority but also aware of the risks of not sharing quality data. 
So if possible I would like to join in any discussion - Saturday would 
work well for me but happy to fit in with others.


Cheers

Nick


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

Re: [Talk-it] Licenza cartina turistica

[Luca Delucchi]

On Tue, 30 Jun 2020 at 10:50, Roberto Brazzelli 
wrote:

> Perfetto e grazie a tutti.
> Ricapitolando se cito ogni fonte e non non aggiungo nulla l'opera
> complessiva
> è soggetta a copyright dell'autore o bisogna scrivere tipo" Edizione 2020
> © Comune di , ,
>
> Tutti i diritti riservati. Vietata le riproduzione senza il consenso
>
> scritto dell'autore-editore"
>

io per sicurezza metterei la frase sopra, di default dovrebbe andare nel
copyright dell'autore ma se lo specifichi penso sia meglio

>
> Grazie
>
> Roberto
>
>
-- 
ciao
Luca

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

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

[Florian LAINEZ]

Pour en rajouter une couche, quand on voit la progression de la courbe des
tags "contact:" liée aux adresses, elle est carrément flat :
https://taghistory.raifer.tech/#***/contact:street/&***/contact:housenumber/&***/contact:postcode/&***/addr:street/&***/addr:housenumber/&***/addr:postcode/

Le mar. 30 juin 2020 à 23:18, Florian LAINEZ  a écrit :

> @jérome @jean-yvon @Yves je suis très conscient des effets de bords que
> vous mentionnez et je suis embêté.
> A vrai dire je suis à deux doigts de suggérer d'abandonner totalement ces
> "contact:" à tout jamais.
>
> Je constate en effet que 9500 contact:street sont en France sur les 10300
> utilisés de par le Monde, soit 92%. Autant dire que c'est un tag
> franco-français.
>
> Cela me fait réfléchir sérieusement : @christian @vdct pourriez-vous svp
> rappeler les raisons qui nous ont poussé à utiliser ces tags ?
> Y a-t-il d'autres raisons que celle, évidente, d'éviter les doublons
> d'adresse ? Est-ce que cela justifie vraiment de créer tout un jeu de tags
> qui n'est utilisé que par les français et qui restera durablement
> incompatible avec les outils d'édition prédominants ?
>
> Ces tags n'apparaissent pas sur les pages
> https://wiki.openstreetmap.org/wiki/FR:Adresses
> https://wiki.openstreetmap.org/wiki/FR:Key:contact
> Par ailleurs le graphique en haut de la page
> https://wiki.openstreetmap.org/wiki/Key:contact indique la popularité
> déclinante des tags "contact:" ces dernières années.
>
> Désolé de ressortir ce vieux squelette du placard mais je ne m'étais pas
> rendu compte que la France faisait exception sur le sujet et j'ai
> l'impression qu'on a fait fausse route depuis des années.
> Ne serait-il pas temps de tuer le monstre ?
>
> Florian, qui donne entre 2 mails un avis totalement opposé (après avoir
> creusé le sujet)
>
> Le mar. 30 juin 2020 à 15:59, Yves P.  a écrit :
>
>> On en déduira que quelqu'un a vérifié que le cinéma a été transformé en
>> toilettes^^.
>>
>> Ça ressemble plus à un nettoyage partiel.
>>
>> +1
>> Ou trop rapide :D
>>
>> __
>> Yves
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> --
>
> *Florian Lainez*
> @overflorian 
>


-- 

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

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

[Florian LAINEZ]

@jérome @jean-yvon @Yves je suis très conscient des effets de bords que
vous mentionnez et je suis embêté.
A vrai dire je suis à deux doigts de suggérer d'abandonner totalement ces
"contact:" à tout jamais.

Je constate en effet que 9500 contact:street sont en France sur les 10300
utilisés de par le Monde, soit 92%. Autant dire que c'est un tag
franco-français.

Cela me fait réfléchir sérieusement : @christian @vdct pourriez-vous svp
rappeler les raisons qui nous ont poussé à utiliser ces tags ?
Y a-t-il d'autres raisons que celle, évidente, d'éviter les doublons
d'adresse ? Est-ce que cela justifie vraiment de créer tout un jeu de tags
qui n'est utilisé que par les français et qui restera durablement
incompatible avec les outils d'édition prédominants ?

Ces tags n'apparaissent pas sur les pages
https://wiki.openstreetmap.org/wiki/FR:Adresses
https://wiki.openstreetmap.org/wiki/FR:Key:contact
Par ailleurs le graphique en haut de la page
https://wiki.openstreetmap.org/wiki/Key:contact indique la popularité
déclinante des tags "contact:" ces dernières années.

Désolé de ressortir ce vieux squelette du placard mais je ne m'étais pas
rendu compte que la France faisait exception sur le sujet et j'ai
l'impression qu'on a fait fausse route depuis des années.
Ne serait-il pas temps de tuer le monstre ?

Florian, qui donne entre 2 mails un avis totalement opposé (après avoir
creusé le sujet)

Le mar. 30 juin 2020 à 15:59, Yves P.  a écrit :

> On en déduira que quelqu'un a vérifié que le cinéma a été transformé en
> toilettes^^.
>
> Ça ressemble plus à un nettoyage partiel.
>
> +1
> Ou trop rapide :D
>
> __
> Yves
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 

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

Re: [Talk-it] Aiuto query overpass-turbo

[Martin Koppenhoefer]

sent from a phone

> On 30. Jun 2020, at 18:13, Andrea Albani  wrote:
> 
> Interessante il punto: se faccio un multipologono semplice con 
> "buchi"=cattivo, mentre frotte di poligoni slegati fra di loro=ok :)


esattamente. Le frotte no creano alcun problema e ti fanno vedere anche i 
limiti delle proprietà verso altri landuse come strade. I multipoligoni invece 
cominciano semplici e poi diventano sempre più complicate, e inoltre richiedono 
che ti scarichi massi di dati anche se vuoi solo inserire una cosa piccola in 
un punto. Inoltre richiedono software (editori) più potenti, e tendono ad 
essere sempre meno perspicue (i principianti hanno generalmente problemi con le 
relazioni).



>  
>>> Nella wiki per altro la questione è affrontata senza fornire indicazioni 
>>> chiare. Ad esempio nell'introduzione [1] si dice:
>>> " The landuse tag is mostly used for larger areas and not at parcel 
>>> granularity; as described above, a single shop in a residential area might 
>>> not always warrant an extra "commercial" landuse. "
>> 
>> 
>> Questo lascia aperta la possibilità di mappare a granularità di lotto (anche 
>> se penso che la granularità del isolato / blocco di particelle dovrebbe 
>> spesso essere sufficiente). In pratica è una descrizione dello stato di 
>> fatto, non esclude avere una visione diversa come meta. 
>> 
>>  
> 
> L'inglese dice che non vanno usati a quella granularità


non lo dice. Quello che dice è che questo metodo è ancora meno diffuso.


>  
>>> certo. Come tutto in OSM, si parte dal grezzo e si spera di arrivare al 
>>> dettaglio. 
>> 
> 
> Io sono per il dettaglio "misurato" (che uno declina come meglio crede), 
> perchè più c'è dettaglio e più forze per manutenerlo ci vogliono


dipende dal tipo di dettaglio. La tendenza generale va verso il più dettaglio. 

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

Re: [Talk-it] Aiuto query overpass-turbo

[Martin Koppenhoefer]

sent from a phone

> On 30. Jun 2020, at 17:29, Manuel  wrote:
> 
> Quindi una roba tipo questa, in cui ci sono decine diederichs 
> landuse=residential?

sì, questa zona mi sembra un modello avanzato, facile da aggiornare e mantenere 
e dettagliato dal punto di vista delle informazioni. Per me questo è dove 
vorrei arrivare in generale.

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

Re: [Talk-GB] positioning of shop nodes as entrances

[Ken Kilfedder]

I'm partial to tagging the shop/cafe as an area within the building.   In a 
highstreet scenario, you might have a 3 storey terrace containing mostly flats, 
with cafes and Argos's on the ground floor.   Very well, tag buildings as 
buildings, and tag the amenities as areas (likely most of the floorplan, except 
residential doors leading upstairs), and tag the doors as entrances.

Tagging the amenities as points within the building outline is certainly better 
than adding them to the doors, though.  I'd call that plain wrong.

I've done it that way for 43 to 79 West Ham Lane E15, for example - 
https://www.openstreetmap.org/#map=19/51.53920/0.00438

---
https://hdyc.neis-one.org/?spiregrain
spiregrain_...@ksglp.org.uk

On Tue, 30 Jun 2020, at 4:53 PM, Cj Malone wrote:
> >Personally, I don't like tagging the whole building as 'amenity=cafe' as it
> >is only the downstairs of the building being used for that purpose, which
> >is why they were nodes.
> 
> I agree, it also means that shops on buildings sometimes have `level`, 
> which doesn't makes sense.
> 
> >So, is there any downside to marking the entrance? I can see that it links
> >the cafe node to the building better.
> 
> One down side I can think of is that people might deleted the old node, 
> and make a new one, and copy the tags across. Losing the history isn't 
> ideal, but it's not really an argument against.
> 
> Also is there a way to link entrances to a poi as a node? In the 
> example below Boots has 2 entrances. Could they both be linked to the 
> pharmacy?
> 
> https://www.openstreetmap.org/node/336202468#map=19/50.70033/-1.29443
> 
> ___
> 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-br] Nova proposta de classificação viária - Votação encerrada

[santamariense]

> Eu gostaria de sugerir que aqueles que fizeram apontamentos nos seus
> votos abram discussão a respeito deles na página de discussão da
> proposta. [1] Lá é o lugar ideal para discutir e depois votar
> alterações e refinamentos na proposta.

> Acho que já existe um consenso substancial de que a regionalização por
> RGInts (parte da regra 2.2) e talvez também por RGIs (parte da regra
> 3.1) não seria a mais adequada. Alguns colegas propuseram e começaram
> a explorar os resultados de regionalizar usando as categorias das
> REGICs para adicionar alguns pólos ao conjunto considerado. As rotas
> preliminares que foram apresentadas por eles no Telegram fazem um
> certo sentido para mim, então, havendo interesse de outros colegas,
> não me oponho à substituição. As que foram apresentadas produzem um
> resultado melhor do que as RGInts, no sentido de identificarem melhor
> os eixos indutores do desenvolvimento regional.

Concordo. Poderíamos já votar sobre a supressão delas no texto uma vez
que são poucas cidades, e poderiam ser tratadas como exceção e também
porque em tais cidades o pessoal pareceu não se importar com a falta
de conexão trunk a elas. Acho que poderia ser aberto uma seção
"votação" na página de discussão e sub-seção para cada ponto a ser
votado. Cada um dá o seu voto e a sua motivação (se achar necessário)
porém para não poluir a página sugiro que discussões continuem se
dando nos canais oficiais e no Telegram. Por fim creio que uma votação
para cada um dos tipos de regiões geográficas fica mais adequado.

> Apesar disso, o número de diferenças em relação ao resultado final das
> demais regras tem se mostrado relativamente pequeno, de forma que
> essas rotas adicionais poderiam ser tratadas na lista de exceções
> junto com outras exceções que possam ser levantadas, por exemplo, como
> já foi citado por colegas diferentes algumas vezes, os acessos a
> grandes portos e aeroportos. Ou seja, é necessário mais estudo e
> comparação dos casos particulares.

Positivo.

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

[Talk-at] Bundesdenkmäler

[Stephan Bösch-Plepelits]

Hi!


Ich hab einen Checker für Bundesdenkmäler für OpenStreetMap, Wikidata u.ä.
geschrieben: https://www.openstreetmap.at/bundesdenkmal-checker/
Damit möchte ich die Verbreitung von ref:at:bda=*, wikidata=* und anderen
Metainformationen erhöhen :-)


Das Bundesdenkmalamt hat eine Liste aller Denkmäler im öffentlichen
Eigentum: https://bda.gv.at/denkmalverzeichnis/

Jedes dieser Denkmäler hat eine numerische ID. Es gibt ein
OpenStreetMap-Tag um die Denkmäler zu referenzieren, 'ref:at:bda':
https://wiki.openstreetmap.org/wiki/Key:ref:at:bda

In der Wikipedia gibt es eine Beschreibung für jedes Denkmal, zu der man
über dieses Skript kommt (Beispiel 21986: Karlskirche):
https://tools.wmflabs.org/denkmalliste/index.php?action=EinzelID=21986

Auch in Wikidata sind (alle?) Bundesdenkmäler eingetragen, zB:
https://www.wikidata.org/wiki/Q408847


Wer Wikidata noch nicht kennt: Diese Datenbank ist eine Ergänzung zur
Wikipedia und enthält Metadaten zu allen möglichen Objekten.
-> Namen in vielen Sprachen
-> beschreibende Attribute (Architekt_in, Gründung, ...)
-> Bilder, Link zu Wikimedia Commons Kategorie
-> Links zu Wikimedia Projekten (z.B. alle Sprachversionen der Wikipedia)
-> Links zu anderen Nachschlagewerken


Nun hab ich festgestellt, dass nur sehr wenige Objekte 'ref:at:bda' Tags in
der OpenStreetMap haben, manche haben zumindest einen 'wikidata' Verweis.

Der Bundesdenkmal Checker soll helfen, fehlende Objekte und fehlende Tags
aufzuspüren:
Zuerst wählt man eine Gemeinde aus und kriegt links im Browserfenster die
Liste an Bundesdenkmäler im Gemeindegebiet. Wenn man auf ein Denkmal
klickt, kriegt man rechts eine Auswertung bezüglich der verschiendenen
Projekte. Man kriegt fehlende und möglicherweise falsche Informationen
angezeigt und Tips, welche weiteren Informationen man eintragen könnte.

Beispiel Karlskirche:
https://www.openstreetmap.at/bundesdenkmal-checker/#21986

Falls Euch der Source Code interessiert, ihr findet ihn hier:
https://github.com/plepe/bundesdenkmal-checker

Ich freue mich über Kommentare, Verbesserungsvorschläge und Pull Requests
:-)

grüße,
Stephan

PS: Ich hab letztens einen Blog-Post über das Mappen von Kunstwerken und
Denkmäler in Verbindung mit Wikidata und Wikimedia Commons geschrieben:
http://plepe.at/398

PPS: Falls ihr mein Hauptprojekt, den OpenStreetBrowser, noch nicht kennt:
Hier werden wikidata und wikimedia_commons Links schon seit Ewigkeiten
ausgewertet, z.B. um Bilder anzuzeigen.
Beispiel: https://www.openstreetbrowser.org/#religion/w8097149/details
-- 
Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich
,--.
| Stephan Bösch-Plepelits  ❤ code ❤ urbanism ❤ free software ❤ cycling |
| Projects:|
| > OpenStreetMap: openstreetbrowser.org > openstreetmap.at|
| > Urbanism: Radlobby Wien > Platz für Wien   |
| Contact: |
| > Mail: sk...@xover.mud.at > Blog: plepe.at > Code: github.com/plepe |
| > Twitter: twitter.com/plepe > Jabber: sk...@jabber.at   |
| > Mastodon: @pl...@en.osm.town   |
`--'

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

Re: [Talk-GB] positioning of shop nodes as entrances

[ndrw]

Hi Jez,

I am not a fan of using entrances for tagging POIs for three reasons:

- An entrance to a shop is not a shop.

- Multiple primary tags cause problems with consuming data (e.g. when 
rendering). Is the point mainly an entrance or mainly a shop? In 
practice, we leave this decision to a piece of software that applies a 
"one fits all" rule.


- It is different from more established methods of tagging POIs as 
separate points or buildings, so we end up with multiple tagging 
conventions for no obvious benefit.


My own rules are to tag POIs as separate points whenever possible, 
especially if they are loosely attached to a building (e.g. there are 
multiple businesses in the building or the building is hired). Only when 
the building has a single, well defined purpose (a pub, a purpose-built 
shop) I tag POI on the building itself.


Tagging addresses on entrances is better (entrances can be actual 
delivery points). But, since this still results in multiple tagging 
conventions and provides a temptation to add POI information to the 
entrance points later, I don't use that technique myself.



On 30/06/2020 16:02, Jez Nicholson wrote:
I notice that a number of my local shop's POI nodes have been 
relocated as entrances, e.g. 
https://www.openstreetmap.org/node/2648378395 rather than them being a 
node within the building outline.


Personally, I don't like tagging the whole building as 'amenity=cafe' 
as it is only the downstairs of the building being used for that 
purpose, which is why they were nodes.


So, is there any downside to marking the entrance? I can see that it 
links the cafe node to the building better.


___
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] Aiuto query overpass-turbo

[Andrea Albani]

Il giorno mar 30 giu 2020 alle ore 11:04 Martin Koppenhoefer <
dieterdre...@gmail.com> ha scritto:

> Am Mo., 29. Juni 2020 um 15:51 Uhr schrieb Andrea Albani  >:
>
>> Quando si parla di landuse per me si parla di oggetti che permettono di
>> classificare ad un livello macroscopico il territorio.
>>
>
>
> non c'è scritto da nessuna parte però (dipende ovviamente da come si
> interpreta "macroscopico". Per esempio metterei un garage dentro un
> landuse=residential, ma ovviamente legalmente non puoi vivere dentro un
> garage.
>

Infatti è una mia personale interpretazione che può essere condivisa o
meno. Per me i landuse rimangono oggetti che descrivono le cose ad alto
livello, un po' come quando guardi una mappa tematica: non hai bisogno di
dettaglio, ma di una "panoramica" su quello che ti ritrovi sul territorio.
Siccome parliamo di aree di grandi dimensioni sapere che un 5% dell'area
considerata è "strada" o meno cambia poco ai fini dell'utilizzo che potrei
fare di quei dati (anche perchè non sai che errori potrebbero esserci
introdotti da chi fa landuse "precisi"). Per altro puoi anche stimare in
qualsiasi momento quanto spazio "rubano" le strade ad un
landuse=residential disegnato come monopoligono



>
>
>
>> A quel livello la precisione di mappatura non aggiunge elementi utili
>> perchè non stai contando il numero di edifici o di panchine, ma aree di una
>> certa estensione.
>>
>
>
> per me non c'è alcun vantaggio nel appositamente togliere il dettaglio. Se
> avessimo tutti i landuse ad alta granularità, potremmo sempre ai fini di
> renderizzare, automaticamente semplificarli e metterli insieme (decidendo
> cosa ci interessa, per esempio un uso industriale "dentro" una zona
> residenziale potrebbe essere visualizzato mentre un uso di vendita al
> dettaglio sotto una certa grandezza no, ecc., secondo lo scopo e la scala
> della mappa. Se invece facciamo finto che tutto sia ad uso residenziale
> (perché ovviamente in un centro abitato abitano appunto persone), non
> potremmo mai ottenere informazioni dettagliate perché non ci sarebbero. (si
> può sempre semplificare in automatico, ma nel verso contrario non funziona).
>
> Il concetto è chiaro: se non hai il dettaglio all'origine non puoi
ricrearlo... ma se stimi lo spazio utilizzato dalle strade non hai forse lo
stesso risultato ? siamo sempre all'interno di un margine di errore
paragonabile a quello di un umano che mappa o meno il giardino condominiale
o la strada di servizio interna che porta ai garage (sono parte di una
residential questi?)


>
>
>>
>> Questa è un'opinione ovviamente, e sottende il fatto che io non mappo
>> landuse residential a blocchi di case o a quartieri, pur escludendo dal
>> poligono tutto ciò che è classificabile con landuse differente. Aggiungo
>> che, avendo mappato prevalentemente piccoli centri abitati, potrei avere
>> una "sensibilità" sulla materia diversa da chi crea landuse=residential a
>> Milano o Roma.
>>
>
>
> anche nei piccoli centri non è vantaggioso avere landuse grandi, perché
> alla fine portano a multipoligoni (si deve rimuovere cose all'interno), e
> tutto diventa un casino complicato.
>
>
Interessante il punto: se faccio un multipologono semplice con
"buchi"=cattivo, mentre frotte di poligoni slegati fra di loro=ok :)


>
>
>>
>> Nella wiki per altro la questione è affrontata senza fornire indicazioni
>> chiare. Ad esempio nell'introduzione [1] si dice:
>> " The landuse tag is mostly used for larger areas *and not at parcel
>> granularity*; as described above, a single shop in a residential area
>> might not always warrant an extra "commercial" landuse. "
>>
>
>
> Questo lascia aperta la possibilità di mappare a granularità di lotto
> (anche se penso che la granularità del isolato / blocco di particelle
> dovrebbe spesso essere sufficiente). In pratica è una descrizione dello
> stato di fatto, non esclude avere una visione diversa come meta.
>
>
>

L'inglese dice che non vanno usati a quella granularità


>
>> Successivamente però si porta a conoscenza del lettore che esistono due
>> macro-scuole di pensiero, ovvero che la modalità di mappatura dei landuse
>> è, come tante cose in OSM, soggetta a libero arbitrio. Si afferma anche,
>> non so su che basi, che la maggior parte dei mapper considera un poligono
>> residential unico non un errore bensì un mapping preliminare.
>>
>
>
> certo. Come tutto in OSM, si parte dal grezzo e si spera di arrivare al
> dettaglio.
>
>
Io sono per il dettaglio "misurato" (che uno declina come meglio crede),
perchè più c'è dettaglio e più forze per manutenerlo ci vogliono


>
>
>>
>> Come ulteriore tassello una indicazione riportata in [2] : "For
>> "Mixed-Use" areas where more than half of the land is residential, tag as
>> residential"
>>
>
>
> questa frase è da rimuovere, al mio parere. Potrei mappare tutta Roma come
> unico landuse=residential perché si tratta di un area mista dove più della
> metà del suolo è utilizzato per abitare. Non ha senso, è espressione della
> 

Re: [Talk-GB] positioning of shop nodes as entrances

[Cj Malone]

>Personally, I don't like tagging the whole building as 'amenity=cafe' as it
>is only the downstairs of the building being used for that purpose, which
>is why they were nodes.

I agree, it also means that shops on buildings sometimes have `level`, which 
doesn't makes sense.

>So, is there any downside to marking the entrance? I can see that it links
>the cafe node to the building better.

One down side I can think of is that people might deleted the old node, and 
make a new one, and copy the tags across. Losing the history isn't ideal, but 
it's not really an argument against.

Also is there a way to link entrances to a poi as a node? In the example below 
Boots has 2 entrances. Could they both be linked to the pharmacy?

https://www.openstreetmap.org/node/336202468#map=19/50.70033/-1.29443

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

Re: [Talk-it] Aiuto query overpass-turbo

[Manuel]

Quindi una roba tipo questa 
, in cui ci 
sono decine di landuse=residential? Non so, mi sembra comunque strano.

Manuel Tassi

Il 30/06/2020 10:45, Martin Koppenhoefer ha scritto:



Am Mo., 29. Juni 2020 um 13:58 Uhr schrieb Manuel mailto:mannivuw...@gmail.com>>:

Sono d'accordo sul parco, ma per il resto l'uso di un landuse che comprenda tutta 
la zona residenziale del paese è molto esteso (anche in Germania - che spesso è presa 
a esempio - l'uso del landuse=residential è fatto in modo simile - es. la zona 
residenziale di Heidelberg ).




infatti, sto cercando di convincere anche i tedeschi ;-)

Ciao
Martin


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

[Talk-GB] positioning of shop nodes as entrances

[Jez Nicholson]

I notice that a number of my local shop's POI nodes have been relocated as
entrances, e.g. https://www.openstreetmap.org/node/2648378395 rather
than them being a node within the building outline.

Personally, I don't like tagging the whole building as 'amenity=cafe' as it
is only the downstairs of the building being used for that purpose, which
is why they were nodes.

So, is there any downside to marking the entrance? I can see that it links
the cafe node to the building better.
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] Inscription à l'atelier du 8.07.2020 à 14h sur la standardisation des données vélo

[Yves P.]

> Pour celles et ceux intéressé par le vélo et OSM …

Le lien direct pour s'inscrire issu de "Des nouvelles de transport.data.gouv.fr 
! | Info-lettre Juin 2020"

Mercredi 8 juillet - atelier autour de l'harmonisation des données 
d'aménagements cyclables.
Cet atelier nous permettra d'avancer sur l'élaboration d'un schéma pour les 
données d'aménagements cyclables. 
Vous pouvez accéder à la billetterie ici  


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

[OSM-talk-fr] Extracteur de fichier GeoJSON correspond aux points d'arrêts et aux lignes à partir d'un fichier GTFS

[Yves P.]

Bonjour,

Pour celles et ceux qui veulent cartographier dans OSM les lignes de transport 
en commun, transport.data.gouv.fr  vient 
d'annoncer ceci dans son Info-lettre de Juin 2020.

__
Yves


Des réseaux de transport cartographiés
Un extracteur de GeoJSON pour ouvrir de nouveaux usages.
[lien vers la photo dans l'article 
]
Le format GTFS peut faire peur. Le Point d'Accès National n'a pas pour seul but 
d'alimenter des calculateurs d'itinéraires mais doit permettre au plus grand 
nombre d'organisations de s'approprier ces données. Aussi diffuser les données 
sous d'autres formats peut être un moyen de toucher de nouveaux utilisateurs et 
développer de nouveaux usages. C'est pourquoi nous avons mis en place un 
extracteur de GeoJSON qui génère pour chaque fichier GTFS un fichier GeoJSON 
correspond aux points d'arrêts et aux lignes. La visualisation de ce GeoJSON 
est pour le moment disponible dans les résultats d'analyses de GTFS. Ceci sera 
également ajouté comme ressource communautaire sur chaque jeu de données pour 
permettre de télécharger ce fichier GeoJSON. Nous envisageons également de 
produire un fichier complet pour la France et une interface de visualisation. 
N'hésitez pas à nous indiquer votre intérêt pour ce travail, il serait alors 
priorisé !


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

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

[Yves P.]

> On en déduira que quelqu'un a vérifié que le cinéma a été transformé en 
> toilettes^^.
> 
> Ça ressemble plus à un nettoyage partiel.
> 
+1
Ou trop rapide :D

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

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

[osm . sanspourriel]

Le 30/06/2020 à 15:22, Yves P. - yves.prat...@gmail.com a écrit :

https://www.openstreetmap.org/relation/11186492
Les relations type=site sont à éviter : pas rendu, peuvent être
remplacer par un polygone ou un multipolygone

C'est curieux ?
Relier des toilettes au bout d'un dédale de souterrain? qui mène au
cinéma (le polygone du bâtiment) ?
Et pour l'autre relier une entrée sur une autre rue avec la salle de
cinéma ??


Justement les dédales ne sont pas dans la relation :
https://www.openstreetmap.org/way/445308489. Est-ce des couloirs publics
? J'imagine mal des toilettes réservées aux clients en dehors du
bâtiment (même si je connais le cas).

Alors j'ai d'autres problèmes :

- toilet=yes Indicates that a feature has a toilet.

Ce n'est donc pas les toilettes elles-mêmes (qui sont publiques amenity
=toilets
).

Donc je mettrais simplement toilet=yes sur le cinéma.

Je suppose que les gens utilisent OSM pour trouver des toilettes
publiques mais par contre que dans un cinéma ils suivent les flèches (et
non les mouches^^ ou OSM).

Mais y a-t-il des cinémas sans toilettes ? Hormis les cinémas en plein
air peut-être.

À voir l'historique du point ça semble avoir été considéré comme le
cinéma. Une entrée ?

source=survey reste depuis le début.

On en déduira que quelqu'un a vérifié que le cinéma a été transformé en
toilettes^^.

Ça ressemble plus à un nettoyage partiel.

Jean-Yvon

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

[OSM-talk-fr] Inscription à l'atelier du 8.07.2020 à 14h sur la standardisation des données vélo

[Yves P.]

Bonjour,

Pour celles et ceux intéressé par le vélo et OSM et qui ne seraient pas inscrit 
à la liste v...@listes.openstreetmap.fr, je vous retransmet le message du 
Responsable de l'ouverture de donnéessur transport.data.gouv.fr
__
Yves

---
Bonjour,

Je suis responsable de l'accompagnement à l'ouverture des données mobilités  
chez transport.data.gouv.fr  , le point d'accès 
nationale aux données mobilité.

J'ai lu dans dans votre discussion sur le forum d'Openstreetmap que certains 
contributeurs aimeraient participer à notre atelier du 8.07 à 14h concernant 
l'élaboration d'un schéma de données pour décrire les aménagements cyclables. 

Pouvez-vous leur demander de m'envoyer un mail à l'adresse : 
deploiem...@transport.beta.gouv.fr   
pour que je puisse confirmer leur inscription et les inclure dans la liste de 
diffusion ?  

Si vous avez des questions ou recommandations, n'hésitez pas à me contacter.

Bonne après-midi
-- 

  •  Miryad Ali
  •  Responsable de l'ouverture de donnéessur transport.data.gouv.fr
  •  Pour prendre rendez-vous : 
https://calendly.com/miryad-ali/reunion-1h 

  •  Incubateur de Services Numériques – DINUM (Services du Premier Ministre)
  •  20, Avenue de Ségur, 75007 Paris  
  •  miryad@beta.gouv.fr  – 
+33.(0)6.95.88.28.69 
> VélOSM mailing list
> v...@listes.openstreetmap.fr
> https://listes.openstreetmap.fr/wws/info/velo
> Archives : https://listes.openstreetmap.fr/wws/arc/velo

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

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

[Flavio Bello Fialho]

Acho que usar a população como critério geral é uma ótima forma para gerar
a base do mapa, e é o que deve estar na regra. É simples, objetivo e
facilmente verificável. Os demais critérios (RGI, REGIC, portos,
aeroportos, etc.) podem servir de base para estudos que identifiquem e
justifiquem as exceções, não cobertas pela regra geral. É importante
lembrar que o que existe hoje pode não existir amanhã (ex: micro e
meso-regiões). No entanto, a população sempre vai existir.

Outro fator a considerar, principalmente na região norte, é que o modal
rodoviário nem sempre é o melhor. Em alguns casos a ligação no nível trunk
pode ser feito por hidrovias, ou até por via aérea (por exemplo, a BR-363
está completamente isolada do resto da malha rodoviária).

Em seg., 29 de jun. de 2020 às 13:14, Fernando Trebien <
fernando.treb...@gmail.com> escreveu:

> Eu gostaria de sugerir que aqueles que fizeram apontamentos nos seus
> votos abram discussão a respeito deles na página de discussão da
> proposta. [1] Lá é o lugar ideal para discutir e depois votar
> alterações e refinamentos na proposta.
>
> Acho que já existe um consenso substancial de que a regionalização por
> RGInts (parte da regra 2.2) e talvez também por RGIs (parte da regra
> 3.1) não seria a mais adequada. Alguns colegas propuseram e começaram
> a explorar os resultados de regionalizar usando as categorias das
> REGICs para adicionar alguns pólos ao conjunto considerado. As rotas
> preliminares que foram apresentadas por eles no Telegram fazem um
> certo sentido para mim, então, havendo interesse de outros colegas,
> não me oponho à substituição. As que foram apresentadas produzem um
> resultado melhor do que as RGInts, no sentido de identificarem melhor
> os eixos indutores do desenvolvimento regional.
>
> Apesar disso, o número de diferenças em relação ao resultado final das
> demais regras tem se mostrado relativamente pequeno, de forma que
> essas rotas adicionais poderiam ser tratadas na lista de exceções
> junto com outras exceções que possam ser levantadas, por exemplo, como
> já foi citado por colegas diferentes algumas vezes, os acessos a
> grandes portos e aeroportos. Ou seja, é necessário mais estudo e
> comparação dos casos particulares.
>
> [1]
> https://wiki.openstreetmap.org/wiki/Talk:Brazil/Classifica%C3%A7%C3%A3o_das_rodovias_do_Brasil
>
>
> On Sun, Jun 28, 2020 at 11:49 AM santamariense 
> wrote:
> >
> > A proposta está recebendo novas propostas de variáveis as quais
> > precisarão passar por novas votações, quer pontualmente, quer em
> > conjuntos. Várias observações foram feitas, muitas poderão ser votadas
> > em breve e outras tantas poderão ser votadas com o amadurecimento da
> > implantação em mapa do que está sendo proposto.
> >
> > Como já foi falado em várias ocasiões, a discussão não acaba aqui, mas
> > sim evolui com o andar do mapeamento. Vou declarar a proposta
> > aprovada, uma vez que há a aprovação da maioria dos que votaram e por
> > respeito a quem dedicou o tempo que tinha para estudar a proposta e
> > dar seu voto. E para que possamos virar a página e a partir desse
> > momento votar casos pontuais conforme forem surgindo, bem como ajustes
> > no texto da proposta que se julgar necessário.
> >
> > ___
> > Talk-br mailing list
> > Talk-br@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-br
>
>
>
> --
> Fernando Trebien
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>


-- 
Flávio Bello Fialho
bello.fla...@gmail.com
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

[Yves P.]

> Sur les relations, je pense qu'il y a des choses à modifier comme 
> https://www.openstreetmap.org/relation/11186531 
>  et 
> https://www.openstreetmap.org/relation/11186492 
> 
> Les relations type=site sont à éviter : pas rendu, peuvent être remplacer par 
> un polygone ou un multipolygone
C'est curieux ?
Relier des toilettes au bout d'un dédale de souterrain? qui mène au cinéma (le 
polygone du bâtiment) ?
Et pour l'autre relier une entrée sur une autre rue avec la salle de cinéma ??

Je pige, tu veux mettre des tags sur un polygone avec une adresse (beurk) sans 
mélanger ces tags avec avec ceux du polygone building=* + addr:*=* (+ 
toilets=yes )

KISS 

Admettons que je mette le noeud amenity=cinema près de l'entrée : 48.8321269, 
2.3758317

Voici les adresses géocodées :
Google  : 162 Avenue de France 128, 
75013 Paris
Site du Mk2  : 128/162 av. de 
France 75013 Paris
Fichier du CNC : 128 A 162 AVENUE DE FRANCE Paris 13e Arrondissement
Nominatim 

 : 128-162, Avenue de France, 75013, Paris
Photon  : 
128-162 Avenue de France 75013 Paris
adresse.data.gouv.fr 
 134 
Avenue de France 75013 Paris

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

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

[Jérôme Amagat]

Le mar. 30 juin 2020 à 09:13, Yves P.  a écrit :

> Yves : en France on veut l'unicité des points adresse.
>
> Oui, et je suis d'accord avec ça.
>
> L'idée de Florian est bonne, le résultat risque de l'être moins (cf. ton
> explication et celle de Jérôme).
>
> Par rapport au cas du ciné sur le bâtiment, je règle le problème en
> séparant le POI (ici le ciné) du bâtiment :
> Je met un noeud pour le POI vers son entrée, et laisse building=*,
> source=cadastre… sur le polygone.
>
> Pour le moment je fais ça manuellement.
>
> Je viens de regarder, d'après TagInfo FR, il y a 676 chemins et 9
> relations
>  avec
> amenity=cinema.
>
> Sur les relations, je pense qu'il y a des choses à modifier comme
https://www.openstreetmap.org/relation/11186531 et
https://www.openstreetmap.org/relation/11186492
Les relations type=site sont à éviter : pas rendu, peuvent être remplacer
par un polygone ou un multipolygone
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-GB] Documenting tagging practice for place nodes in London

[Alan Mackie]

On Thu, 25 Jun 2020 at 13:56, Russ Garrett  wrote:

> On Thu, 25 Jun 2020 at 13:20, Andy Townsend  wrote:
> > Quite a lot of stuff of the placename info on OS StreetView probably
> > _shouldn't_ be in OSM.  Leaving aside farm and house names, the where I
> > used to live in Derbyshire is according to OS StreetView composed of 5
> > different "villages".  It's actually either 1 or 2, depending on who you
> > ask.  It's probably less of an issue in London (less space for
> > extraneous names), though.
>
> I have noticed a few cases, especially in areas of London I know very
> well, where OS shows an archaic name which isn't really in general
> use. This gets a bit tricky because there's not really a way of
> signalling to other mappers that a place name isn't in use based on
> local knowledge. Obviously local knowledge is best here but we
> probably don't have mappers with good local knowledge of all the
> various corners of London, and I'm pretty sure that there are areas of
> London where the area names have never been adequately mapped (which
> is why I started this thread). So I'm not sure how best to solve that
> conundrum.
>
> Out of date names might show up less in addr:? Of course then you need
full addresses rather than street, number and "leave it to the algo".
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] Alternatives à Mapillary

[Yves P.]

> Y a-t-il un.e thésard.e dans la salle qui peut nous faire un topo en français 
> ?

Une recherche GitHub montre qu'il existe plusieurs modèles pré-entrainés dont 
de la détection de visage, d'expression du visage, de postures…

#pretrained-models #face-detection 

timesler  / facenet-pytorch 

MaybeS  / face-detection 

syedalamabbas  / FaceLandMark 


L'image animée 

 dans le readme 
 du premier 
projet est bluffante :)

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

Re: [Talk-it] Aiuto query overpass-turbo

[Alessandro Vitali]

Per la query grazie!

Per quel che riguarda il landuse passo... al momento ho altre priorità. Ma
grazie cmq! Ci tornerò su in un futuro!

Ale Vit


Mail
priva di virus. www.avast.com

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

Il giorno lun 29 giu 2020 alle ore 07:29 Alessandro Sarretta <
alessandro.sarre...@gmail.com> ha scritto:

> Ciao,
>
> a quanto ho capito, geocodeArea va a cercare tramite Nominatim e viene
> considerata solo la prima corrispondenza, in questo caso l'area
> residenziale: https://www.openstreetmap.org/relation/2196897
>
> Se usi
>
> area[name=Castelnuovo][admin_level=8]->.searchArea;
>
> va a cercarti il confine comunale
> https://www.openstreetmap.org/relation/46713
>
> La query che ti serve dovrebbe essere questa:
> http://overpass-turbo.eu/s/Vyu
>
> Ale
>
>
> On 29/06/20 02:03, Alessandro Vitali wrote:
>
> Ciao,
>
> io parto con questa query (http://overpass-turbo.eu/s/Vyn) che mi
> permette di estrarre gli indirizzi nell'area di Castelnuovo.
> Quando però verifico l'estrazione noto che non ha estratto tutti gli
> indirizzi contenuti nel confine comunale ma solo quelli contenuti nel
> multipoligono landuse:residential.
>
> Come posso fare per estendere l'area di ricerca ai confini comunali?
>
> Grazie!
> Ale Vit
>
> ___
> Talk-it mailing 
> listTalk-it@openstreetmap.orghttps://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] Alternatives à Mapillary

[Yves P.]

> Je viens de mettre mon script sur github:
> https://github.com/tyndare/blur-persons

Une lecture en diagonal indique que tu utilises TensorFlow.

Je me demandais quel est l'algorithme derrière leur "deep neural networks"  ?

Dans la doc de TensorFlow on trouve les termes Convolutional Neural Network 
(CNN)  et Quantum 
Convolutional Neural Network (QCNN) 
.

Une recherche avec "mapillary QCNN" renvoi du code et des articles avec les 
termes CNN et R-CNN :
mapillary/seamseg: Seamless Scene Segmentation 
 - GitHub
Tout le code semble ouvert 

Ils utilisent (entre-autres) le jeu de détection d'objet COCO 
 (330 000 photos téléchargeables 
 en licence CC 4.0 
)


Y a-t-il un.e thésard.e dans la salle qui peut nous faire un topo en français ?

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

Re: [Talk-it-lazio] incontro lunedì

[Marcello Pelato via Talk-it-lazio]

 Eheheh :-D"alle 18:00 un pó d'oro ci sarebbe"bèh, non era certo quello che 
intendevo ahahah, ma apprezzo lo sforzo ;-)
Per quell'ora volentieri, ma non posso confermare in questo momento. Incrocio 
le dita.Comunque nel caso concordo giorno, ora, centro e panino..
On Tuesday, June 30, 2020, 01:30:30 PM GMT+2, Martin Koppenhoefer 
 wrote:  
 
 per me va benissimo
CiaoMartin
  ___
Talk-it-lazio mailing list
Talk-it-lazio@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it-lazio

Re: [OSM-talk-fr] Learning with Verification: Improving Object Recognition with the Community’s Input - The Mapillary Blog

[Yves P.]

> > 297K of them were approvals of detections, and 293K were rejections.
> 
> 50 % de faux, pas mal !
> 
Si j'ai bien compris, c'était avant les vérifications faites par les 
utilisateurs.
Après les scores augmentent.

> > This led to a total number of 114K positive (approvals) and 137K negative 
> > (rejections) training samples to be used for improving our algorithms.
> 
> Encore pire !
> 
Bien avant de lire cet article j'ai constaté qu'ils détectent plus de choses : 
c'est assez bluffant.

Avez-vous vu ce lien en bas d'article ?
https://help.mapillary.com/hc/en-us/articles/360025532692-Verification-projects

Je l'ai parcouru en diagonal, mais ça semble intéressant.

Plutôt que de réinventer la roue, il faudrait voir si c'est possible de 
contribuer à entrainer leur "deep neural networks" mais avec une licence qui 
permet de récupérer les données d'apprentissage.

Et dans leur MarketPlace , on voit 
qu'il y a des projets "locaux" en France :
Paris :
MEMEX Research Project: Rosa Park https://memexproject.eu
Grenoble :
Help identifying bike racks in Grenoble
Help identifying crosswalks in Grenoble
Help identifying benchs in Grenoble.
Help identifying fire hydrants in Grenoble.

Quelqu'un en sait plus sur ces projets ?

__
Yves

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

Re: [Talk-it-lazio] incontro lunedì

[Martin Koppenhoefer]

per me va benissimo

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

Re: [Talk-it-lazio] incontro lunedì

[Flaminia Tumino]

Ciao a tutti,
per me lunedì 6 luglio alle 18 andrebbe bene, potremmo vederci in centro
approfittando del fatto che è piuttosto vuoto (e bellissimo).
Propongo inoltre che ognuno si porti un panino o qualcosa da mangiare
cosi che possiamo girare senza preoccuparci di doverci fermare e cercare
cibo.
Che ne dite?
A presto,
Flaminia

Il giorno mar 30 giu 2020 alle ore 11:43 Martin Koppenhoefer <
dieterdre...@gmail.com> ha scritto:

> Ottimo, ricapitolando, la proposta è vederci prima? Che orario suggerite?
> Per me troppo nella giornata non sarebbe consigliabile, per le temperature
> pomeridiane, ma potremmo anticipare di qualche ora, che ne so, alle 18?
> Anche perché la notta al momento arriva dopo le 21, così un po' di oro ci
> sarebbe. Comporterebbe anche la necessità di mangiare qualcosa durante
> l'incontro.
>
> Direi di mantenere il Lunedì, perché siamo abituato e sarebbe buono
> garantire (o meglio riacquistare) un minimo di "continuità".
>
> Per la zona ditemi voi, naturalmente mi trovo bene a Garbatella, ma se
> volete cambiare zona, per me andrebbe bene ugualmente. A dire la verità, di
> tutte le zone "centrali" mi sembra quasi il centro la parte meno mappata, e
> soprattutto poco aggiornato/mantenuto. E ancora abbastanza privo di turisti
> (in confronto alla situazione "normale").
>
> Appena abbiamo conferma su orario e punto d'incontro, mettiamo tutto nel
> wiki (primo lunedì del mese = 6 Luglio va bene?).
>
> Ciao
> Martin
> ___
> Talk-it-lazio mailing list
> Talk-it-lazio@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it-lazio
>
___
Talk-it-lazio mailing list
Talk-it-lazio@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it-lazio

Re: [OSM-talk-fr] maj base de rendu bloquée (osm.org, osm.fr, osm.ch et surement d'autres)

[Christian Quest]

Le correctif est arrivé (osm2pgsql 1.2.2 et libosmium 2.15.6).

osm13 et osm25 sont à jour, les mise à jour reprennent... quelques jours 
de retard à rattraper ce qui va prendre quelques heures.


Suite ici: https://github.com/osm-fr/infrastructure/issues/208


Le 27/06/2020 à 17:24, Marc M. a écrit :

Bonjour,

pour info, un diff bloque le maj des bases de rendu utilisant osm2pgsql,
entre autre celle de osm.org, osm.fr, osm.ch
sequenceNumber=4082799
timestamp=2020-06-26T19:17:02Z

On attend le correctif :)

Regards,
Marc


--
Christian Quest - OpenStreetMap France


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

[OSM-talk-fr] Learning with Verification: Improving Object Recognition with the Community’s Input - The Mapillary Blog

[Yves P.]

https://blog.mapillary.com/update/2020/06/09/improving-object-recognition-with-communitys-input.html
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Noms des quartiers en ville

[Arnaud Champollion]

Fait.

J'ai passé le Plan de Gaubert en place=neighbourhood

et ajouté un place=neighbourhood "Les Sieyes".




Le 30/06/2020 à 11:54, Arnaud Champollion a écrit :

Le 30/06/2020 à 10:27, osm.sanspourr...@spamgourmet.com a écrit :

Arnaud, ici c'est un neighbourhood, pas un hamlet donc déjà testé


On peut quand même le passer en neighbourhood, car c'est ce qui 
correspond à la réalité.


Et augmenter la densité des neighbourhood, dans le cas présent en 
ajoutant le nom du quartier qui manque, ça pourrait aider Nominatim à 
être plus précis ?


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



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

Re: [OSM-talk-fr] Noms des quartiers en ville

[Arnaud Champollion]

Le 30/06/2020 à 10:27, osm.sanspourr...@spamgourmet.com a écrit :

Arnaud, ici c'est un neighbourhood, pas un hamlet donc déjà testé


On peut quand même le passer en neighbourhood, car c'est ce qui 
correspond à la réalité.


Et augmenter la densité des neighbourhood, dans le cas présent en 
ajoutant le nom du quartier qui manque, ça pourrait aider Nominatim à 
être plus précis ?


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

Re: [Talk-it-lazio] incontro lunedì

[Martin Koppenhoefer]

Ottimo, ricapitolando, la proposta è vederci prima? Che orario suggerite?
Per me troppo nella giornata non sarebbe consigliabile, per le temperature
pomeridiane, ma potremmo anticipare di qualche ora, che ne so, alle 18?
Anche perché la notta al momento arriva dopo le 21, così un po' di oro ci
sarebbe. Comporterebbe anche la necessità di mangiare qualcosa durante
l'incontro.

Direi di mantenere il Lunedì, perché siamo abituato e sarebbe buono
garantire (o meglio riacquistare) un minimo di "continuità".

Per la zona ditemi voi, naturalmente mi trovo bene a Garbatella, ma se
volete cambiare zona, per me andrebbe bene ugualmente. A dire la verità, di
tutte le zone "centrali" mi sembra quasi il centro la parte meno mappata, e
soprattutto poco aggiornato/mantenuto. E ancora abbastanza privo di turisti
(in confronto alla situazione "normale").

Appena abbiamo conferma su orario e punto d'incontro, mettiamo tutto nel
wiki (primo lunedì del mese = 6 Luglio va bene?).

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

Re: [Talk-GB] Virtual meeting: New open data and towards more UK addresses

[Dan S]

I probably won't make the meeting myself - but it sounds clever to put
it in SotM, you might acquire a couple of bonus participants that way?

Best
Dan

Op ma 29 jun. 2020 om 21:46 schreef Tony OSM :
>
> Hi Rob
>
> I think a meeting this weekend is a good idea.
>
> Even if a basic discussion of what we understand is available and the 
> creation of an agenda of how to use the data.
>
> Tony Shield
>
> On 29/06/2020 20:37, Rob Nickerson wrote:
>
> Hi all,
>
> The new open data comes out on Wednesday this week (land ownership 
> boundaries, Unique Property Reference Number, etc). We are considering 
> holding a virtual meeting to discuss how we might be able to use this and any 
> next steps.
>
> Does this sound of interest to you? If so, what times and dates might work 
> best? One option is we schedule it as a State of the Map virtual session. 
> Either 19:00 BST on Saturday 3rd July (just before Allan's Q session) or at 
> 19:45 BST on Sunday 4 July. If this is too soon then we can slip it by a week 
> or so.
>
> Let me know what you think.
>
> Best regards,
> Rob
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

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

Re: [Talk-it] Aiuto query overpass-turbo

[Martin Koppenhoefer]

Am Mo., 29. Juni 2020 um 15:51 Uhr schrieb Andrea Albani :

> Quando si parla di landuse per me si parla di oggetti che permettono di
> classificare ad un livello macroscopico il territorio.
>


non c'è scritto da nessuna parte però (dipende ovviamente da come si
interpreta "macroscopico". Per esempio metterei un garage dentro un
landuse=residential, ma ovviamente legalmente non puoi vivere dentro un
garage.





> A quel livello la precisione di mappatura non aggiunge elementi utili
> perchè non stai contando il numero di edifici o di panchine, ma aree di una
> certa estensione.
>


per me non c'è alcun vantaggio nel appositamente togliere il dettaglio. Se
avessimo tutti i landuse ad alta granularità, potremmo sempre ai fini di
renderizzare, automaticamente semplificarli e metterli insieme (decidendo
cosa ci interessa, per esempio un uso industriale "dentro" una zona
residenziale potrebbe essere visualizzato mentre un uso di vendita al
dettaglio sotto una certa grandezza no, ecc., secondo lo scopo e la scala
della mappa. Se invece facciamo finto che tutto sia ad uso residenziale
(perché ovviamente in un centro abitato abitano appunto persone), non
potremmo mai ottenere informazioni dettagliate perché non ci sarebbero. (si
può sempre semplificare in automatico, ma nel verso contrario non funziona).




>
> Questa è un'opinione ovviamente, e sottende il fatto che io non mappo
> landuse residential a blocchi di case o a quartieri, pur escludendo dal
> poligono tutto ciò che è classificabile con landuse differente. Aggiungo
> che, avendo mappato prevalentemente piccoli centri abitati, potrei avere
> una "sensibilità" sulla materia diversa da chi crea landuse=residential a
> Milano o Roma.
>


anche nei piccoli centri non è vantaggioso avere landuse grandi, perché
alla fine portano a multipoligoni (si deve rimuovere cose all'interno), e
tutto diventa un casino complicato.



>
> Nella wiki per altro la questione è affrontata senza fornire indicazioni
> chiare. Ad esempio nell'introduzione [1] si dice:
> " The landuse tag is mostly used for larger areas *and not at parcel
> granularity*; as described above, a single shop in a residential area
> might not always warrant an extra "commercial" landuse. "
>


Questo lascia aperta la possibilità di mappare a granularità di lotto
(anche se penso che la granularità del isolato / blocco di particelle
dovrebbe spesso essere sufficiente). In pratica è una descrizione dello
stato di fatto, non esclude avere una visione diversa come meta.



>
> Successivamente però si porta a conoscenza del lettore che esistono due
> macro-scuole di pensiero, ovvero che la modalità di mappatura dei landuse
> è, come tante cose in OSM, soggetta a libero arbitrio. Si afferma anche,
> non so su che basi, che la maggior parte dei mapper considera un poligono
> residential unico non un errore bensì un mapping preliminare.
>


certo. Come tutto in OSM, si parte dal grezzo e si spera di arrivare al
dettaglio.




>
> Come ulteriore tassello una indicazione riportata in [2] : "For
> "Mixed-Use" areas where more than half of the land is residential, tag as
> residential"
>


questa frase è da rimuovere, al mio parere. Potrei mappare tutta Roma come
unico landuse=residential perché si tratta di un area mista dove più della
metà del suolo è utilizzato per abitare. Non ha senso, è espressione della
mancata standardizzazione per landuse misti abbinata alla inerzia contro il
cambiamento, è una dichiarazione di capitolazione. Sono le persone che non
vogliono il progresso che scrivono cose del genere, perché così si sentono
in pace. "C'è la regola".
Comunque, "non funziona", perché non si capisce quanto sia grande questa
"area". Una particella? Un isolato? Un quartiere? Una città? Un'area
metropolitana?

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

Re: [Talk-it] Aiuto query overpass-turbo

[Martin Koppenhoefer]

Am Mo., 29. Juni 2020 um 15:51 Uhr schrieb Andrea Albani :

> Quando si parla di landuse per me si parla di oggetti che permettono di
> classificare ad un livello macroscopico il territorio.
>


non c'è scritto da nessuna parte però (dipende ovviamente da come si
interpreta "macroscopico". Per esempio metterei un garage dentro un
landuse=residential, ma ovviamente legalmente non puoi vivere dentro un
garage.





> A quel livello la precisione di mappatura non aggiunge elementi utili
> perchè non stai contando il numero di edifici o di panchine, ma aree di una
> certa estensione.
>


per me non c'è alcun vantaggio nel appositamente togliere il dettaglio. Se
avessimo tutti i landuse ad alta granularità, potremmo sempre ai fini di
renderizzare, automaticamente semplificarli e metterli insieme (decidendo
cosa ci interessa, per esempio un uso industriale "dentro" una zona
residenziale potrebbe essere visualizzato mentre un uso di vendita al
dettaglio sotto una certa grandezza no, ecc., secondo lo scopo e la scala
della mappa. Se invece facciamo finto che tutto sia ad uso residenziale
(perché ovviamente in un centro abitato abitano appunto persone), non
potremmo mai ottenere informazioni dettagliate perché non ci sarebbero. (si
può sempre semplificare in automatico, ma nel verso contrario non funziona).




>
> Questa è un'opinione ovviamente, e sottende il fatto che io non mappo
> landuse residential a blocchi di case o a quartieri, pur escludendo dal
> poligono tutto ciò che è classificabile con landuse differente. Aggiungo
> che, avendo mappato prevalentemente piccoli centri abitati, potrei avere
> una "sensibilità" sulla materia diversa da chi crea landuse=residential a
> Milano o Roma.
>


anche nei piccoli centri non è vantaggioso avere landuse grandi, perché
alla fine portano a multipoligoni (si deve rimuovere cose all'interno), e
tutto diventa un casino complicato.



>
> Nella wiki per altro la questione è affrontata senza fornire indicazioni
> chiare. Ad esempio nell'introduzione [1] si dice:
> " The landuse tag is mostly used for larger areas *and not at parcel
> granularity*; as described above, a single shop in a residential area
> might not always warrant an extra "commercial" landuse. "
>


Questo lascia aperta la possibilità di mappare a granularità di lotto
(anche se penso che la granularità del isolato / blocco di particelle
dovrebbe spesso essere sufficiente). In pratica è una descrizione dello
stato di fatto, non esclude avere una visione diversa come meta.



>
> Successivamente però si porta a conoscenza del lettore che esistono due
> macro-scuole di pensiero, ovvero che la modalità di mappatura dei landuse
> è, come tante cose in OSM, soggetta a libero arbitrio. Si afferma anche,
> non so su che basi, che la maggior parte dei mapper considera un poligono
> residential unico non un errore bensì un mapping preliminare.
>


certo. Come tutto in OSM, si parte dal grezzo e si spera di arrivare al
dettaglio.




>
> Come ulteriore tassello una indicazione riportata in [2] : "For
> "Mixed-Use" areas where more than half of the land is residential, tag as
> residential"
>


questa frase è da rimuovere, al mio parere. Potrei mappare tutta Roma come
unico landuse=residential perché si tratta di un area mista dove più della
metà del suolo è utilizzato per abitare. Non ha senso, è espressione della
mancata standardizzazione per landuse misti abbinata alla inerzia contro il
cambiamento, è una dichiarazione di capitolazione. Sono le persone che non
vogliono il progresso che scrivono cose del genere, perché così si sentono
in pace. "C'è la regola".
Comunque, "non funziona", perché non si capisce quanto sia grande questa
"area". Una particella? Un isolato? Un quartiere? Una città? Un'area
metropolitana?

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

Re: [OSM-talk-fr] Comment restaurer des données supprimée

[osm . sanspourriel]

La question est ambigüe, porte-t-elle sur le comment le faire auquel cas
Adrien a répondu ou sur le comment retrouver le changeset.

" je m'en rend compte très tardivement. La zone est très limité. Sur
deux immeubles."

À partir de https://www.openstreetmap.org/user//history
tu peux retrouver le changeset à problème que tu annules comme dit par
Adrien.

Tu peux utiliser overpass en mode diff avec deux dates, aussi près que
possible de la date de la boulette (avant et après) et tu cherches les
building supprimés. Il ne doit pas y en avoir beaucoup si tu zoomes
assez avant de lancer la requête. Là encore le plus simple c'est de
trouver ainsi le changeset et se ramener au cas précédent.

Jean-Yvon

Le 30/06/2020 à 07:53, PanierAvide - panierav...@riseup.net a écrit :


Bonjour,

Pour référence : https://wiki.openstreetmap.org/wiki/Change_rollback

Et dans ce cas là, à priori le plus simple est le plugin "undelete" de
JOSM https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Undelete

Cordialement,

Adrien P.
Le 30/06/2020 à 06:33, Gad Jo a écrit :

Bonjour,


J'ai fait une suppression malheureuse mais je m'en rend compte très
tardivement. La zone est très limité. Sur deux immeubles.

C'est plus simple de refaire un import du cadastre mais je demande ça
aussi pour apprendre comment répondre à cette étude de cas.

J'ai posté la demande sur le forum pour que le plus grand nombre
profite de la réponse mais sans succès depuis depuis mai.

Est-ce qu'une personne aurait une solution ?
https://forum.openstreetmap.fr/viewtopic.php?f=5=7400
--
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma
brièveté.

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


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

[Talk-es] Nuevos roles para las relaciones tipo ruta (route)

[bobeeeze]

Ayer leí [1] que habían sido aprovada una propuesta de nuevos roles para los 
miembros de las relaciones tipo rutas (type=route), tanto las de senderismo 
como las de bicicletas, a caballo, etc...
Eso permitira describir de manera más precisa las rutas mapeadas. No lo he 
probado todavía ni sé si están incluidos ya en JOSM. Si alguien tiene más 
información sobre este tema, se agradecería leerlo por aquí.
Un saludo

[1] 
https://wiki.openstreetmap.org/wiki/Proposed_features/Recreational_route_relation_roles

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

Re: [talk-ph] Filipino speakers at State of the Map 2020

[Eugene Alvin Villar]

Hello all,

In addition to the regular talks and presentation for State of the Map, we
also have the following people who are submitting lightning talks:

1. David Garcia - Nurturing a Ministry of Mapping
2. Andi Tabinas - Uses of Mapping for Community Care During the Pandemic
3. Arnalie Vicario - GeoLadies PH

You can see a description of their talks here:
https://wiki.openstreetmap.org/wiki/State_of_the_Map_2020/registration_lightning_talks

The final schedule for the lightning talks (the order and on which dates)
will be posted by the SotM team shortly before the conference.

~Eugene

On Mon, Jun 29, 2020 at 5:30 PM Eugene Alvin Villar 
wrote:

> Hello all,
>
> State of the Map (SotM), which is the annual conference for and by the OSM
> community, will be happening this weekend from July 4, Saturday, to July 5,
> Sunday, online. Visit the website here: https://2020.stateofthemap.org
>
> Filipino OSM community members have been presenting or speaking at SotM
> since 2018 and 2020 is no different. Catch the following people:
>
>1. Leigh Lunas
>"Drones for Community Mapping"
>https://2020.stateofthemap.org/sessions/8JQ7PY/
>Saturday, 18:45 PHT
>
>2. Eugene Alvin Villar
>"Building Stronger Communities Together: the Local Chapters &
>Communities Working Group"
>https://2020.stateofthemap.org/sessions/DVR7ME
>Sunday, 05:30 PHT
>Note: Eugene will be presenting together with the rest of the working
>group
>
>3. Mikko Tamura
>"MAPBEKS: Mapping of HIV Facilities and LGBT spaces in the Philippines
>on OpenStreetMap"
>https://2020.stateofthemap.org/sessions/L3RTUK
>Sunday, 18:00 PHT
>
>4. Thinking Machines Data Science: Ardie Orden, Ren Avell Flores, Pia
>Faustino, Mark Steve Samson
>"Measuring OpenStreetMap building footprint completeness using human
>settlement layers"
>https://2020.stateofthemap.org/sessions/YUM9PY
>Sunday, 18:45 PHT
>Note: This is an academic paper presentation for the SotM academic
>track
>
> See you there!
>
> ~Eugene
>
>
>
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

Re: [Talk-it] Licenza cartina turistica

[Roberto Brazzelli]

Perfetto e grazie a tutti.
Ricapitolando se cito ogni fonte e non non aggiungo nulla l'opera
complessiva
è soggetta a copyright dell'autore o bisogna scrivere tipo" Edizione 2020 ©
Comune di , ,

Tutti i diritti riservati. Vietata le riproduzione senza il consenso

scritto dell'autore-editore"


Grazie

Roberto


Il giorno mar 30 giu 2020 alle ore 07:30 Maurizio Napolitano <
napoo...@gmail.com> ha scritto:

> Mi associo da quanto esposto da Luca
> Ci sono altri casi simili e fino a che si cita ogni fonte - come richiesto
> da ogni singola licenza dei dataset elencati - è tutto regolare oltre che
> essere il modo più elegante per informare chi userà la mappa e omaggiare
> chi ha raccolto i dati
> My2cents
>
> Il lun 29 giu 2020, 22:14 Luca Delucchi  ha scritto:
>
>>
>>
>> On Mon, 29 Jun 2020 at 16:52, Roberto Brazzelli 
>> wrote:
>>
>>> Ciao a tutti,
>>>
>>
>> Ciao Roberto,
>>
>>
>>> sto preparando una cartina turistica cartacea e ho dei dubbi su quale
>>> debba essere la licenza
>>> finale del mio prodotto, così costruito:
>>> - dati cartografici: dati grezzi di osm (ad accezione dell'idrografia)
>>> - idrografia: Bdtre Regione Piemonte:
>>> CCBY4.0
>>> - ombreggiatura virtuale (hillshade): Arpa Piemonte - Sfumo Europa WM:
>>> riporta qui 1) il testo di cui sotto e basta.
>>> Limitazione d'uso: Ogni iniziativa di divulgazione delle informazioni
>>> contenute nel dataset o da esso derivate (cartogrammi, relazioni, servizi
>>> informativi), dovrà sempre citare la fonte del dato originale (autori,
>>> proprietario). Per eventuali aggregazioni o rielaborazioni dei dati forniti
>>> finalizzate alla realizzazione di prodotti diversi dall'originale, pur
>>> permanendo l'obbligo di citazione della fonte, si declina ogni
>>> responsabilità.
>>>
>>>   1)
>>> http://webgis.arpa.piemonte.it/geoportalserver_arpa/catalog/search/resource/details.page?uuid=ARLPA_TO%3ASfumo_Europa_WM_2014-10-22-10%3A30=Arpa%20Piemonte%20-%20Sfumo%20Europa%20WM
>>>
>>>
>>> Il mio è un prodotto derivato costruito con 3 dataset opensource,
>>> ovviamente riporto i crediti di tutti e tre ma ho dei dubbi sull'opera
>>> derivata
>>>
>>> personalmente vedendo le licenze dei dataset che utilizzi non mi
>> preoccuperei molto, una volta che citi le sorgenti dei dati stai
>> rispettando le loro licenze perciò puoi scegliere che licenza utilizzare
>> per il tuo lavoro.
>>
>> Per avere una risposta certa dovresti sentire un legale specializzato in
>> questo settore.
>>
>> Ma te che dubbi hai?
>>
>>
>>> Grazie
>>>
>>> Roberto
>>>
>>>
>> --
>> ciao
>> Luca
>>
>> www.lucadelu.org
>> ___
>> 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] Aiuto query overpass-turbo

[Martin Koppenhoefer]

Am Mo., 29. Juni 2020 um 13:58 Uhr schrieb Manuel :

> Sono d'accordo sul parco, ma per il resto l'uso di un landuse che
> comprenda tutta la zona residenziale del paese è molto esteso (anche in
> Germania - che spesso è presa a esempio - l'uso del landuse=residential è
> fatto in modo simile - es. la zona residenziale di Heidelberg
> ).
>



infatti, sto cercando di convincere anche i tedeschi ;-)

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

Re: [OSM-talk-fr] Noms des quartiers en ville

[osm . sanspourriel]

Le 30/06/2020 à 09:40, Yves P. - yves.prat...@gmail.com a écrit :


Si oui, faut-il créer un place=hamlet "Les Sieyes" qui est le
quartier du lieu correspondant à la position donnée ?

Peut-être ?


En tous cas pas des isolated_dweling comme ici :
https://overpass-turbo.eu/s/VBo

On devrait faire des requêtes pour vérifier l'absence de bâtiments
nombreux autour !


Le problème est que nous définissions les lieux-dit, hameaux,
quartiers dans OSM sous forme de noeuds.

Pour régler ce problème il faudrait définir un polygone, que nous
n'avons presque jamais concernant les lieux dits


Mais quand on l'a il faut le faire.


Le 30/06/2020 à 10:04, Christian Quest - cqu...@openstreetmap.fr a écrit :

Ce défaut disparaît-il quand on définit le hameau en surfacique plutôt
qu'avec un unique noeud ?


La réponse est non par contre on a des arguments pour demander à
Nominatim de ne pas retourner un tel résultat.

Exemple assez fort de café :

https://www.openstreetmap.org/search?query=jardins%20de%20vitalis%2C%20guidel#map=18/47.78742/-3.48546

2 réponses : le lotissement en question (bien) et une piscine en dehors
qui ne porte pas de nom ni d'adresse !

Arnaud, ici c'est un neighbourhood, pas un hamlet donc déjà testé ;-).

Jean-Yvon




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

Re: [OSM-talk-fr] Noms des quartiers en ville

[Arnaud Champollion]

Le 30/06/2020 à 10:04, Christian Quest a écrit :

Ce défaut disparaît-il quand on définit le hameau en surfacique plutôt 
qu'avec un unique noeud ?


Je peux tester ça quand j'ai un moment.

Ou plutôt le passer en neighbourhood, ce qui correspondrait à la réalité 
(car il s'agit bien d'un quartier et non d'un hameau) ?



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

Re: [Talk-GB] "secret" site

[Steve Doerr]

On 29/06/2020 22:56, Colin Smale wrote:
It was completed in 1964 as the GPO Tower. The GPO became the Post 
Office in 1969, at which time the tower was also renamed.


I stand corrected - partially. It seems to have been referred to in 
pariament as the Post Office Tower as early as 1963: https://bit.ly/2ZkUVah


--
Steve

--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Re: [OSM-talk-fr] Noms des quartiers en ville

[Christian Quest]

C'est malheureusement la logique de fonctionnement de nominatim qui 
cherche à hiérarchiser toute la toponymie.


On a du coup parfois à des niveaux intermédiaires des toponymes 
inadaptés, uniquement par la proximité.


Un chemin près d'un hameau se retrouve rattaché même si il n'en fait pas 
partie.


Très difficile à changer sans revoir l'ensemble de la logique de 
nominatim qui doit surtout s'adapter à des densités très variables 
d'infos dans OSM. En France, nous avons l'ensemble des limites 
administratives et donc à ce niveau on peut raisonner par zonage, mais 
c'est loin d'être le cas partout dans le monde.


Ce défaut disparaît-il quand on définit le hameau en surfacique plutôt 
qu'avec un unique noeud ?



Le 30/06/2020 à 07:53, Arnaud Champollion a écrit :

Bonjour,

Je viens de constater un phénomène en partageant une adresse avec 
l'application Osmand.


Quand on sélectionne cette position :
https://www.openstreetmap.org/?mlat=44.08165=6.20359#map=19/44.08165/6.20359 



on obtient le libellé suivant :

Chemin des Gravas (Le Plan de Gaubert) 14, Digne-les-Bains
Position: geo:44.081646,6.20359?z=19
https://osmand.net/go?lat=44.081646=6.20359=19

Je m'interroge sur "Le Plan de Gaubert" qui est certes un quartier de 
la ville, mais pas le bon. Il en est même relativement éloigné du 
point de vue de l'organisation de la ville, même si proche à vol 
d'oiseau.


Est-ce parce-que "Le Plan de Gaubert" est le place=hamlet le plus 
proche ?


Si oui, faut-il créer un place=hamlet "Les Sieyes" qui est le quartier 
du lieu correspondant à la position donnée ?


Et comment limiter la "portée" d'un place=hamlet pour qu'il ne soit 
pas pris en compte par défaut dans d'autres parties de la ville qui en 
sont dépourvues ?


Merci

Arnaud


--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Noms des quartiers en ville

[Yves P.]

Pour répondre directement à ta question :)

> Est-ce parce-que "Le Plan de Gaubert" est le place=hamlet le plus proche ?
Oui

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

> 
> Si oui, faut-il créer un place=hamlet "Les Sieyes" qui est le quartier du 
> lieu correspondant à la position donnée ?
Peut-être ?

> Et comment limiter la "portée" d'un place=hamlet pour qu'il ne soit pas pris 
> en compte par défaut dans d'autres parties de la ville qui en sont dépourvues 
> ?
Le problème est que nous définissions les lieux-dit, hameaux, quartiers dans 
OSM sous forme de noeuds.

Pour régler ce problème il faudrait définir un polygone, que nous n'avons 
presque jamais concernant les lieux dits/

L'autre solution serait d'avoir un formatage "régional" (pays par pays) cf. mon 
mél précédent.

Un formatage house_number + road + ',' + postcode + town + ',' + country 
fonctionne bien en ville en France.
Mais pas pour une adresse pour un hameau…

A creuser

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

Re: [OSM-talk-fr] Noms des quartiers en ville

[Yves P.]

> OsmAnd se base sur la proximité géographique d'autres objets pour déterminer 
> une adresse à partir d'une coordonnée de ce que j'ai pu comprendre, ce qui 
> donne souvent des résultats incorrectes.
Je ne sais pas si OsmAnd utilise Nominatim.

En tout cas, si tu cherches 14 Chemin des Gravas 

 dans OSM, il te retourne :
14, Chemin des Gravas, Le Plan de Gaubert, Digne-les-Bains, 
Alpes-de-Haute-Provence, Provence-Alpes-Côte d'Azur, France métropolitaine, 
04000, France

C'est un problème de Nominatim qui ne dit pas tout simplement "14, Chemin des 
Gravas, 04000 Digne-les-Bains, France"

J'avais demandé il y a quelques années aux développeurs de mettre un formatage 
par pays pour éviter ce problème, sans résultat :/

__
Yves

Photon ne renvoi pas d'adresse complète mais si tu mets bout à bout les valeurs 
retournées, l'adresse est bonne :
http://photon.komoot.de/api/?q=14+Chemin+des+Gravas
{
  "features": [
{
  "geometry": {
"coordinates": [
  6.2036739,
  44.0816309
],
"type": "Point"
  },
  "type": "Feature",
  "properties": {
"osm_id": 5498485824,
"osm_type": "N",
"country": "France",
"osm_key": "place",
"housenumber": "14",
"city": "Digne-les-Bains",
"street": "Chemin des Gravas",
"osm_value": "house",
"postcode": "04000",
"state": "Provence-Alpes-Côte d'Azur"
  }
}
  ],
  "type": "FeatureCollection"
}

En appelant l'API Nominatim et en lui demandant explicitement de détailler 
l'adresse on obtient :
https://nominatim.openstreetmap.org/search?q=14+Chemin+des+Gravas=json=1
[
  {
"place_id": 64039962,
"licence": "Data © OpenStreetMap contributors, ODbL 1.0. 
https://osm.org/copyright;,
"osm_type": "node",
"osm_id": 5498485824,
"boundingbox": [
  "44.0815809",
  "44.0816809",
  "6.2036239",
  "6.2037239"
],
"lat": "44.0816309",
"lon": "6.2036739",
"display_name": "14, Chemin des Gravas, Le Plan de Gaubert, 
Digne-les-Bains, Alpes-de-Haute-Provence, Provence-Alpes-Côte d'Azur, France 
métropolitaine, 04000, France",
"class": "place",
"type": "house",
"importance": 0.411,
"address": {
  "house_number": "14",
  "road": "Chemin des Gravas",
  "hamlet": "Le Plan de Gaubert",
  "town": "Digne-les-Bains",
  "municipality": "Digne-les-Bains",
  "county": "Alpes-de-Haute-Provence",
  "state": "Provence-Alpes-Côte d'Azur",
  "country": "France",
  "postcode": "04000",
  "country_code": "fr"
}
  }
]
En ne gardant que les champs house_number, road, town, postcode, country 
l'adresse "à la française" est correcte.

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

[talk-ph] Rollback of admin boundary edits in the Philippines due to incompatible license (was Re: Alaminos Barangay borders)

[maning sambale]

Hi Everyone,

After reviewing the edits and communicating with the mapper, we
decided to roll-back all edits related to this issue due to
incompatible source.
We plan to do this as a local community.  Please see the plane here
for comments and suggestions:
https://github.com/OSMPH/papercut_fix/issues/67

cc'ed here is OpenStreetMap Foundation's Data Working Group for guidance.

On Fri, Jun 26, 2020 at 4:39 PM Erwin Olario  wrote:
>
>
> Glen, thank you for the heads up! Boundaries are great to have, but I'll also 
> look into the affected changesets, and reach out to the contributor
>
> Are you still in Pangasinan? Stay healthy and safe.
>
> /erwin
>
> - - - - - - - - - - - - - - - - - - -
> » email: er...@ngnuity.xyz | gov...@gmail.com
> » mobile: https://t.me/GOwin
> » OpenPGP key: 3A93D56B | 5D42 7CCB 8827 9046 1ACB 0B94 63A4 81CE 3A93 D56B
>
>
> On Fri, Jun 26, 2020 at 2:21 PM Glen Scott  wrote:
>>
>> Hi PH mapping folks,
>> I was just in a boring online meeting and had a chance to look at OSM (been 
>> too busy to get to it for a while).  I noticed Barangay borders have been 
>> added to Alaminos (and between Alaminos and other Pangasinan cities), yet 
>> these are radically different to either Alaminos Town Hall maps or the 
>> Cadastal survey map set I got from DENR.
>>
>> The borders were added by VMPanes, I'll try to contact VMPanes to establish 
>> the basis of the borders. I think that no borders is better than incorrect 
>> borders, unfortunately I haven't had the time to stitch the cadastral set 
>> together in electronic format to arrive at a more accurate border than the 
>> Alaminos City Hall map, which is at quite a small scale.
>>
>> Cheers
>> Glen
>>
>>
>> ___
>> talk-ph mailing list
>> talk-ph@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ph
>
> ___
> talk-ph mailing list
> talk-ph@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ph



-- 
cheers,
maning
--
"Freedom is still the most radical idea of all" -N.Branden
https://github.com/maning
http://twitter.com/maningsambale
--

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

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

[Yves P.]

> Yves : en France on veut l'unicité des points adresse.
> 
Oui, et je suis d'accord avec ça.

L'idée de Florian est bonne, le résultat risque de l'être moins (cf. ton 
explication et celle de Jérôme).

Par rapport au cas du ciné sur le bâtiment, je règle le problème en séparant le 
POI (ici le ciné) du bâtiment :
Je met un noeud pour le POI vers son entrée, et laisse building=*, 
source=cadastre… sur le polygone.

Pour le moment je fais ça manuellement.

Je viens de regarder, d'après TagInfo FR, il y a 676 chemins et 9 relations 
 avec 
amenity=cinema.

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

Re: [OSM-talk-fr] Noms des quartiers en ville

[Topographe Fou]

Vue la carte je doute que le Plan de Gaubert soit un hameau, cela m'a tout 
l'air d'un quartier et dans ce cas on utilise au maximum place=suburb (ou 
quarter ou neighboroud si pertinent).

Si il y a un quartier qui s'appelle Les Sieyes alors il mérite son propre noeud 
(ou way s'il y a une limite officielle).

OsmAnd se base sur la proximité géographique d'autres objets pour déterminer 
une adresse à partir d'une coordonnée de ce que j'ai pu comprendre, ce qui 
donne souvent des résultats incorrectes.

LeTopographeFou


  Message original  


De: arnaud.champoll...@linux-alpes.org
Envoyé: 30 juin 2020 7:54 AM
À: talk-fr@openstreetmap.org
Répondre à: talk-fr@openstreetmap.org
Objet: [OSM-talk-fr] Noms des quartiers en ville


Bonjour,

Je viens de constater un phénomène en partageant une adresse avec
l'application Osmand.

Quand on sélectionne cette position :
https://www.openstreetmap.org/?mlat=44.08165=6.20359#map=19/44.08165/6.20359

on obtient le libellé suivant :

Chemin des Gravas (Le Plan de Gaubert) 14, Digne-les-Bains
Position: geo:44.081646,6.20359?z=19
https://osmand.net/go?lat=44.081646=6.20359=19

Je m'interroge sur "Le Plan de Gaubert" qui est certes un quartier de la
ville, mais pas le bon. Il en est même relativement éloigné du point de
vue de l'organisation de la ville, même si proche à vol d'oiseau.

Est-ce parce-que "Le Plan de Gaubert" est le place=hamlet le plus proche ?

Si oui, faut-il créer un place=hamlet "Les Sieyes" qui est le quartier
du lieu correspondant à la position donnée ?

Et comment limiter la "portée" d'un place=hamlet pour qu'il ne soit pas
pris en compte par défaut dans d'autres parties de la ville qui en sont
dépourvues ?

Merci

Arnaud




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