Re: [Talk-us] United States Bicycle Route System ballot(s) pending AASHTO approval

[stevea]

Thanks, Richard.  That's valuable input and I've updated the USBRS wiki, which 
effectively puts the (informal) proposal for 
proposed:route=bicycle into a sort of stalemate.

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

Re: [Talk-it] Way Marked Trails - Download GPX - Altitudine

[Danilo via Talk-it]

I gpx generati e utilizzati dalle app "moderne" non contengono la quota perché esistono i file DEM utilizzabili appunto dalle app per generare il profilo altimetrico. Waymarked Trail opera in tal senso.DaniloIl 24 Set 2020 21:27, mich...@michelevicario.net ha scritto:


Grazie della risposta.Ho posto male la domanda, la rifaccio:Su Way 
Marked Trails ho provato a scaricare alcune tracce GPX, ma l’altitudine 
visualizzata nel profilo altimetrico non viene esportata, come mai?
 
-Messaggio originale- Date: Thu, 24 Sep 2020 16:07:24 
+0200From: emmexx To: 
openstreetmap list - italiano Subject: 
Re: [Talk-it] Way Marked Trails - Download GPX - AltitudineMessage-ID: 
<9f787330-0fdb-76ed-be90-faf5b65ecf96@tiscalinet.it">9f787330-0fdb-76ed-be90-faf5b65ecf96@tiscalinet.it>Content-Type: 
text/plain; charset=utf-8
 
On 9/24/20 1:15 PM, michele@michelevicario.net 
wrote:> Su Way Marked Trails, i sentieri di montagna hanno il 
profilo> altimetrico, ho provato a scaricare alcune tracce GPX, ma 
l’altitudine> non viene esportata, c’è un modo per farlo?
 
https://www.gpsvisualizer.com/elevation
 
ciao
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-us] [Tagging] Large fire perimeter tagging?

[stevea]

Clifford Snow  wrote:
> Just a reminder, landuse is to tag what the land is used for. landuse=forest 
> is for areas that have harvestable wood products, ie trees. Just because 
> there was a fire doesn't mean the landuse changes. Landcover is a better tag 
> for burnt areas as well as areas just clearcut.

This thread likely shouldn't have been cross-posted by me to talk-us and is now 
(substantially) continued at the tagging list.
SteveA
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Tagging] Large fire perimeter tagging?

[Clifford Snow]

Steve,
Just a reminder, landuse is to tag what the land is used for.
landuse=forest is for areas that have harvestable wood products, ie trees.
Just because there was a fire doesn't mean the landuse changes. Landcover
is a better tag for burnt areas as well as areas just clearcut.



On Thu, Sep 24, 2020 at 2:31 PM stevea  wrote:

> I didn't get a single reply on this (see below), which I find surprising,
> especially as there are currently even larger fires that are more
> widespread all across the Western United States.
>
> I now ask if there are additional, appropriate polygons with tags I'm not
> familiar with regarding landcover that might be added to the map (as
> "landuse=forest" might be strictly true now only in a 'zoning' sense, as
> many of the actual trees that MAKE these forests have sadly burned down, or
> substantially so).
>
> Considering that there are literally millions and millions of acres of
> (newly) burned areas (forest, scrub, grassland, residential, commercial,
> industrial, public, private...), I'm surprised that OSM doesn't have some
> well-pondered and actual tags that reflect this situation.  My initial
> tagging of this (simply tagged, but enormous) polygon as "fire=perimeter"
> was coined on my part, but as I search wiki, taginfo and Overpass Turbo
> queries for similar data in the map, I come up empty.
>
> First, do others think it is important that we map these?  I say yes, as
> this fire has absolutely enormous impact to what we do and might map here,
> both present and future.  The aftermath of this fire (>85,000 acres this
> fire alone) will last for decades, and for OSM to not reflect this in the
> map (somehow, better bolstered than a simple, though huge, polygon tagged
> with fire=perimeter, start_date and end_date) seems OSM "cartographically
> misses something."  I know that HOT mappers map the "present- and
> aftermath-" of humanitarian disasters, I've HOT-participated myself.  So,
> considering the thousands of structures that burned (most of them homes),
> tens of thousands of acres which are burn-scarred and distinctly different
> than their landcover, millions of trees (yes, really) and even landuse is
> now currently tagged, I look for guidance — beyond the simple tag of
> fire=perimeter on a large polygon.
>
> Second, if we do choose to "better" map these incidents and results (they
> are life- and planet-altering on a grand scale) how might we choose to do
> that?  Do we have landcover tags which could replace landuse=forest or
> natural=wood with something like natural=fire_scarred?  (I'm making that
> up, but it or something like it could work).  How and when might we replace
> these with something less severe?  On the other hand, if it isn't
> appropriate that we map any of this, please say so.
>
> Thank you, especially any guidance offered from HOT contributors who have
> worked on post-fire humanitarian disasters,
>
> SteveA
> California (who has returned home after evacuation, relatively safe now
> that this fire is 100% contained)
>
>
> On Aug 29, 2020, at 7:20 PM, stevea  wrote:
> > Not sure if crossposting to talk-us is correct, but it is a "home list"
> for me.
> >
> > I've created a large fire perimeter in OSM from public sources,
> http://www.osm.org/way/842280873 .  This is a huge fire (sadly, there are
> larger ones right now, too), over 130 square miles, and caused the
> evacuation of every third person in my county (yes).  There are hundreds,
> perhaps thousands of structures, mostly residential homes, which have
> burned down and the event has "completely changed" giant redwoods in and
> the character of California's oldest state park (Big Basin).
> >
> > This perimeter significantly affects landuse, landcover and human
> patterns of movement and activity in this part of the world for a
> significant time to come.  It is a "major disaster."  I'm curious how HOT
> teams might delineate such a thing (and I've participated in a HOT fire
> team, mapping barns, water sources for helicopter dips and other human
> structures during a large fire near me), I've simply made a polygon tagged
> fire=perimeter, a name=* tag and a start_date.  I don't expect rendering,
> it's meant to be an "up to right about here" (inside the polygon is/was a
> burning fire, outside was no fire).  I wouldn't say it is more accurate
> than 20 to 50 meters on any edge, an "across a wide street" distance to be
> "off" is OK with me, considering this fire's size, but if a slight skew
> jiggles the whole thing into place better, feel free to nudge.  It's the
> tagging I'm interested in getting right, and perhaps wondering if or even
> that people enter gigantic fires that will significantly change landscape
> for some time into OSM, as I have done.  This will affect my local mapping,
> as a great much has burned.  Even after starting almost two weeks ago, as
> of 20 minutes ago this fire is 33% contained, with good, steady progress.
> These men and women are heroes.
> >
> > 

Re: [Talk-it] Way Marked Trails - Download GPX - Altitudine

[Ivo Reano]

No. Per me è una scelta corretta.
Il dislivello calcolato sui DTM è sempre da prendere con cautela.
Certo, su un percorso di costa, può essere molto vicino alla realtà, ma se
hai dei traversi l'errore può essere enorme.
Ho esperienza di anelli studiati a tavolino dove avrei fatto un dislivello
pazzesco, mentre in realtà è stato spesso vicino alla mera differenza tra
punto più basso e più alto.


Il gio 24 set 2020, 22:41  ha scritto:

> Sì, avevo capito che in Way Marked Trails il tag ele non viene considerato
> e l’altimetria viene calcolata in altro modi, infatti qui viene descritto:
> https://hiking.waymarkedtrails.org/help/rendering/elevationprofiles
>
> Mi chiedevo semplicemente perché Way Marked Trails esegue un calcolo, la
> fa vedere, ma poi non lo esporta in GPX
> Way Marked Trails mette in guardia e descrive i limiti e le
> approssimazioni del calcolo ma dice anche che è abbastanza valido, ma alla
> fine non lo esporta... appare un po’ strano, secondo te non è un bug?.
>
> *From:* Ivo Reano
> *Sent:* Thursday, September 24, 2020 9:58 PM
> *To:* openstreetmap list - italiano
> *Subject:* Re: [Talk-it] Way Marked Trails - Download GPX - Altitudine
>
>
>
> Il giorno gio 24 set 2020 alle ore 21:28  ha
> scritto:
>
>> Grazie della risposta.
>> Ho posto male la domanda, la rifaccio:
>> Su Way Marked Trails ho provato a scaricare alcune tracce GPX, ma
>> l’altitudine visualizzata nel profilo altimetrico non viene esportata, come
>> mai?
>>
>
> Credo semplicemente che non sia previsto.
> L'altimetria è ottenuta da un layer di terze parti. Nel senso che su OSM i
> dati altimetrici non sono presenti.
> Ok. Esiste il tag ele. ma chi lo prende in considerazione? Utile per punti
> particolari come cime e valichi.
> Ma ti assicuro che i dati da altimetrici di un gps sono spettacolarmente
> relativi. Se ti fidi puoi considerarli, ma sono troppe le variabili che lo
> rendono un dato non replicabile.
> E se non lo puoi replicare...
>
>
> --
> ___
> 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-us] Large fire perimeter tagging?

[stevea]

I didn't get a single reply on this (see below), which I find surprising, 
especially as there are currently even larger fires that are more widespread 
all across the Western United States.

I now ask if there are additional, appropriate polygons with tags I'm not 
familiar with regarding landcover that might be added to the map (as 
"landuse=forest" might be strictly true now only in a 'zoning' sense, as many 
of the actual trees that MAKE these forests have sadly burned down, or 
substantially so).

Considering that there are literally millions and millions of acres of (newly) 
burned areas (forest, scrub, grassland, residential, commercial, industrial, 
public, private...), I'm surprised that OSM doesn't have some well-pondered and 
actual tags that reflect this situation.  My initial tagging of this (simply 
tagged, but enormous) polygon as "fire=perimeter" was coined on my part, but as 
I search wiki, taginfo and Overpass Turbo queries for similar data in the map, 
I come up empty.

First, do others think it is important that we map these?  I say yes, as this 
fire has absolutely enormous impact to what we do and might map here, both 
present and future.  The aftermath of this fire (>85,000 acres this fire alone) 
will last for decades, and for OSM to not reflect this in the map (somehow, 
better bolstered than a simple, though huge, polygon tagged with 
fire=perimeter, start_date and end_date) seems OSM "cartographically misses 
something."  I know that HOT mappers map the "present- and aftermath-" of 
humanitarian disasters, I've HOT-participated myself.  So, considering the 
thousands of structures that burned (most of them homes), tens of thousands of 
acres which are burn-scarred and distinctly different than their landcover, 
millions of trees (yes, really) and even landuse is now currently tagged, I 
look for guidance — beyond the simple tag of fire=perimeter on a large polygon.

Second, if we do choose to "better" map these incidents and results (they are 
life- and planet-altering on a grand scale) how might we choose to do that?  Do 
we have landcover tags which could replace landuse=forest or natural=wood with 
something like natural=fire_scarred?  (I'm making that up, but it or something 
like it could work).  How and when might we replace these with something less 
severe?  On the other hand, if it isn't appropriate that we map any of this, 
please say so.

Thank you, especially any guidance offered from HOT contributors who have 
worked on post-fire humanitarian disasters,

SteveA
California (who has returned home after evacuation, relatively safe now that 
this fire is 100% contained)


On Aug 29, 2020, at 7:20 PM, stevea  wrote:
> Not sure if crossposting to talk-us is correct, but it is a "home list" for 
> me.
> 
> I've created a large fire perimeter in OSM from public sources, 
> http://www.osm.org/way/842280873 .  This is a huge fire (sadly, there are 
> larger ones right now, too), over 130 square miles, and caused the evacuation 
> of every third person in my county (yes).  There are hundreds, perhaps 
> thousands of structures, mostly residential homes, which have burned down and 
> the event has "completely changed" giant redwoods in and the character of 
> California's oldest state park (Big Basin).
> 
> This perimeter significantly affects landuse, landcover and human patterns of 
> movement and activity in this part of the world for a significant time to 
> come.  It is a "major disaster."  I'm curious how HOT teams might delineate 
> such a thing (and I've participated in a HOT fire team, mapping barns, water 
> sources for helicopter dips and other human structures during a large fire 
> near me), I've simply made a polygon tagged fire=perimeter, a name=* tag and 
> a start_date.  I don't expect rendering, it's meant to be an "up to right 
> about here" (inside the polygon is/was a burning fire, outside was no fire).  
> I wouldn't say it is more accurate than 20 to 50 meters on any edge, an 
> "across a wide street" distance to be "off" is OK with me, considering this 
> fire's size, but if a slight skew jiggles the whole thing into place better, 
> feel free to nudge.  It's the tagging I'm interested in getting right, and 
> perhaps wondering if or even that people enter gigantic fires that will 
> significantly change landscape for some time into OSM, as I have done.  This 
> will affect my local mapping, as a great much has burned.  Even after 
> starting almost two weeks ago, as of 20 minutes ago this fire is 33% 
> contained, with good, steady progress.  These men and women are heroes.
> 
> To me, this is a significant polygon in my local mapping:  it is a "huge 
> thing" that is a major feature on a map, especially right now.  I firmly 
> believe it belongs in OSM for many reasons and want it tagged "correctly."  
> Yes, there are other maps that show this, I believe OSM should have these 
> data, too, as this perimeter will affect much (in the real world) and 

Re: [Talk-it] Way Marked Trails - Download GPX - Altitudine

[michele]

Sì, avevo capito che in Way Marked Trails il tag ele non viene considerato e 
l’altimetria viene calcolata in altro modi, infatti qui viene descritto:
https://hiking.waymarkedtrails.org/help/rendering/elevationprofiles

Mi chiedevo semplicemente perché Way Marked Trails esegue un calcolo, la fa 
vedere, ma poi non lo esporta in GPX 
Way Marked Trails mette in guardia e descrive i limiti e le approssimazioni del 
calcolo ma dice anche che è abbastanza valido, ma alla fine non lo esporta... 
appare un po’ strano, secondo te non è un bug?.
From: Ivo Reano 
Sent: Thursday, September 24, 2020 9:58 PM
To: openstreetmap list - italiano 
Subject: Re: [Talk-it] Way Marked Trails - Download GPX - Altitudine



Il giorno gio 24 set 2020 alle ore 21:28  ha 
scritto:

  Grazie della risposta.
  Ho posto male la domanda, la rifaccio:
  Su Way Marked Trails ho provato a scaricare alcune tracce GPX, ma 
l’altitudine visualizzata nel profilo altimetrico non viene esportata, come mai?

Credo semplicemente che non sia previsto.
L'altimetria è ottenuta da un layer di terze parti. Nel senso che su OSM i dati 
altimetrici non sono presenti.
Ok. Esiste il tag ele. ma chi lo prende in considerazione? Utile per punti 
particolari come cime e valichi.
Ma ti assicuro che i dati da altimetrici di un gps sono spettacolarmente 
relativi. Se ti fidi puoi considerarli, ma sono troppe le variabili che lo 
rendono un dato non replicabile.
E se non lo puoi replicare...




___
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] Regione geografica italiana

[Ivo Reano]

Sono andato a tradurre la frase. Non perché non mi fidi della tua
traduzione, ma proprio perchè sono un dog in inglese.
Google traslator, da inglese a italiano:
> La "regione geografica d'Italia" è nel migliore dei casi un confine
storico mal definito (che non mappiamo), e nel peggiore dei casi una
fantasia politica di destra.>
Che sembra scritto da uno che nel suo parlamento fa sedere alla destra i
conservatori o i nazionalisti (o nostalgici, in Italia)
Fosse un americano non userebbe la direzione (o almeno credo).

Sciocchezzuole dialettiche a parte il succo è, a mio parere, correttissimo.
Per un animo sentimental/anarchico la discussione sarebbe se sono valide le
frontiere politiche, pardon amministrative, che sono presenti in OSM.
Il mio un animo umanitario mi dice: che stupidaggini!

Ivo

