Re: [talk-au] I want to add a national park

[Paul Morton]

I agree the larger government data set, from which I extracted the national
park boundary shapefile, does appear to have an incompatible licence (see
https://creativecommons.org/licenses/by-nc/2.0/). So by extension the
extracted subset cannot be used.

Can you suggest another source for the landuse outline for this public
national park? It must be available under a less restrictive licence
somewhere - many other maps like google etc show the park boundary.

Paul

On 16 October 2017 at 13:29, Ian Sergeant  wrote:

> Do we have permission for that data?  On the face of it the licence is
> incompatible with OSM.
>
> Ian.
>
> On 16 October 2017 at 16:12, Paul Morton  wrote:
>
>> OSM is missing the Leeuwin-Naturaliste National Park land use. I have
>> extracted a shapefile for the park from https://catalogue.data.wa
>> .gov.au/dataset/dpaw-managed-lands-and-waters/resource/274b5
>> ca5-8efd-3f43-92d8-50db803d5c48?inner_span=True and want to import it to
>> OSM.
>>
>> http://wiki.openstreetmap.org/wiki/Import/Guidelines request I ask you
>> for community buy in before importing.
>>
>> Do you want me to import the data for the park?
>>
>> What is the best way to import a shapefile to OSM? Shall I use JOSM or is
>> there a better way?
>>
>> Thanks,
>> Paul Morton
>>
>> ___
>> Talk-au mailing list
>> Talk-au@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-au
>>
>>
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-it] Ultimo tratto relazione Alpinistica

[angelo mornata]

Scusate ma, usando sac_scale per il tratto alpinistico non perdiamo tempistica 
e dislivello  del sopracitato?

Vi sembra giusto farlo?

Grazie per la pazienza

Angelo


Da: matteocalosi 
Inviato: domenica 15 ottobre 2017 12:13
A: talk-it@openstreetmap.org
Oggetto: Re: [Talk-it] Ultimo tratto relazione Alpinistica

Se non ci sono indicazioni/segnavia non mettere nessuna ref e nessuna
relazione sentiero, solo la way con le tag appropriate. Io non metterei
cai_scale in questo caso, sac_scale va sicuramente bene anche per tratti
(semi)alpinistici di questo tipo (scrambling, non vie di roccia vere e
proprie), altrimenti cosa esisterebbero a fare i gradi T4-T6? Per me "via
normale cima x" va bene come nome way.

La relazione andrebbe messa invece sul sentiero per il bivacco (23?) ma in
realtà andrebbe messa a partire da zero su tutti i sentieri della zona che è
da questo punto di vista completamente vuota.


voschix wrote
> forse aiuta in questa discussione
> alpino (it) = alpine (en)
> alpinistico (it) = mountaineering (en)
>
> Sac scale:
> http://www.sac-cas.ch/it/in-cammino/scale-della-difficolta.html;
> http://www.sac-cas.ch/fileadmin/sac/PDF-Dateien/
> Unterwegs/Schwierigkeitsskala/Scala_di_difficolta_per_gite_
> escursionistiche-trekking.pdf
> http://www.sac-cas.ch/it/in-cammino/scale-della-difficolta.html;
> è solo applicabile per trekking alpino, non per tratti alpinistici
>
> http://www.sac-cas.ch/it/in-cammino/scale-della-difficolta.html;
>
> http://www.sac-cas.ch/it/in-cammino/scale-della-difficolta.html;
>
>
>
> 2017-10-15 10:42 GMT+02:00 angelo mornata 

> angelo.mornata@

> :
>
>> https://www.vienormali.it/montagna/cima_scheda.asp?cod=2247
[https://www.vienormali.it/images/fotocime/2247_cimadimalvedello1.jpg]

Cima di Malvedello via normale - Relazione scalata Cima di 
...
www.vienormali.it
Cima di Malvedello: descrizione della via normale di salita a Cima di 
Malvedello nel gruppo Masino con itinerario, tempi e difficoltà (relazione del 
16/06/2012 di ...


>> https://www.vienormali.it/montagna/cima_scheda.asp?cod=2247;
>> Cima di Malvedello via normale - Relazione scalata Cima di ...
>> https://www.vienormali.it/montagna/cima_scheda.asp?cod=2247;
>> www.vienormali.it
>> Cima di Malvedello: descrizione della via normale di salita a Cima di
>> Malvedello nel gruppo Masino con itinerario, tempi e difficoltà
>> (relazione
>> del 16/06/2012 di ...
>> *Situazione fisica della via dal bivacco*: nessun segno di vernice,
>> nessuna traccia, 4/5 ometti non contigui, nessuna croce di vetta,
>> praticamtente via per chi ha esperienza alpinistrica, non particolarmente
>> difficile confermo la difficolta F scala CAI Alpinismo.
>>
>>
>> *Situazione grafica in OSM prima del mio inserimento*: Giorgio83 con
>> metodo sac_scale ha tracciato il sentiero che da Poira di Civo sale al
>> Bivacco, e una via alpinistica più diretta che sale alla cima.
>>
>>
>> *Situazione grafica in OSM attuale*: ho rivisto sentiero, aggiungento
>> cartelli, tratti di sentiero esistenti ma non tracciati nei pressi di Pra
>> Soccio e ultimo tratto prima di arrivare al Bivacco, ho completato il
>> nome
>> del bivacco inserendo i nomi, non solo i cognomi a cui è dedicato, ho
>> inserito il fondo del percorso(ground, gravel ecc) rispettosamente
>> non
>> ho toccato sac_scale esistente, in fine ho inserito traccia che arriva in
>> cima dal canalone.
>>
>>
>> *Attualmente manca*: Pendenze e relazione.
>>
>>
>> *Considerazioni personali*: anche a me piace una relazione unica, la
>> difficoltà da inserire è quella più alta del percorso, in questo caso F
>> (alpinistica passaggi su roccia di 1° grado).
>>
>>
>> *Dubbi d'inserimento*: *nome*... " Cima di Malvedello via normale"... o
>> cos'altro?
>>
>> *ref* quale ref?
>>
>>
>>
>> Spero che le indicazioni fornite siano sufficenti e che non portino a
>> discussioni logorroiche ma pratiche.
>>
>>
>> P.s. Sarò presente al "secondo corso di formazione per operatori
>> sentieri"
>> che si terrà sabato 21 ottobre dalle 09 alle 17 presso Casa Alpina "La
>> Montanina" Via per Campelli 23821 Piani dei Resinelli,  Organizzato dal
>> Cai
>> Riccardo Cassin Lecco e a cui parteciperà sicuramente anche un Vostro
>> rappresentante.
>>
>>
>> Nella speranza di un futuro incontro un gentile saluto
>>
>>
>> Angelo
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> *Da:* Alfredo Gattai 

> alfredo.gattai@

> 
>> *Inviato:* domenica 15 ottobre 2017 00:04
>> *A:* openstreetmap list - italiano
>> *Oggetto:* Re: [Talk-it] Ultimo tratto relazione Alpinistica
>>
>> In effetti nella proposta relativa al cai_scale e nella wiki abbiamo
>> scritto che il cai_scale e' per la relazione. Non e' che abbiamo
>> "proibito"
>> di metterlo sulla way ma non avrebbe molto 

Re: [talk-au] I want to add a national park

[Ian Sergeant]

Do we have permission for that data?  On the face of it the licence is
incompatible with OSM.

Ian.

On 16 October 2017 at 16:12, Paul Morton  wrote:

> OSM is missing the Leeuwin-Naturaliste National Park land use. I have
> extracted a shapefile for the park from https://catalogue.data.wa
> .gov.au/dataset/dpaw-managed-lands-and-waters/resource/
> 274b5ca5-8efd-3f43-92d8-50db803d5c48?inner_span=True and want to import
> it to OSM.
>
> http://wiki.openstreetmap.org/wiki/Import/Guidelines request I ask you
> for community buy in before importing.
>
> Do you want me to import the data for the park?
>
> What is the best way to import a shapefile to OSM? Shall I use JOSM or is
> there a better way?
>
> Thanks,
> Paul Morton
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

[Talk-it] Utilità cartelli limiti di velocità

[Andreas Lattmann]

Buongiorno a tutti, volevo porvi una domanda riguardante l' utilità di inserire 
in OSM i cartelli di velocità massima consentita, perché l' utente ginfix ha 
cancellato i punti vicino la way dicendo che la velocità si indica nella strada 
non con un punto [1]. Domanda, può essere di qualche utilità l'inserimento ed 
il posizionamento dei cartelli di velocità lungo una way?
Grazie per le risposte.

[1] https://www.openstreetmap.org/changeset/52967218
Andreas Lattmann
-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità. 

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

Re: [OSM-talk-be] Importing Villo! API data

[Marc Gemis]

I'm not sure whether it is a good idea to "copy" the address of a
house to another object, that does not really have that address.
As the original address information is "face 35-39 / tegenover 35-39",
the bicycle rental place should not have addr:housenumber=35-39 imho


m.

On Sun, Oct 15, 2017 at 6:57 PM, Yves bxl-forever
 wrote:
> Hello,
>
> In the past weeks I have also wanted to do some cleanup on Villo! stations 
> and it’s a fact that there still quite a lot of work to be done.
>
> Just a few thoughts about the idea of bulk data imports because this is what 
> gave us really "ugly" nodes sometimes.
>
> The name itself is a problem because what they present as the name is 
> actually a string that concatenates the ID of the station, the name and its 
> address.  This is why tagging this as "official_name" does not seem to make 
> any sense.
>
> Their JSON dataset usually looks like this:
>
> "name":"076 - PLACE VAN MEENEN/VAN MEENENPLEIN",
> "address":"PLACE VAN MEENEN/VAN MEENENPLEIN - AV PAUL DEJAER (FACE 35 - 39) / 
> PAUL DEJAERLAAN (TEGENOVER 35 - 39)"
>
>
> And we must translate it as such in our OSM nodes:
>
> ref=76
> name="Place Van Meenen - Van Meenenplein"
> name:fr="Place Van Meenen"
> name:nl="Van Meenenplein"
> addr:street="Place Maurice Van Meenen - Maurice Van Meenenplein"
> addr:housenumber="35-39"
>
>
> It’s probably feasible to parse the fields automatically and make something 
> that looks clean.
> But I am not sure that the street name will always match (see example here, 
> official name has "Maurice" somewhere and our parsing script will not guess 
> it unless you feed it with a list of all streets).
>
> About missing names in one language, this is tricky: normally we should stick 
> with the official name given by the operator.  But another approach will be 
> that if we know of an official translation (because it is the same name as 
> the street or even a bus stop nearby, or a building) it should be used.  And 
> I agree that we should fix typos without asking, like in your example.
>
> Another problem is that the longitude and latitude fields must be checked to 
> avoid putting stations in the middle of an intersection or inside a building.
>
>
> In summary, I will recommend a safer approach, i.e. extracting a list of 
> missing stations, and add them one by one manually, after checking whether 
> the data looks fine.
> But it will be nice to hear the thoughts of other members of the community.
>
> Have a nice day.
>
> Yves
>
>
>
> On Sun, 15 Oct 2017 13:48:42 +0200
> CedB12  wrote:
>
>> Hello all,
>>
>> Lately I have been looking at the Villo! dataset from the JCDecaux API
>> at [1], which is released under the Etalab Open License (see also [2]).
>> I want to consult the community about the use of this data to improve
>> the tagging of the stations we have already mapped. I would also like to
>> discuss a potential import of the hundred or so stations that are
>> reported in the API but have not been mapped yet in OSM.
>>
>> My priority is to fix the tagging of station names and reference
>> numbers, which are often wrong or missing in the already-mapped
>> stations. I am aware of a few quality issues in the names reported by
>> the API (which, as far as I know, are actually the names reported at the
>> stations themselves), so this cannot be a fully automated process. As
>> far as ref tags are concerned, only 25 existing station nodes do not
>> match the API. I have not pushed any change yet in case this thread
>> brings up an objection to the use of this API data.
>>
>> More importantly, given the quality issues in the API names, we would
>> need to discuss how exactly we want to tag names vs. what the "official"
>> names are.
>>
>> To give you a quick example of what kind of problems we can find in the
>> API, consider that one station is named "342 - MAISON COMMUNALE DE
>> BERCHEM ST AGHATE". Like all other stations, the name is in all-caps.
>> This one in particular contains a misspelling: the commune is actually
>> spelled "Berchem-Ste-Agathe". Also, unlike other stations, this one has
>> no official Dutch name, and it is not clear to me whether we should
>> provide our own translation in the name and name:nl tags.
>>
>> I actually got a little bit ahead of myself and had prepared a diary
>> entry draft as well as a more detailed and specific email for this
>> mailing list, but I now realize that unloading all of this at once might
>> have felt a bit forceful. So before I go into the details of all the
>> quirks in the API data and formulate a general proposal for tagging, I
>> wanted to take a more open-ended approach and ask if anyone had anything
>> to share regarding our mapping and tagging of Villo! stations. I am also
>> interested in your thoughts on how we should tag the station I gave
>> above as an example (in terms of name, name:fr, name:nl, and maybe other
>> kinds of name tags like official_name).
>>
>> 

Re: [OSM-talk] New OSM Quick-Fix service

[Yuri Astrakhan]

Tobias, as promised, a thorough response.


On Sun, Oct 15, 2017 at 9:14 AM, Tobias Zwick  wrote:

>
> So, the initial question is: What is the conceptual use case for such a
> tool? Where would be its place in the range of available OSM tools?
>

I think my main target is the JOSM validator's "fix" button. The fix button
allows contributors to auto-fix everything that validator has found, even
without looking at it.  In order to actually see what the autofix did, one
has to select all modified objects, select them all in the "selection"
window, hit "history", wait for all individual objects to download, and
then view individual changes one by one.  It requires a great deal of
dedication and diligence, especially considering that these auto-changes
will be combined with all the other changes the user might have made.
While I trust that many OSM contributors are highly skilled, this
complexity may lead to errors, especially as some people might not know the
exact steps required to view it, cut corners, or think that the "fix"
button should know what it's doing.  Lastly, if I spot a bad autofix, I
have to go to the antiquated JOSM issue reporting site, create an account,
and file a bug. Not an easy endeavor for most of the users, so most would
probably not bother. So the "FIX" button is similar to my "SAVE" button -
users either catch it and do nothing, or they don't, and it gets saved, if
not by this person than by next.

There is the use case where one tagging scheme has been deprecated by
> community consensus and one (combination of) tag(s) should be changed
> into another (combination of) tag(s) globally.
>
> 1. If this does not require humans because both tagging schemes are
> mutually translatable (i.e. lets say for sport=handball <->
> sport=team_handball), then, the edit can be made automatically by a bot.
>

Here are a few of the existing JOSM autofixes done with my tool. See full
list at JOSM autofixes
.
* replace operator=ERDF -> operator=Enedis -- 5422 cases

* use  "cs:" instead of "cz:" prefix for Wikipedia links -- 3 cases

* fix duplicate Wikipedia tag prefixes, e.g.  "ru:ru:Something"  126 cases


While they probably should be ran by a bot, the barrier of entry is too
high to be realistic, especially for the smaller cases.  The very few
globally-licensed bot operators would probably not want to deal with these
small fixups, and for a very good reason - its not worth the risk! The
chance of a programming error far outweighs the benefits of the full
automation at so few objects. In addition to the programming error risks,
the community must have a far more thorough review of the proposal before
"bot-agreeing" to it - because what if there are corner cases that proposal
would break? This fear is what prevents the ease of bot adaption.

Lets look at a another example - a large 215,000+ cases autofix: removing
unnecessary "area=yes". These would greatly benefit from a bot edit, BUT
everyone makes coding mistakes, so there are some chances of a bad autofix.
If a bot owner makes a mistake, it can only be spotted AFTER running the
bot. A user would then post a message on the changeset, bot owner would
have to do a complex full/partial revert, fix the bot, and re-run it.
Painful. BTW, while doing these examples, I spotted a few potential bugs
with the existing JOSM autofixes that noone has reported - another reason
to put it through one-by-one accept/reject testing.

My tool would actually address these issues! When community first proposes
a change, it is relatively easy to add it to the tool - you simply write a
query and save it on a wiki page, possibly under the "proposed" section.
Then, many users can go through it one by one, accepting or rejecting them.
If there are rejects, anyone can go and fix the query, and the process
continues. Once this has been going on long enough, and there hasn't been
any rejects, some bot owner could simply run the exact same query on the
server, auto-applying it to the rest of the world. By that time, the query
has been well tested by many different members, and will be a much greater
quality than some bot author can ever do alone.


> 2. If this does require humans to check the transition to the new tag
> because the deprecated tagging scheme is ambiguous (i.e. , such as
> sport=football -> soccer or american/australian/canadian/... football),
> then, an automatic edit cannot be done. Instead, tools like MapRoulette
> are used.
>

I agree that my tool does not cover this use case yet.  I was thinking of
adding an option picker - a fairly easy task if the options are known in
advance, but this use case is not my primary target at the moment.


>
> 3. Finally, if this also does require humans because a tag combination
> is suspicious (what would show up as warnings in JOSM and what most of
> 

Re: [OSM-talk] Could we just pause any wikidata edits for a month or two?

[Minh Nguyen]

On 15/10/2017 05:39, Michael Reichert wrote:

And even if detecting disambiguation pages in Wikipedia would miss too
much of them, you could use Wikidata to check if the Wikipedia page the
Wikidata item points to is a disambiguation page according to Wikidata?

While wroting the paragraph above, I wondered how the status of a
Wikipedia page a Wikidata item links to is maintained. Is there a bot
updating them every hour in Wikidata? If there is no such bot (or it is
not running every minute or hour), there is no need for wikidata=* tags
in OSM to find wikipedia=* tags pointing to disambiguation pages because
you could get the status of a Wikipedia page by parsing the Wikipedia
page itself.


When a Wikidata item is modified to link to a Wikipedia article (or 
Wikivoyage article etc.), the Wikipedia article automatically links back 
to the Wikidata item. This is a software feature made possible because 
Wikipedia and Wikidata are colocated in the same database cluster. No 
bots are involved; this is unlike the process by which interwiki links 
used to be maintained before Wikidata was introduced.


When a Wikipedia article is renamed, it does temporarily get detached 
from the Wikidata item because the task of updating the Wikidata item 
falls to a process that runs asynchronously on a job queue. It isn't 
possible for OpenStreetMap, as an external site, to automatically update 
its wikipedia tags via the same mechanism. However, in principle, one 
could write a bot that consumes Wikipedia's or Wikidata's recent changes 
feed, looking for features to update. I'm not personally proposing to 
run such a bot, to be clear. And one of the benefits of wikidata tags is 
that such a bot would decrease in necessity over time, since Wikidata 
QIDs are more stable.


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


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

Re: [Talk-it] Coordinate (per me) incomprensibili

[Francesco Pelullo]

Il 16 ott 2017 00:30, "demon.box"  ha scritto:

Ciao, chiedo che cortesemente qualcuno mi illumini a riguardo delle
coordinate e conversioni.


Sono coordinate UTM nel sistema ED50:
https://it.m.wikipedia.org/wiki/ED50

Puoi convertirle in altri sistemi, ad esempio WGS84, con qualche tool
online. Ad esempio:
http://www.geoin.it/coordinate_converter/

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

Re: [Talk-us] Trunk

[Martijn van Exel]

Okay folks. Coming back from not even 48 hours camping and this thread has
exploded. I don't think it benefits anyone to continue in this way.
Valuable insights get lost in the sheer volume of email; arguments are
being repeated.

I am dedicating the next Many Mappy Minutes (our monthly-ish online
hangout) to discuss road classification. I proposed November 15 5:30 PT in
an earlier email to this group. I invite you all to join then.

In the mean time, if you would like to have a more interactive discussion,
please join IRC or Slack and continue the discussion there.

Martijn

On Sun, Oct 15, 2017 at 9:03 AM, Nathan Mills  wrote:

> In the US, we've always treated primary/secondary/tertiary as a way to tag
> importance to the road network, while physical construction was secondary.
> Motorway, of course, was and still is treated differently. Trunk has always
> been stuck in the middle between people who like me and Paul want to use it
> more like motorway but for divided highways and people who want it to mean
> more primary than primary.
>
> That's why we're still taking about it now, long after the usage of other
> highway tag values has long been settled. The closest thing to a decision
> that was ever made was NE2's unilateral mass edit, some of which has been
> reverted, some of which hasn't. Without consensus that the tagging is wrong
> and not just the unilateral decision, I'm not going to go out of my way to
> revert his trunk changes on ways I'm not otherwise editing large portions
> of. It's not a nice thing to do. It's got nothing to do with thinking that
> things should be that way and everything to do with not being a jackass who
> unilaterally imposes their will on the whole community.
>
> -Nathan
>
> On October 15, 2017 1:40:16 AM EDT, Bradley White <
> theangrytom...@gmail.com> wrote:
>
>> If we can determine importance (which is what the 'highway=' tag
>> fundamentally represents per the wiki) solely by what's on the ground,
>> why not just tag what's physically there, ditch the 'highway' tag
>> altogether, and let the renders handle it with their own algorithms?
>>
>> On Sun, Oct 15, 2017 at 12:19 AM, Paul Johnson  
>> wrote:
>>>

  The US is pretty well known for overbuilding highways.  Are we trying to
  document how things are on the ground or how things are actually
  connected?  If we're going for the former, then yeah, only Bend Parkway 
 and
  a brief streak through Klamath Falls is a trunk part of US 97.  If we're
  going for the latter, then go ahead with NE2's idea and smash almost
  everything into trunk.
>>>
>>>
>>>
>>>
>>> Keep hitting send too soon.  Personally, I find what's on the ground to be
>>> more useful than the connections.  Game theory and any routing engine can
>>> figure out the connections.  But knowing what's a stupid rural road with an
>>> overly generous speed limit and what's almost but not quite a freeway is
>>> more useful.  If I'm driving a big rig going from southwestern Canada or
>>> Alaska to somewhere in Nevada, I don't give two shakes what some toolbag
>>> things is the most prominent road.  I care more about what *actually is a
>>> big road*.  Calling a two leg segment of US 97 30km outside of East
>>> Butthump, Oregon a trunk is a great disservice when it's basically on par
>>> with County Road Number Who Even Cares tracing off to Outer
>>> Smalltownsville, other than the fact that it goes through.  Calling it a
>>> trunk when it's not is going to set an unreasonably high expectation for
>>> what is otherwise an overtravelled, glorified two digit National Forest
>>> route through the east Cascades frontier.  Primary is definitely ample for
>>> that road, even if you're going a more obscure minor haul route like Salem
>>> to Reno.
>>>
>>
>> --
>>
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
> ___
> 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-in] old_name tag for merged Associate State Banks

[Arun Ganesh]

Overpass has a useful function to query historic data using the data
parameter. It also supports a CSV output.

Putting them together, this query will give a CSV of the OSM id and names
of banks and atms: http://overpass-turbo.eu/s/sms . This should hopefully
match the spreadsheet and be useful for such tasks in future.

Theres also a super handy script to update data from a CSV to OSM
https://github.com/srividyacb/osm-name-translation. It was mainly created
to update translations, but this seems like a good use case as well. We
should just get consensus that we want to do this.



On Sat, Oct 14, 2017 at 2:43 AM, Warin <61sundow...@gmail.com> wrote:

> Revert the name changesets and start again?
>
> The new changes should then place the original name into old_name and
> introduce the new name.
>
> On 13-Oct-17 11:08 PM, Srihari Thalla wrote:
>
> Chetan, Is there any possibility to update them via script?
>
> I am not sure if Overpass API can download based on changes in changesets.
> If not, manually going through the spreadsheet would be the obvious choice.
>
> It would be better to write a script to query the histories of Bank
> amenity objects
> and import them into JOSM and update.
>
> Scripting would, of course, need approval from the community!
>
> Here are my changesets: OSMCha: https://goo.gl/V76HoH
>
> I bundled all the changes into two changesets. (There are 5 other singled
> out changesets too.)
>
> Manually :: Downloading the changeset -> going through each object history
> -> updating each object
>
> What do you say would be a good idea?
>
> On Fri 13 Oct, 2017, 17:03 Chetan H A,  wrote:
>
>> Srihari, makes sense. I wonder how to get back deleted old names and add
>> it in old_name tag in one go like you added?
>>
>>
>>
>> On Fri, Oct 13, 2017 at 2:37 PM, Srihari Thalla 
>> wrote:
>>
>>> Hi,
>>>
>>> Back in May 2017, we have updated the name tags of merged Associate
>>> State Banks from their old names (State Bank of xxx) to the new name,
>>> "State Bank of India".
>>>
>>> We have identified and tracked the entries in a spreadsheet [1]. I have
>>> updated many entries.
>>> However, I forgot to add the old_name tag with the old name (State Bank
>>> of xxx) and just updated the name tag to State Bank of India.
>>>
>>> I think it is good to have the old names in the old_name tag as people
>>> might still remember the banks with their old names.
>>>
>>> Thoughts?
>>>
>>> Cheers,
>>> Srihari
>>>
>>> [1] - https://docs.google.com/spreadsheets/d/
>>> 17VXVWQVF1rujmQiSQVrXiTOi2sRImh29I2JCGWCKaxc/edit#gid=1622201629
>>>
>>> talk-in Discussions
>>> [1] - https://lists.openstreetmap.org/pipermail/talk-in/2017-
>>> April/002862.html
>>> [2] - https://lists.openstreetmap.org/pipermail/talk-in/2017-
>>> May/002888.html
>>>
>>> cc Chetan, Bharata
>>> --
>>> Cheers,
>>> Srihari
>>>
>>> ___
>>> Talk-in mailing list
>>> Talk-in@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-in
>>>
>>>
>> ___
>> Talk-in mailing list
>> Talk-in@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-in
>>
> --
> Cheers,
> Srihari
>
>
> ___
> Talk-in mailing 
> listTalk-in@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-in
>
>
>
> ___
> Talk-in mailing list
> Talk-in@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-in
>
>
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

[OSM-talk] Hardware partnership and projects wishlist

[Daniel Koć]

Hi,

I'm looking for partners with hardware resources in Poland to use it for 
some interesting OSM-related projects.


I've made basic research with OSMF, French and German pages about 
hardware and network connectivity and it looks like they collaborate 
with academic and business world:


- https://hardware.openstreetmap.org/thanks/

- https://www.openstreetmap.fr/soutiens

- https://wiki.openstreetmap.org/wiki/FOSSGIS/Server

What are your experience with such collaborations in different places 
(not only in GB, FR and DE)? Any advices or warnings?


I have few ideas what could be done with enough hardware resources 
available, but I'm also interested what other people think could be the 
most wanted and useful projects for the OSM community?



--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


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

[OSM-talk] Island/islet area tagging

[Daniel Koć]

Hi,

We'll probably start to render island/islet labels earlier (if the code 
will be merged, of course), so I've made a short info with renderings on 
z4-z6 showing only island names on the planet:


https://github.com/gravitystorm/openstreetmap-carto/pull/2890#issuecomment-336664545

It looks like some of the biggest islands are not tagged this way - 
probably because they are already visible as a land and tagged as admin 
entity, but not all the maps are political, so please add the proper 
tagging to make island/islet dataset more complete.



--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


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

[Talk-it] Coordinate (per me) incomprensibili

[demon.box]

Ciao, chiedo che cortesemente qualcuno mi illumini a riguardo delle
coordinate e conversioni.

Per un punto di interesse, prima mi venivano passati questi valori:

X 1598477,351   
Y 5044306,337

con i quali, dopo averli convertiti da "Piane Gauss-Boaga Roma40" a "WGS84
gps", mi ci ritrovavo perfettamente ma ora per lo stesso punto, e sottolineo
per il medesimo punto, mi vengono passate queste coordinate:

X598449,4359
Y5044285,948

e non mi ci ritrovo più. che formato sono secondo voi? Soprattuto il
valore di X è tutt'altro rispetto a prima. Come le converto in formato GPS?
Grazie.
--enrico




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

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

Re: [OSM-talk-be] Meetup about rendering of maps

[Marc Ducobu]

Hello,

Two years ago I created a map with QGIS & OSM. You can find the QGIS style
there : https://github.com/Champs-Libres/QGIS-OSM-styles

I explained the method is a blog-post (
http://blog.champs-libres.coop/carto/2015/04/10/creer-une-carte-cycliste-avec-osm-et-qgis.html
). I took some inspiration from
https://anitagraser.com/2014/05/31/a-guide-to-googlemaps-like-maps-with-osm-in-qgis/
& https://www.youtube.com/watch?v=Zsf4OxUDS44

Have a nice evening.

Marc

On 10 October 2017 at 18:04, joost schouppe 
wrote:

> I set up a repo a couple of days ago. I've now added you, Jo.
>
> This is the URL:
> https://github.com/osmbe/qgis_rendering
>
> I use sqlite databases (which behave like files) in QGIS, and they behave
> just fine.
>
> 2017-10-09 14:45 GMT+02:00 Jo :
>
>> Yes, we can look into github on Wednesday evening. Joost, please set up a
>> repo for it.
>>
>> OK, so with a bit of luck we have Clem to show Maperitive and Pieter to
>> show QGIS for rendering.
>>
>> Yesterday I started watching this series:
>> https://www.youtube.com/playlist?list=PL7HotvlLKHCs9nD1fFUjSOsZrsnctyV2R
>>
>> This explains it quite succinctly, but putting it into practice is still
>> a challenge with QGIS. Mine crashes a lot. Now I'm thinking it would be
>> better if I would involve PostGIS, instead of working with files, for a
>> larger region.
>>
>> Somehow Maperitive was able to cope with it, but there my problem is
>> automating the workflow to get consistent results.
>>
>> Jo
>>
>> 2017-10-05 11:06 GMT+02:00 Pieter Brusselman <
>> pieter.brussel...@tragewegen.be>:
>>
>>> @Joost,
>>>
>>> OK, you can do that.  But I need a short intro in Github.  Maybe
>>> wendsday evening?
>>>
>>>
>>> Pieter Brusselman
>>> *Cartografie ~ Projectmedewerker*
>>>
>>> [image: (logo boompja)] 
>>>
>>> *A* Kasteellaan 349
>>>  A,
>>> 9000 Gent
>>> *T* 09 / 331 59 27
>>> *W *www.tragewegen.be
>>>
>>> [image: logo facebook] 
>>>
>>> ter info: ik werk niet op vrijdag
>>> Op 5/10/2017 om 10:48 schreef joost schouppe:
>>>
>>> Pieter,
>>>
>>> I could make a repository on our github page https://github.com/osmbe/
>>> for a QGIS project if you're interested.
>>>
>>> 2017-10-05 10:22 GMT+02:00 Jo :
>>>
 Hey, that is great news! I will also come to FOSS4G the day after our
 Meetup. Somebody who uses Maperitive to render maps for the GR guides will
 probably also join us on Wednesday evening.

 Jo

 2017-10-05 9:33 GMT+02:00 Pieter Brusselman <
 pieter.brussel...@tragewegen.be>:

> Hi,
>
> The last year we (trage wegen vzw) made a lot of maps based on
> OSM-data using QGIS.  On octobre 26th we give a talk about this on FOSS4G.
> But I like to come to the meeting to talk about this and sharing 
> experience
> (and stylsheets :-))
>
> Grtz,
> Pieter
>
> Pieter Brusselman
> *Cartografie ~ Projectmedewerker*
>
> [image: (logo boompja)] 
>
> *A* Kasteellaan 349
>  A,
> 9000 Gent
> *T* 09 / 331 59 27
> *W *www.tragewegen.be
>
> [image: logo facebook] 
>
> ter info: ik werk niet op vrijdag
> Op 5/10/2017 om 9:11 schreef joost schouppe:
>
> I like to use QGIS for basic stuff. E.g. use an open layers background
> map, and some data on top of that to highlight certain details. E.g. the
> maps in this diary were made with OSM data queried from overpass and some
> open layers map: http://www.openstreetmap.
> org/user/joost%20schouppe/diary/38103
>
> It's also relativly easy to use QGIS for rendering OSM data using a
> sqlite database (and that's easy to make within the package, based on a
> .pbf file). I don't have experience making a pretty map that way, but it
> can be quite useful to make maps highlighting specific kinds of data. E.g.
> maps like these are easy to make in QGIS: http://www.openstreetmap
> .org/user/joost%20schouppe/diary/40267
> (though here the data comes from the osm-history toolchain, not just
> from a pbf file)
>
> I think theoretically you could use QGIS and a stylesheet to make a
> pretty map from scratch, but haven't seen an example yet. And someone has
> been working for years on doing something similar in ArcGIS, and I don't
> think he released it yet.
>
> 2017-10-05 8:17 GMT+02:00 Jo :
>
>> Hi,
>>
>> During the next Leuven Monthly OSM Meetup I would like to discuss
>> rendering. I was using Maperitive in the past to create this:
>>
>> https://upload.wikimedia.org/wikipedia/commons/a/a2/Pad_van_
>> Ad_op_OSM.png
>>
>> I know. I should update that map more regularly...

Re: [Talk-it] Tag bacheca necrologi

[Volker Schmidt]

Come s chiamano queste bacheche ufficialmente? Dalle mie parti (Padova) o
mi sono sfuggite  o non esistono.

2017-10-15 19:45 GMT+02:00 Marco :

> Immagino che ogni comune in Italia abbia un discreto numero di "bacheche"
> apposite per i necrologi, quindi magari qualcuno prima di me si è già posto
> il problema di quale tag scegliere. Sulla wiki non ho trovato nulla di
> simile, come posso mapparle?
>
> Grazie
>
> Marco
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[OSM-talk-fr] office=foundation

[Paul Desgranges]

Bonsoir,
J'ai créé la page en français sur office=foundation, avec qq trucs.
Je prendrais tous les commentaires, si il y en a, pour faire évoluer la page
http://wiki.openstreetmap.org/wiki/FR:Tag:office%3Dfoundation
merci par avance!
Paul

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

Re: [OSM-talk] New OSM Quick-Fix service

[Frederik Ramm]

Yuri,

On 10/15/2017 11:53 AM, Yuri Astrakhan wrote:
> Christoph, kindly explain, instead of making snide remarks. You have not
> added to the discussion, but instead raised the level of toxicity of
> this channel even further.  Note that several people have already noted
> that this channel is toxic and refused to participate in it,

There's toxic talk and toxic behaviour. I have called you out because I
think that for the last half year, your behaviour has been toxic. You
have used nice and pleasant words, reassured us all that you mean no
evil, but if one looks at your actions, it is clear that you have very
little respect for OSM and how we've been doing things until now.

Now in certain circles that might be called "disruptive" and seen in a
positive way; but I think that disrupting OSM is not positive, and I
think you have been doing that very brazenly. When I attack you with
clear words, then that is a response to you attacking OSM with clear
actions, with a speed and intensity that few of us "spare time OSMers"
can match. Before we really had time to see what you were doing, you had
already automatically added often questionable Wikidata tags to tens of
thousands of objects. You've built a query engine to work with OSM and
Wikidata and are pushing that relentlessly, to a point where the
decision of just how much Wikiadata linking we want in OSM is totally
taken out of our hands.

Repeatedly during the process, you have said things like "I don't see
why people should waste time on  when it can be done
automatically". Then some explained to you why it would be better and
more OSM-like to *not* do it automatically. And the next thing you do is
come up with a tool to allow even more de-facto automatic changes
because you either haven't understood, or simply don't care for how OSM
operates.

I think the latter is the case; you find it silly, backwards, a waste of
time to do what we do, and how we do it. To you, OSM is not a community
of people, it's just a database that can be queried, bulk-updated, and
bulk-updated again. Numerous efforts have been undertaken to explain
this to you but you just don't want to see it; you insist on treating
OSM, on treating us all, as if we were just too stupid to simply do a
few SQL updates on our database. Your "Quick Fix" tool is either a sign
that you have understood nothing and really believe that a tag change
edit can be "checked" by someone while looking at a zoom level 4 map, or
it is another brazen attempt at subverting our quality standards,
seducing even more people to make the kind of poor-quality,
lack-of-local-knowledge types of edits that you have often been
criticized for.

If you are harshly criticized then it is because your actions are
dangerous to OSM, and because you haven't listened to prior friendly
messages and warnings. You have harmed OSM, and when this was pointed
out to you, you harmed OSM even more, and now you're proudly presenting
a software that will help others to harm OSM. You have had ample
friendly warnings, but you have heaped toxic actions on toxic actions.

You have been criticised professionally and in a friendly way and you
replied along the lines of "thank you I will consider it", and continued
- again and again. This may look friendly on paper; you didn't use any
swear words and you always said thank you. But after a while, the "thank
yous" ring hollow. Your actions are treating OSM with disrespect, and
have been doing so for the last half year. You have no right to complain
about "toxicity".

Bye
Frederik

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

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

Re: [Talk-it] Nomi di fiumi e torrenti, e (ab)uso di waterway=river

[Max1234Ita]

Daniele wrote
> Le targhe su superstrade/autostrade ecc. indicano generalmente il nome del
> ponte/cavalcavia stessi, non quelli del fiume/torrente che scavalcano. 
> Ma probabilmente sono più pratico di viabilità ordinaria che autostradale.
> 
> Dom 15/10/17, demon.box 

> e.rossini73@

>  ha scritto:
> 
>  Oggetto: Re: [Talk-it] Nomi di fiumi e torrenti, e (ab)uso di
> waterway=river
>  A: 

> talk-it@

>  Data: Domenica 15 ottobre 2017, 21:00
>  
>  Daniele wrote
>  >
>  Inoltre quelle (rare) volte che sul ponte che lo scavalca vi
>  è la targa
>  > indicante il corso
>  d'acqua superato mi sembra ci sia scritto solitamente,
>  
>  > ad esempio "Fiume Po" , e
>  non semplicemente "Po"
>  
>  Come puoi vedere purtroppo per ogni
>  "regola" esiste già più di una
>  eccezione:
>  
> 
> http://gis.19327.n8.nabble.com/file/t339261/galleria-Trentapassi.jpg;
>  
>  
>  In provincia di Brescia
>  c'è infatti la superstrada che sale in vallecamonica
>  lungo la quale tutti i cavalcavia e tutte le
>  gallerie sono segnalate nel
>  modo in cui
>  vedi, cioè sul relativo cartello è stato sempre omesso
>  il
>  prefisso "Galleria" piuttosto
>  che "Ponte" o "Calcavia" o
>  "Viadotto".
>  E volendo vedere
>  quando li ho mappati mi sono chiesto cosa mettere in
>  
>  bridge:name e tunnel:name
>  
>  e per ora sono stato ligio a
>  ciò che c'è scritto sul cartello omettendo il
>  prefisso.
>  Ciao.
>  
>  --enrico
>  


Non per fare l'avvocato del diavolo, ma... a voler ben vedere la "lettura
del cartello è incompleta: si trascrive solo la dicitura scritta a chiare
lettere ma si trascura la parte "iconografica" (rassegniamoci al fatto che
ormai le lingue moderne si stanno sempre più contaminando con ideogrammi di
vario genere).

Sicuramente, il cartello che indica l'inizio di un tunnel si compone di due
parti: una è l'indicazione "grafica"  del manufatto che si sta per
incontrare: 

https://it.wikipedia.org/wiki/File:Italian_traffic_signs_-_galleria.svg
e che indica, appunto "Galleria" (o Tunnel, Galería, Galerie, галерея,
Galerij, ecc. a seconda della lingua di chi lo legge)

Segue poi un altro cartello, a fondo bianco, recante il nome del medesimo
(nel caso citato "Trentapassi".

La lettura completa del segnale restituirebbe quindi "Galleria Trentapassi",
almeno nella nostra Lingua.
 :)

Poi, sul fatto che il nome riportato sul cartello indichi il nome della
montagna  (se è un tunnel) o del corso d'acqua che viene oltrepassato, sono
più che d'accordo: personalmente ho visto diversi casi in cui il nome si
riferisce ad esempio a paesi che si trovano sopra, sotto o nelle immediate
vicinanze.
So addirittura di un "viadotto Campo Sportivo", che dovrebbe trovarsi nei
dintorni di Savona (http://motorways-exitlists.com/europe/i/a10.htm)

Max




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

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

Re: [OSM-talk-be] http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Walking_Routes

[Wouter Hamelinck]

I agree that the page is getting huge. The three page suggestion looks OK
to me. It is probably best to keep a general page that basically links to
the three new pages.
Short remark about the nordic walking routes: when I added the table of the
routes in Viroinval, I did it on the walking routes page because creating a
new page for nordic walking seemed like overkill.  If we are splitting the
page, it might be worth considering to create a separate page for nordic
walking routes. But apart from the Vironval network, I am personally not
aware of other specific routes. If there are others, I would be in favour
of a separate page. If those in Viroinval are the only ones, I would rather
keep them on the walking page.

wouter


On Sat, Oct 14, 2017 at 6:03 PM, joost schouppe 
wrote:

> Hi Stijn,
>
> That is a huge page!
>
> I would suggest splitting it in three:
>
> - long distance routes
>
> - walking node networks
>
> - local routes
>
>
>
> 2017-10-03 20:20 GMT+02:00 Stijn Rombauts :
>
>> Hello,
>>
>> Could it be that this page [1] has become too big, with too many links to
>> relations? I hope you see what I see: from the 5th relation in the Nordic
>> Walking table all relations are replaced by a Template:Relation.
>> If so, what are we going to do about it? Split it up? In how many pages?
>>
>> Regards,
>>
>> StijnRR
>>
>> [1] http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Walki
>> ng_Routes#Nordic_Walking
>>
>>
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>>
>
>
> --
> Joost Schouppe
> OpenStreetMap  |
> Twitter  | LinkedIn
>  | Meetup
> 
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>


-- 
"Den som ikke tror på seg selv kommer ingen vei."
   - Thor Heyerdahl
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk] [Tagging] New OSM Quick-Fix service

[Éric Gillet]

2017-10-13 23:25 GMT+02:00 Yuri Astrakhan :

> I would like to introduce a new quick-fix editing service.  It allows
> users to generate a list of editing suggestions using a query, review each
> suggestion one by one, and click "Save" on each change if they think it's a
> good edit.
>
> For example, RU community wants to convert  amenity=sanatorium  ->
> leisure=resort + resort=sanatorium.  Clicking on a dot shows a popup with
> the suggested edit. If you think the edit is correct, simply click Save.
> Try it:  http://tinyurl.com/y8mzvk84
>
> I have started a Quick fixes wiki page, where we can share and discuss
> quick fix ideas.
> * Quick fixes 
> * Documentation
> 
>
> This is a very new project, and bugs are likely. Please go slowly, and
> check the resulting edits. Let me know if you find any problems. Your
> technical expertise is always welcome, see the code at
> https://github.com/nyurik/wikidata-query-gui  The service has adapted
> some code from the Osmose project (thanks!)
>
> TODO:
> * Allow multiple edits per one change set
> * Show objects instead of the dots
> * Allow users to change comment before saving
>

(Posting also in talk ML.)

First of, I comend you for the calm you've expressed in this thread, in
face of the hostile (I don't mean constructive criticism) answers you've
been getting.

I think this is a nice tool, however as for every tool, it can be used for
good and bad things. As long as you adress pertinent feedback I encourage
you to continue developping this tool.
As Simon pointed out, having a "False positive" button on each correction
would be really helpful (like Osmose for example).
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

[Éric Gillet]

2017-10-14 12:05 GMT+02:00 Christoph Hormann :

> On Friday 13 October 2017, Yuri Astrakhan wrote:
> > I would like to introduce a new quick-fix editing service.  It allows
> > users to generate a list of editing suggestions using a query, review
> > each suggestion one by one, and click "Save" on each change if they
> > think it's a good edit.
>
> This is a tool to perform automated edits as per the automated edits
> policy.  A resposible developer of such a tool should inform its users
> that making automated edits comes with certain requirements and that
> not following these rules can result in changes being reverted and user
> accounts being blocked.
>

Every editor can be used for "mechanical edits". The responsability of
doing correct changes and changesets lies on the user of such tools.
I don't think we can blame a tool for blind, thoughtless edits by users.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

[Stephen Doerr]

On 15 October 2017, at 13:51, Yuri Astrakhan  wrote:

>Andy, first off, this whole email thread was about "hi, this is a new, rough 
>around the edges tool I'm building, that MIGHT benefit SOME people" 
>Suggestions/ideas welcome.  When you say "stop" - stop what? Stop coding?

The only thing I would say is, as the tool is clearly still at the 
proof-of-concept stage / in development, it should be hitting the test database 
and not the live one. It's not clear to me from what you've posted that that's 
the case: can you reassure us on that point?

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

Re: [Talk-it] information=board vuoto!!

[demon.box]

Certo sono perfettamente d'accordo che essendo vuote non danno nessuna
informazione
Ciao.
--enrico




--
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-it] information=board vuoto!!

[Alfredo Gattai]

Se sono vuote io non le mapperei affatto. E' evidente che non c'e'
interesse a ripristinarle quindi che indicazione si da mappandole?

2017-10-15 21:06 GMT+02:00 demon.box :

> Mi è capitato spesso in zone montane o collinari, comunque molto distanti
> dai
> centri abitati (anche a 1500 metri di altitudine) di trovare delle belle
> bacheche in legno, in perfetto stato ma sempre rigorosamente vuote
> nonostante miei ripetuti passaggi anche a distanza di anni
> Come le mappo, visto che non si tratta di un caso isolato? Così va comunque
> bene?
>
> tourism=information
> information=board
> material=wood
>
> Di sicuro non metto nessun board_type ma per indicare che è sempre vuota
> non
> metto nulla?
> Grazie.
> --enrico
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-it] R: Tag bacheca necrologi