Il giorno gio 24 set 2020 alle ore 21:59 Alessandro Barbieri <
lssndrbarbi...@gmail.com> ha scritto:

> Il 15/09/20 09:36, totera ha scritto:
>
> Ciao a tutti,
> ricordate la discussione sulla regione geografica italiana [1]?
>
> Ieri Frederik Ramm del DWG ha cancellato la relazione [2], immagino su
> segnalazione di chi vede in essa una rivendicazione territoriale,
> invitandoci comunque a parlarne in lista.
>
> Come ho provato a spiegargli nel commento, a mio avviso si tratta di una
> definizione geografica ampiamente diffusa, che ricordo di aver trovato su
> diversi testi di geografia, di storia, enciclopedie, ecc.
>
> Con essa si intende il territorio a sud dell'arco alpino, che non coincide
> esattamente con i confini italiani (né attuali, né passati), né con le
> rivendicazioni degli irredentisti, che erano basate su considerazioni
> etnolinguistiche e quindi comprendevano anche territori esterni come la
> Dalmazia.
>
> Ciao,
> Gianluca
>
> [1] 
> =https://lists.openstreetmap.org/pipermail/talk-it/2017-October/060515.html
> [2] = https://www.openstreetmap.org/changeset/90871685
>
> Sono stato invitato ad esprimere il mio punto di vista anche in lista,
> eccomi qui.
>
> Questo è il suo commento:
>
> The "geographic region of Italy" is at best an ill-defined historic
> boundary (which we don't map), and at worst a right-wing political fantasy. I
> am removing this with my DWG hat on.
>
> Sono d'accordo sulla prima parte: non c'è posto in OSM per cose mal
> definite come le regioni geografiche mentre temo che sia stata rimossa per
> un motivo politico (dovremmo anche tenere la politica lontana da OSM).
> ___
> 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] Regione geografica italiana

[Alessandro Barbieri]

Il 15/09/20 09:36, totera ha scritto:
> Ciao a tutti,
> ricordate la discussione sulla regione geografica italiana [1]?
>
> Ieri Frederik Ramm del DWG ha cancellato la relazione [2], immagino su
> segnalazione di chi vede in essa una rivendicazione territoriale,
> invitandoci comunque a parlarne in lista.
>
> Come ho provato a spiegargli nel commento, a mio avviso si tratta di una
> definizione geografica ampiamente diffusa, che ricordo di aver trovato su
> diversi testi di geografia, di storia, enciclopedie, ecc.
>
> Con essa si intende il territorio a sud dell'arco alpino, che non coincide
> esattamente con i confini italiani (né attuali, né passati), né con le
> rivendicazioni degli irredentisti, che erano basate su considerazioni
> etnolinguistiche e quindi comprendevano anche territori esterni come la
> Dalmazia.
>
> Ciao,
> Gianluca
>
> [1] =
> https://lists.openstreetmap.org/pipermail/talk-it/2017-October/060515.html
> [2] = https://www.openstreetmap.org/changeset/90871685

Sono stato invitato ad esprimere il mio punto di vista anche in lista,
eccomi qui.

Questo è il suo commento:

>
> The "geographic region of Italy" is at best an ill-defined
> historic boundary (which we don't map), and at worst a
> right-wing political fantasy.
>
>
> I am removing this with my DWG hat on.
>
Sono d'accordo sulla prima parte: non c'è posto in OSM per cose mal
definite come le regioni geografiche mentre temo che sia stata rimossa
per un motivo politico (dovremmo anche tenere la politica lontana da OSM).
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Way Marked Trails - Download GPX - Altitudine

[Ivo Reano]

Il giorno gio 24 set 2020 alle ore 21:28  ha
scritto:

> Grazie della risposta.
> Ho posto male la domanda, la rifaccio:
> Su Way Marked Trails ho provato a scaricare alcune tracce GPX, ma
> l’altitudine visualizzata nel profilo altimetrico non viene esportata, come
> mai?
>

Credo semplicemente che non sia previsto.
L'altimetria è ottenuta da un layer di terze parti. Nel senso che su OSM i
dati altimetrici non sono presenti.
Ok. Esiste il tag ele. ma chi lo prende in considerazione? Utile per punti
particolari come cime e valichi.
Ma ti assicuro che i dati da altimetrici di un gps sono spettacolarmente
relativi. Se ti fidi puoi considerarli, ma sono troppe le variabili che lo
rendono un dato non replicabile.
E se non lo puoi replicare...
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Regione geografica italiana

[Ivo Reano]

Grazie Martin, per la precisazione.
Il senso spero si sia capito!

Il giorno gio 24 set 2020 alle ore 21:33 Martin Koppenhoefer <
dieterdre...@gmail.com> ha scritto:

>
>
> sent from a phone
>
> On 24. Sep 2020, at 21:04, Ivo Reano  wrote:
>
> Propongo la cancellazione del dato.
>
>
>
> Ivo, la relazione è già stato cancellato 10 giorni fa dal DWG, qui siamo
> discutendo di lasciarla cancellata ;)
> https://www.openstreetmap.org/changeset/90871685#map=4/41.60/12.67
>
> Ciao Martin
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Regione geografica italiana

[Martin Koppenhoefer]

sent from a phone

> On 24. Sep 2020, at 21:04, Ivo Reano  wrote:
> 
> Propongo la cancellazione del dato.


Ivo, la relazione è già stato cancellato 10 giorni fa dal DWG, qui siamo 
discutendo di lasciarla cancellata ;)
https://www.openstreetmap.org/changeset/90871685#map=4/41.60/12.67

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

Re: [Talk-it] Regione geografica italiana

[Martin Koppenhoefer]

sent from a phone

> On 24. Sep 2020, at 20:53, Ivo Reano  wrote:
> 
> Lo spartiacque alpino ha un senso geografico.
> La "Regione geografica italiana" no.


+1, non si può chiamare la zona “italiana“, e pretendere che sia unicamente 
geografica invece di politica.

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

Re: [Talk-it] Way Marked Trails - Download GPX - Altitudine

[michele]

Grazie della risposta.
Ho posto male la domanda, la rifaccio:
Su Way Marked Trails ho provato a scaricare alcune tracce GPX, ma l’altitudine 
visualizzata nel profilo altimetrico non viene esportata, come mai?


-Messaggio originale- 
Date: Thu, 24 Sep 2020 16:07:24 +0200
From: emmexx 
To: openstreetmap list - italiano 
Subject: Re: [Talk-it] Way Marked Trails - Download GPX - Altitudine
Message-ID: <9f787330-0fdb-76ed-be90-faf5b65ec...@tiscalinet.it>
Content-Type: text/plain; charset=utf-8

On 9/24/20 1:15 PM, mich...@michelevicario.net wrote:
> Su Way Marked Trails, i sentieri di montagna hanno il profilo
> altimetrico, ho provato a scaricare alcune tracce GPX, ma l’altitudine
> non viene esportata, c’è un modo per farlo?

https://www.gpsvisualizer.com/elevation

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

Re: [OSM-talk] Can you recommend good introduction to JOSM for 100% osm newbie?

[Mikel Maron via talk]

Might be a touch out of date, but useful guide to JOSM 
https://labs.mapbox.com/mapping/

* Mikel Maron * +14152835207 @mikel s:mikelmaron






On Thursday, September 24, 2020, 03:20:01 AM EDT, Maarten Deen 
 wrote: 





On 2020-09-24 08:50, Mateusz Konieczny via talk wrote:
> I looked at https://wiki.openstreetmap.org/wiki/JOSM and
> 
> https://wiki.openstreetmap.org/wiki/JOSM/Guide and
> https://learnosm.org/en/josm/
> 
> but I am not fully happy about any of them (a bit too much at one for
> someone new)
> 
> Why not iD: they want to edit and fix hiking relations, what AFAIK is
> not well supported in iD

Well, I only know the very basics in iD (and also Potlatch2). I even 
have problems putting a node because it always wants to continue to a 
way and I don't know how to stop this (believe in Potlatch2).
So every editor has a learning curve, even the ones that are supposed to 
be the easy ones like iD or Potlatch2. Because I've been using JOSM for 
years, I know how to use most if not all of the functions and I shun 
away from iD or Potlatch2 just because I've never familiarized myself 
with them (I don't see the need because they lack the features of JOSM).

I don't see what is "much" about 
https://wiki.openstreetmap.org/wiki/JOSM/Guide. 2 steps to start the 
program (if you have Java installed) and the basic functions are 
explained step by step.
Relations are always a more advanced topic, but I can't imagine that 
with a few days of fiddling around you don't get the hang of it.

Regards,
Maarten


___
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-fr] Maj Cadastre vectoriel

[Jérôme Seigneuret]

https://cadastre.data.gouv.fr/datasets/cadastre-etalab

Le jeu. 24 sept. 2020 à 21:03, Yves P.  a écrit :

> Il y a des fichiers geojson sur data.gouv.fr Il y a une carte des mises à
> jour et ces éléments ont été mis à disposition en juillet.
>
>
> As-tu un lien sur un exemple précis ?
>
>
> Le fichier geojson peut être chargé il me semble dans JOSM
>
>
> Oui
>
> __
> 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: [Talk-it] Regione geografica italiana

[Ivo Reano]

Il riassunto non è degno di essere presentato come prova.
Le fonti sono insufficienti per giudicare la tua proposta come accettabile.

Propongo la cancellazione del dato.

Il giorno gio 24 set 2020 alle ore 20:57 lorenzo casoli <
lollorenz...@live.it> ha scritto:

> Senta legga le fonti e la definizione che ho dato come riassunto di esse,
> mi sembrano sufficientemente chiare, più di così non saprei come potrebbero
> esserle.
> Per il resto buona serata.
>
> Il giorno 24 set 2020, alle ore 20:52, Ivo Reano  ha
> scritto:
>
>  Geograficamente, cartografica, osmericamente, storicamente, politicamente
> ed anche volgarmente sono cose non discernibili da quello che tu hai
> chiamato"Regione geografica italiana"e che ora tu chiami "Italia".
> Scusa l'Italia senza Lampedusa? Ma con dentro Malta? In quale secolo o
> spazio/tempo vivi?
>
> Lo spartiacque alpino ha un senso geografico.
> La "Regione geografica italiana" no.
>
> Il giorno gio 24 set 2020 alle ore 20:33 lorenzo casoli <
> lollorenz...@live.it> ha scritto:
>
>> Va bene, se vuole la può chiamare Italia al posto di regione geografica
>> italiana, sono sinonimi.
>>
>> Le mappe indicate sono mappe storiche nel senso che sono state realizzate
>> in un passato relativamente remoto, ma la line di spartiacque alpina rimane
>> quella, non cambia (o lo fa in minima parte).
>>
>> Il giorno 24 set 2020, alle ore 20:06, Ivo Reano  ha
>> scritto:
>>
>> Il giorno gio 24 set 2020 alle ore 20:00 lorenzo casoli <
>> lollorenz...@live.it> ha scritto:
>>
>>> Cito il mio messaggio:
>>>
>>>  "Le fonti sono varie ma rinvierei alla fonte della Treccani come
>>> principale: https://www.treccani.it/enciclopedia/italia/
>>>
>> Non vedo da nessuna parte un "Regione geografica italiana" , solo varie
>> citazioni geografiche storiche sull'Italia.
>>
>> Oppure in questo sito sono contenute mappe della deAgostini che riportano
>>> lo stesso confine Alpino:
>>> http://digitale.bnc.roma.sbn.it/mappe?paginate_pageNum=1;
>>>
>>
>> Non vado a guardarle tutte. Vedo si tratta di mappe storiche e/o politiche
>>
>> Ivo, Jrachi
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Maj Cadastre vectoriel

[Yves P.]

> Il y a des fichiers geojson sur data.gouv.fr  Il y a 
> une carte des mises à jour et ces éléments ont été mis à disposition en 
> juillet.

As-tu un lien sur un exemple précis ?


> Le fichier geojson peut être chargé il me semble dans JOSM

Oui

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

Re: [Talk-it] Regione geografica italiana

[lorenzo casoli]

Senta legga le fonti e la definizione che ho dato come riassunto di esse, mi 
sembrano sufficientemente chiare, più di così non saprei come potrebbero 
esserle.
Per il resto buona serata.

Il giorno 24 set 2020, alle ore 20:52, Ivo Reano 
mailto:reano...@gmail.com>> ha scritto:

 Geograficamente, cartografica, osmericamente, storicamente, politicamente ed 
anche volgarmente sono cose non discernibili da quello che tu hai 
chiamato"Regione geografica italiana"e che ora tu chiami "Italia".
Scusa l'Italia senza Lampedusa? Ma con dentro Malta? In quale secolo o 
spazio/tempo vivi?

Lo spartiacque alpino ha un senso geografico.
La "Regione geografica italiana" no.

Il giorno gio 24 set 2020 alle ore 20:33 lorenzo casoli 
mailto:lollorenz...@live.it>> ha scritto:
Va bene, se vuole la può chiamare Italia al posto di regione geografica 
italiana, sono sinonimi.

Le mappe indicate sono mappe storiche nel senso che sono state realizzate in un 
passato relativamente remoto, ma la line di spartiacque alpina rimane quella, 
non cambia (o lo fa in minima parte).

Il giorno 24 set 2020, alle ore 20:06, Ivo Reano 
mailto:reano...@gmail.com>> ha scritto:

Il giorno gio 24 set 2020 alle ore 20:00 lorenzo casoli 
mailto:lollorenz...@live.it>> ha scritto:
Cito il mio messaggio:

 "Le fonti sono varie ma rinvierei alla fonte della Treccani come principale: 
https://www.treccani.it/enciclopedia/italia/
Non vedo da nessuna parte un "Regione geografica italiana" , solo varie 
citazioni geografiche storiche sull'Italia.

Oppure in questo sito sono contenute mappe della deAgostini che riportano lo 
stesso confine Alpino: http://digitale.bnc.roma.sbn.it/mappe?paginate_pageNum=1;

Non vado a guardarle tutte. Vedo si tratta di mappe storiche e/o politiche

Ivo, Jrachi

___
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] Maj Cadastre vectoriel

[Jérôme Seigneuret]

Bonsoir,
Il y a des fichiers geojson sur data.gouv.fr Il y a une carte des mises à
jour et ces éléments ont été mis à disposition en juillet. Il existe un
migrateur geojson vers postgresql en nodejs.

Le fichier geojson peut être chargé il me semble dans JOSM

Le ven. 18 sept. 2020 à 23:03, Eric SIBERT  a
écrit :

> Bonsoir,
>
> Ça y est, le cadastre vectoriel a été mis à jour sur la commune de Saint
> Martin d'Hères. Maintenant, il faut que je me souvienne de tous les
> chantiers rencontrés ces derniers mois ;-)
>
> Sinon, il y a le cadastre de Grenoble (raster et vecteur) qui est figé
> depuis 3 ou ans. Toujours pas de traces de bâtiments livrés depuis 3 ans
> :-(
>
> Eric
>
> ___
> 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: [Talk-it] Regione geografica italiana

[Ivo Reano]

 Geograficamente, cartografica, osmericamente, storicamente, politicamente
ed anche volgarmente sono cose non discernibili da quello che tu hai
chiamato"Regione geografica italiana"e che ora tu chiami "Italia".
Scusa l'Italia senza Lampedusa? Ma con dentro Malta? In quale secolo o
spazio/tempo vivi?

Lo spartiacque alpino ha un senso geografico.
La "Regione geografica italiana" no.

Il giorno gio 24 set 2020 alle ore 20:33 lorenzo casoli <
lollorenz...@live.it> ha scritto:

> Va bene, se vuole la può chiamare Italia al posto di regione geografica
> italiana, sono sinonimi.
>
> Le mappe indicate sono mappe storiche nel senso che sono state realizzate
> in un passato relativamente remoto, ma la line di spartiacque alpina rimane
> quella, non cambia (o lo fa in minima parte).
>
> Il giorno 24 set 2020, alle ore 20:06, Ivo Reano  ha
> scritto:
>
> Il giorno gio 24 set 2020 alle ore 20:00 lorenzo casoli <
> lollorenz...@live.it> ha scritto:
>
>> Cito il mio messaggio:
>>
>>  "Le fonti sono varie ma rinvierei alla fonte della Treccani come
>> principale: https://www.treccani.it/enciclopedia/italia/
>>
> Non vedo da nessuna parte un "Regione geografica italiana" , solo varie
> citazioni geografiche storiche sull'Italia.
>
> Oppure in questo sito sono contenute mappe della deAgostini che riportano
>> lo stesso confine Alpino:
>> http://digitale.bnc.roma.sbn.it/mappe?paginate_pageNum=1;
>>
>
> Non vado a guardarle tutte. Vedo si tratta di mappe storiche e/o politiche
>
> Ivo, Jrachi
>
> ___
> 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-us] place=neighborhood on subdivisions?

[Mark Wagner]

The problem with "suburb" is like the problem with "football": there
are two meanings, and a very large population that doesn't know about
the other meaning.  That guarantees widespread misuse.

-- 
Mark

On Thu, 24 Sep 2020 11:55:55 -0400
Brian Stromberg  wrote:

> If suburb is a commonly understood and useful concept in other
> countries then it seems good to keep it around. I don't really know
> what the implications are of retirement or what the process would be.
> I would instead advocate for country-specific guidance on its usage.
> 
> --
> Brian
> 
> 
> On Thu, Sep 24, 2020 at 11:38 AM Paul Johnson 
> wrote:
> 
> > On Thu, Sep 24, 2020 at 8:32 AM Brian Stromberg
> >  wrote:
> >  
> >> This contradicts the OSM wiki but seems like the only way to avoid
> >> confusion.
> >>  
> >
> > Much like sport=american_football vs sport=soccer, this makes sense.
> > Maybe it's time to retire place=suburb as a tag due to its
> > ambiguity?
> >
> >  
> >> The only reason I can think of to use 'suburb' as a tag in the
> >> context of the United States would be if a tag indicating 'central
> >> city' or something similar was introduced.
> >>  
> >
> > Ostensibly, that's what place=city was supposed to be, but not
> > helping OSM would be that some places have cities and towns of
> > different legal importance (Oklahoma), or "it's a city or it's not
> > a city" with no room for nuance (Oregon).  Not making things any
> > easier is how lopsided populations are in the US, a midsize
> > municipality is about 5500 people.  Once you get to about 90,000,
> > you're in the top 2% largest anything in the US.
> > ___ Talk-us mailing list
> > Talk-us@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-us
> >  


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

Re: [Talk-it] Regione geografica italiana

[lorenzo casoli]

Va bene, se vuole la può chiamare Italia al posto di regione geografica 
italiana, sono sinonimi.

Le mappe indicate sono mappe storiche nel senso che sono state realizzate in un 
passato relativamente remoto, ma la line di spartiacque alpina rimane quella, 
non cambia (o lo fa in minima parte).

Il giorno 24 set 2020, alle ore 20:06, Ivo Reano 
mailto:reano...@gmail.com>> ha scritto:

Il giorno gio 24 set 2020 alle ore 20:00 lorenzo casoli 
mailto:lollorenz...@live.it>> ha scritto:
Cito il mio messaggio:

 "Le fonti sono varie ma rinvierei alla fonte della Treccani come principale: 
https://www.treccani.it/enciclopedia/italia/
Non vedo da nessuna parte un "Regione geografica italiana" , solo varie 
citazioni geografiche storiche sull'Italia.

Oppure in questo sito sono contenute mappe della deAgostini che riportano lo 
stesso confine Alpino: http://digitale.bnc.roma.sbn.it/mappe?paginate_pageNum=1;

Non vado a guardarle tutte. Vedo si tratta di mappe storiche e/o politiche

Ivo, Jrachi

___
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] Regione geografica italiana

[Ivo Reano]

Il giorno gio 24 set 2020 alle ore 20:00 lorenzo casoli <
lollorenz...@live.it> ha scritto:

> Cito il mio messaggio:
>
>  "Le fonti sono varie ma rinvierei alla fonte della Treccani come
> principale: https://www.treccani.it/enciclopedia/italia/
>
Non vedo da nessuna parte un "Regione geografica italiana" , solo varie
citazioni geografiche storiche sull'Italia.

Oppure in questo sito sono contenute mappe della deAgostini che riportano
> lo stesso confine Alpino:
> http://digitale.bnc.roma.sbn.it/mappe?paginate_pageNum=1;
>

Non vado a guardarle tutte. Vedo si tratta di mappe storiche e/o politiche

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

Re: [Talk-it] Regione geografica italiana

[lorenzo casoli]

Cito il mio messaggio:

 "Le fonti sono varie ma rinvierei alla fonte della Treccani come principale: 
https://www.treccani.it/enciclopedia/italia/

Oppure in questo sito sono contenute mappe della deAgostini che riportano lo 
stesso confine Alpino: http://digitale.bnc.roma.sbn.it/mappe?paginate_pageNum=1;


Il giorno 24 set 2020, alle ore 19:58, Ivo Reano 
mailto:reano...@gmail.com>> ha scritto:



Il giorno gio 24 set 2020 alle ore 19:56 lorenzo casoli 
mailto:lollorenz...@live.it>> ha scritto:
Questo perché la definizione di regione geografica italiana prevede così. Come 
vede non c'è niente di arbitrario ma si seguono ligi criteri accademici.

Il giorno 24 set 2020, alle ore 19:51, Ivo Reano 
mailto:reano...@gmail.com>> ha scritto:

Piccola aggiunta di richiesta spiegazioni.
Perchè hai messo dentro Malta e Linosa, ma non Lampedusa?

Mi dici su quali testi ti sei basato?
O i criteri accademici nascono un po a caso.

___
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-us] place=neighborhood on subdivisions?

[stevea]

I'd like to clarify my take-aways from this discussion, hopefully yours, too.  
Thank you for reading and your patience.

Brian says that a common (THE common) definition of "suburb" in the US is 
(roughly) "a smaller city next to or near a much larger one as part of a 
conurbation."  I agree that is a very frequent understanding of how the word 
"suburb" is both used and understood in the USA, even most or almost all of the 
time.

I also assert that there is a (much less-common, agreed) usage for "suburb" in 
the US that is more in line with how OSM tags with place=suburb, as a kind of 
"district of a larger city."  Magnolia (in Seattle) is tagged place=suburb, 
believed correctly as to how that tag should be used, even though Magnolia is 
CALLED a "neighborhood" in local vernacular.  It seems these two usages of 
"suburb" can co-exist simultaneously (OSM tagging and local vernacular) while 
disagreeing slightly, though with some confusion unless and until this 
clarification is understood.  OK, we've discussed it, I hope it is less 
confusing.

(In the USA, we tend to CALL someplace like Bellevue a "suburb," though we 
correctly TAG it a place=city in OSM.  Such differences between "call" and 
"tag" are the source of much of the confusion about "suburb" and "neighborhood" 
or place=neighbourhood).

I fully support the use of place=neighbourhood tagging on nodes or polygons in 
the USA where it makes sense to do so.  In a previous post, I said the logic of 
using place=neighbourhood in Seattle makes less sense, as there is a hierarchy 
with using place=* (city, suburb, neighbourhood, among other values if greater 
granularity exists).  So, with what are CALLED neighborhoods being actually 
TAGGED place=suburb, there is "excess room" in that hierarchy:  with Seattle 
tagged "city" and Magnolia (and other so-called neighborhoods) tagged "suburb," 
tagging Magnolia (and others) with place=neighbourhood (because it is "called" 
that) would leave a gap between neighbourhood and city:  what suburb would 
Magnolia be a part of?  Yes, as it was said somewhere that Seattle's 
"neighborhoods" have specific boundaries, it could be a small OSM project to 
restructure Seattle from nodes-tagged-suburb to polygons-tagged-neighbourhood.  
That could happen, though I still ask what place=suburb tag, if any, would be 
appropriate to bridge the gap between neighbourhood and city.  Perhaps none, 
and that is OK, I'm not sure if this is "allowed" with place=* tagging, maybe 
it is.

In the example I gave in the city of Santa Cruz (Prospect Heights 
"neighborhood," now tagged with a relatively large landuse=residential PLUS 
smaller more-correct, "block-level" landuse=residential polygons), our county 
wiki outlines a strategy for the already-existing large landuse=residential 
polygons (older, less correct, "first draft") and the smaller 
landuse=residential polygons (newer, more correct, "corrections to first draft 
underway"):  when all the smaller, more correct polygons are completed, the 
landuse=residential tag on the larger, less correct is changed to 
place=neighbourhood!  Santa Cruz, a city of about 65,000, already has five 
nodes tagged place=suburb, (13,000 in a suburb seems about right, these suburb 
names are widely used), as well as five or so "smaller" (in identity) scattered 
place=locality nodes (slightly different than the suburb or neighborhood names).

This all works both in how the real world names things and in OSM:  the City 
(multipolygon) is tagged place=city, its five suburbs (in the less common 
sense) are nodes tagged place=suburb, the "residential neighborhoods" are NOW 
tagged landuse=residential, yet OSM is on track (and documents how) we're 
converting these to better-granularity "block-level" landuse=residential 
polygons inside of larger polygons, and these larger polygons will be changed 
from landuse=residential to place=neighbourhood when full "inner 
high-granularity" polygons are completed inside of the to-be-designated 
place=neighbourhood larger enclosing polygons.  (Additionally, there are some 
scattered nodes tagged place=locality, what might be considered "the bottom of 
the hierarchy," which have accrued and stabilized according to local 
convention).  Clear!

May this clarify similar strategies for better place=* tagging in the USA.  It 
is complicated when US English diverges from the more British (or Australian) 
English that strongly influences wiki definitions of tags, but with some 
discussion, we can both better understand these potentially confusing (but 
ultimately understandable) differences, and tag well, even in the USA.

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

Re: [Talk-it] Regione geografica italiana

[Ivo Reano]

Il giorno gio 24 set 2020 alle ore 19:56 lorenzo casoli <
lollorenz...@live.it> ha scritto:

> Questo perché la definizione di regione geografica italiana prevede così.
> Come vede non c'è niente di arbitrario ma si seguono ligi criteri
> accademici.
>
> Il giorno 24 set 2020, alle ore 19:51, Ivo Reano  ha
> scritto:
>
> Piccola aggiunta di richiesta spiegazioni.
> Perchè hai messo dentro Malta e Linosa, ma non Lampedusa?
>
> Mi dici su quali testi ti sei basato?
O i criteri accademici nascono un po a caso.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Regione geografica italiana

[Ivo Reano]

@lorenzo casoli
Mi rispondo da solo:
(Hai inserito anche Palagruza)
Hai seguito i confini territoriali (politici) per semplicità e non per
seguire il tuo stesso filo logico.
Mi viene da pensare che lo hai fatto solo per creare una discussione.
Vedo che hai dato una risposta mentre scrivevo. Ma rimane valido quello che
ho scritto.

Il giorno gio 24 set 2020 alle ore 19:51 Ivo Reano  ha
scritto:

> Piccola aggiunta di richiesta spiegazioni.
> Perchè hai messo dentro Malta e Linosa, ma non Lampedusa?
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Regione geografica italiana

[lorenzo casoli]

Questo perché la definizione di regione geografica italiana prevede così. Come 
vede non c'è niente di arbitrario ma si seguono ligi criteri accademici.

Il giorno 24 set 2020, alle ore 19:51, Ivo Reano 
mailto:reano...@gmail.com>> ha scritto:

Piccola aggiunta di richiesta spiegazioni.
Perchè hai messo dentro Malta e Linosa, ma non Lampedusa?

___
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] Regione geografica italiana

[lorenzo casoli]

No, il concetto di regione geografica italiana non me lo sono inventato io e 
non è nella mia testa, nella mia testa ci sono le mie opinioni politiche come 
nella sua ci saranno le sue. Il concetto di regione geografica italiana è un 
concetto accademico assolutamente indipendente da ideologie politiche, le fonti 
e la definizione sono nel mio primo messaggio.

Il giorno 24 set 2020, alle ore 19:49, Ivo Reano 
mailto:reano...@gmail.com>> ha scritto:



Il giorno gio 24 set 2020 alle ore 19:26 lorenzo casoli 
mailto:lollorenz...@live.it>> ha scritto:
Interessante disquisizione ma di nuovo, la relazione non riguarda nessuno degli 
argomenti che lei ha descritto a parte quello meramente geografico, non 
esistono confini storici ne politici ne altro. Se nella storia o attualmente 
alcuni confini politici sono venuti a coincidere con questi, se vuole la mia 
opinione, tanto meglio, ma a priori non si tratta di nient'altro che geografia, 
confini geografici e nient'altro.

Il giorno 24 set 2020, alle ore 19:09, Ivo Reano 
mailto:reano...@gmail.com>> ha scritto:

Mi chiedo... Che senso ha una regione geografica italiana?
Geologicamente è un miscuglio terrificante!
Politicamente è un pezzo dell'intento...
Geograficamente non ho capito cosa significa!

Quindi è tutto nella tua testa? Se dici che è una "Regione geografica italiana" 
perché hai messo
name=

Geographical region of Italy
in inglese?
Mentre non vengono coinvolte le lingue parlate nei paesi che tu hai inserito 
nella relazione?
Forse perchè è una tua convinzione?
La pagina wiki che hai preso come giustificazione (fonte dati?) è molto 
discutibile, da molti punti di vista.
Confini geografici?
Mi ricordo che la geografia divide il territorio in aree affini.
Non sono un geografo ma mi pare che geograficamente si parla di arco alpino, 
pianura padana ecc. E non di un assembramento come tu hai fatto.
Che sembra, ripeto sembra, un parto cerebrale e non un corrispettivo di "tutto 
possono vedere".

Ivo, Jrachi.

___
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] Regione geografica italiana

[Ivo Reano]

Piccola aggiunta di richiesta spiegazioni.
Perchè hai messo dentro Malta e Linosa, ma non Lampedusa?
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Regione geografica italiana

[Ivo Reano]

Il giorno gio 24 set 2020 alle ore 19:26 lorenzo casoli <
lollorenz...@live.it> ha scritto:

> Interessante disquisizione ma di nuovo, la relazione non riguarda nessuno
> degli argomenti che lei ha descritto a parte quello meramente geografico,
> non esistono confini storici ne politici ne altro. Se nella storia o
> attualmente alcuni confini politici sono venuti a coincidere con questi, se
> vuole la mia opinione, tanto meglio, ma a priori non si tratta di
> nient'altro che geografia, confini geografici e nient'altro.
>
> Il giorno 24 set 2020, alle ore 19:09, Ivo Reano  ha
> scritto:
>
> Mi chiedo... Che senso ha una regione geografica italiana?
> Geologicamente è un miscuglio terrificante!
> Politicamente è un pezzo dell'intento...
> Geograficamente non ho capito cosa significa!
>
>
Quindi è tutto nella tua testa? Se dici che è una "Regione geografica
italiana" perché hai messo
name=

Geographical region of Italy
in inglese?
Mentre non vengono coinvolte le lingue parlate nei paesi che tu hai
inserito nella relazione?
Forse perchè è una tua convinzione?
La pagina wiki che hai preso come giustificazione (fonte dati?) è molto
discutibile, da molti punti di vista.
Confini geografici?
Mi ricordo che la geografia divide il territorio in aree affini.
Non sono un geografo ma mi pare che geograficamente si parla di arco
alpino, pianura padana ecc. E non di un assembramento come tu hai fatto.
Che sembra, ripeto sembra, un parto cerebrale e non un corrispettivo di
"tutto possono vedere".

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

Re: [Talk-it] Regione geografica italiana

[lorenzo casoli]