[Daniele]

Nei piccoli comuni spesso non ci sono bacheche apposite, bensì i necrologi 
vengono apposti nelle bacheche destinate agli avvisi istituzionali del comune.
Inoltre in alcune grandi città non ci sono proprio (ad esempio a Torino non li 
ho mai visti)

Dom 15/10/17, Marco  ha scritto:

 Oggetto: [Talk-it]  Tag bacheca necrologi
 A: "openstreetmap list - italiano" 
 Data: Domenica 15 ottobre 2017, 19:45
 
 Immagino che ogni comune in Italia abbia un
 discreto numero di 
 "bacheche" apposite per i necrologi,
 quindi magari qualcuno prima di me 
 si è già posto il problema di quale
 tag scegliere. Sulla wiki non ho 
 trovato nulla di simile, come posso
 mapparle?
 
 Grazie
 
 Marco
 
 
 ___
 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] Nomi di fiumi e torrenti, e (ab)uso di waterway=river

[Daniele]

Le targhe su superstrade/autostrade ecc. indicano generalmente il nome del 
ponte/cavalcavia stessi, non quelli del fiume/torrente che scavalcano. 
Ma probabilmente sono più pratico di viabilità ordinaria che autostradale.

Dom 15/10/17, demon.box  ha scritto:

 Oggetto: Re: [Talk-it] Nomi di fiumi e torrenti, e (ab)uso di waterway=river
 A: talk-it@openstreetmap.org
 Data: Domenica 15 ottobre 2017, 21:00
 
 Daniele wrote
 >
 Inoltre quelle (rare) volte che sul ponte che lo scavalca vi
 è la targa
 > indicante il corso
 d'acqua superato mi sembra ci sia scritto solitamente,
 
 > ad esempio "Fiume Po" , e
 non semplicemente "Po"
 
 Come puoi vedere purtroppo per ogni
 "regola" esiste già più di una
 eccezione:
 
 
 
 
 In provincia di Brescia
 c'è infatti la superstrada che sale in vallecamonica
 lungo la quale tutti i cavalcavia e tutte le
 gallerie sono segnalate nel
 modo in cui
 vedi, cioè sul relativo cartello è stato sempre omesso
 il
 prefisso "Galleria" piuttosto
 che "Ponte" o "Calcavia" o
 "Viadotto".
 E volendo vedere
 quando li ho mappati mi sono chiesto cosa mettere in
 
 bridge:name e tunnel:name
 
 e per ora sono stato ligio a
 ciò che c'è scritto sul cartello omettendo il
 prefisso.
 Ciao.
 
 --enrico
 
 
 
 
 --
 Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
 
 ___
 Talk-it mailing list
 Talk-it@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-it
 

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

[Talk-it] information=board vuoto!!

[demon.box]

Mi è capitato spesso in zone montane o collinari, comunque molto distanti dai
centri abitati (anche a 1500 metri di altitudine) di trovare delle belle
bacheche in legno, in perfetto stato ma sempre rigorosamente vuote
nonostante miei ripetuti passaggi anche a distanza di anni
Come le mappo, visto che non si tratta di un caso isolato? Così va comunque
bene?

tourism=information
information=board
material=wood

Di sicuro non metto nessun board_type ma per indicare che è sempre vuota non
metto nulla?
Grazie.
--enrico