Interessante disquisizione ma di nuovo, la relazione non riguarda nessuno degli 
argomenti che lei ha descritto a parte quello meramente geografico, non 
esistono confini storici ne politici ne altro. Se nella storia o attualmente 
alcuni confini politici sono venuti a coincidere con questi, se vuole la mia 
opinione, tanto meglio, ma a priori non si tratta di nient'altro che geografia, 
confini geografici e nient'altro.

Il giorno 24 set 2020, alle ore 19:09, Ivo Reano 
mailto:reano...@gmail.com>> ha scritto:

Mi chiedo... Che senso ha una regione geografica italiana?
Geologicamente è un miscuglio terrificante!
Politicamente è un pezzo dell'intento...
Geograficamente non ho capito cosa significa!

Se l'utente avesse tracciato lo spartiacque delle Alpi, sarei stato felice!
Pensate a mettere un uovo sulla cima e vedere verso quale mare o oceano scorre 
l'albume!
Quello che ha fatto è di collegare una parte di buondary amministrativi attuali 
con altri storici e qualche ragionamento spartacqueo.
Insomma un lavoro interessante ma non degno di discussione.

Il problema probabilmente nasce dalla mancanza di veri "layer" nel DB OSM.
Se avessimo un layer storio, uno geologico, uno politico nazionalista, uno 
politico europeista, ed uno per ogni corrente filosofica.
Bhe! Allora non ci sarebbero discussioni come questa.

Ma abbiamo un DB cartografico (non geografico!) senza layer, e dobbiamo far 
condividere "cose" reali, come strade, edifici, fiumi ecc. con "cose" virtuali, 
come confini amministrativi, aree protette per l'ambiente ecc. ecc.

Insomma, acci..enti. Uno non può fare un sacco di lavoro rispettando le regole 
e poi trovare qualcuno che con la scusa di essere nubbio si matte a mappare un 
mondo che esiste solo nella sua mente.

Scusate la vena sentimentale, ma volevo dire la mia..

Ivo, Jrachi

___
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] Regione geografica italiana

[emmexx]

On 9/24/20 6:37 PM, Max1234Ita wrote:
> Vivendo in Oltrepò Pavese mi sento tirato in causa :-)

Non so, inizialmente ero favorevole a questo tipo di toponimi, ora non
ne sono più molto sicuro.

Probabilmente converrebbe che nominatim rimandasse ad una voce di
wikipedia piuttosto che ad un "confine" di OSM. Sarebbe probabilmente
più utile a chi fa la ricerca.

ciao
maxx


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

Re: [Talk-it] Regione geografica italiana

[Ivo Reano]

Mi chiedo... Che senso ha una regione geografica italiana?
Geologicamente è un miscuglio terrificante!
Politicamente è un pezzo dell'intento...
Geograficamente non ho capito cosa significa!

Se l'utente avesse tracciato lo spartiacque delle Alpi, sarei stato felice!
Pensate a mettere un uovo sulla cima e vedere verso quale mare o oceano
scorre l'albume!
Quello che ha fatto è di collegare una parte di buondary amministrativi
attuali con altri storici e qualche ragionamento spartacqueo.
Insomma un lavoro interessante ma non degno di discussione.

Il problema probabilmente nasce dalla mancanza di veri "layer" nel DB OSM.
Se avessimo un layer storio, uno geologico, uno politico nazionalista, uno
politico europeista, ed uno per ogni corrente filosofica.
Bhe! Allora non ci sarebbero discussioni come questa.

Ma abbiamo un DB cartografico (non geografico!) senza layer, e dobbiamo far
condividere "cose" reali, come strade, edifici, fiumi ecc. con "cose"
virtuali, come confini amministrativi, aree protette per l'ambiente ecc.
ecc.

Insomma, acci..enti. Uno non può fare un sacco di lavoro rispettando le
regole e poi trovare qualcuno che con la scusa di essere nubbio si matte a
mappare un mondo che esiste solo nella sua mente.

Scusate la vena sentimentale, ma volevo dire la mia..

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

Re: [Talk-it] Regione geografica italiana

[Alessandro Sarretta]

Ciao

On 24/09/20 17:10, lorenzo casoli wrote:
    - aggiunta di elementi marcati come "proposed", visto la 
traduzione del termine dall'inglese immaginavo che si potesse 
aggiungere tutte quelle opere non ancora realizzate o non ancora in 
fase di realizzazione ma, appunto proposte. Ovviamente se non sono 
previste all'interno di OSM, vanno tolte: attualmente sono presenti il 
sistema delle tramvie di Firenze non ancora realizzato e una mia 
proposta di viabilità a sud di Firenze.


mi limito a questo aspetto, non entrando negli altri più ampi.

Il riferimento per la mappatura è sempre primariamente il wiki e la 
pagina https://wiki.openstreetmap.org/wiki/Tag:highway%3Dproposed mi 
pare esprima in modo netto che il tag riguarda solamente opere 
chiaramente (e in modo verificabile) "pronte" per essere iniziate (anche 
se non sono ancora in fase di costruzione). E' scritto cmq che andrebbe 
utilizzata solo in casi eccezionali e dopo una discussione con la 
comunità locale ("should therefore only be mapped in exceptional cases 
and after a discussion with the relevant OSM community").


L'idea poi di inserire in OpenStreetMap delle proposte personali è 
assolutamente da rigettare.


Consiglierei quindi di eliminare gli elementi mappati in quel modo.

Ale

--
--

Alessandro Sarretta

skype/twitter: alesarrett
Web: ilsarrett.wordpress.com 

Research information:

 * Google scholar profile
   
 * ORCID 
 * Research Gate 
 * Impactstory 

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

Re: [Talk-it] Regione geografica italiana

[Federico Cortese]

On Thu, Sep 24, 2020 at 6:38 PM Max1234Ita  wrote:
>
> Mi chiedevo semplicemente se, al di là dei risvolti
> etnico/ideologico/politici, non abbia effettivamente senso mappare anche
> quelle regioni che non sono l' "Italia Irredenta", ma più semplicemente aree
> geografiche definite, come ad esempio il già citato Oltrepò Pavese, Le
> Langhe o la Franciacorta... e per non citare solo aree enologiche potrei
> aggiungere la Maremma, il Salento il Logudoro... e così via
>

Già nelle note qualcuno chiede che venga mappato il Salento :)
https://www.openstreetmap.org/note/2234706.

Ciao,
Federico

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

Re: [Talk-us] place=neighborhood on subdivisions?

[Kevin Kenny]

Another vote for Evin and Minh's interpretation.

I've been tagging named, signed, suburban (in the US sense)
subdivisions with landuse=residential and name=*.

I make no distinction among the subdivisions that consist of
apartments, terraces, or detached houses (except when mapping the
buildings themselves): thus, I've mapped 'Hillcrest Villaage' and 'Van
Antwerp Village' (apartment complexes), 'Village Meadow' and 'Country
Gardens' (condos), 'Orchard Park' (mixed condos and detached houses)
and 'Hawthorne Hill' (detached houses) all as landuse=residential
name=*.

I overlap natural=wood where appropriate, since the overlap of landuse
and landcover causes no conflict. I work similarly with
amenity=parking when the parking lot is part of the community. If
there's landuse=basin, landuse=religious, or something similar inside
the area, I make a cutout, since those are conflicting land uses, even
if the drainage basin or church is part of the planned community.

I've contemplated using place=neighbourhood (on either node or way)
with them, but eventually concluded that it was too subjective a
decision for whether residents would self-identify their neighbourhood
as being the same as their subdivision.  To someone from Niskayuna,
New York, I might say that I live in Orchard Park, or that Andrea
lives in Windsor Estates - the locals know most of the subdivision
names, and many of them have the names of the main entrance roads
match the name of the subdivision (Orchard Park Road, Windsor Drive).
To someone who isn't local, I'd more likely reference cross streets or
landmarks: "the subdivision on the north side of the high school". I
have no problem, though, with putting the name of the subdivision on
the landuse=residential polygon: the names are signed and
field-verifiable.

When I'm micromapping a neighbourhood, I do map private swimming pools
because the fire department appreciates it.

I try to respect privacy, and map landuse=residential on individual
lots only when the lot is completely surrounded by other land uses.
That case is hard to reconcile with privacy: if someone owns a parcel
that has park land (in the US sense) on two sides, a wastewater plant
on a third, and a river on the fourth, the parcel is going to be
visible in any case as the hole among the other land uses.  To have it
not be deducible, I'd have to refrain from mapping one or another of
the adjoining facilities, and I think we all agree that parks,
wastewater plants and rivers are objects that ought to be mapped.



On Thu, Sep 24, 2020 at 11:48 AM Evin Fairchild  wrote:
>
> I totally agree with Minh here. I always thought that it was standard 
> parctice in OSM to add the name tag to a landuse=residential way that 
> encompasses the subdivision. Subdivision names aren't always used in common 
> parlance (especially if it's a smaller subdivision) so most people wouldn't 
> necessarily consider the subdivision name to be the name of the neighborhood 
> that they live in.
>
> On Thu, Sep 24, 2020, 12:44 AM Minh Nguyen  
> wrote:
>>
>> Vào lúc 18:40 2020-09-22, Paul Johnson đã viết:
>> >
>> >
>> > On Tue, Sep 22, 2020 at 8:36 PM Mike N
>> > > > > wrote:
>> >
>> > On 9/22/2020 9:26 PM, Paul Johnson wrote:
>> >  > The extra hamlet nodes are import remainders that haven't
>> > yet been
>> >  > converted to landuse areas.   The general landuse zones for
>> > that area
>> >  > have been identified, but do not exactly correspond to the named
>> >  > subdivisions.   As I get a chance to survey, I divide the
>> > landuse into
>> >  > subdivisions and convert the node to a named area for the
>> > subdivision.
>> >  >
>> >  >
>> >  > Please don't expand these as landuse, please expand them as
>> >  > place=neighborhood instead.  Landuse polygons should be congruent
>> > to the
>> >  > actual land use.
>> >
>> > That's a good point: the subdivisions often contain one or more landuse
>> > basins, clusters of trees, etc.   I've been thinking of them as one big
>> > blob, but it seem correct on a more micromap level to mark them as
>> > place=, and identify the smaller landuse areas (which are sometimes all
>> > residential).
>> >
>> >
>> > Exactly.  My rule of thumb is if you're thinking about putting a name on
>> > it, and it's not a shopping center, apartment complex or similar large
>> > but contiguous landuse, then landuse=* probably isn't what your polygon
>> > should be.
>>
>> It's common, intuitive, and IMO beneficial to map a planned,
>> suburban-style residential development as a single named
>> landuse=residential area. These developments have well-defined
>> boundaries and are primarily residential in character. If there are some
>> wooded lots in the subdivision, it's perfectly fine to map a
>> natural=wood area inside of or partially overlapping the
>> landuse=residential area, ideally without being connected 

Re: [Talk-it] Regione geografica italiana

[Max1234Ita]

Vivendo in Oltrepò Pavese mi sento tirato in causa :-)

Mi chiedevo semplicemente se, al di là dei risvolti
etnico/ideologico/politici, non abbia effettivamente senso mappare anche
quelle regioni che non sono l' "Italia Irredenta", ma più semplicemente aree
geografiche definite, come ad esempio il già citato Oltrepò Pavese, Le
Langhe o la Franciacorta... e per non citare solo aree enologiche potrei
aggiungere la Maremma, il Salento il Logudoro... e così via

Immagino esistano già i tag per farlo, e sicuramente sarebbe utile ai fini
della ricerca. 
Perchè, se su Nominatim cerco "Oltrepo", la regione in cui vivo non mi viene
restituita, mentre trovo un sacco di toponimi ed altri riscontri, tra cui un
negozio di vini in Lettonia? (https://www.openstreetmap.org/node/3249141390)
:-o

Saluti!
Max





totera wrote
> (...)
> Se vuoi un concetto simile, su scala diversa, potresti prendere ad esempio
> la Romagna o l'Oltrepò Pavese. Non so se siano mappate su Openstreetmap,
> ma
> con un tag del tipo place=region che indichi che non si tratta di
> suddivisioni amministrative definite ma di regioni storiche credo ci
> potrebbero stare tranquillamente.
> (...)
> 
> 
> 
> 
> 
> --
> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
> 
> ___
> Talk-it mailing list

> Talk-it@

> https://lists.openstreetmap.org/listinfo/talk-it





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

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

Re: [Talk-us] place=neighborhood on subdivisions?

[Brian Stromberg]

If suburb is a commonly understood and useful concept in other countries
then it seems good to keep it around. I don't really know what the
implications are of retirement or what the process would be. I would
instead advocate for country-specific guidance on its usage.

--
Brian


On Thu, Sep 24, 2020 at 11:38 AM Paul Johnson  wrote:

> On Thu, Sep 24, 2020 at 8:32 AM Brian Stromberg 
> wrote:
>
>> This contradicts the OSM wiki but seems like the only way to avoid
>> confusion.
>>
>
> Much like sport=american_football vs sport=soccer, this makes sense.
> Maybe it's time to retire place=suburb as a tag due to its ambiguity?
>
>
>> The only reason I can think of to use 'suburb' as a tag in the context of
>> the United States would be if a tag indicating 'central city' or something
>> similar was introduced.
>>
>
> Ostensibly, that's what place=city was supposed to be, but not helping OSM
> would be that some places have cities and towns of different legal
> importance (Oklahoma), or "it's a city or it's not a city" with no room for
> nuance (Oregon).  Not making things any easier is how lopsided populations
> are in the US, a midsize municipality is about 5500 people.  Once you get
> to about 90,000, you're in the top 2% largest anything in the US.
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] place=neighborhood on subdivisions?

[Evin Fairchild]

I totally agree with Minh here. I always thought that it was standard
parctice in OSM to add the name tag to a landuse=residential way that
encompasses the subdivision. Subdivision names aren't always used in common
parlance (especially if it's a smaller subdivision) so most people wouldn't
necessarily consider the subdivision name to be the name of the
neighborhood that they live in.

On Thu, Sep 24, 2020, 12:44 AM Minh Nguyen 
wrote:

> Vào lúc 18:40 2020-09-22, Paul Johnson đã viết:
> >
> >
> > On Tue, Sep 22, 2020 at 8:36 PM Mike N
> >  > > wrote:
> >
> > On 9/22/2020 9:26 PM, Paul Johnson wrote:
> >  > The extra hamlet nodes are import remainders that haven't
> > yet been
> >  > converted to landuse areas.   The general landuse zones for
> > that area
> >  > have been identified, but do not exactly correspond to the
> named
> >  > subdivisions.   As I get a chance to survey, I divide the
> > landuse into
> >  > subdivisions and convert the node to a named area for the
> > subdivision.
> >  >
> >  >
> >  > Please don't expand these as landuse, please expand them as
> >  > place=neighborhood instead.  Landuse polygons should be congruent
> > to the
> >  > actual land use.
> >
> > That's a good point: the subdivisions often contain one or more
> landuse
> > basins, clusters of trees, etc.   I've been thinking of them as one
> big
> > blob, but it seem correct on a more micromap level to mark them as
> > place=, and identify the smaller landuse areas (which are sometimes
> all
> > residential).
> >
> >
> > Exactly.  My rule of thumb is if you're thinking about putting a name on
> > it, and it's not a shopping center, apartment complex or similar large
> > but contiguous landuse, then landuse=* probably isn't what your polygon
> > should be.
>
> It's common, intuitive, and IMO beneficial to map a planned,
> suburban-style residential development as a single named
> landuse=residential area. These developments have well-defined
> boundaries and are primarily residential in character. If there are some
> wooded lots in the subdivision, it's perfectly fine to map a
> natural=wood area inside of or partially overlapping the
> landuse=residential area, ideally without being connected to it. This
> approach is supported by longstanding documentation [1], old threads
> [2], and good support in both renderers [3] and search engines.
>
> There have also been old discussions where folks have conflated the
> concept of landcover with landuse. [4] But I find this approach overly
> academic. Taking it to the logical extreme, landuse=residential would
> only be coincident to each house in a subdivision, given that the yards
> are non-dwellings.
>
> I don't see the need for a fundamental distinction between planned
> residential developments consisting of multi-family apartments and those
> consisting of single-family houses, such that the former would be mapped
> as a coherent landuse area but the latter would be a shapeless place
> point. Where there's no such distinction, the landuse areas lend
> themselves to ab intuitive rendering that's good for navigating suburban
> sprawl. [5]
>
> If a planned development truly is actually mixed-use, and not only in a
> garden-level micromapping sense, then something other than landuse=*
> would be reasonable, since a particular landuse doesn't characterize
> that development anyways. Named landuse=residential areas also don't
> tend to make as much sense in urban areas, older inner suburbs, and
> rural areas. But the areas in changeset 91255294 aren't mixed-use
> developments; they're residential areas in a suburban setting.
>
> [1] https://wiki.openstreetmap.org/wiki/Special:Diff/1087300
> [2] I previously wrote on this topic in
> 
> and
> it seemed like other respondents were taking the same approach.
> [3] https://github.com/gravitystorm/openstreetmap-carto/issues/351
> [4]
> https://lists.openstreetmap.org/pipermail/talk-gb/2017-January/019811.html
> [5] https://osm.org/go/ZTVSa4OB
>
> --
> m...@nguyen.cincinnati.oh.us
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] place=neighborhood on subdivisions?

[Paul Johnson]

On Thu, Sep 24, 2020 at 8:32 AM Brian Stromberg 
wrote:

> This contradicts the OSM wiki but seems like the only way to avoid
> confusion.
>

Much like sport=american_football vs sport=soccer, this makes sense.  Maybe
it's time to retire place=suburb as a tag due to its ambiguity?


> The only reason I can think of to use 'suburb' as a tag in the context of
> the United States would be if a tag indicating 'central city' or something
> similar was introduced.
>

Ostensibly, that's what place=city was supposed to be, but not helping OSM
would be that some places have cities and towns of different legal
importance (Oklahoma), or "it's a city or it's not a city" with no room for
nuance (Oregon).  Not making things any easier is how lopsided populations
are in the US, a midsize municipality is about 5500 people.  Once you get
to about 90,000, you're in the top 2% largest anything in the US.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-TW] weeklyOSM #530 2020-09-08-2020-09-14

[weeklyteam]

台灣社群朋友好：
每週 OSM 新聞匯集文摘，# 530 期，如今已經發佈台灣華語版本，涵蓋開放街圖世界的大小事情！

https://www.weeklyosm.eu/zh/archives/13755/

歡迎閱讀！

你知道你能提供消息給 weeklyOSM 小組嗎？只要用 OSM 帳號登入 https://osmbc.openstreetmap.de/login 
就可以了。關於怎麼撰寫的方式請參閱：http://www.weeklyosm.eu/this-news-should-be-in-weeklyosm 

weeklyOSM? 
誰：https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
那裡呢？：https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-TW mailing list
Talk-TW@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-tw

Re: [OSM-legal-talk] Changeset Comments Copyright

[Kathleen Lu via legal-talk]

On Thu, Sep 24, 2020 at 3:30 AM Martin Koppenhoefer 
wrote:

>
>
> Am Do., 24. Sept. 2020 um 12:05 Uhr schrieb Tom Hughes :
>
>> On 24/09/2020 10:18, Martin Koppenhoefer wrote:
>>
>> > it contains changesets, notes, etc. but not diary posts or changeset
>> > comments (correct me if I’m wrong).
>>
>> You're wrong:
>>
>> https://planet.openstreetmap.org/planet/discussions-latest.osm.bz2
>
>
>
> thank you Tom, thought they must be somewhere but couldn't find them at a
> glance.
> Can still not find the diaries, this seems to imply diaries are not
> covered by the CT (but by the ToU), because they are not part of the
> geodatabase, while changeset comments are (i.e. are published with ODbL
> license)?
>
> Cheers,
> Martin
>

This is my view.
-Kathleen
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [Talk-it] Regione geografica italiana

[lorenzo casoli]

Salve, forse sono riuscito a capire come partecipare a questa discussione:

Grazie di avermi indicato questo sito, è carino partecipare al processo alle 
proprie opinioni e ai propri interessi, è molto democratico e fa sentire 
davvero a proprio agio.

Comunque se dovrò difendermi, mi difenderò. Adiamo con ordine.
Le mie modifiche ad openstreetmap hanno riguardato i seguenti temi fino ad ora:
-  modifiche a viabilità e mobilità nell'area di Firenze:
- aggiunta di elementi effettivamente esistenti
- aggiunta di elementi in costruzione
- aggiunta di elementi marcati come "proposed", visto la traduzione del 
termine dall'inglese immaginavo che si potesse aggiungere tutte quelle opere 
non ancora realizzate o non ancora in fase di realizzazione ma, appunto 
proposte. Ovviamente se non sono previste all'interno di OSM, vanno tolte: 
attualmente sono presenti il sistema delle tramvie di Firenze non ancora 
realizzato e una mia proposta di viabilità a sud di Firenze.

- modifiche di tipo politico-amministrativo:
- modifica etichette esistenti
- aggiunta di aree intercomunali esistenti
- aggiunta di aree intercomunali proposte le quali sono già state eliminate 
perché non previste all'interno di OSM (vale lo stesso che mi ha indotto in 
errore per il caso precedente)
- aggiunta di aree linguistiche, alcune sono ancora presenti, altre sono 
state cancellate, senza apparentemente che vi sia una logica dietro univoca, 
dando adito a contraddizioni. Tuttavia non voglio far partire un dibattito su 
questo, perciò mi accontenterò della contraddizione senza chiedere altre 
spiegazioni.
   - aggiunta di confini amministrativi storici poi in seguito rivertiti 