--
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-it] Nomi di fiumi e torrenti, e (ab)uso di waterway=river

[demon.box]

Daniele wrote
> Inoltre quelle (rare) volte che sul ponte che lo scavalca vi è la targa
> indicante il corso d'acqua superato mi sembra ci sia scritto solitamente, 
> ad esempio "Fiume Po" , e non semplicemente "Po"

Come puoi vedere purtroppo per ogni "regola" esiste già più di una
eccezione:

 

In provincia di Brescia c'è infatti la superstrada che sale in vallecamonica
lungo la quale tutti i cavalcavia e tutte le gallerie sono segnalate nel
modo in cui vedi, cioè sul relativo cartello è stato sempre omesso il
prefisso "Galleria" piuttosto che "Ponte" o "Calcavia" o "Viadotto".
E volendo vedere quando li ho mappati mi sono chiesto cosa mettere in

bridge:name e tunnel:name

e per ora sono stato ligio a ciò che c'è scritto sul cartello omettendo il
prefisso.
Ciao.

--enrico




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

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

Re: [OSM-talk] New OSM Quick-Fix service

[Dave F]

It's both the splash screen & value for your created_by tag!

DaveF

On 15/10/2017 14:24, Yuri Astrakhan wrote:
Christoph, once again, what does Wikidata have to do with anything in 
this thread?  Wikidata is a heated and important point, and just today 
I saw another great use of it - https://opentripmap.com/en/ but this 
is totally irrelevant for the current discussion.



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


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

[Talk-it] Tag bacheca necrologi

[Marco]

Immagino che ogni comune in Italia abbia un discreto numero di 
"bacheche" apposite per i necrologi, quindi magari qualcuno prima di me 
si è già posto il problema di quale tag scegliere. Sulla wiki non ho 
trovato nulla di simile, come posso mapparle?


Grazie

Marco


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

Re: [Talk-it] Alta Via dei Parchi (e percorsi a tappe con sovrarelazione in generale)

[Alfredo Gattai]

Si, solo che nella pratica non ha quasi mai lo stesso ref, network, name,
etc. Io le superroute cerco di non usarle, non trovo particolarmente utile
questi raggruppamenti, ma se proprio uno le usa perlomeno che siano utili.
Quindi nel tuo caso nel name=Alta Via dei Parchi mentre nelle altre ci
metti anche la tappa.

On Sun, Oct 15, 2017 at 3:30 PM, matteocalosi 
wrote:

> Ma dovrei usare http://wiki.openstreetmap.org/wiki/Relation:superroute ?
> Dice: The superroute has the same characteristics as the routes regarding
> route=*, ref=*, network=*, name=*, …
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-be] Importing Villo! API data

[Yves bxl-forever]

Hello,

In the past weeks I have also wanted to do some cleanup on Villo! stations and 
it’s a fact that there still quite a lot of work to be done.

Just a few thoughts about the idea of bulk data imports because this is what 
gave us really "ugly" nodes sometimes.

The name itself is a problem because what they present as the name is actually 
a string that concatenates the ID of the station, the name and its address.  
This is why tagging this as "official_name" does not seem to make any sense.

Their JSON dataset usually looks like this:

"name":"076 - PLACE VAN MEENEN/VAN MEENENPLEIN",
"address":"PLACE VAN MEENEN/VAN MEENENPLEIN - AV PAUL DEJAER (FACE 35 - 39) / 
PAUL DEJAERLAAN (TEGENOVER 35 - 39)"


And we must translate it as such in our OSM nodes:

ref=76
name="Place Van Meenen - Van Meenenplein"
name:fr="Place Van Meenen"
name:nl="Van Meenenplein"
addr:street="Place Maurice Van Meenen - Maurice Van Meenenplein"
addr:housenumber="35-39"


It’s probably feasible to parse the fields automatically and make something 
that looks clean.
But I am not sure that the street name will always match (see example here, 
official name has "Maurice" somewhere and our parsing script will not guess it 
unless you feed it with a list of all streets).

About missing names in one language, this is tricky: normally we should stick 
with the official name given by the operator.  But another approach will be 
that if we know of an official translation (because it is the same name as the 
street or even a bus stop nearby, or a building) it should be used.  And I 
agree that we should fix typos without asking, like in your example.

Another problem is that the longitude and latitude fields must be checked to 
avoid putting stations in the middle of an intersection or inside a building.


In summary, I will recommend a safer approach, i.e. extracting a list of 
missing stations, and add them one by one manually, after checking whether the 
data looks fine.
But it will be nice to hear the thoughts of other members of the community.

Have a nice day.

Yves



On Sun, 15 Oct 2017 13:48:42 +0200
CedB12  wrote:

> Hello all,
> 
> Lately I have been looking at the Villo! dataset from the JCDecaux API
> at [1], which is released under the Etalab Open License (see also [2]).
> I want to consult the community about the use of this data to improve
> the tagging of the stations we have already mapped. I would also like to
> discuss a potential import of the hundred or so stations that are
> reported in the API but have not been mapped yet in OSM.
> 
> My priority is to fix the tagging of station names and reference
> numbers, which are often wrong or missing in the already-mapped
> stations. I am aware of a few quality issues in the names reported by
> the API (which, as far as I know, are actually the names reported at the
> stations themselves), so this cannot be a fully automated process. As
> far as ref tags are concerned, only 25 existing station nodes do not
> match the API. I have not pushed any change yet in case this thread
> brings up an objection to the use of this API data.
> 
> More importantly, given the quality issues in the API names, we would
> need to discuss how exactly we want to tag names vs. what the "official"
> names are.
> 
> To give you a quick example of what kind of problems we can find in the
> API, consider that one station is named "342 - MAISON COMMUNALE DE
> BERCHEM ST AGHATE". Like all other stations, the name is in all-caps.
> This one in particular contains a misspelling: the commune is actually
> spelled "Berchem-Ste-Agathe". Also, unlike other stations, this one has
> no official Dutch name, and it is not clear to me whether we should
> provide our own translation in the name and name:nl tags.
> 
> I actually got a little bit ahead of myself and had prepared a diary
> entry draft as well as a more detailed and specific email for this
> mailing list, but I now realize that unloading all of this at once might
> have felt a bit forceful. So before I go into the details of all the
> quirks in the API data and formulate a general proposal for tagging, I
> wanted to take a more open-ended approach and ask if anyone had anything
> to share regarding our mapping and tagging of Villo! stations. I am also
> interested in your thoughts on how we should tag the station I gave
> above as an example (in terms of name, name:fr, name:nl, and maybe other
> kinds of name tags like official_name).
> 
> But before that, I would like to make sure that it is OK to import
> Etalab-licensed data, because otherwise this effort will be pointless. I
> assume it must be fine because the license states to be compatible with
> "any licence which requires at least the attribution of the «
> Information »" [3], including the Open Government License which is in
> turn listed on the OSM wiki page on ODbL compatibility [4]. How are the
> requirements of the license (attribution by source name + date + URL)
> 

Re: [OSM-talk] New OSM Quick-Fix service

[john whelan]

>Thank you for a very well thought out analysis.

Surely the analysis should be done at the front of the project.  Making a
change during the project has costs.  The further you are into the project
normally the higher the cost is to correct something.  This is general not
specifically your project.

In this case the cost is either we end up with tatty data or some poor
muggings has to clean it up plus of course some reputational damage.

I suggest pausing and then defining the problem(s) you are trying to
address.  Once that is agreed then is the time to work out a solution that
is agreeable to more people than the present version.

Cheerio John

On 15 October 2017 at 09:24, Yuri Astrakhan  wrote:

> Tobias, this is the best and most constructive email I have seen yet!
> Thank you for a very well thought out analysis. I want to give it justice
> and do a thorough reply, but only after getting some sleep.  Thank you for
> restoring my faith in the proper communication.
>
> Christoph, once again, what does Wikidata have to do with anything in this
> thread?  Wikidata is a heated and important point, and just today I saw
> another great use of it - https://opentripmap.com/en/  but this is
> totally irrelevant for the current discussion.
>
> On Sun, Oct 15, 2017 at 9:14 AM, Tobias Zwick  wrote:
>
>> Hi Yuri
>>
>> I am not aware of the record of your previous interactions with the
>> community and I think you cannot be blamed to not respond to any toxic
>> feedback and/or accusations thrown at you here, whether they may be
>> justified or not.
>>
>> So, I give you the benefit of the doubt and write up this honest and
>> constructive feedback. Substantively, I come to the same conclusions as
>> the previous posters: That I find it hard to see that the app will have
>> any positive impact - at least "as is". I hope you value it nonetheless,
>> I also have some suggestions at the end.
>>
>> So, the initial question is: What is the conceptual use case for such a
>> tool? Where would be its place in the range of available OSM tools?
>>
>> There is the use case where one tagging scheme has been deprecated by
>> community consensus and one (combination of) tag(s) should be changed
>> into another (combination of) tag(s) globally.
>>
>> 1. If this does not require humans because both tagging schemes are
>> mutually translatable (i.e. lets say for sport=handball <->
>> sport=team_handball), then, the edit can be made automatically by a bot.
>>
>> 2. If this does require humans to check the transition to the new tag
>> because the deprecated tagging scheme is ambiguous (i.e. , such as
>> sport=football -> soccer or american/australian/canadian/... football),
>> then, an automatic edit cannot be done. Instead, tools like MapRoulette
>> are used.
>>
>> 3. Finally, if this also does require humans because a tag combination
>> is suspicious (what would show up as warnings in JOSM and what most of
>> Osmose consists of), also, a tool like Osmose or MapRoulette is used.
>>
>> Though, note, for all three cases, a prior consensus is required, either
>> by prior discussion or by looking at what was previously agreed on in
>> the wiki. That is the case for *any* organized re-tagging of existing
>> tags.
>>
>> I reckon you see the quick fix tool to be in category 2 and 3 here,
>> along with MapRoulette and Osmose, only with the crucial advantage of
>> being quicker to use, since no editor is required.
>> But it seems to me, you didn't think this through. If the tool offers
>> *one* solution to any re-tagging ("Save" or leave it), then, this is
>> pretty much a manually operated automatic bot (case 1), which really
>> doesn't make sense. For case 2 and 3, it cannot be used as is, because:
>>
>> - Quick fix cannot be used to find what kind of football it is (case 2),
>> but MapRoulette can, because it leaves the actual editing to the user.
>>
>> - Quick fix cannot be used to solve any markers which may or may not be
>> an actual problem (case 3) because it has no way of marking any of the
>> things as false-positives.
>>
>> Looking at your linked Wiki document (
>> https://wiki.openstreetmap.org/wiki/Quick_fixes ), most of these are
>> candidates for automatic corrections. I.e.:
>> - Convert religion=Christian to religion=christian
>> - Convert various common forms of religion=catholic to
>> religion=christian + denomination=catholic
>> - Convert religion=islam to religion=muslim
>> - etc.
>>
>> (Only) your initial example ( amenity=sanatorium -> leisure=resort +
>> resort=sanatorium for ex-USSR-countries) falls in case 2. But then, as
>> mentioned, either marking as false-positives or other answer options
>> (i.e. "yes, it is a sanatorium in the West European sense") are missing.
>>
>> Okay, so much for why I think the tool is, as is, not fit to be used and
>> probably why you got so many negative responses here.
>>
>> *However*, the idea as such, to make the clean-up process of either

Re: [Talk-us] Trunk

[Nathan Mills]

In the US, we've always treated primary/secondary/tertiary as a way to tag 
importance to the road network, while physical construction was secondary. 
Motorway, of course, was and still is treated differently. Trunk has always 
been stuck in the middle between people who like me and Paul want to use it 
more like motorway but for divided highways and people who want it to mean more 
primary than primary.

That's why we're still taking about it now, long after the usage of other 
highway tag values has long been settled. The closest thing to a decision that 
was ever made was NE2's unilateral mass edit, some of which has been reverted, 
some of which hasn't. Without consensus that the tagging is wrong and not just 
the unilateral decision, I'm not going to go out of my way to revert his trunk 
changes on ways I'm not otherwise editing large portions of. It's not a nice 
thing to do. It's got nothing to do with thinking that things should be that 
way and everything to do with not being a jackass who unilaterally imposes 
their will on the whole community.

-Nathan

On October 15, 2017 1:40:16 AM EDT, Bradley White  
wrote:
>If we can determine importance (which is what the 'highway=' tag
>fundamentally represents per the wiki) solely by what's on the ground,
>why not just tag what's physically there, ditch the 'highway' tag
>altogether, and let the renders handle it with their own algorithms?
>
>>On Sun, Oct 15, 2017 at 12:19 AM, Paul Johnson ursamundi.org> wrote:
>>>
>>> The US is pretty well known for overbuilding highways.  Are we
>trying to
>>> document how things are on the ground or how things are actually
>>> connected?  If we're going for the former, then yeah, only Bend
>Parkway and
>>> a brief streak through Klamath Falls is a trunk part of US 97.  If
>we're
>>> going for the latter, then go ahead with NE2's idea and smash almost
>>> everything into trunk.
>>>
>>
>>
>>Keep hitting send too soon.  Personally, I find what's on the ground
>to be
>>more useful than the connections.  Game theory and any routing engine
>can
>>figure out the connections.  But knowing what's a stupid rural road
>with an
>>overly generous speed limit and what's almost but not quite a freeway
>is
>>more useful.  If I'm driving a big rig going from southwestern Canada
>or
>>Alaska to somewhere in Nevada, I don't give two shakes what some
>toolbag
>>things is the most prominent road.  I care more about what *actually
>is a
>>big road*.  Calling a two leg segment of US 97 30km outside of East
>>Butthump, Oregon a trunk is a great disservice when it's basically on
>par
>>with County Road Number Who Even Cares tracing off to Outer
>>Smalltownsville, other than the fact that it goes through.  Calling it
>a
>>trunk when it's not is going to set an unreasonably high expectation
>for
>>what is otherwise an overtravelled, glorified two digit National
>Forest
>>route through the east Cascades frontier.  Primary is definitely ample
>for
>>that road, even if you're going a more obscure minor haul route like
>Salem
>>to Reno.
>
>___
>Talk-us mailing list
>Talk-us@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-us

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

Re: [OSM-talk] New OSM Quick-Fix service

[Dave F]

Hi
"this tool has nothing to do with Wikidata"

"Currently, the tool creates two changeset tags:
 created_by=OSM+Wikidata 0.1"

Am I confused by what you mean by "this tool"?

DaveF

On 15/10/2017 13:04, Yuri Astrakhan wrote:
Andu, with all due respect, you are misrepresenting things.  I have 
received praises on OSM-RU channel, and that's where I got my first 
bug reports and suggestions that were quickly fixed.  The current 
mailing thread also received a praise from Steve. I have received a 
private email explicitly praising this tool, some twitter feedback, 
plus, some general encouragements for my efforts. So, despite some 
vocal people on one side of the issue, claiming to represent "the 
community" is not accurate, as others have expressed opposing views.  
Thus, it is not as uniform as you try to portray it, but rather, as 
any other conflict, deserves a thoughtful approach to attempt to 
balance goals of everyone, and to find a valuable compromise.


At the same time, judging from the fact that someone did not feel 
comfortable emailing to the group, there seems to be significant 
toxicity and bullying going on.  There was a number of personal 
attacks, which to me seems to be a violation of our communication 
policies, and which I deliberately ignore. So no, I see some people in 
the community may support it, but do not want to participate in such a 
violent discussion. When someone is foaming at the mouth, people tend 
to stay away, rather than engage in a constructive discussion.


Luckily, there has been some valuable feedback too, and I hope our 
community will be mature enough to provide more broadly.  For example, 
Simon was very clear and explicit about the exact deficiencies he 
objected to - something that I attempted to rectify, and will continue 
to improve on.  Some other remarks, despite being presented in a bad 
form, lead me to more good fixes such as a mandatory high zoom before 
editing. I am clearly continuing to participate in the discussion, and 
try to abstain from discussing PEOPLE, but instead concentrate on a 
specific IDEA being presented in this thread, and the specific 
PROBLEMS it tries to solve. As a volunteer. Without any financial 
benefit from anything I do. Same as many other participants on this 
channel, regardless of their views. Trying to maneuver between the 
abstract philosophy, various believes of what is the "right thing to 
do", and the specific problems and solutions.


P.S. @mmd, sorry for not replying earlier. I suspect you meant it as 
an "ad absurdum" argument. Thing is, Wikidata does use wiki pages to 
store bot states. Mostly bots generate various talk pages and 
templates, and users sometimes modify those talk pages to control the 
bots. Yet, this tool has nothing to do with Wikidata, so it is a moot 
point to discuss storing OSM metadata there. See my reply about the 
"nobot" tag. I think it would help to partially heal the bot-nobot 
divide, as it gives control over each object to editors, and allows 
mini-bots.


And one last thing.  Something that has helped me many times to find 
COMPROMISE in a forum discussion. When replying, let's try to sum up 
the opponent's position and the reasons for that position, and explain 
why you think it is incorrect. Perhaps we should learn from the high 
school debate class? Sorry for the long email.





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


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

Re: [Talk-us] Trunk

[Nathan Mills]

Yes, on more than one occasion back in the mists of time before armchair 
mappers had spread the lanes and other condition tags widely I found some 
pretty shitty US highways labeled as trunk, not because they are better roads, 
but because they happen to be long distance through routes. US412 should not be 
trunk across most of the state of Arkansas. It's mostly a crappy winding route 
that is actively dangerous for trucks, who should be taking I-49 to I-40 or 
US71 north to 44 unless their destination is directly along the route.

By the network definition, it solidly deserves trunk, but by any other measure 
it does not, and calling it so drives traffic to places it shouldn't be and 
makes the map harder to use effectively at a glance.

Yesterday(ish) someone asked which maps differentiate expressway vs freeway vs 
everything else that is paved in their inking styles. I'll answer that with a 
question. Have you ever seen a US paper map? Until the digital road atlases 
with topo shading and/or overlays started becoming common in the late 90s 
basically every official state highway map, chamber of commerce map, gas 
station map, and road atlas differentiated divided, limited access, undivided 
paved, and unpaved with styles and paved/unpaved with weight. Sometimes you'd 
get numbered highways in red and other roads in black (with light grey or 
dashed lines to mean unpaved, depending on the map)

It's long been how US road maps are drawn, so map users here expect that 
differentiation to exist. Of course, we also expect toll roads to be colored 
green, but OSM doesn't do that either. (And I'm fine with that, TBH. I don't 
consider it as important as being able to differentiate between divided and 
undivided in a relatively simple way.)

If someone could explain why primary is insufficient to denote a paved rural 
road that connects minor population centers far from other routes. Why should 
US-71 south of Witcherville in Arkansas not be tagged as primary once the 
divided segment ends? There aren't many US highways of that size with more 
traffic, but it seems solidly primary to me. Some might make the whole thing a 
trunk since the route goes through several states and is important enough to be 
being replaced as money becomes available with I-49. Never mind the four plus 
hours of driving through little towns on a windy mountain road involved. I'd 
have gotten in an edit war over it if someone had tried to tag the part north 
of I-40 a trunk before the freeway was built to Fayetteville and beyond.

-Nathan

On October 15, 2017 1:27:42 AM EDT, Paul Johnson  wrote:
>On Sun, Oct 15, 2017 at 12:19 AM, Paul Johnson 
>wrote:
>>
>> The US is pretty well known for overbuilding highways.  Are we trying
>to
>> document how things are on the ground or how things are actually
>> connected?  If we're going for the former, then yeah, only Bend
>Parkway and
>> a brief streak through Klamath Falls is a trunk part of US 97.  If
>we're
>> going for the latter, then go ahead with NE2's idea and smash almost
>> everything into trunk.
>>
>
>
>Keep hitting send too soon.  Personally, I find what's on the ground to
>be
>more useful than the connections.  Game theory and any routing engine
>can
>figure out the connections.  But knowing what's a stupid rural road
>with an
>overly generous speed limit and what's almost but not quite a freeway
>is
>more useful.  If I'm driving a big rig going from southwestern Canada
>or
>Alaska to somewhere in Nevada, I don't give two shakes what some
>toolbag
>things is the most prominent road.  I care more about what *actually is
>a
>big road*.  Calling a two leg segment of US 97 30km outside of East
>Butthump, Oregon a trunk is a great disservice when it's basically on
>par
>with County Road Number Who Even Cares tracing off to Outer
>Smalltownsville, other than the fact that it goes through.  Calling it
>a
>trunk when it's not is going to set an unreasonably high expectation
>for
>what is otherwise an overtravelled, glorified two digit National Forest
>route through the east Cascades frontier.  Primary is definitely ample
>for
>that road, even if you're going a more obscure minor haul route like
>Salem
>to Reno.

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

Re: [OSM-talk] Could we just pause any wikidata edits for a month or two?

[Tomas Straupis]

  Lets take an example. History of this hillfort:
  http://www.openstreetmap.org/node/1717783246/history

  What happened here:
1. I've added a hillfort object "Žagarės piliakalnis" (Žagarės hillfort).
2. Med fixed wikipedia tag (removed underscores - good change, my
mistake fixed).
3. I've updated local Lithuanian heritage id's (fine, we use that for
synchronisation).
4. rmikke added a wikidata entry... chrm... could be fine as we do not
use wikidata at all, somebody else might, but... then
5. kartonage "corrected" wikidata tag (whatever, don't care about
that) but also wikipedia tag! And let's look what was the change:
"Žagarės piliakalnis" changed to "Žagarės antrasis piliakalnis". In
English „Žagarės hillfort“ to „Žagarės SECOND hillfort". Reason stated
for change is "pointing to disambiquity page" (so fixing wiki* tags
according to Youris idea/tool). What is wrong here? Name tag is still
"Žagarės I piliakalnis“ - Žagarės FIRST hillfort. And that is correct,
because there is a second hillfort nearby called "Žagarės SECOND"
hillfort:
 http://www.openstreetmap.org/#map=19/56.35690/23.23084
  But wikipedia link on this FIRST hillfort now points to the SECOND hillfort.

  What happens then. I fixed wikipedia tag and removed wikidata entry
so that somebody else would not come and "fix" it again (at least
until we fix the actual problem). But rmikke runs his script again and
adds the same wikidata value again. So this item will once again show
up in Youri's tool and somebody else can try to "fix" it.

  The actual "on the ground" problem here is an error in official
heritage data. Heritage codes or names are mixed/swaped in several
official sources. It is impossible to fix this stuff by simply looking
at the OSM data (and even by simply looking at heritage data because
it contradicts with data of archaeologists). We (local community) will
have to contact heritage guys, archaeologists to find out who is
wrong. So it cannot be fixed by somebody without local knowledge and
without local contacts. And the problem is that Youri's tool gives a
false impression that it CAN be fixed.

  And this hillfort does show up in our local wikipedia error list
(which is produced without any use of wikidata whatsoever) and is just
waiting in queue to be fixed.

  The points I'm showing here:
  1. Error identification can be done without wikidata tags (and we
already identify more errors like: no object in OSM or no coordinates
in wikipedia, multiple objects in OSM for the same wikipedia page).
  2. Error can not be fixed without local knowledge.
  3. If it was only wikidata tag I would not have noticed the bad
change, because there is no way I would somehow know what those 324657
897984 65465465 id's stand for. It is only because of wikipedia tag
that I spotted the problem.

  There was a very logical and practical advice somewhere in this
thread. If you got approval in OSM-RU, why can't you do your
experimenting/fixing there first? To the very end. When all (or almost
all) wiki errors would be fixed in Russia, you could create a report
about your work. It could then by compared to other processes of
fixing wiki data and it would be possible for a specific community to
choose the most appropriate method. And there would be less
"toxicity", because you would not be forcing your way on people who
are successfully doing it in a different way.

-- 
Tomas

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

Re: [Talk-it] Alta Via dei Parchi (e percorsi a tappe con sovrarelazione in generale)

[matteocalosi]

Ma dovrei usare http://wiki.openstreetmap.org/wiki/Relation:superroute ?
Dice: The superroute has the same characteristics as the routes regarding
route=*, ref=*, network=*, name=*, … 



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

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

Re: [OSM-talk] New OSM Quick-Fix service

[Yuri Astrakhan]

Tobias, this is the best and most constructive email I have seen yet!
Thank you for a very well thought out analysis. I want to give it justice
and do a thorough reply, but only after getting some sleep.  Thank you for
restoring my faith in the proper communication.

Christoph, once again, what does Wikidata have to do with anything in this
thread?  Wikidata is a heated and important point, and just today I saw
another great use of it - https://opentripmap.com/en/  but this is totally
irrelevant for the current discussion.

On Sun, Oct 15, 2017 at 9:14 AM, Tobias Zwick  wrote:

> Hi Yuri
>
> I am not aware of the record of your previous interactions with the
> community and I think you cannot be blamed to not respond to any toxic
> feedback and/or accusations thrown at you here, whether they may be
> justified or not.
>
> So, I give you the benefit of the doubt and write up this honest and
> constructive feedback. Substantively, I come to the same conclusions as
> the previous posters: That I find it hard to see that the app will have
> any positive impact - at least "as is". I hope you value it nonetheless,
> I also have some suggestions at the end.
>
> So, the initial question is: What is the conceptual use case for such a
> tool? Where would be its place in the range of available OSM tools?
>
> There is the use case where one tagging scheme has been deprecated by
> community consensus and one (combination of) tag(s) should be changed
> into another (combination of) tag(s) globally.
>
> 1. If this does not require humans because both tagging schemes are
> mutually translatable (i.e. lets say for sport=handball <->
> sport=team_handball), then, the edit can be made automatically by a bot.
>
> 2. If this does require humans to check the transition to the new tag
> because the deprecated tagging scheme is ambiguous (i.e. , such as
> sport=football -> soccer or american/australian/canadian/... football),
> then, an automatic edit cannot be done. Instead, tools like MapRoulette
> are used.
>
> 3. Finally, if this also does require humans because a tag combination
> is suspicious (what would show up as warnings in JOSM and what most of
> Osmose consists of), also, a tool like Osmose or MapRoulette is used.
>
> Though, note, for all three cases, a prior consensus is required, either
> by prior discussion or by looking at what was previously agreed on in
> the wiki. That is the case for *any* organized re-tagging of existing tags.
>
> I reckon you see the quick fix tool to be in category 2 and 3 here,
> along with MapRoulette and Osmose, only with the crucial advantage of
> being quicker to use, since no editor is required.
> But it seems to me, you didn't think this through. If the tool offers
> *one* solution to any re-tagging ("Save" or leave it), then, this is
> pretty much a manually operated automatic bot (case 1), which really
> doesn't make sense. For case 2 and 3, it cannot be used as is, because:
>
> - Quick fix cannot be used to find what kind of football it is (case 2),
> but MapRoulette can, because it leaves the actual editing to the user.
>
> - Quick fix cannot be used to solve any markers which may or may not be
> an actual problem (case 3) because it has no way of marking any of the
> things as false-positives.
>
> Looking at your linked Wiki document (
> https://wiki.openstreetmap.org/wiki/Quick_fixes ), most of these are
> candidates for automatic corrections. I.e.:
> - Convert religion=Christian to religion=christian
> - Convert various common forms of religion=catholic to
> religion=christian + denomination=catholic
> - Convert religion=islam to religion=muslim
> - etc.
>
> (Only) your initial example ( amenity=sanatorium -> leisure=resort +
> resort=sanatorium for ex-USSR-countries) falls in case 2. But then, as
> mentioned, either marking as false-positives or other answer options
> (i.e. "yes, it is a sanatorium in the West European sense") are missing.
>
> Okay, so much for why I think the tool is, as is, not fit to be used and
> probably why you got so many negative responses here.
>
> *However*, the idea as such, to make the clean-up process of either
> clearly wrong tags, deprecated tags or even just warnings
> semi-automatic, is a very good one. The prerequisite is, that there must
> always be the option to *not* apply that fix and save that decision. The
> other very critical point is, that the easier you make it for users to
> apply a predefined fix, the more precautions must be taken to ensure
> that the user really checked the situation.
>
> So, the most critical missing features from my point of view in your
> tool are
>
> a) There must be an option to manually edit this instead and/or marking
> it as a false positive. In any case, the marker may not be shown for
> other users anymore. This was a topic in this thread already and it was
> voiced that inventing new tags just to be used by this tool in not
> acceptable and I agree with that. The other tools 

Re: [OSM-talk] New OSM Quick-Fix service

[Tobias Zwick]

Hi Yuri

I am not aware of the record of your previous interactions with the
community and I think you cannot be blamed to not respond to any toxic
feedback and/or accusations thrown at you here, whether they may be
justified or not.

So, I give you the benefit of the doubt and write up this honest and
constructive feedback. Substantively, I come to the same conclusions as
the previous posters: That I find it hard to see that the app will have
any positive impact - at least "as is". I hope you value it nonetheless,
I also have some suggestions at the end.

So, the initial question is: What is the conceptual use case for such a
tool? Where would be its place in the range of available OSM tools?

There is the use case where one tagging scheme has been deprecated by
community consensus and one (combination of) tag(s) should be changed
into another (combination of) tag(s) globally.

1. If this does not require humans because both tagging schemes are
mutually translatable (i.e. lets say for sport=handball <->
sport=team_handball), then, the edit can be made automatically by a bot.

2. If this does require humans to check the transition to the new tag
because the deprecated tagging scheme is ambiguous (i.e. , such as
sport=football -> soccer or american/australian/canadian/... football),
then, an automatic edit cannot be done. Instead, tools like MapRoulette
are used.

3. Finally, if this also does require humans because a tag combination
is suspicious (what would show up as warnings in JOSM and what most of
Osmose consists of), also, a tool like Osmose or MapRoulette is used.

Though, note, for all three cases, a prior consensus is required, either
by prior discussion or by looking at what was previously agreed on in
the wiki. That is the case for *any* organized re-tagging of existing tags.

I reckon you see the quick fix tool to be in category 2 and 3 here,
along with MapRoulette and Osmose, only with the crucial advantage of
being quicker to use, since no editor is required.
But it seems to me, you didn't think this through. If the tool offers
*one* solution to any re-tagging ("Save" or leave it), then, this is
pretty much a manually operated automatic bot (case 1), which really
doesn't make sense. For case 2 and 3, it cannot be used as is, because:

- Quick fix cannot be used to find what kind of football it is (case 2),
but MapRoulette can, because it leaves the actual editing to the user.

- Quick fix cannot be used to solve any markers which may or may not be
an actual problem (case 3) because it has no way of marking any of the
things as false-positives.

Looking at your linked Wiki document (
https://wiki.openstreetmap.org/wiki/Quick_fixes ), most of these are
candidates for automatic corrections. I.e.:
- Convert religion=Christian to religion=christian
- Convert various common forms of religion=catholic to
religion=christian + denomination=catholic
- Convert religion=islam to religion=muslim
- etc.

(Only) your initial example ( amenity=sanatorium -> leisure=resort +
resort=sanatorium for ex-USSR-countries) falls in case 2. But then, as
mentioned, either marking as false-positives or other answer options
(i.e. "yes, it is a sanatorium in the West European sense") are missing.

Okay, so much for why I think the tool is, as is, not fit to be used and
probably why you got so many negative responses here.

*However*, the idea as such, to make the clean-up process of either
clearly wrong tags, deprecated tags or even just warnings
semi-automatic, is a very good one. The prerequisite is, that there must
always be the option to *not* apply that fix and save that decision. The
other very critical point is, that the easier you make it for users to
apply a predefined fix, the more precautions must be taken to ensure
that the user really checked the situation.

So, the most critical missing features from my point of view in your
tool are

a) There must be an option to manually edit this instead and/or marking
it as a false positive. In any case, the marker may not be shown for
other users anymore. This was a topic in this thread already and it was
voiced that inventing new tags just to be used by this tool in not
acceptable and I agree with that. The other tools also do not require that.

b) I strongly suggest to offer different answer options. As I said, if
only one option is available, it is really nothing else than a manually
operated automatic edit. If several options are available (i.e.
"american football", "soccer" etc. ) as a quick fix, only then the tool
becomes to be useful. (There are some challenges like that on
MapRoulette also, such as "Phone or fax number is not in international
format" and these in my opinion also do not belong there because they
can be solved automatically)

c) Require users to zoom into the map at around zoom 17 or more to make
any changes. If the users are supposed to check if something is the case
(via satellite image), then at least don't let them cheat by just
solving 

Re: [OSM-talk] Could we just pause any wikidata edits for a month or two?

[Yuri Astrakhan]