(vedere qui: 
https://www.openstreetmap.org/changeset/49835295#map=8/44.569/7.048 per la 
ragione per la quale avevo ritenuto possibile l'aggiunta di relazioni storiche)

- altre varie ed eventuali (tra cui elementi naturali, sentire, ecc...)

Ovviamente in generale ho commesso errori nei 3 anni di editaggio su OSM, i 
quali sono stati riveriti ovunque sia stato ritenuto necessario.

Ma ora veniamo al dunque dell'argomento trattato in questo thread: la relazione 
https://www.openstreetmap.org/relation/7357659

Innanzitutto sì, inizialmente ho fatto un po' di confusione dovuta alla mia 
inesperienza con l'editiere di OSM, potete leggere la discussione qui per 
ulteriori informazioni: 
https://www.openstreetmap.org/changeset/49835295#map=8/44.569/7.048

Dopodiché veniamo al senso della relazione: come altri hanno scritto non si 
tratta né di una relazione storica ne di una relazione politica, ma di una 
relazione geografica, cioè di una relazione "relativa all'osservabile".
La definizione di Regione geografica Italiana è: la parte di continente europeo 
compresa tra lo spartiacque alpino e il Mare Mediterraneo, con le isole 
(europee) ad esso afferenti.

Le fonti sono varie ma rinvierei alla fonte della Treccani come principale: 
https://www.treccani.it/enciclopedia/italia/
Oppure in questo sito sono contenute mappe della deAgostini che riportano lo 
stesso confine Alpino: http://digitale.bnc.roma.sbn.it/mappe?paginate_pageNum=1

Per quanto riguarda i dubbi sulla laicità di una relazione geografica in 
openstreetmap, credo che sia da ritenerla tale sia in quanto una relazione del 
genere già esiste (https://www.openstreetmap.org/relation/3870917), sia in 
quanto una regione fisica è una regione geografica ben individuabile e 
verificabile da chiunque e che da informazioni importanti per esempio su 
caratteristiche idrogeologiche del territorio.



Il giorno 24 set 2020, alle ore 16:17, Volker Schmidt 
mailto:vosc...@gmail.com>> ha scritto:

Aggiungo:

Altri aspetti dell'utente lorec10:
ha inserito due "proposte" sue per la viabilità a Firenze come relazioni, 
composti da strade taggate highway=proposed, ma le relazioni sono reali.

  *   Bypass Gavinana (9123407, 
v6)
  *   viabilità Firenze Sud (11186930, 
v1)

Purtroppo non dovrebbero essere in OSM.

Poi ho scoperto che sul sito www.deviantart.com 
esiste un utente con lo stesso nome, che 
pubblica mappe.

Esiste anche un utente lorec10 su Wikipedia e su Pinterest

Se si tratta della stessa persona, direi che si tratta di un'artista.



On Thu, 24 Sep 2020 at 15:43, Volker Schmidt 
mailto:vosc...@gmail.com>> wrote:
L'utente lorec10 ha una storia:

nel 2017

  *   ha lavorato sul confine della Peninsula Iberica (changeset 53355956 ...)
  *   "ajouté une proposition de Grand Bruxelles" (CS 54035610 ...)
  *   lavorato sul "confine storico Italia-Francia" (CS 54282137...)
  *   "added Italian Switzerland" (CS 54740342 ...)

nel 2018

  *   "Huating total population correction" (CS 64954773) in China
  *   "added Zona de Lengua Catalana de Aragón" (CS 62080288 ...)

nel 20120

  *   "relation Grand Genève" (CS 83726885 ...
  *   una 

Re: [Talk-it] Regione geografica italiana

[Martin Koppenhoefer]

sent from a phone

> On 24. Sep 2020, at 16:18, Volker Schmidt  wrote:
> 
> Se si tratta della stessa persona, direi che si tratta di un'artista.


Preferirei discutere su questo oggetto senza guardare chi lo ha inserito. 
Certo, se tu avessi scoperto (non ho seguito ancora tutti i links e non conosco 
la situazione reale a Firenze) che questo utente disegna oggetti non 
comunemente considerati reali, allora meriterebbe questo uno secondo sguardo, 
ma in un altro thread.

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

Re: [Talk-us] While we're fixing things in iterations

[Paul Johnson]

On Thu, Sep 24, 2020 at 3:55 AM Minh Nguyen 
wrote:

> Vào lúc 10:45 2020-09-23, Paul Johnson đã viết:
> > Can we finally fix two other longstanding problems, then?
> >
> > 1. The wiki being incorrect about not counting bicycle lanes.  That's
> > not reflective of how validators deal with lanes, how data consumers
> > like Osmand or Magic Earth deal with lanes, or how ground truth works.
> > The whole "but you can't fit a motor vehicle down it" argument is
> > facile, that's what access:lanes=* and width:lanes=* is for.
>
> I agree that width is a poor argument for the status quo, especially
> given the common practice (in California, anyways) of bike lanes that
> double as right turn lanes for cars.
>
> For what it's worth, the lanes=* documentation has long included a
> passage recommending that data consumers treat lanes=* as a minimum
> value rather than a reliable exact lane count. Apparently some mappers
> only count through lanes but exclude turn lanes.
>

Fortunately, editors will automatically fix this and make lanes=* be the
total of lanes:forward=*, lanes:backward=* and lanes:both_ways=*, so this
is something that isn't hard to solve long term.  Hopefully when id gets
lane tools, it does the same thing JOSM does in this regard.


> I'm pretty sure existing routers would have no problem with including
> bike lanes in lanes=*, as long as bicycle:lanes=* and vehicle:lanes=*
> are both present. So I think a reasonable migration path would be to use
> the bicycle:lanes=* and vehicle:lanes=* tags to explicitly mark the
> non-auto-centric approach you're advocating.
>

There's no need.  We already have access:lanes=* for this.  Lanes are
lanes, regardless of access, and it takes a very narrowly motorist-centric
view in order to break this already fairly universally implemented
assumption.


> > 2. Tagging route information on ways.  It's about a decade too long at
> > this point for ref=* on a way to be completely disconnected from the
> > entity the tag applies to:  That's why route relations exist.  Biggest
> > problem child on this at the moment:  OSM's own tilesets.  Let's drop
> > rendering for ref=* on ways and just render the route relations already,
> > this and multipolygons are why relations came to exist in the first
> place.
>
> I'm as excited about route relations as anyone, especially because route
> relations are required for more nuanced route shield selection in
> renderers and routers. But for all the problems route relations solve,
> there are still some unresolved issues:
>
> * Even once rendered maps display pictioral route shields [2], there
> will still be situations where plain text is more appropriate, just as
> on the ground. It isn't always obvious how to transform a particular
> network=* value into a human-readable ref prefix to display in prose or
> read aloud during turn-by-turn navigation. Signposted ref prefixes can
> be pretty idiosyncratic, like "CC" for network=US:NV:Clark. I'm slowly
> building up Wikidata's coverage of signposted road networks and linking
> it to OSM Wiki data items, to make it easier for data consumers to look
> up the human-readable ref prefix on demand [3] or export a lookup table
> like [4] to hard-code. Incidentally, I've also proposed a road name
> formatter property at Wikidata [5], so that data consumers can expand
> network=US:NV:Clark to "Clark County Route", but it hasn't gotten much
> traction yet.
>

Honestly it isn't that hard to include modifier=* for bannered routes (ie,
Business, Bypass, Truck, Express, etc) and match against network on that to
get a good starting place without having to look up the whole thing.  So,
for example, (using NA as an abbreviation for the fictional state of
Nebrahoma), US:NA:Nebrahoma with no modifier would be easy to assume
"County Route".  US:NA:Nebrahoma:Nebrahoma City would be "City Route",
US:NA:Business with modifier=Business would be "State Business Route"...


> * A way's ref=* key is an ordered list, whereas there's no explicit
> ordering of a way's membership in multiple route relations. (A relation
> explicitly contains its members but not the other way around.) A data
> consumer either has to hard-code some heuristics that may not always be
> accurate [3] or infer the order from the way refs, as OSRM does. [6]
> There's a parallel situation with route numbers associated with a bus
> stop. The route_ref=* key on the stop node makes the order explicit,
> since some agencies don't sort the routes numerically on signage.
>

Perhaps we can get some insight from Osmand.


> * The destination:ref=* key uses the same prefixed syntax as way refs.
> No structured alternative has been formally proposed, but
> destination:network=* is common in Australia (where network=* is common
> on ways) and I've begun using destination:ref:wikidata=* in some parts
> of the U.S. I don't think it's too outlandish to imagine a future where
> navigation software uses destination:wikidata=* to detect street names
> that 

Re: [Talk-us] While we're fixing things in iterations

[Kevin Kenny]

On Thu, Sep 24, 2020 at 6:04 AM Minh Nguyen
 wrote:
> More recently, Kevin Kenny reimplemented the shield renderer using a
> more robust approach [3] and has discussed route relation support with
> the openstreetmap-carto developers. [4]
>
> OSMUS is interested in offering an Americentric renderer replete with
> shields. If anyone would like to help with the server situation, let's
> get in touch. Also I'm sure Kevin would welcome any pull requests to his
> osm-shields project, which would probably be a good starting point for
> this renderer if we go with Mapnik and raster tiles.

Everything Minh said here is true. I'd welcome all the help I can get!

The project has been on hold for quite some time, because I got
tremendously frustrated with it.  There are a lot of moving parts that
all need to come together to make it work. It touches a many
components in the rendering chain.

OSM-Carto is not the main problem.  Its developers are quite
responsive indeed to the idea. (I know that it would eventually bog
down for a while in controversy, but if we're talking about a
US-centric openstreetmap.us server, we could fork the style.) It's not
been my #1 priority, simply because I use the shield rendering for
some of my own maps, and I don't use the OSM style for them.

For OSM-Carto to do the shield rendering, Carto itself would have to
handle it.  That requires support in Carto for the GroupSymbolzer in
Mapnik. [5] I don't imagine this would be all that hard a problem, and
again the Carto developers are interested and would most likely accept
a well-done PR.

Mapnik is a non-issue. For my maps, I was able to use Mapnik itself
'out of the box', except for the fact that I render in two layers, one
for fill colour and one to overlay linear features, icons and labels.
(I work it this way because I interrupt linear features with
transparent cutouts for labels, and I want the fill colour to show in
the transparent areas.) This is easy enough in Python; I have no idea
what the impact would be on Carto because at present I don't use it.

The shield placement in Mapnik depends on quite a complex piece of
SQL. [6] The reason for the complexity is that readable shield
placement is extremely difficult when considering a route as a bucket
of discrete ways. It gets much easier if ways can be grouped into the
longest possible linear sequences that share a set of markers (this
happens at [7]). The SQL in turn depends on a couple of extra tables
in the rendering database: 'planet_shieldroute', which enumerates the
route relations that require shields; and 'planet_shieldway', which
enumerates the ways that are members of the routes and gives their
roles.

Because of the complexity of composing the shielded routes at the time
of rendering, Paul Norman and Sarah Hoffmann are convinced that the
approach I'm using would be far too slow if it were tried on an OSM
tile server, and demand a different one. Neither of them has, so far,
sketched an alternative design, and I have so far not been able to
come up with one myself. Paul, in one message, hinted that developing
a renderer for concurrent routes that would satisfy all his
constraints may not, in fact, be possible. Unfortunately for me, this
discussion spilled over into the changes that would be required for
osm2pgsql; I sketched what osm2pgsql would need for the two auxiliary
tables to be created, and drafted a formal proposal [8] for the idea.
(Note that in that proposal I proposed no changes whatsoever to OSM's
main renderer.) The developers of osm2pgsql unambiguously indicated
that a PR implementing the change would not be considered. As a
result, I decided that the project would have to switch to another
database importer, likely imposm3. [9] Maintaining a fork of osm2pgsql
indefinitely was not an acceptable approach to me! Making the switch
would require me to retool quite a lot of unrelated work, so I
reluctantly decided to put the project on hold.

Since then, Joseph Eisenberg and Jochen Topf have stepped in on the
osm2pgsql project and committed the 'Flex' backend. [10] I have not
had the time to try to use the Flex backend to develop an importer for
the tables that I need, but quickly scanning the documentation
suggests that it has everything that the project would require - and
was found acceptable to the osm2pgsql developers. I think, therefore,
that particular roadblock may have been removed.

So the limiting factor, then, is my time - which is in
catastrophically short supply at the moment. I'm facing clamouring
demands at work because people seem finally to be getting the idea
that I'm retiring - with only five weeks left to go.  Once I've
finally left the workplace and had a little bit of time to rest, I
might take another run at the hill.

In the meantime, the Github for the project has some further notes on
what needs to be done to make the shaped rendering and route relation
handling scalable. [11]

On Wed, Sep 23, 2020 at 6:57 PM Andy Townsend  wrote:
> 1. 

Re: [Talk-it] Regione geografica italiana

[Volker Schmidt]

Aggiungo:

Altri aspetti dell'utente lorec10:
ha inserito due "proposte" sue per la viabilità a Firenze come relazioni,
composti da strade taggate highway=proposed, ma le relazioni sono reali.

   - Bypass Gavinana (9123407, v6)
   
   - viabilità Firenze Sud (11186930, v1)
   

Purtroppo non dovrebbero essere in OSM.

Poi ho scoperto che sul sito www.deviantart.com esiste un utente con lo
stesso nome , che pubblica mappe.

Esiste anche un utente lorec10 su Wikipedia e su Pinterest

Se si tratta della stessa persona, direi che si tratta di un'artista.



On Thu, 24 Sep 2020 at 15:43, Volker Schmidt  wrote:

> L'utente lorec10 ha una storia:
>
> nel 2017
>
>- ha lavorato sul confine della Peninsula Iberica (changeset 53355956
>...)
>- "ajouté une proposition de Grand Bruxelles" (CS 54035610 ...)
>- lavorato sul "confine storico Italia-Francia" (CS 54282137...)
>- "added Italian Switzerland" (CS 54740342 ...)
>
> nel 2018
>
>- "Huating total population correction" (CS 64954773) in China
>- "added Zona de Lengua Catalana de Aragón" (CS 62080288 ...)
>
>
> nel 20120
>
>- "relation Grand Genève" (CS 83726885 ...
>- una marea di "correzione confini" (CS 86290173 ...) che si
>riferiscono all'Italia "geografica"
>
>
> Non ho controllato nessuno di questi changeset e non dico niente sulla
> qualità - mi riferisco solo ai commenti inseriti dall'utente.
>
>
> On Thu, 24 Sep 2020 at 12:41, Andrea Musuruane  wrote:
>
>> L'utente lorec10 ha ...
>>
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_-3627051721672370906_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Way Marked Trails - Download GPX - Altitudine

[emmexx]

On 9/24/20 1:15 PM, mich...@michelevicario.net wrote:
> Su Way Marked Trails, i sentieri di montagna hanno il profilo
> altimetrico, ho provato a scaricare alcune tracce GPX, ma l’altitudine
> non viene esportata, c’è un modo per farlo?

https://www.gpsvisualizer.com/elevation

ciao
maxx

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

Re: [Talk-pt] Frases especiais em portugues no Nominatim

[Topo Lusitania Lusitania via Talk-pt]

1
TopoLusitania 

On Thursday, September 24, 2020, 11:31:52 AM GMT+1, David Morais Ferreira 
 wrote:  
 
 Bom dia,

Após uma discussão no canal de telegrama, reparei que algumas frases
"especiais" [1] utilizadas pelo Nominatim [2] não estão traduzidas em
português [3]. Estas frases permitem a pesquisa localizada.

Um exemplo seria quando se procura "farmácia perto de Lisboa" na caixa
de pesquisa. O Nominatim não é capaz de traduzir o pedido para uma
pesquisa de farmácias, e assume que estão a pesquisar
nodes/ways/relations chamadas “farmácia”.


Estas frases são importadas para Nominatim numa base irregular,
portanto pode levar algum tempo a ser importado. Há uma issue no
Github [4] que visa automatizar este processo, por isso espero que
haja uma importação automática, ou manual num futuro próximo.


Há interessados? :)

Cumprimentos

David (dmlu)

[1] https://wiki.openstreetmap.org/wiki/Nominatim/Special_Phrases/PT
[2] https://wiki.openstreetmap.org/wiki/Pt:Nominatim
[3] https://wiki.openstreetmap.org/wiki/Nominatim/Special_Phrases/EN
[4] https://github.com/osm-search/Nominatim/issues/235

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

Re: [Talk-it] Regione geografica italiana

[Volker Schmidt]

L'utente lorec10 ha una storia:

nel 2017

   - ha lavorato sul confine della Peninsula Iberica (changeset 53355956
   ...)
   - "ajouté une proposition de Grand Bruxelles" (CS 54035610 ...)
   - lavorato sul "confine storico Italia-Francia" (CS 54282137...)
   - "added Italian Switzerland" (CS 54740342 ...)

nel 2018

   - "Huating total population correction" (CS 64954773) in China
   - "added Zona de Lengua Catalana de Aragón" (CS 62080288 ...)


nel 20120

   - "relation Grand Genève" (CS 83726885 ...
   - una marea di "correzione confini" (CS 86290173 ...) che si riferiscono
   all'Italia "geografica"


Non ho controllato nessuno di questi changeset e non dico niente sulla
qualità - mi riferisco solo ai commenti inseriti dall'utente.


On Thu, 24 Sep 2020 at 12:41, Andrea Musuruane  wrote:

> L'utente lorec10 ha ...
>


Virus-free.
www.avast.com

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

Re: [Talk-us] place=neighborhood on subdivisions?

[Brian Stromberg]

>
> I don't know that I agree with "suburbs have had a very clear definition
> in the United States for decades."  To wit, some would say that a "suburb"
> can be an incorporated city that is smaller than, but "associated with"
> (and maybe even sharing a partial contiguous boundary with) a larger city,
> of which it "is a suburb."  (For example, Bellevue to Seattle, or El Cajon
> to San Diego).  These are quite precisely defined as incorporated cities
> with rather exact boundaries.
>

This is the only definition I've ever encountered in the US. I don't think
anyone who lives in Seattle would consider Wallingford, Fremont, or
Magnolia to be suburbs, much like nobody would consider the Upper East Side
or SoHo to be suburbs of New York City.

The all-knowing Wikipedia agrees with Minh [1], it looks like OSM uses the
UK/Aus/NZ/Ireland definition of suburb. That usage does not reconcile well
with the American usage which is more of a relational definition (Y is a
suburb of X). It seems like the proper procedure is to avoid using the tag
at all and use neighbourhood instead (if a tag is required). This
contradicts the OSM wiki but seems like the only way to avoid confusion.
The only reason I can think of to use 'suburb' as a tag in the context of
the United States would be if a tag indicating 'central city' or something
similar was introduced.

Just my two cents.

[1] https://en.wikipedia.org/wiki/Suburb

--
Brian


On Thu, Sep 24, 2020 at 5:37 AM Minh Nguyen 
wrote:

> Vào lúc 11:02 2020-09-23, stevea đã viết:
> > On Sep 23, 2020, at 10:51 AM, Brian Stromberg 
> wrote:
> >> A short question of a lengthy response: What is the history behind that
> definition of 'suburb'? Is it a result of the term being used that way in
> UK/Europe/elsewhere? Seems like an odd usage, since "suburbs" have had a
> very clear definition in the United States for decades now, and it has
> nothing to do with neighborhoods.
> >
> > I believe it is UK-derived, as are many OSM "definitions" (usually /
> often clarified in wiki for that key).
>
> If I'm not mistaken, the definition on the wiki seems to align more
> closely with the meaning of "suburb" in Australian English, in which
> it's understood to be anywhere within the city, even near the central
> business district. [1] place=suburb was originally proposed by an
> Australian mapper in 2006. [2] Also, around early 2008, Australia jumped
> from 7.8% to 29% of global place=suburb usage, which could have helped
> to reinforce that definition. [3]
>
> The wiki says place=suburb is "in a place=town or place=city", but that
> doesn't necessarily say it has to lie within the administrative boundary
> that contains the place=town/city as a label. place=town/city is mapped
> as a POI, not as an area with distinct boundaries. But even so, it is
> pretty far from how Americans associate suburbs with distinct
> incorporated municipalities or unincorporated areas on the outskirts of
> the city.
>
> [1] https://en.wiktionary.org/wiki/suburb#English
> [2] https://wiki.openstreetmap.org/wiki/Special:Diff/55503
> [3] https://ohsome.org/apps/dashboard/
>
> --
> m...@nguyen.cincinnati.oh.us
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-it] Alert tematici

[Luca Delucchi]

On Wed, 23 Sep 2020 at 10:00, Cascafico Giovanni 
wrote:

> Ciao Volker ed in Cc Ciao Lista,
>
> ciao a tutti,


> Uno strumento analogo è stato fatto in python (presumo meglio) anche
> da LucadeLu, per cui se Luca si basa su servizi online più "robusti",
> che batta un colpo :-)
>
> La mia implementazione si trova qui [3] per quanto riguarda la richiesta a
overpass api e la trasformazione in diversi formati e per ottenere i
changeset interessati. La spedizione via telegram e mail invece è gestita
qui [4]

[3]
https://github.com/osmItalia/cai_scripts/blob/c21d96bc07ac2d00c97a540ddc538d57af01e296/caiosm/data_from_overpass.py#L608
[4]
https://github.com/osmItalia/cai_scripts/blob/c21d96bc07ac2d00c97a540ddc538d57af01e296/caiosm/data_diff.py#L14

-- 
ciao
Luca

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

[Talk-it] Way Marked Trails - Download GPX - Altitudine

[michele]

Su Way Marked Trails, i sentieri di montagna hanno il profilo altimetrico, ho 
provato a scaricare alcune tracce GPX, ma l’altitudine non viene esportata, c’è 
un modo per farlo?___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Regione geografica italiana

[Andrea Musuruane]

L'utente lorec10 ha commentato il changeset 90871685 con "*Hi, I’m the
original author of the relation, [...] what is talk-it, how do I take part
in the discussion?*" peccato che dopo qualche ora abbia fatto revert:
https://www.openstreetmap.org/changeset/91417698

Ciao,

Andrea




On Tue, Sep 15, 2020 at 9:49 AM totera  wrote:

> Ciao a tutti,
> ricordate la discussione sulla regione geografica italiana [1]?
>
> Ieri Frederik Ramm del DWG ha cancellato la relazione [2], immagino su
> segnalazione di chi vede in essa una rivendicazione territoriale,
> invitandoci comunque a parlarne in lista.
>
> Come ho provato a spiegargli nel commento, a mio avviso si tratta di una
> definizione geografica ampiamente diffusa, che ricordo di aver trovato su
> diversi testi di geografia, di storia, enciclopedie, ecc.
>
> Con essa si intende il territorio a sud dell'arco alpino, che non coincide
> esattamente con i confini italiani (né attuali, né passati), né con le
> rivendicazioni degli irredentisti, che erano basate su considerazioni
> etnolinguistiche e quindi comprendevano anche territori esterni come la
> Dalmazia.
>
> Ciao,
> Gianluca
>
> [1] =
> https://lists.openstreetmap.org/pipermail/talk-it/2017-October/060515.html
> [2] = https://www.openstreetmap.org/changeset/90871685
>
>
>
> --
> 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-pt] Frases especiais em portugues no Nominatim

[David Morais Ferreira]

Bom dia,

Após uma discussão no canal de telegrama, reparei que algumas frases
"especiais" [1] utilizadas pelo Nominatim [2] não estão traduzidas em
português [3]. Estas frases permitem a pesquisa localizada.

Um exemplo seria quando se procura "farmácia perto de Lisboa" na caixa
de pesquisa. O Nominatim não é capaz de traduzir o pedido para uma
pesquisa de farmácias, e assume que estão a pesquisar
nodes/ways/relations chamadas “farmácia”.


Estas frases são importadas para Nominatim numa base irregular,
portanto pode levar algum tempo a ser importado. Há uma issue no
Github [4] que visa automatizar este processo, por isso espero que
haja uma importação automática, ou manual num futuro próximo.


Há interessados? :)

Cumprimentos

David (dmlu)

[1] https://wiki.openstreetmap.org/wiki/Nominatim/Special_Phrases/PT
[2] https://wiki.openstreetmap.org/wiki/Pt:Nominatim
[3] https://wiki.openstreetmap.org/wiki/Nominatim/Special_Phrases/EN
[4] https://github.com/osm-search/Nominatim/issues/235

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

Re: [OSM-legal-talk] Changeset Comments Copyright

[Martin Koppenhoefer]

Am Do., 24. Sept. 2020 um 12:05 Uhr schrieb Tom Hughes :

> On 24/09/2020 10:18, Martin Koppenhoefer wrote:
>
> > it contains changesets, notes, etc. but not diary posts or changeset
> > comments (correct me if I’m wrong).
>
> You're wrong:
>
> https://planet.openstreetmap.org/planet/discussions-latest.osm.bz2



thank you Tom, thought they must be somewhere but couldn't find them at a
glance.
Can still not find the diaries, this seems to imply diaries are not covered
by the CT (but by the ToU), because they are not part of the geodatabase,
while changeset comments are (i.e. are published with ODbL license)?

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

Re: [OSM-legal-talk] Changeset Comments Copyright

[Tom Hughes via legal-talk]

On 24/09/2020 10:18, Martin Koppenhoefer wrote:

it contains changesets, notes, etc. but not diary posts or changeset 
comments (correct me if I’m wrong).


You're wrong:

https://planet.openstreetmap.org/planet/discussions-latest.osm.bz2

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/

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

Re: [Talk-us] While we're fixing things in iterations

[Minh Nguyen]