If a community has had a well established and agreed process running, which
does not create any new data issues, why should someone outside of that
community be requesting a global halt?  It's not like the data is getting
worse all of a sudden, right? And their work does not prevent global
community from reaching a consensus on how to move forward.  I suspect this
discussion may take a very long time to complete, so proposing to ban
various communities from doing what they have already been happily doing
because somewhere else something is being discussed is strange.  There are
over 40,000 users editing OSM, so reaching a consensus on a fundamental
topic of external DB linking might take years.

Has there ever been a global halt like this in OSM, where several people in
@talk demanded a certain tag to not be (mass) edited globally?  I'm totally
ok if there is a process for that, but global halt does seem a bit extreme
due to a relatively low impact.  After all, we are discussing philosophy of
the project here, not that tag X breaks half of the map renderers all of a
sudden, right?
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

[Christoph Hormann]

On Sunday 15 October 2017, ajt1...@gmail.com wrote:
>
> You did indeed receive one message in your favour - I miscounted.
> That's 1 in favour, 1 question (from someone who has been critical
> elsewhere) and 7 against.  Maybe that counts as a majority in your
> favour in some places, but it doesn't here.

Indeed - and you should always be careful to make assumptions about 
the 'silent majority' of people who do not voice their opinion for one 
reason or another.  I for example know of quite a few people who in 
general have a positive attitude to either Wikidata or mechanical edits 
and want to explore the possibilities of these but who feel the 
attitude and approach of Yuri Astrakhan is inconsiderate, 
non-constructive and damaging.  I would wish more of them would speak 
up here but i also understand if they do not want to "pour oil into the 
fire" so to speak.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [OSM-talk] New OSM Quick-Fix service

[Yuri Astrakhan]

Andy, first off, this whole email thread was about "hi, this is a new,
rough around the edges tool I'm building, that MIGHT benefit SOME people"
Suggestions/ideas welcome.  When you say "stop" - stop what? Stop coding? I
have not done any significant amount of editing since last month, right
around the time when Wikidata debacle happened. Also, I think you are
ignoring what I said - others who are NOT on this thread have also
expressed support - and they have not spoken here, possibly due to the
toxic environment. When you say we voted - voted on what? Was there a
proposal? Was there a bad action being performed?

Re toxicity - these are not my words to qualify what has been going on, but
I do agree with them.  I cannot say that I have been perfect in all of my
responses, but I do try to keep them civil, and expect the same back.
Also, please reread my previous email, I tried to carefully express most
issues I encountered.

John, noone is saying its a consensus either way.  I am WORKING on finding
a compromise, while also building a tool that at least some people in some
communities find useful.   I did draw a comparison to at least two tools -
MapRoullette and Osmose. The first - mostly about building "challenges",
the second - in how it presented the editing interface. Osmose has many
more features than I do, allowing greater editing experience.  Also, I do
draw a comparison with RawEdit (Osmose) and Level0 - they both allow very
quick text editing of the raw XML content - a highly error-prone process
that I try to avoid.

On Sun, Oct 15, 2017 at 8:33 AM, john whelan  wrote:

> > I have received praises on OSM-RU channel,
>
> Wow, within the large number of active mappers there is a very broad range
> of opinions.  One or two people saying this is wonderful is not a
> consensus within OpenStreetMap that it is.
>
> Within OpenStreetMap the authority is normally accepted to be the local
> mappers and the DWG.  There are processes to follow for automated edits.
>
> I seem to recall you drawing a comparison between your work and
> MapRoulette.  MapRoulette identifies problems and has mappers resolve
> them one at a time.  My understanding is it does not make changes or add
> anything to the database.  Your approach seems to be quite different and I
> don't think the two can be compared.
>
> My understanding is you have not followed these processes and have ignored
> the wishes of local mappers.  This is not a personal attack these are
> issues and concerns.
>
> Could you be so kind as to address the issues and concerns raised please.
>
> Especially not taking into account the wishes of the local communities
> when expressed.
>
> Many Thanks
>
> Cheerio John
>
>
>
>
>
> On 15 October 2017 at 08:04, Yuri Astrakhan 
> wrote:
>
>> Andu, with all due respect, you are misrepresenting things.  I have
>> received praises on OSM-RU channel, and that's where I got my first bug
>> reports and suggestions that were quickly fixed.  The current mailing
>> thread also received a praise from Steve. I have received a private email
>> explicitly praising this tool, some twitter feedback, plus, some general
>> encouragements for my efforts. So, despite some vocal people on one side of
>> the issue, claiming to represent "the community" is not accurate, as others
>> have expressed opposing views.  Thus, it is not as uniform as you try to
>> portray it, but rather, as any other conflict, deserves a thoughtful
>> approach to attempt to balance goals of everyone, and to find a valuable
>> compromise.
>>
>> At the same time, judging from the fact that someone did not feel
>> comfortable emailing to the group, there seems to be significant toxicity
>> and bullying going on.  There was a number of personal attacks, which to me
>> seems to be a violation of our communication policies, and which I
>> deliberately ignore. So no, I see some people in the community may support
>> it, but do not want to participate in such a violent discussion. When
>> someone is foaming at the mouth, people tend to stay away, rather than
>> engage in a constructive discussion.
>>
>> Luckily, there has been some valuable feedback too, and I hope our
>> community will be mature enough to provide more broadly.  For example,
>> Simon was very clear and explicit about the exact deficiencies he objected
>> to - something that I attempted to rectify, and will continue to improve
>> on.  Some other remarks, despite being presented in a bad form, lead me to
>> more good fixes such as a mandatory high zoom before editing. I am clearly
>> continuing to participate in the discussion, and try to abstain from
>> discussing PEOPLE, but instead concentrate on a specific IDEA being
>> presented in this thread, and the specific PROBLEMS it tries to solve. As a
>> volunteer. Without any financial benefit from anything I do. Same as many
>> other participants on this channel, regardless of their views. Trying to
>> maneuver 

Re: [OSM-talk] Could we just pause any wikidata edits for a month or two?

[Michael Reichert]

Hi Ryszard,

Am 2017-10-12 um 22:41 schrieb Ryszard Mikke:
> On 3 October 2017 at 18:56, Christoph Hormann  wrote:
> 
>> On Tuesday 03 October 2017, Frederik Ramm wrote:
>>> Hi,
>>>
>>>seeing that the matter is discussed quite intensively and opinions
>>> vary widely, could we perhaps agree to pause any (large scale)
>>> wikidata edits for a while until more members of our community have
>>> had a chance to form an opinion?
>>
>> I think that is a good idea.
>>
> 
> I'm not happy with it, as the way I do it is sensitive to amount of data to
> work with, so if I don't run it regularly, I have to restart from fragments.
> But well, I might limit the query to Poland where the adding of wikidata
> entries is widely accepted.
> I will repeat Yuri's question here:
> If a specific community is ok with it, does it override world wide ban for
> that location?

Please pause your edits of such kind at all!

If a part of the OSM community thinks that an edit of type X is good but
another part of the community opposes, there is not enough consent on
the topic. The question if we shold have wikidata=* tags in OSM and
which objects should have them, is an international questions. As long
as international discussions are going on, everyone has to wait.

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [OSM-talk] Could we just pause any wikidata edits for a month or two?

[Michael Reichert]

Hi Ryszard,

Am 2017-10-13 um 01:11 schrieb Ryszard Mikke:
> On 12 October 2017 at 23:23, Christoph Hormann  wrote:
> 
>> As i have pointed out elsewhere doing QA in OSM based on Wikidata does
>> not in any way depend on the automatic addition of Wikidata IDs to
>> OSM - or in other words: Any ID you'd add based on some matching
>> algorithm just for QA purposes you would not need to add at all.
>>
> 
> How exactly would you approach detecting OSM objects with wikipedia=*
> pointing to disambiguation page in wikipedia, instead of the correct one,
> without using wikidata? This is a real problem - e.g. wikipedia link
> "pl:Józefów" is useless as it points to a list of about a hundred places of
> this name. With wikidata one can locate all similar cases and correct them
> - I have done this for Poland as well as for other countries, using Yuri's
> QA tool. Without it, disambig wikipedia links would stay there until
> someone accidentally finds one and will be willing to correct it. One by
> one. There were hundreds of such cases in Poland alone.

You don't need an additional key in OpenStreetMap to find wikipedia=*
tags pointing to disambiguation pages. By parsing the content of the
Wikipedia page and checking if the page looks like a disambiguation page.

And even if detecting disambiguation pages in Wikipedia would miss too
much of them, you could use Wikidata to check if the Wikipedia page the
Wikidata item points to is a disambiguation page according to Wikidata?

While wroting the paragraph above, I wondered how the status of a
Wikipedia page a Wikidata item links to is maintained. Is there a bot
updating them every hour in Wikidata? If there is no such bot (or it is
not running every minute or hour), there is no need for wikidata=* tags
in OSM to find wikipedia=* tags pointing to disambiguation pages because
you could get the status of a Wikipedia page by parsing the Wikipedia
page itself.

Best regards

Michael

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Talk-it] Nomi di fiumi e torrenti, e (ab)uso di waterway=river

[demon.box]

+1

sono perfettamente d'accordo perchè anch'io mi sono spesso imbattuto nel
nome del corso d'acqua mutilato (secondo me ingiustamente) della prima
parte, soprattutto nel caso delle relazioni waterway spesso nel name si
trova ad esempio "Val Grande" anzichè "Torrente Val Grande" e francamente
non mi sembra corretto.

sempre in tema di corsi d'acqua ho anche notato come tanti corsi d'acqua che
nel nome riportano il prefisso "Torrente" sono stati mappati come:

waterway=river

anzichè (secondo me) come:

waterway=stream

ciao

--enrico




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

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

Re: [OSM-talk] New OSM Quick-Fix service

[john whelan]

> I have received praises on OSM-RU channel,

Wow, within the large number of active mappers there is a very broad range
of opinions.  One or two people saying this is wonderful is not a consensus
within OpenStreetMap that it is.

Within OpenStreetMap the authority is normally accepted to be the local
mappers and the DWG.  There are processes to follow for automated edits.

I seem to recall you drawing a comparison between your work and MapRoulette.
MapRoulette identifies problems and has mappers resolve them one at a
time.  My understanding is it does not make changes or add anything to the
database.  Your approach seems to be quite different and I don't think the
two can be compared.

My understanding is you have not followed these processes and have ignored
the wishes of local mappers.  This is not a personal attack these are
issues and concerns.

Could you be so kind as to address the issues and concerns raised please.

Especially not taking into account the wishes of the local communities when
expressed.

Many Thanks

Cheerio John





On 15 October 2017 at 08:04, Yuri Astrakhan  wrote:

> Andu, with all due respect, you are misrepresenting things.  I have
> received praises on OSM-RU channel, and that's where I got my first bug
> reports and suggestions that were quickly fixed.  The current mailing
> thread also received a praise from Steve. I have received a private email
> explicitly praising this tool, some twitter feedback, plus, some general
> encouragements for my efforts. So, despite some vocal people on one side of
> the issue, claiming to represent "the community" is not accurate, as others
> have expressed opposing views.  Thus, it is not as uniform as you try to
> portray it, but rather, as any other conflict, deserves a thoughtful
> approach to attempt to balance goals of everyone, and to find a valuable
> compromise.
>
> At the same time, judging from the fact that someone did not feel
> comfortable emailing to the group, there seems to be significant toxicity
> and bullying going on.  There was a number of personal attacks, which to me
> seems to be a violation of our communication policies, and which I
> deliberately ignore. So no, I see some people in the community may support
> it, but do not want to participate in such a violent discussion. When
> someone is foaming at the mouth, people tend to stay away, rather than
> engage in a constructive discussion.
>
> Luckily, there has been some valuable feedback too, and I hope our
> community will be mature enough to provide more broadly.  For example,
> Simon was very clear and explicit about the exact deficiencies he objected
> to - something that I attempted to rectify, and will continue to improve
> on.  Some other remarks, despite being presented in a bad form, lead me to
> more good fixes such as a mandatory high zoom before editing. I am clearly
> continuing to participate in the discussion, and try to abstain from
> discussing PEOPLE, but instead concentrate on a specific IDEA being
> presented in this thread, and the specific PROBLEMS it tries to solve. As a
> volunteer. Without any financial benefit from anything I do. Same as many
> other participants on this channel, regardless of their views. Trying to
> maneuver between the abstract philosophy, various believes of what is the
> "right thing to do", and the specific problems and solutions.
>
> P.S. @mmd, sorry for not replying earlier. I suspect you meant it as an
> "ad absurdum" argument. Thing is, Wikidata does use wiki pages to store bot
> states. Mostly bots generate various talk pages and templates, and users
> sometimes modify those talk pages to control the bots. Yet, this tool has
> nothing to do with Wikidata, so it is a moot point to discuss storing OSM
> metadata there. See my reply about the "nobot" tag. I think it would help
> to partially heal the bot-nobot divide, as it gives control over each
> object to editors, and allows mini-bots.
>
> And one last thing.  Something that has helped me many times to find
> COMPROMISE in a forum discussion. When replying, let's try to sum up the
> opponent's position and the reasons for that position, and explain why you
> think it is incorrect. Perhaps we should learn from the high school debate
> class?  Sorry for the long email.
>
> On Sun, Oct 15, 2017 at 6:38 AM, ajt1...@gmail.com 
> wrote:
>
>> On 15/10/2017 11:04, Christoph Hormann wrote:
>>
>>> On Sunday 15 October 2017, Yuri Astrakhan wrote:
>>>
 [...] I was following up on the Christoph Hormann's
>> idea of the "bot=no" tag, to "allow mappers to opt out of bot
>> edits on a case-by-case basis."
>>
> No, you were not, likely because you misunderstood my suggestion
> which is likely because you don't get how OpenStreetMap is working
> overall.
>
> I would strongly advise you to reconsider your whole approach to
> OpenStreetMap and to interacting with the OpenStreetMap community.
>

Re: [OSM-talk] New OSM Quick-Fix service

[ajt1...@gmail.com]

On 15/10/2017 13:04, Yuri Astrakhan wrote:
Andu, with all due respect, you are misrepresenting things.  I have 
received praises on OSM-RU channel, and that's where I got my first 
bug reports and suggestions that were quickly fixed.  The current 
mailing thread also received a praise from Steve.


You did indeed receive one message in your favour - I miscounted. That's 
1 in favour, 1 question (from someone who has been critical elsewhere) 
and 7 against.  Maybe that counts as a majority in your favour in some 
places, but it doesn't here.


At the same time, judging from the fact that someone did not feel 
comfortable emailing to the group, there seems to be significant 
toxicity and bullying going on.

Your message to Christoph seems to be an attempt by you to do exactly that.

People are telling you to stop; you need to stop.

Any amount of dissembling by you won't change the facts.

Best Regards,

Andy


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

Re: [OSM-talk] New OSM Quick-Fix service

[Yuri Astrakhan]

Andu, with all due respect, you are misrepresenting things.  I have
received praises on OSM-RU channel, and that's where I got my first bug
reports and suggestions that were quickly fixed.  The current mailing
thread also received a praise from Steve. I have received a private email
explicitly praising this tool, some twitter feedback, plus, some general
encouragements for my efforts. So, despite some vocal people on one side of
the issue, claiming to represent "the community" is not accurate, as others
have expressed opposing views.  Thus, it is not as uniform as you try to
portray it, but rather, as any other conflict, deserves a thoughtful
approach to attempt to balance goals of everyone, and to find a valuable
compromise.

At the same time, judging from the fact that someone did not feel
comfortable emailing to the group, there seems to be significant toxicity
and bullying going on.  There was a number of personal attacks, which to me
seems to be a violation of our communication policies, and which I
deliberately ignore. So no, I see some people in the community may support
it, but do not want to participate in such a violent discussion. When
someone is foaming at the mouth, people tend to stay away, rather than
engage in a constructive discussion.

Luckily, there has been some valuable feedback too, and I hope our
community will be mature enough to provide more broadly.  For example,
Simon was very clear and explicit about the exact deficiencies he objected
to - something that I attempted to rectify, and will continue to improve
on.  Some other remarks, despite being presented in a bad form, lead me to
more good fixes such as a mandatory high zoom before editing. I am clearly
continuing to participate in the discussion, and try to abstain from
discussing PEOPLE, but instead concentrate on a specific IDEA being
presented in this thread, and the specific PROBLEMS it tries to solve. As a
volunteer. Without any financial benefit from anything I do. Same as many
other participants on this channel, regardless of their views. Trying to
maneuver between the abstract philosophy, various believes of what is the
"right thing to do", and the specific problems and solutions.

P.S. @mmd, sorry for not replying earlier. I suspect you meant it as an "ad
absurdum" argument. Thing is, Wikidata does use wiki pages to store bot
states. Mostly bots generate various talk pages and templates, and users
sometimes modify those talk pages to control the bots. Yet, this tool has
nothing to do with Wikidata, so it is a moot point to discuss storing OSM
metadata there. See my reply about the "nobot" tag. I think it would help
to partially heal the bot-nobot divide, as it gives control over each
object to editors, and allows mini-bots.

And one last thing.  Something that has helped me many times to find
COMPROMISE in a forum discussion. When replying, let's try to sum up the
opponent's position and the reasons for that position, and explain why you
think it is incorrect. Perhaps we should learn from the high school debate
class?  Sorry for the long email.

On Sun, Oct 15, 2017 at 6:38 AM, ajt1...@gmail.com 
wrote:

> On 15/10/2017 11:04, Christoph Hormann wrote:
>
>> On Sunday 15 October 2017, Yuri Astrakhan wrote:
>>
>>> [...] I was following up on the Christoph Hormann's
> idea of the "bot=no" tag, to "allow mappers to opt out of bot
> edits on a case-by-case basis."
>
 No, you were not, likely because you misunderstood my suggestion
 which is likely because you don't get how OpenStreetMap is working
 overall.

 I would strongly advise you to reconsider your whole approach to
 OpenStreetMap and to interacting with the OpenStreetMap community.

>>> Christoph, kindly explain, instead of making snide remarks. You have
>>> not added to the discussion, but instead raised the level of toxicity
>>> of this channel even further.  Note that several people have already
>>> noted that this channel is toxic and refused to participate in it,
>>> rather than being productive and beneficial to everyone involved.
>>>
>> I rest my case.
>>
>>
> Yuri,
>
> In English there is a common phrase "which part of  *** do you not
> understand" (expletive removed because people offended by such words may be
> reading).
>
> This thread https://lists.openstreetmap.org/pipermail/talk/2017-October/
> thread.html#79145 currently has replies from 9 people.  1 is asking a
> question but all other replies are entirely negative (including comments
> such as "I'm appalled" and "that isn't acceptable behaviour").
>
> Christoph Hormann's comment above is not a snide remark; it's entirely
> reasonable based on your actions so far - for an example of that see Tomas'
> reply earlier in the thread, or indeed almost any of the other interactions
> that you've had with the OSM community.
>
> Best Regards,
> Andu
>
>
>
>
> ___
> talk mailing list
> 

[OSM-talk-be] Importing Villo! API data

[CedB12]

Hello all,

Lately I have been looking at the Villo! dataset from the JCDecaux API
at [1], which is released under the Etalab Open License (see also [2]).
I want to consult the community about the use of this data to improve
the tagging of the stations we have already mapped. I would also like to
discuss a potential import of the hundred or so stations that are
reported in the API but have not been mapped yet in OSM.

My priority is to fix the tagging of station names and reference
numbers, which are often wrong or missing in the already-mapped
stations. I am aware of a few quality issues in the names reported by
the API (which, as far as I know, are actually the names reported at the
stations themselves), so this cannot be a fully automated process. As
far as ref tags are concerned, only 25 existing station nodes do not
match the API. I have not pushed any change yet in case this thread
brings up an objection to the use of this API data.

More importantly, given the quality issues in the API names, we would
need to discuss how exactly we want to tag names vs. what the "official"
names are.

To give you a quick example of what kind of problems we can find in the
API, consider that one station is named "342 - MAISON COMMUNALE DE
BERCHEM ST AGHATE". Like all other stations, the name is in all-caps.
This one in particular contains a misspelling: the commune is actually
spelled "Berchem-Ste-Agathe". Also, unlike other stations, this one has
no official Dutch name, and it is not clear to me whether we should
provide our own translation in the name and name:nl tags.

I actually got a little bit ahead of myself and had prepared a diary
entry draft as well as a more detailed and specific email for this
mailing list, but I now realize that unloading all of this at once might
have felt a bit forceful. So before I go into the details of all the
quirks in the API data and formulate a general proposal for tagging, I
wanted to take a more open-ended approach and ask if anyone had anything
to share regarding our mapping and tagging of Villo! stations. I am also
interested in your thoughts on how we should tag the station I gave
above as an example (in terms of name, name:fr, name:nl, and maybe other
kinds of name tags like official_name).

But before that, I would like to make sure that it is OK to import
Etalab-licensed data, because otherwise this effort will be pointless. I
assume it must be fine because the license states to be compatible with
"any licence which requires at least the attribution of the «
Information »" [3], including the Open Government License which is in
turn listed on the OSM wiki page on ODbL compatibility [4]. How are the
requirements of the license (attribution by source name + date + URL)
handled, though?

Also, does an operation of this scale (tagging a subset of 200 existing
nodes and possibly importing another 100) require that I follow the
import guidelines?

Thanks,

Cédric


[1] https://developer.jcdecaux.com/
[2] http://opendatastore.brussels/en/dataset/villo
[3] https://developer.jcdecaux.com/files/Open-Licence-en.pdf
[4] https://wiki.openstreetmap.org/wiki/Import/ODbL_Compatibility

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

Re: [Talk-us] Trunk

[Richard Fairhurst]

Bradley White wrote:
> The UK/Canada system and the central Europe system both adopt 
> the tag in a way that makes sense for the road network they 
> have. We are trying to shoehorn the central European tagging 
> system into our country when, to me, it makes more sense to
> use the UK/Canada system.

Just for information, if you wanted to adopt the UK system in the US, you
could do that absolutely trivially by defining highway=trunk as those
(non-motorway) roads within your National Highway System. That's pretty much
analogous to how it's used here in the UK.

https://en.wikipedia.org/wiki/National_Highway_System_(United_States)

Richard



--
Sent from: http://gis.19327.n8.nabble.com/USA-f5284732.html

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

Re: [OSM-talk] New OSM Quick-Fix service

[ajt1...@gmail.com]

On 15/10/2017 11:04, Christoph Hormann wrote:

On Sunday 15 October 2017, Yuri Astrakhan wrote:

[...] I was following up on the Christoph Hormann's
idea of the "bot=no" tag, to "allow mappers to opt out of bot
edits on a case-by-case basis."

No, you were not, likely because you misunderstood my suggestion
which is likely because you don't get how OpenStreetMap is working
overall.

I would strongly advise you to reconsider your whole approach to
OpenStreetMap and to interacting with the OpenStreetMap community.

Christoph, kindly explain, instead of making snide remarks. You have
not added to the discussion, but instead raised the level of toxicity
of this channel even further.  Note that several people have already
noted that this channel is toxic and refused to participate in it,
rather than being productive and beneficial to everyone involved.

I rest my case.



Yuri,

In English there is a common phrase "which part of  *** do you not 
understand" (expletive removed because people offended by such words may 
be reading).