Vào lúc 15:56 2020-09-23, Andy Townsend đã viết:
I'm actually surprised that someone associated with the OSM US community 
hasn't created a proof-of-concept "good US road route rendering" variant 
of the OSM Carto style on a live server that people can use for 
reference (I'm guessing ongoing server costs wouldn't be huge - a couple 
of $ a day at one of the cheaper hosters).  Of the issues above (1) you 
can ignore in a proof of concept (or deal with some of the edge cases), 
(2) isn't an issue if you're just rendering the US and (3) isn't a 
problem if you can live with downtime at the occasional reload (or have 
two databases - one live, one available to be reloaded if you can't).


In 2012, Phil Gold and Richard Weait developed a "shield renderer" and 
set it up on an OSMUS server. [1] The renderer not only eschewed way 
refs in favor of route relations but also used the network=*, ref=*, and 
modifier=* keys to choose accurate shields consistent with road signage 
-- not a small feat for the U.S.


It was something of a proof of concept, apparently taking an approach to 
processing the relations and generating shields that would've been a 
nonstarter for the openstreetmap-carto project. The project did get 
pretty far in terms of supporting not only state-specific shield designs 
but even plenty of county-specific shield designs and some one-off 
shields. [2] However, the server isn't maintained. It ran out of disk 
space, so it hasn't kept up with OSM planet updates.


More recently, Kevin Kenny reimplemented the shield renderer using a 
more robust approach [3] and has discussed route relation support with 
the openstreetmap-carto developers. [4]


OSMUS is interested in offering an Americentric renderer replete with 
shields. If anyone would like to help with the server situation, let's 
get in touch. Also I'm sure Kevin would welcome any pull requests to his 
osm-shields project, which would probably be a good starting point for 
this renderer if we go with Mapnik and raster tiles.


[1] http://elrond.aperiodic.net/shields/
[2] https://bugs.launchpad.net/osm-shields/
[3] https://github.com/kennykb/osm-shields/
[4] https://github.com/gravitystorm/openstreetmap-carto/issues/596

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


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

Re: [Talk-us] place=neighborhood on subdivisions?

[Minh Nguyen]

Vào lúc 11:02 2020-09-23, stevea đã viết:

On Sep 23, 2020, at 10:51 AM, Brian Stromberg  wrote:

A short question of a lengthy response: What is the history behind that definition of 
'suburb'? Is it a result of the term being used that way in UK/Europe/elsewhere? Seems 
like an odd usage, since "suburbs" have had a very clear definition in the 
United States for decades now, and it has nothing to do with neighborhoods.


I believe it is UK-derived, as are many OSM "definitions" (usually / often 
clarified in wiki for that key).


If I'm not mistaken, the definition on the wiki seems to align more 
closely with the meaning of "suburb" in Australian English, in which 
it's understood to be anywhere within the city, even near the central 
business district. [1] place=suburb was originally proposed by an 
Australian mapper in 2006. [2] Also, around early 2008, Australia jumped 
from 7.8% to 29% of global place=suburb usage, which could have helped 
to reinforce that definition. [3]


The wiki says place=suburb is "in a place=town or place=city", but that 
doesn't necessarily say it has to lie within the administrative boundary 
that contains the place=town/city as a label. place=town/city is mapped 
as a POI, not as an area with distinct boundaries. But even so, it is 
pretty far from how Americans associate suburbs with distinct 
incorporated municipalities or unincorporated areas on the outskirts of 
the city.


[1] https://en.wiktionary.org/wiki/suburb#English
[2] https://wiki.openstreetmap.org/wiki/Special:Diff/55503
[3] https://ohsome.org/apps/dashboard/

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


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

Re: [Talk-se] Samarbete med Wikidataprojekt om naturcampingplatser

[pangoSE]

Hej!

Tusen tack för ditt meddelande. Jag kände inte till den och gillar
den starkt så jag delade på FB :)

Härnösand där jag bor är ganska tom än så länge, men jag la just till
en bärbuske. 

Du har helt rätt i att Commons Appen kanske inte är rätt verktyg
eftersom en mera specialiserad app skulle vara att föredra för just
detta projekt.

Fruktkartan är väldigt intressant eftersom det säkert hyfsat enkelt
skulle gå att göra en fork som möjliggör skapande av en campsite-item
på WD och lägga till bilder också.

Modellen av hur en campsite ska se ut på WD är inte riktigt fullmogen
än heller faktiskt eftersom att den nuvarande modell har lite brister.

En förbättring av modellen skulle kunna vara:
campsite-item
 -> har del: vindskydd-item

I dagsläget har jag lagt upp ett 40-tal items med denna modell
campsite-item
 -> har facilitet: vindskydd
Se
https://query.wikidata.org/#%23Campsites%20and%20shelters%20in%20Sweden%0ASELECT%20DISTINCT%20%3Fitem%20%3FitemLabel%20%3FadminLabel%20%3Fcoor%20%3Fpic%0AWHERE%20%0A%7B%0A%20%20%3Fitem%20wdt%3AP31%20wd%3AQ832778%3B%20%23campsite%0A%20%20%20%20%20%20%20%20wdt%3AP17%20wd%3AQ34%3B%0A%20%20%20%20%20%20%20%20wdt%3AP625%20%3Fcoor%3B%0A%20%20%20%20%20%20%20%20wdt%3AP131%20%3Fadmin%3B%0A%20%20%0A%20%20OPTIONAL%20%0A%20%20%7B%3Fitem%20wdt%3AP18%20%3Fpic.%7D%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22%5BAUTO_LANGUAGE%5D%2Cen%2Csv%22.%20%7D%0A%7D

Skillnaden med den föreslagna modell är hur lätt det är att lägga till
bilder och area på golv, m.m. vilket är alldeles för krångligt i den
nuvarande modell tycker jag.

Ett bra app eller webb-interface skulle kunna dölja denna komplexitet
och bara skapa alla campsite- och vindskydd-items i bakgrunden och
länka ihop dem, ladda upp bilderna på commons och länka till dem med
lämplig egenskap.

Är du intresserad av att tillsamman med mig skapa en
webb-app baserad på fruktkartan för detta?

Mvh
pangoSE

Den Thu, 24 Sep 2020 10:20:26 +0200
skrev Re: [Talk-se] Samarbete med Wikidataprojekt om
naturcampingplatser:

> Fint initiativ!
> 
> Jag är med och (ny)bygger https://fruktkartan.se och har ibland
> funderat på vad man skulle kunna ha en mer generaliserad variant av
> denna till. OSM och Wikidata har som du säger rätt höga trösklar för
> att man ska komma igång och bidra med information.
> 
> Commons-appen var smidig i sin enkelhet. Men det känns som det skulle
> till något slags läge med templates eller workflows, som gör det mer
> rätt fram beroende på vad man vill göra (eller vill få folk att göra).
> 
> --
> Daniel
> lublin.se
> 
> ___
> Talk-se mailing list
> Talk-se@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-se



-- 
--
Cheers/Mvh
Egil Priskorn
CEO Egils Verkstad/Egils Consulting
Sweden

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

Re: [OSM-ja] 自然災害伝承碑データのインポート

[tomoya muramoto]

hayashi様

コメントありがとうございます。
hayashi様にご提示いただきましたが、期間を表す記法があるのを見逃していました。

> start_date=1914..1918 indicates some time during WW1.
とありますので、江戸時代については
start_date=1603..1868
としたいと思います。

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

Re: [OSM-talk-fr] -Interroger les objets- > Requête sur les objets

[Brice]

Le 24/09/2020 à 10:32, leni a écrit :

Il affiche les objets à proximité et les objets englobants.


J'en fais un usage intensif


Et avec les objets englobants, je peux montrer à de nouveaux 
contributeurs qu'il n'est vraiment pas nécessaire de saisir dans 
l’adresses ni addr:city ni le code postal


Je n'avais pas pensé à cet usage, très bonne idée.

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

Re: [OSM-legal-talk] Changeset Comments Copyright

[Martin Koppenhoefer]

sent from a phone

> On 24. Sep 2020, at 02:41, Kathleen Lu via legal-talk 
>  wrote:
> 
> I read "geo-database contributions" as including changeset comments & 
> discussions and map notes, because they are tied to the map features. I do 
> not think geo-database contributions include blog posts.



I can follow this for changeset discussions, but map notes are notes with a 
coordinate, not referring to things we have already mapped (exclusively). This 
is very similar to diaries, which are longer texts with a coordinate 
(optionally), and generally dealing with topics that are in relation with 
creating the geo database.

Cheers Martin 

PS: I don’t know whether it is relevant, but the text on 
planet.OpenStreetMap.org states:
“
Planet OSM
The files found here are regularly-updated, complete copies of the 
OpenStreetMap.org database”





complete copies of the database.

it contains changesets, notes, etc. but not diary posts or changeset comments 
(correct me if I’m wrong).___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [Talk-us] While we're fixing things in iterations

[Minh Nguyen]

Vào lúc 10:45 2020-09-23, Paul Johnson đã viết:

Can we finally fix two other longstanding problems, then?

1. The wiki being incorrect about not counting bicycle lanes.  That's 
not reflective of how validators deal with lanes, how data consumers 
like Osmand or Magic Earth deal with lanes, or how ground truth works.  
The whole "but you can't fit a motor vehicle down it" argument is 
facile, that's what access:lanes=* and width:lanes=* is for.


I agree that width is a poor argument for the status quo, especially 
given the common practice (in California, anyways) of bike lanes that 
double as right turn lanes for cars.


For what it's worth, the lanes=* documentation has long included a 
passage recommending that data consumers treat lanes=* as a minimum 
value rather than a reliable exact lane count. Apparently some mappers 
only count through lanes but exclude turn lanes.


I'm pretty sure existing routers would have no problem with including 
bike lanes in lanes=*, as long as bicycle:lanes=* and vehicle:lanes=* 
are both present. So I think a reasonable migration path would be to use 
the bicycle:lanes=* and vehicle:lanes=* tags to explicitly mark the 
non-auto-centric approach you're advocating.


2. Tagging route information on ways.  It's about a decade too long at 
this point for ref=* on a way to be completely disconnected from the 
entity the tag applies to:  That's why route relations exist.  Biggest 
problem child on this at the moment:  OSM's own tilesets.  Let's drop 
rendering for ref=* on ways and just render the route relations already, 
this and multipolygons are why relations came to exist in the first place.


I'm as excited about route relations as anyone, especially because route 
relations are required for more nuanced route shield selection in 
renderers and routers. But for all the problems route relations solve, 
there are still some unresolved issues:


* Even once rendered maps display pictioral route shields [2], there 
will still be situations where plain text is more appropriate, just as 
on the ground. It isn't always obvious how to transform a particular 
network=* value into a human-readable ref prefix to display in prose or 
read aloud during turn-by-turn navigation. Signposted ref prefixes can 
be pretty idiosyncratic, like "CC" for network=US:NV:Clark. I'm slowly 
building up Wikidata's coverage of signposted road networks and linking 
it to OSM Wiki data items, to make it easier for data consumers to look 
up the human-readable ref prefix on demand [3] or export a lookup table 
like [4] to hard-code. Incidentally, I've also proposed a road name 
formatter property at Wikidata [5], so that data consumers can expand 
network=US:NV:Clark to "Clark County Route", but it hasn't gotten much 
traction yet.


* A way's ref=* key is an ordered list, whereas there's no explicit 
ordering of a way's membership in multiple route relations. (A relation 
explicitly contains its members but not the other way around.) A data 
consumer either has to hard-code some heuristics that may not always be 
accurate [3] or infer the order from the way refs, as OSRM does. [6] 
There's a parallel situation with route numbers associated with a bus 
stop. The route_ref=* key on the stop node makes the order explicit, 
since some agencies don't sort the routes numerically on signage.


* The destination:ref=* key uses the same prefixed syntax as way refs. 
No structured alternative has been formally proposed, but 
destination:network=* is common in Australia (where network=* is common 
on ways) and I've begun using destination:ref:wikidata=* in some parts 
of the U.S. I don't think it's too outlandish to imagine a future where 
navigation software uses destination:wikidata=* to detect street names 
that should be prefixed by "onto" instead of "toward" (instead of using 
destination:street=*, which takes some destinations out of order) and 
uses destination:ref:wikidata=* to choose the right shield to display 
and the correct ref prefix to read aloud.


[1] https://wiki.openstreetmap.org/wiki/Key:lanes#Description
[2] https://github.com/gravitystorm/openstreetmap-carto/issues/508
[3] 
https://wiki.openstreetmap.org/wiki/SPARQL_examples#Human-readable_route_refs

[4] https://tinyurl.com/yxk5ux8h
[5] 
https://www.wikidata.org/wiki/Wikidata:Property_proposal/road_name_formatter

[6] https://github.com/Project-OSRM/osrm-backend/pull/4524

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


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

[OSM-talk-fr] Interroger les objets

[leni]

Bonjour,

Je viens de découvrir "Interroger les objets" avec le bouton droit (w10) 
sur la carte d'OSM.


Il affiche les objets à proximité et les objets englobants.

Avant, j'utilisais dans les couches de carte la case à cocher "Données 
de carte" avec l'inconvénient, quand je sélectionnais un objet beaucoup 
plus grand que la fenêtre, la carte dézoomait, et j'avais tellement 
d'objets dans la fenêtre que cela figeait le navigateur.


Et avec les objets englobants, je peux montrer à de nouveaux 
contributeurs qu'il n'est vraiment pas nécessaire de saisir dans 
l’adresses ni addr:city ni le code postal


Certains d'entre vous connaissaient certainement, mais pas moi !!!

cordialement

leni


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

Re: [Talk-us] United States Bicycle Route System ballot(s) pending AASHTO approval

[Richard Fairhurst]

SteveA wrote:
> With both of us in agreement about tag "proposed:route=bicycle"
> (especially as it co-exists with "state=proposed") can we gain
> some more consensus (here, soon?) allowing us to move closer towards
> recommending in our wiki that we tag proposed USBRs with
> "proposed:route=bicycle"?

Honestly, please don't. state=proposed has been around since the very first 
days of route relations and everything supports it.

proposed:route=bicycle is wordier and has no advantage other than some people 
appear to think tags with a colon in are automatically superior, because XML 
has namespaces and therefore we must too.

Changing the tags will achieve nothing; will mean that data consumers have to 
support two schemes instead of one; and will needlessly break stuff.

On the positive side, great to see all these USBRs going into OSM as ever!

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

Re: [OSM-talk-fr] OSMdata

[Nelson Tayou]

Bonjour,

Merci pour toutes ces remarques !

Pour connaître la requête exécutée pour une couche c'est sur son bouton "i".
[image: Capture 2.png]
[image: Capture.png]
Pour les piscines, c'est* leisure='swimming_pool' AND (tags->'access'='yes'
OR tags->'access'='customers').*

Je trouve les emails compliqués pour échange sur les requêtes des couches
ou leurs pictos, surtout qu'ils conduisent très rapidement à des débats.
Une issue sur github  ou
Loomio  permettrait de
débattre problématique par problématique et garder une trace plus facile à
retrouver.

   - L'ouverture de la plateforme ne se fait plus sur la thématique
   "Tourisme et loisirs", ca avait été fait pour permettre aux visiteurs
   d'ajouter une couche en un seul clic ^^
   - Bonne idée pour le changement de "Fond de carte" à "Plus de fonds
   carte"
   - Tous les titres ont basculé vers "Data OSM"
   - Il est possible d'envisager une plus grande échelle à la fin d'année
   lorsque QGIS aura sorti une version permettant de faire des WMS tuilés avec
   des gutter (pour éviter les cassures des icônes/étiquettes)
   - J'ai listé d'autres remarques d'ici dans les issues de git

Bonne journée à tous

Karl


Le jeu. 24 sept. 2020 à 08:07, Denis Chenu  a écrit :