This thread 
https://lists.openstreetmap.org/pipermail/talk/2017-October/thread.html#79145 
currently has replies from 9 people.  1 is asking a question but all 
other replies are entirely negative (including comments such as "I'm 
appalled" and "that isn't acceptable behaviour").


Christoph Hormann's comment above is not a snide remark; it's entirely 
reasonable based on your actions so far - for an example of that see 
Tomas' reply earlier in the thread, or indeed almost any of the other 
interactions that you've had with the OSM community.


Best Regards,
Andu



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

Re: [Talk-it] Ultimo tratto relazione Alpinistica

[matteocalosi]

Se non ci sono indicazioni/segnavia non mettere nessuna ref e nessuna
relazione sentiero, solo la way con le tag appropriate. Io non metterei
cai_scale in questo caso, sac_scale va sicuramente bene anche per tratti
(semi)alpinistici di questo tipo (scrambling, non vie di roccia vere e
proprie), altrimenti cosa esisterebbero a fare i gradi T4-T6? Per me "via
normale cima x" va bene come nome way.

La relazione andrebbe messa invece sul sentiero per il bivacco (23?) ma in
realtà andrebbe messa a partire da zero su tutti i sentieri della zona che è
da questo punto di vista completamente vuota.


voschix wrote
> forse aiuta in questa discussione
> alpino (it) = alpine (en)
> alpinistico (it) = mountaineering (en)
> 
> Sac scale:
> http://www.sac-cas.ch/it/in-cammino/scale-della-difficolta.html;
> http://www.sac-cas.ch/fileadmin/sac/PDF-Dateien/
> Unterwegs/Schwierigkeitsskala/Scala_di_difficolta_per_gite_
> escursionistiche-trekking.pdf
> http://www.sac-cas.ch/it/in-cammino/scale-della-difficolta.html;
> è solo applicabile per trekking alpino, non per tratti alpinistici
> 
> http://www.sac-cas.ch/it/in-cammino/scale-della-difficolta.html;
> 
> http://www.sac-cas.ch/it/in-cammino/scale-della-difficolta.html;
> 
> 
> 
> 2017-10-15 10:42 GMT+02:00 angelo mornata 

> angelo.mornata@

> :
> 
>> https://www.vienormali.it/montagna/cima_scheda.asp?cod=2247
>> https://www.vienormali.it/montagna/cima_scheda.asp?cod=2247;
>> Cima di Malvedello via normale - Relazione scalata Cima di ...
>> https://www.vienormali.it/montagna/cima_scheda.asp?cod=2247;
>> www.vienormali.it
>> Cima di Malvedello: descrizione della via normale di salita a Cima di
>> Malvedello nel gruppo Masino con itinerario, tempi e difficoltà
>> (relazione
>> del 16/06/2012 di ...
>> *Situazione fisica della via dal bivacco*: nessun segno di vernice,
>> nessuna traccia, 4/5 ometti non contigui, nessuna croce di vetta,
>> praticamtente via per chi ha esperienza alpinistrica, non particolarmente
>> difficile confermo la difficolta F scala CAI Alpinismo.
>>
>>
>> *Situazione grafica in OSM prima del mio inserimento*: Giorgio83 con
>> metodo sac_scale ha tracciato il sentiero che da Poira di Civo sale al
>> Bivacco, e una via alpinistica più diretta che sale alla cima.
>>
>>
>> *Situazione grafica in OSM attuale*: ho rivisto sentiero, aggiungento
>> cartelli, tratti di sentiero esistenti ma non tracciati nei pressi di Pra
>> Soccio e ultimo tratto prima di arrivare al Bivacco, ho completato il
>> nome
>> del bivacco inserendo i nomi, non solo i cognomi a cui è dedicato, ho
>> inserito il fondo del percorso(ground, gravel ecc) rispettosamente
>> non
>> ho toccato sac_scale esistente, in fine ho inserito traccia che arriva in
>> cima dal canalone.
>>
>>
>> *Attualmente manca*: Pendenze e relazione.
>>
>>
>> *Considerazioni personali*: anche a me piace una relazione unica, la
>> difficoltà da inserire è quella più alta del percorso, in questo caso F
>> (alpinistica passaggi su roccia di 1° grado).
>>
>>
>> *Dubbi d'inserimento*: *nome*... " Cima di Malvedello via normale"... o
>> cos'altro?
>>
>> *ref* quale ref?
>>
>>
>>
>> Spero che le indicazioni fornite siano sufficenti e che non portino a
>> discussioni logorroiche ma pratiche.
>>
>>
>> P.s. Sarò presente al "secondo corso di formazione per operatori
>> sentieri"
>> che si terrà sabato 21 ottobre dalle 09 alle 17 presso Casa Alpina "La
>> Montanina" Via per Campelli 23821 Piani dei Resinelli,  Organizzato dal
>> Cai
>> Riccardo Cassin Lecco e a cui parteciperà sicuramente anche un Vostro
>> rappresentante.
>>
>>
>> Nella speranza di un futuro incontro un gentile saluto
>>
>>
>> Angelo
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> *Da:* Alfredo Gattai 

> alfredo.gattai@

> 
>> *Inviato:* domenica 15 ottobre 2017 00:04
>> *A:* openstreetmap list - italiano
>> *Oggetto:* Re: [Talk-it] Ultimo tratto relazione Alpinistica
>>
>> In effetti nella proposta relativa al cai_scale e nella wiki abbiamo
>> scritto che il cai_scale e' per la relazione. Non e' che abbiamo
>> "proibito"
>> di metterlo sulla way ma non avrebbe molto senso farlo. il sac_scale gia'
>> universalmente adottato assolve a questo compito di distinguere le
>> singole
>> way, il cai_scale per il suolo italiano mette a disposizione di tutti la
>> valutazione del CAI sull'interezza del percorso.
>>
>> Il caso in questione e' particolarmente interessante perche' affronta un
>> problema non molto dibattuto fino ad ora.
>> Che cosa si intente per tratto alpinistico? La sac_scale prevede tratti
>> di
>> "path-sentiero" con difficolta' alpinistiche e questo di per se puo'
>> essere
>> fuorviante perche' comunemente chi fa alpinismo nonostante le chiami
>> "vie"
>> ha ben chiara la differenza fra una via alpinistica ed un sentiero.
>>
>> Dal mio punto di vista forse highway=path nonostante sia corredato di un
>> sac_scale=difficult_alpine_hiking non rappresenta adeguatamente quei
>> tratti 

Re: [OSM-talk] New OSM Quick-Fix service

[Christoph Hormann]

On Sunday 15 October 2017, Yuri Astrakhan wrote:
>
> > > [...] I was following up on the Christoph Hormann's
> > > idea of the "bot=no" tag, to "allow mappers to opt out of bot
> > > edits on a case-by-case basis."
> >
> > No, you were not, likely because you misunderstood my suggestion
> > which is likely because you don't get how OpenStreetMap is working
> > overall.
> >
> > I would strongly advise you to reconsider your whole approach to
> > OpenStreetMap and to interacting with the OpenStreetMap community.
> 
> Christoph, kindly explain, instead of making snide remarks. You have
> not added to the discussion, but instead raised the level of toxicity
> of this channel even further.  Note that several people have already
> noted that this channel is toxic and refused to participate in it,
> rather than being productive and beneficial to everyone involved.

I rest my case.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Talk-it] ascensione vie normali, was Ultimo tratto relazione Alpinistica

[at1839]

Un saluto a tutti.

IMHO ...



In effetti nella proposta relativa al cai_scale e nella wiki abbiamo
scritto che il cai_scale e' per la relazione.


Quasi mai, almeno nella mia esperienza, la salita di una via normale è 
assimilabile ad un *sentiero* e tanto meno ad un percorso CAI. Non per 
la difficoltà, ci sono vie normali banalissime,  ma perchè di solito i 
sentieri, quelli numerati e segnalati, si fermano *al piano di sotto*. 
Quindi quasi mai avrà senso metterla nella *relazione*. Secondo me ha 
senso invece gestirla come way indipendente e la relazione non dovrebbe 
essere un obbligo.



  il sac_scale gia'
universalmente adottato assolve a questo compito di distinguere le singole
way,


Appunto.


Che cosa si intente per tratto alpinistico?


Nella pratica corrente secondo me significa un contesto di I grado con 
passaggi, anche numerosi, di II grado. Se ci sono (pochi, brevi) 
passaggi di III grado vanno segnalati esplicitamente.  Oltre si sconfina 
nella via alpinistica.



Dal mio punto di vista forse highway=path nonostante sia corredato di un
sac_scale=difficult_alpine_hiking non rappresenta adeguatamente quei tratti
che una persona esperta affronterebbe solo corredato di imbraco, corda e
materiale per proteggersi (chiodi, nut, friends)


Trovo difficile infatti definire path queste situazioni e secondo me 
entriamo proprio in un ambito differente.







Non conosco la via in questione quindi dare un giudizio e' difficile ma
direi che la proposta di Volker e' un'idea se il percorso nella sua
interezza non eccede la cai_scale=EEA ma se e' piu' difficile forse
conviene fare la relazione solo per il tratto non alpinistico e lasciare
per il tratto alpinistico solo la way con un sac_scale adeguato.


E' esattamente come la penso anche io ed è quello che ho fatto quando mi 
sono capitati questi casi.



Esempio: Partenza, arrivo al bivacco una relazione, bivacco cima
un'altra relazione?


Ma anche senza la relazione, perchè di solito sarà un tratto unico.


Che Ref va messo su una via Alpinistica?


Non mi risulta che ancora abbiamo messo i *numerini* sulle vie 
alpinistiche ...



https://www.vienormali.it/montagna/cima_scheda.asp?cod=2247




Situazione fisica della via dal bivacco: nessun segno di vernice, nessuna 
traccia, 4/5 ometti non contigui, nessuna croce di vetta, praticamtente via per 
chi ha esperienza alpinistrica, non particolarmente difficile confermo la 
difficolta F scala CAI Alpinismo.


In questo caso abbiamo una via normale molto facile. Malgrado questo 
ribadisco che secondo me sarebbe meglio gestirla in modo indipendente 
dal resto del percorso.

Non è un tratto che va inserito in una relazione imho ...

Paolo Cecchini


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

Re: [OSM-talk] New OSM Quick-Fix service

[Yuri Astrakhan]

Christoph, kindly explain, instead of making snide remarks. You have not
added to the discussion, but instead raised the level of toxicity of this
channel even further.  Note that several people have already noted that
this channel is toxic and refused to participate in it, rather than being
productive and beneficial to everyone involved.

On Sun, Oct 15, 2017 at 5:39 AM, Christoph Hormann  wrote:

> On Sunday 15 October 2017, Yuri Astrakhan wrote:
> > [...] I was following up on the Christoph Hormann's
> > idea of the "bot=no" tag, to "allow mappers to opt out of bot edits
> > on a case-by-case basis."
>
> No, you were not, likely because you misunderstood my suggestion which
> is likely because you don't get how OpenStreetMap is working overall.
>
> I would strongly advise you to reconsider your whole approach to
> OpenStreetMap and to interacting with the OpenStreetMap community.
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> 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: [Talk-it] Ultimo tratto relazione Alpinistica

[Volker Schmidt]

forse aiuta in questa discussione
alpino (it) = alpine (en)
alpinistico (it) = mountaineering (en)

Sac scale:

http://www.sac-cas.ch/fileadmin/sac/PDF-Dateien/
Unterwegs/Schwierigkeitsskala/Scala_di_difficolta_per_gite_
escursionistiche-trekking.pdf

è solo applicabile per trekking alpino, non per tratti alpinistici







2017-10-15 10:42 GMT+02:00 angelo mornata :

> https://www.vienormali.it/montagna/cima_scheda.asp?cod=2247
> 
> Cima di Malvedello via normale - Relazione scalata Cima di ...
> 
> www.vienormali.it
> Cima di Malvedello: descrizione della via normale di salita a Cima di
> Malvedello nel gruppo Masino con itinerario, tempi e difficoltà (relazione
> del 16/06/2012 di ...
> *Situazione fisica della via dal bivacco*: nessun segno di vernice,
> nessuna traccia, 4/5 ometti non contigui, nessuna croce di vetta,
> praticamtente via per chi ha esperienza alpinistrica, non particolarmente
> difficile confermo la difficolta F scala CAI Alpinismo.
>
>
> *Situazione grafica in OSM prima del mio inserimento*: Giorgio83 con
> metodo sac_scale ha tracciato il sentiero che da Poira di Civo sale al
> Bivacco, e una via alpinistica più diretta che sale alla cima.
>
>
> *Situazione grafica in OSM attuale*: ho rivisto sentiero, aggiungento
> cartelli, tratti di sentiero esistenti ma non tracciati nei pressi di Pra
> Soccio e ultimo tratto prima di arrivare al Bivacco, ho completato il nome
> del bivacco inserendo i nomi, non solo i cognomi a cui è dedicato, ho
> inserito il fondo del percorso(ground, gravel ecc) rispettosamente non
> ho toccato sac_scale esistente, in fine ho inserito traccia che arriva in
> cima dal canalone.
>
>
> *Attualmente manca*: Pendenze e relazione.
>
>
> *Considerazioni personali*: anche a me piace una relazione unica, la
> difficoltà da inserire è quella più alta del percorso, in questo caso F
> (alpinistica passaggi su roccia di 1° grado).
>
>
> *Dubbi d'inserimento*: *nome*... " Cima di Malvedello via normale"... o
> cos'altro?
>
> *ref* quale ref?
>
>
>
> Spero che le indicazioni fornite siano sufficenti e che non portino a
> discussioni logorroiche ma pratiche.
>
>
> P.s. Sarò presente al "secondo corso di formazione per operatori sentieri"
> che si terrà sabato 21 ottobre dalle 09 alle 17 presso Casa Alpina "La
> Montanina" Via per Campelli 23821 Piani dei Resinelli,  Organizzato dal Cai
> Riccardo Cassin Lecco e a cui parteciperà sicuramente anche un Vostro
> rappresentante.
>
>
> Nella speranza di un futuro incontro un gentile saluto
>
>
> Angelo
>
>
>
>
>
>
>
>
>
> --
> *Da:* Alfredo Gattai 
> *Inviato:* domenica 15 ottobre 2017 00:04
> *A:* openstreetmap list - italiano
> *Oggetto:* Re: [Talk-it] Ultimo tratto relazione Alpinistica
>
> In effetti nella proposta relativa al cai_scale e nella wiki abbiamo
> scritto che il cai_scale e' per la relazione. Non e' che abbiamo "proibito"
> di metterlo sulla way ma non avrebbe molto senso farlo. il sac_scale gia'
> universalmente adottato assolve a questo compito di distinguere le singole
> way, il cai_scale per il suolo italiano mette a disposizione di tutti la
> valutazione del CAI sull'interezza del percorso.
>
> Il caso in questione e' particolarmente interessante perche' affronta un
> problema non molto dibattuto fino ad ora.
> Che cosa si intente per tratto alpinistico? La sac_scale prevede tratti di
> "path-sentiero" con difficolta' alpinistiche e questo di per se puo' essere
> fuorviante perche' comunemente chi fa alpinismo nonostante le chiami "vie"
> ha ben chiara la differenza fra una via alpinistica ed un sentiero.
>
> Dal mio punto di vista forse highway=path nonostante sia corredato di un
> sac_scale=difficult_alpine_hiking non rappresenta adeguatamente quei
> tratti che una persona esperta affronterebbe solo corredato di imbraco,
> corda e materiale per proteggersi (chiodi, nut, friends)
>
> Dato che sembra ormai aver preso piede highway=via_ferrata per tutti quei
> tratti attrezzati con cavi, pioli, etc forse bisognerebbe ipotizzare una
> highway=climb o qualcosa del genere.
>
> Esiste gia' una proposta per climbing route ma che e' specifica e vere e
> proprie vie di arrampicata infatti spesso possono essere rappresentate solo
> con un nodo o al massimo due molto vicini.
>
> Non conosco la via in questione quindi dare un giudizio e' difficile ma
> direi che la proposta di Volker e' un'idea se il percorso nella sua
> interezza non eccede la cai_scale=EEA ma se e' piu' difficile forse
> conviene fare la relazione 

Re: [OSM-talk] New OSM Quick-Fix service

[Christoph Hormann]

On Sunday 15 October 2017, Yuri Astrakhan wrote:
> [...] I was following up on the Christoph Hormann's
> idea of the "bot=no" tag, to "allow mappers to opt out of bot edits
> on a case-by-case basis."

No, you were not, likely because you misunderstood my suggestion which 
is likely because you don't get how OpenStreetMap is working overall.

I would strongly advise you to reconsider your whole approach to 
OpenStreetMap and to interacting with the OpenStreetMap community.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Talk-it] Ultimo tratto relazione Alpinistica

[angelo mornata]

https://www.vienormali.it/montagna/cima_scheda.asp?cod=2247

[https://www.vienormali.it/images/fotocime/2247_cimadimalvedello1.jpg]

Cima di Malvedello via normale - Relazione scalata Cima di 
...
www.vienormali.it
Cima di Malvedello: descrizione della via normale di salita a Cima di 
Malvedello nel gruppo Masino con itinerario, tempi e difficoltà (relazione del 
16/06/2012 di ...

Situazione fisica della via dal bivacco: nessun segno di vernice, nessuna 
traccia, 4/5 ometti non contigui, nessuna croce di vetta, praticamtente via per 
chi ha esperienza alpinistrica, non particolarmente difficile confermo la 
difficolta F scala CAI Alpinismo.


Situazione grafica in OSM prima del mio inserimento: Giorgio83 con metodo 
sac_scale ha tracciato il sentiero che da Poira di Civo sale al Bivacco, e una 
via alpinistica più diretta che sale alla cima.


Situazione grafica in OSM attuale: ho rivisto sentiero, aggiungento cartelli, 
tratti di sentiero esistenti ma non tracciati nei pressi di Pra Soccio e ultimo 
tratto prima di arrivare al Bivacco, ho completato il nome del bivacco 
inserendo i nomi, non solo i cognomi a cui è dedicato, ho inserito il fondo del 
percorso(ground, gravel ecc) rispettosamente non ho toccato sac_scale 
esistente, in fine ho inserito traccia che arriva in cima dal canalone.


Attualmente manca: Pendenze e relazione.


Considerazioni personali: anche a me piace una relazione unica, la difficoltà 
da inserire è quella più alta del percorso, in questo caso F (alpinistica 
passaggi su roccia di 1° grado).


Dubbi d'inserimento: nome... " Cima di Malvedello via normale"... o cos'altro?

ref quale ref?



Spero che le indicazioni fornite siano sufficenti e che non portino a 
discussioni logorroiche ma pratiche.


P.s. Sarò presente al "secondo corso di formazione per operatori sentieri" che 
si terrà sabato 21 ottobre dalle 09 alle 17 presso Casa Alpina "La Montanina" 
Via per Campelli 23821 Piani dei Resinelli,  Organizzato dal Cai Riccardo 
Cassin Lecco e a cui parteciperà sicuramente anche un Vostro rappresentante.


Nella speranza di un futuro incontro un gentile saluto


Angelo









Da: Alfredo Gattai 
Inviato: domenica 15 ottobre 2017 00:04
A: openstreetmap list - italiano
Oggetto: Re: [Talk-it] Ultimo tratto relazione Alpinistica

In effetti nella proposta relativa al cai_scale e nella wiki abbiamo scritto 
che il cai_scale e' per la relazione. Non e' che abbiamo "proibito" di metterlo 
sulla way ma non avrebbe molto senso farlo. il sac_scale gia' universalmente 
adottato assolve a questo compito di distinguere le singole way, il cai_scale 
per il suolo italiano mette a disposizione di tutti la valutazione del CAI 
sull'interezza del percorso.

Il caso in questione e' particolarmente interessante perche' affronta un 
problema non molto dibattuto fino ad ora.
Che cosa si intente per tratto alpinistico? La sac_scale prevede tratti di 
"path-sentiero" con difficolta' alpinistiche e questo di per se puo' essere 
fuorviante perche' comunemente chi fa alpinismo nonostante le chiami "vie" ha 
ben chiara la differenza fra una via alpinistica ed un sentiero.

Dal mio punto di vista forse highway=path nonostante sia corredato di un 
sac_scale=difficult_alpine_hiking non rappresenta adeguatamente quei tratti che 
una persona esperta affronterebbe solo corredato di imbraco, corda e materiale 
per proteggersi (chiodi, nut, friends)

Dato che sembra ormai aver preso piede highway=via_ferrata per tutti quei 
tratti attrezzati con cavi, pioli, etc forse bisognerebbe ipotizzare una 
highway=climb o qualcosa del genere.

Esiste gia' una proposta per climbing route ma che e' specifica e vere e 
proprie vie di arrampicata infatti spesso possono essere rappresentate solo con 
un nodo o al massimo due molto vicini.

Non conosco la via in questione quindi dare un giudizio e' difficile ma direi 
che la proposta di Volker e' un'idea se il percorso nella sua interezza non 
eccede la cai_scale=EEA ma se e' piu' difficile forse conviene fare la 
relazione solo per il tratto non alpinistico e lasciare per il tratto 
alpinistico solo la way con un sac_scale adeguato.

Se hai un esempio fotografico o se hai informazioni sulla via in questione da 
consultare potremmo usarla come caso di studio.

Ciao
Alfredo





2017-10-14 22:56 GMT+02:00 Ivo Reano 
>:
Interessante questa distinzione tra il sac_scale sulla way, accettata in modo 
universale e il cai_scale sulla relazione.

Mi piacerebbe sentire cosa dice Alfredo e il sosec
Però devo aggiungere che da neofito per i sentieri a catasto regionale di cui 
sto creando le relazioni, effettivamente ho già fatto cosi:
il sac_scale lo lascio cosi com'è se presente e sul percorso metto quello 
deciso dal 

Re: [Talk-us] Trunk

[Mark Wagner]

On Sat, 14 Oct 2017 22:40:16 -0700
Bradley White  wrote:

> If we can determine importance (which is what the 'highway=' tag
> fundamentally represents per the wiki) solely by what's on the ground,
> why not just tag what's physically there, ditch the 'highway' tag
> altogether, and let the renders handle it with their own algorithms?

Because we can't.

WA-290 at Starr Road is two paved lanes wide, with 12-foot lanes and
4-foot paved shoulders.  It has a speed limit of 45 mph.

WA-261 at Lyons Ferry Fish Hatchery is two paved lanes wide, with
11-foot lanes and 4-foot paved shoulders.  It has a speed limit of 50
mph.

Two very similar-looking roads, so they should have similar
classifications, right?  WA-261 runs from nowhere much to nowhere
much, and sees maybe 300 vehicles a day.  In contrast, WA-290 is the
other major route between the Spokane and Coeur d'Alene metropolitan
areas (the main route is the interstate), and sees 13,000 vehicles a
day go by.  If you omitted WA-261 from a map, almost nobody would
notice.  If you omitted WA-290, people would discard your map as
useless.

I've driven both roads, and they *feel* very different.  But it's not a
difference that I can put into numbers -- at least, not without putting
a traffic counter out for a few days.

-- 
Mark

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

Re: [Talk-us] Trunk

[Paul Johnson]

Not entirely a bad idea, but runs fundamentally in to the same issue this
thread is about, if not moreso.  FM 2161 would wind up as a more
significant road than OR 22 in such a scenario.  Never mind that OR 22 on
the west side of Salem, OR is a major 50 MPH expressway going directly to
the core of Oregon's capital as an expressway leading west from the
Willamette RIver to OR 99W.  FM 2161 is a 70 MPH road best known for part
of it being US 66 before 1988 when US 66 was retired.  I'd still consider
OR 22 as a trunk.  The old_ref=US 66 portion of ref=FM 2161 would be a
judgement call on primary, even if I'd consider most Texas Farm to Market
routes as unclassified or tertiary; it's extremely strong historical
significiance would be what brings it to as high as secondary or primary in
my mind, despite being literally of the same design and barely less
significant than US 97 for most of it's length.

On Sun, Oct 15, 2017 at 12:40 AM, Bradley White 
wrote:

> If we can determine importance (which is what the 'highway=' tag
> fundamentally represents per the wiki) solely by what's on the ground,
> why not just tag what's physically there, ditch the 'highway' tag
> altogether, and let the renders handle it with their own algorithms?
>
> >On Sun, Oct 15, 2017 at 12:19 AM, Paul Johnson 
> wrote:
> >>
> >> The US is pretty well known for overbuilding highways.  Are we trying to
> >> document how things are on the ground or how things are actually
> >> connected?  If we're going for the former, then yeah, only Bend Parkway
> and
> >> a brief streak through Klamath Falls is a trunk part of US 97.  If we're
> >> going for the latter, then go ahead with NE2's idea and smash almost
> >> everything into trunk.
> >>
> >
> >
> >Keep hitting send too soon.  Personally, I find what's on the ground to be
> >more useful than the connections.  Game theory and any routing engine can
> >figure out the connections.  But knowing what's a stupid rural road with
> an
> >overly generous speed limit and what's almost but not quite a freeway is
> >more useful.  If I'm driving a big rig going from southwestern Canada or
> >Alaska to somewhere in Nevada, I don't give two shakes what some toolbag
> >things is the most prominent road.  I care more about what *actually is a
> >big road*.  Calling a two leg segment of US 97 30km outside of East
> >Butthump, Oregon a trunk is a great disservice when it's basically on par
> >with County Road Number Who Even Cares tracing off to Outer
> >Smalltownsville, other than the fact that it goes through.  Calling it a
> >trunk when it's not is going to set an unreasonably high expectation for
> >what is otherwise an overtravelled, glorified two digit National Forest
> >route through the east Cascades frontier.  Primary is definitely ample for
> >that road, even if you're going a more obscure minor haul route like Salem
> >to Reno.
>
> ___
> 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