> Bonjour,
>
> Non, selon le wiki ce n'est pas le cas.
> https://wiki.openstreetmap.org/wiki/Tag:sport%3Dswimming
>
> Il existe :  leisure=swimming_area et leisure=water_park  pour les 2 cas
> dont tu parle.
> Si il faut que cela soit autrement : cela doit être dans le wiki.
>
> Denis
>
>
> Le 23/09/2020 à 18:10, Philippe Verdy a écrit :
>
> sur  "leisure=sports_centre + sport=swimming", cela n'indique pas
> nécessairement le contour de la piscine mais l'emprise de la zone sportive
> qui inclue une piscine, ou un bassin protégé ça peut être zone délimitée
> d'un étang naturel ou artificiel ou d'un lac, et ne concerner qu'une partie
> du bassin, le reste étant pour d'autres activités comme la pratique de
> sports en eau vive avec une autre organisation.
> De plus même si le sport principal c'est la natation, on peut y trouver
> une zone dédié au plongeon, à l'entrainement à la plongée, il peut y avoir
> aussi une utilisation mixte (genre bassin qui peut être couvert d'un
> plancher mobile, et servir à d'autres sports, sans compter aussi des salles
> de culture physique et même dans un parc autour de l'athlétisme, un terrain
> de tennis. S'il y a unen tribune, ce peut être aussi une salle de
> spectacle; dans certains cas c'est aussi un musée où la piscine est
> conservée pour sa beauté architecturale, ses céramiques: la maintenir en
> eau permet de préserver l'équilibre de l'édifice et le bassin n'avoir plus
> qu'une fonction ornementale qui servira seulement à certaines occasions de
> prestige après un controle de l'eau et un peu de rangement autour...)
>
> Le lun. 21 sept. 2020 à 11:34, Denis Chenu  a écrit :
>
>> Quand je parle des erreurs, cela peut être sur la carte ou sur la façon
>> de les récupérer. Donc 2 liens différents : comment contribuer à
>> openstreetmap et comment remonter les erreurs ici(cf exemple).
>>
>> Denis
>> exemple : les piscines ne remonte pas toutes, pas celle en
>> leisure=sports_centre + sport=swimming
>>
>
> Donc si c'est biuen une piscine, autant la délimiter en tant que tel à
> l'intérieur du centre sportif. Enfin des centres sportifs consacrés à la
> natation peuvent ne plus être qu'un point de rassemblement d'un club,
> l'activité étant ailleurs (surtout je pense pour les clubs liés aux équipes
> de compétition, ou la préparation sportive hors eau).
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-se] Samarbete med Wikidataprojekt om naturcampingplatser

[Daniel Lublin]

Fint initiativ!

Jag är med och (ny)bygger https://fruktkartan.se och har ibland funderat på
vad man skulle kunna ha en mer generaliserad variant av denna till. OSM och
Wikidata har som du säger rätt höga trösklar för att man ska komma igång och
bidra med information.

Commons-appen var smidig i sin enkelhet. Men det känns som det skulle till
något slags läge med templates eller workflows, som gör det mer rätt fram
beroende på vad man vill göra (eller vill få folk att göra).

--
Daniel
lublin.se

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

Re: [Talk-us] place=neighborhood on subdivisions?

[Minh Nguyen]

Vào lúc 21:47 2020-09-22, Paul Johnson đã viết:
On Tue, Sep 22, 2020 at 8:56 PM stevea 
> wrote:


If you MUST tag place=neighbourhood (note the u) see if you agree
with me that this tag makes most sense in a hierarchy where
place=suburb (and perhaps quarter, if applicable, is/are above) also
exist(s).  I'm not strictly saying I believe that
place=neighbourhood CANNOT exist without place=suburb, but it makes
me wrinkle my brow a bit at it not fitting as well as a
landuse=residential (multi)polygon might rather generically and
innocently (without any hierarchy required) fit in.


Landuse=residential fits better for the lots within a place, not as a 
substitute for it.


I've never gotten into mapping individual lots, but I agree that 
landuse=residential is a reasonable tag to use in conjunction with 
place=plot. [1] I don't think that needs to be mutually exclusive of 
mapping the surrounding subdivision as a named landuse=residential area.


[1] https://wiki.openstreetmap.org/wiki/Tag:place%3Dplot

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


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

[Talk-se] Samarbete med Wikidataprojekt om naturcampingplatser

[pangoSE]

Hej

Jag är intresserad av att samla in bra data om våra fantastiska svenska 
naturcampingplatser som i dagsläget är antingen undermåligt dokumenterade eller 
helt saknas i OSM och Wikidata.

Jag har tidigare tagit initiativ till att öppna upp data från facebook gruppen 
Vindskydd i Norden och det har visat sig svårt i praktiken trots att 
majoriteten av användarna gärna VILL dela sin data fritt.

Det saknas bra verktyg för att lätt dela både metadata och bild inom 
frikulturrörelsen i dagsläget och Openstreetmap är alldeles för komplicerad för 
många att vilja ge sig in på. Det samma gäller tyvärr Wikidata där man måste 
lära sig en massa egenskaper, m.m.

Vi behöver enkla och välgjorda verktyg för att engagera och fånga upp data som 
i dag i stället delas via och låsas in i tex Facebook. 

Se och delta gärna på  https://wikidata.org/wiki/Wikidata:WikiProject_Campsites 
för att föra detta arbete framåt.

Fördelen med Wikidata som source of truth över OSM är flera:
1) det är CC0 vilket är mindre restriktivt än OSM
2) bilderna kan kopplas via egenskaper som anger vad bilden föreställer
3) Integration med Wikivoyage listings är på gång
4) bättre och snabbare API än overpass och Sophox. 
5) bättre appstöd tex via Commons Appen 
6) enklare API som redan används av tusentals olika utvecklare inkl. tex 
OsmAnd. ___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

[Talk-dk] Samarbete med Wikidataprojekt om naturcampingplatser

[pangoSE]

Hej

Jag är intresserad av att samla in bra data om våra fantastiska svenska 
naturcampingplatser som i dagsläget är antingen undermåligt dokumenterade eller 
helt saknas i OSM och Wikidata.

Jag har tidigare tagit initiativ till att öppna upp data från facebook gruppen 
Vindskydd i Norden och det har visat sig svårt i praktiken trots att 
majoriteten av användarna gärna VILL dela sin data fritt.

Det saknas bra verktyg för att lätt dela både metadata och bild inom 
frikulturrörelsen i dagsläget och Openstreetmap är alldeles för komplicerad för 
många att vilja ge sig in på. Det samma gäller tyvärr Wikidata där man måste 
lära sig en massa egenskaper, m.m.

Vi behöver enkla och välgjorda verktyg för att engagera och fånga upp data som 
i dag i stället delas via och låsas in i tex Facebook. 

Se och delta gärna på  https://wikidata.org/wiki/Wikidata:WikiProject_Campsites 
för att föra detta arbete framåt.

Fördelen med Wikidata som source of truth över OSM är flera:
1) det är CC0 vilket är mindre restriktivt än OSM
2) bilderna kan kopplas via egenskaper som anger vad bilden föreställer
3) Integration med Wikivoyage listings är på gång
4) bättre och snabbare API än overpass och Sophox. 
5) bättre appstöd tex via Commons Appen 
6) enklare API som redan används av tusentals olika utvecklare inkl. tex 
OsmAnd. ___
Talk-dk mailing list
Talk-dk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-us] place=neighborhood on subdivisions?

[Minh Nguyen]

Vào lúc 18:40 2020-09-22, Paul Johnson đã viết:



On Tue, Sep 22, 2020 at 8:36 PM Mike N 
> wrote:


On 9/22/2020 9:26 PM, Paul Johnson wrote:
 >         The extra hamlet nodes are import remainders that haven't
yet been
 >     converted to landuse areas.   The general landuse zones for
that area
 >     have been identified, but do not exactly correspond to the named
 >     subdivisions.   As I get a chance to survey, I divide the
landuse into
 >     subdivisions and convert the node to a named area for the
subdivision.
 >
 >
 > Please don't expand these as landuse, please expand them as
 > place=neighborhood instead.  Landuse polygons should be congruent
to the
 > actual land use.

That's a good point: the subdivisions often contain one or more landuse
basins, clusters of trees, etc.   I've been thinking of them as one big
blob, but it seem correct on a more micromap level to mark them as
place=, and identify the smaller landuse areas (which are sometimes all
residential).


Exactly.  My rule of thumb is if you're thinking about putting a name on 
it, and it's not a shopping center, apartment complex or similar large 
but contiguous landuse, then landuse=* probably isn't what your polygon 
should be.


It's common, intuitive, and IMO beneficial to map a planned, 
suburban-style residential development as a single named 
landuse=residential area. These developments have well-defined 
boundaries and are primarily residential in character. If there are some 
wooded lots in the subdivision, it's perfectly fine to map a 
natural=wood area inside of or partially overlapping the 
landuse=residential area, ideally without being connected to it. This 
approach is supported by longstanding documentation [1], old threads 
[2], and good support in both renderers [3] and search engines.


There have also been old discussions where folks have conflated the 
concept of landcover with landuse. [4] But I find this approach overly 
academic. Taking it to the logical extreme, landuse=residential would 
only be coincident to each house in a subdivision, given that the yards 
are non-dwellings.


I don't see the need for a fundamental distinction between planned 
residential developments consisting of multi-family apartments and those 
consisting of single-family houses, such that the former would be mapped 
as a coherent landuse area but the latter would be a shapeless place 
point. Where there's no such distinction, the landuse areas lend 
themselves to ab intuitive rendering that's good for navigating suburban 
sprawl. [5]


If a planned development truly is actually mixed-use, and not only in a 
garden-level micromapping sense, then something other than landuse=* 
would be reasonable, since a particular landuse doesn't characterize 
that development anyways. Named landuse=residential areas also don't 
tend to make as much sense in urban areas, older inner suburbs, and 
rural areas. But the areas in changeset 91255294 aren't mixed-use 
developments; they're residential areas in a suburban setting.


[1] https://wiki.openstreetmap.org/wiki/Special:Diff/1087300
[2] I previously wrote on this topic in 
 and 
it seemed like other respondents were taking the same approach.

[3] https://github.com/gravitystorm/openstreetmap-carto/issues/351
[4] 
https://lists.openstreetmap.org/pipermail/talk-gb/2017-January/019811.html

[5] https://osm.org/go/ZTVSa4OB

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


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

[OSM-talk-fr] Facebook : défaut d'attribution

[Denis Chenu]

Bonjour,

Je sais que il ya une procédure à suivre, et qui fonctionne sans doute
pour les plus petites entreprises ou même sur certaines plus grosse.
Mais avant de prendre contact avec facebook, j'aimerais vérifier
plusieurs chose.

Le système sur Facebook, exemple sur la page
https://www.facebook.com/Jardins-du-H%C3%AAtre-le-42-ex-Ferme-aux-Loisirs-101234147890218
Ce lieu à une adresse, sur le coté droit :
1. un mini plan est visible (aucune attribution)
2. je clic sur le mini plan : aucun attribution visible
3. Je vois un petit point d'exclamation
4. je clic sur le point d'exclamation :
4.1 : lien "Mention légale du mappage de donnée" clic : ouvre la page
https://www.facebook.com/maps/attribution_terms/
4.2 lien (c) OpenStreetMap donne sur
https://www.openstreetmap.org/copyright/

Alors mes questions :
1. sur la page de copyright (https://www.openstreetmap.org/copyright/) :
il est indiqué "Le crédit devrait apparaître" et non doit (en français):
est-ce que cela veut dire que Facebook satisfait aux obligations légales
? Ou non : les crédits doivent apparaître sur la carte.
2. Peut on bien considérer que 3 clic pour avoir l'information de
copyright des contributeurs ne satisfait pas le "Vous devez également
préciser clairement"
3. Est ce que je dois contacter mapbox, facebook ou les deux ?

Pour information : il y aurait déjà eu un contact avec Facebook :
https://wiki.openstreetmap.org/wiki/Lacking_proper_attribution
(User:Nunocaldeira ) mais non daté.

D'autres ont ilk déjà commencé des remontées à facebook ?

Merci,
Denis



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

Re: [OSM-talk] Can you recommend good introduction to JOSM for 100% osm newbie?

[Maarten Deen]

On 2020-09-24 08:50, Mateusz Konieczny via talk wrote:

I looked at https://wiki.openstreetmap.org/wiki/JOSM and

https://wiki.openstreetmap.org/wiki/JOSM/Guide and
https://learnosm.org/en/josm/

but I am not fully happy about any of them (a bit too much at one for
someone new)

Why not iD: they want to edit and fix hiking relations, what AFAIK is
not well supported in iD


Well, I only know the very basics in iD (and also Potlatch2). I even 
have problems putting a node because it always wants to continue to a 
way and I don't know how to stop this (believe in Potlatch2).
So every editor has a learning curve, even the ones that are supposed to 
be the easy ones like iD or Potlatch2. Because I've been using JOSM for 
years, I know how to use most if not all of the functions and I shun 
away from iD or Potlatch2 just because I've never familiarized myself 
with them (I don't see the need because they lack the features of JOSM).


I don't see what is "much" about 
https://wiki.openstreetmap.org/wiki/JOSM/Guide. 2 steps to start the 
program (if you have Java installed) and the basic functions are 
explained step by step.
Relations are always a more advanced topic, but I can't imagine that 
with a few days of fiddling around you don't get the hang of it.


Regards,
Maarten

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

[OSM-talk] Can you recommend good introduction to JOSM for 100% osm newbie?

[Mateusz Konieczny via talk]

I looked at https://wiki.openstreetmap.org/wiki/JOSM and 
https://wiki.openstreetmap.org/wiki/JOSM/Guide and https://learnosm.org/en/josm/
but I am not fully happy about any of them (a bit too much at one for someone 
new)

Why not iD: they want to edit and fix hiking relations, what AFAIK is not well 
supported in iD
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] OSMdata

[Denis Chenu]

Bonjour,

Non, selon le wiki ce n'est pas le cas.
https://wiki.openstreetmap.org/wiki/Tag:sport%3Dswimming

Il existe :  leisure=swimming_area et leisure=water_park  pour les 2 cas
dont tu parle.
Si il faut que cela soit autrement : cela doit être dans le wiki.

Denis


Le 23/09/2020 à 18:10, Philippe Verdy a écrit :
> sur  "leisure=sports_centre + sport=swimming", cela n'indique pas
> nécessairement le contour de la piscine mais l'emprise de la zone
> sportive qui inclue une piscine, ou un bassin protégé ça peut être
> zone délimitée d'un étang naturel ou artificiel ou d'un lac, et ne
> concerner qu'une partie du bassin, le reste étant pour d'autres
> activités comme la pratique de sports en eau vive avec une autre
> organisation.
> De plus même si le sport principal c'est la natation, on peut y
> trouver une zone dédié au plongeon, à l'entrainement à la plongée, il
> peut y avoir aussi une utilisation mixte (genre bassin qui peut être
> couvert d'un plancher mobile, et servir à d'autres sports, sans
> compter aussi des salles de culture physique et même dans un parc
> autour de l'athlétisme, un terrain de tennis. S'il y a unen tribune,
> ce peut être aussi une salle de spectacle; dans certains cas c'est
> aussi un musée où la piscine est conservée pour sa beauté
> architecturale, ses céramiques: la maintenir en eau permet de
> préserver l'équilibre de l'édifice et le bassin n'avoir plus qu'une
> fonction ornementale qui servira seulement à certaines occasions de
> prestige après un controle de l'eau et un peu de rangement autour...)
>
> Le lun. 21 sept. 2020 à 11:34, Denis Chenu  a écrit :
>
> Quand je parle des erreurs, cela peut être sur la carte ou sur la
> façon
> de les récupérer. Donc 2 liens différents : comment contribuer à
> openstreetmap et comment remonter les erreurs ici(cf exemple).
>
> Denis
> exemple : les piscines ne remonte pas toutes, pas celle en
> leisure=sports_centre + sport=swimming
>
>
> Donc si c'est biuen une piscine, autant la délimiter en tant que tel à
> l'intérieur du centre sportif. Enfin des centres sportifs consacrés à
> la natation peuvent ne plus être qu'un point de rassemblement d'un
> club, l'activité étant ailleurs (surtout je pense pour les clubs liés
> aux équipes de compétition, ou la préparation sportive hors eau). 
>
> ___
> 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