[Talk-us] rayman 765

[Albert Pundt]

A user by the name of rayman 765 has been making some... interesting edits.
He seems to be mapping some fictitious road "80/erie highway", in bits and
pieces with various classifications (everything from secondary to
motorway). He's also been adding and naming streets with abbreviated names
and no capitalization whatsoever.

Every single one of his edits has the comment "breezwood pa", even though
hardly any of his edits are around Breezewood.

What's the proper thing to do here? Obviously I can't just mass-undo every
single one of his edits, but obviously this "Route 80" is complete BS.

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

[OSM-talk] Limitations on mapping private information

[Tom Pfeifer]

While OSM has a Privacy Policy [1] regarding the data of OSM users, it appears we are lacking a 
central reference point about which personal data about individuals are to be mapped within the OSM 
database, and which not.


For the purpose, a wiki page has been created [2] which can be discussed here 
or on the talk page.
The intent is to embed a summary in the Good practice page [3], after 
consolidation.

[1] https://wiki.openstreetmap.org/wiki/Privacy_Policy
[2] 
https://wiki.openstreetmap.org/wiki/Limitations_on_mapping_private_information
[3] https://wiki.openstreetmap.org/wiki/Good_practice

Kind regards
Tom

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

Re: [Talk-ca] BC2020i - Solving the licensing issues

[Tracey P. Lauriault]

Makes sense Stewart!

On Fri, Feb 9, 2018 at 5:37 PM, Stewart C. Russell  wrote:

> On 2018-02-08 08:39 PM, Tracey P. Lauriault wrote:
> >
> > OSM resembles ordnance survey as was part of the original raison
> > d'etre When it started in the UK, but that does not preclude the
> > possibility of incorporating administrative boundaries such as wards,
> > and less formal boundaries such as neighbourhoods, and potentially
> > even other cachtment are boundaries such as school boards, and police
> > districts and so on.
>
> The guiding principles of OSM are “How We Map”
> :
>
> > Contributions to OpenStreetMap should be:
> >
> > * Truthful - means that you cannot contribute something you have
> > invented.
> > * Legal - means that you don't copy copyrighted data without
> > permission.
> > * Verifiable - means that others can go there and see for themselves if
> > your data is correct.
> > * Relevant - means that you have to use tags that make clear to others
> > how to re-use the data.
> > When in doubt, also consider the "on the ground rule": map the world
> > as it can be observed by someone physically there.
>
> The difficulty with neighbourhoods, catchment areas and other soft
> boundaries is that they can't be verified on the ground. The only
> reference is the imported source file. Boundaries
>  are assigned a fairly
> limited set of tags, and administrative boundaries a very
> narrowly-defined set of values
> .
> Administrative boundaries tend to pile up in Nominatim's address
> resolution - I'm supposed to be living in "The Golden Mile, Scarborough,
> Toronto, Ontario" (neighbourhood, postal town, city, province), though
> no-one uses that level of detail. Also, the Federal neighbourhood points
> (imported years ago) don't match municipal neighbourhoods (according to
> the city, I'm in Kennedy Park).
>
> So while municipal boundaries have their place in OSM, a really good
> case (and a whole lot of convincing tagging mavens) would need to be
> made before those softer boundaries made it into OSM.
>
> cheers,
>  Stewart
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>



-- 
*Tracey P. Lauriault*

Assistant Professor
Critical Media Studies and Big Data
Communication Studies
School of Journalism and Communication
Suite 4110, River Building
Carleton University
1125 Colonel By Drive
Ottawa (ON) K1S 5B6

1-613-520-2600 x7443
tracey.lauria...@carleton.ca
@TraceyLauriault
Skype: Tracey.P.Lauriault
https://carleton.ca/sjc/people-archives/lauriault-tracey/
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] BC2020i - Solving the licensing issues

[Stewart C. Russell]

On 2018-02-08 08:39 PM, Tracey P. Lauriault wrote:
> 
> OSM resembles ordnance survey as was part of the original raison
> d'etre When it started in the UK, but that does not preclude the
> possibility of incorporating administrative boundaries such as wards,
> and less formal boundaries such as neighbourhoods, and potentially
> even other cachtment are boundaries such as school boards, and police
> districts and so on.

The guiding principles of OSM are “How We Map”
:

> Contributions to OpenStreetMap should be:
> 
> * Truthful - means that you cannot contribute something you have
> invented.
> * Legal - means that you don't copy copyrighted data without
> permission.
> * Verifiable - means that others can go there and see for themselves if
> your data is correct.
> * Relevant - means that you have to use tags that make clear to others
> how to re-use the data.
> When in doubt, also consider the "on the ground rule": map the world
> as it can be observed by someone physically there.

The difficulty with neighbourhoods, catchment areas and other soft
boundaries is that they can't be verified on the ground. The only
reference is the imported source file. Boundaries
 are assigned a fairly
limited set of tags, and administrative boundaries a very
narrowly-defined set of values
.
Administrative boundaries tend to pile up in Nominatim's address
resolution - I'm supposed to be living in "The Golden Mile, Scarborough,
Toronto, Ontario" (neighbourhood, postal town, city, province), though
no-one uses that level of detail. Also, the Federal neighbourhood points
(imported years ago) don't match municipal neighbourhoods (according to
the city, I'm in Kennedy Park).

So while municipal boundaries have their place in OSM, a really good
case (and a whole lot of convincing tagging mavens) would need to be
made before those softer boundaries made it into OSM.

cheers,
 Stewart

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

Re: [Talk-it] [Imports] Fwd: Re: Sabbioneta buildings import

[Giorgio Limonta]

 On Thu, Feb 8, 2018 at 2:49 PM, Andrea Musuruane 
wrote:

Hi Andrea,

I understand this is your first import (and I definitely hope it's not your
> last!). It's really difficult to get things right the first time. Imports
> are not easy tasks - there are so much things to pay attention to.
> I find your goal valuable. Having buildings for Sabbioneta (BTW, it's nice
> place I visited some moons ago :-)) in OSM is definitely welcome.


Yes I was joking, really thank you for your time. I hope our work could
help future import processes.


> > The "Schedule" chapter is missing.
> >>
> >
> Fine, but English can be improved:



*The Municipality of Sabbioneta released a written permission in December
> 2017 stating it allows works derived from the "Carta Tecnica Comunale" to
> be distributed under the ODbL. My aim is to upload building data by the end
> of February 2018. *
>
> > "Import Type" section in "Import Data" chapter is missing. You should
> >> likely say your import is a one-time import, you won't use automated
> >> scripts, all the tags will be entered manually and data will be
> imported in
> >> the OSM database using JOSM.
> >
> >
> >
> > I hope that everything is clearer now
> >
> >
> Yes, much better, thanks.
> English can be improved:
> *This is a one-time import. The dataset will be uploaded as a single
> changeset without using an automated script. All the tags will be entered
> manually and the dataset will be uploaded using JOSM.*


Done thank you

> You should upload the original dataset.
> >
> >
> >
> > I can't. the Municipality license it's just to extract the data and share
> > throught Osm.
> >
> >
> I think it's fine but, if possible, I'd like to have a more authoritative
> (i.e. legal) opinion about this: we can't see the source data set but we're
> allowed to derive works from it.



> "Data license" should link to a text copy of the ODbL.
> >> "Type of license" should be "ODbL".
> >
> >
> >
> > Done (I hope)
> >
> >
> This is strictly linked with the previous point.
> *Data license:* *proprietary* (owned by the Municipality of Sabbioneta)
> [...]
> *ODbL Compliance verified:* Municipality of Sabbioneta has agreed to
> license *derived* data under the ODbL
> .


I am waiting clarification but I belive this doesn't stop the import (I
hope)

> The data still have some issue:
> >> - adjacent buildings that are not connected
> >> - a building has self-intersecting ways
> >
> >
> > Fix it, sorry Josm marked as Advertising and I ignored them.
> >
> >
> JOSM validator still shows two warnings you must address.


Yes now


>
> > - churches are tagged with "denominati" (it should be denomination)
> >
> >
> > Yes sorry was a mistake depending to the shp field name limitation...
> >
> >
> Now the OSM file has both the "denominati"  and " "denomination" tags :-(


Yes sorry...  

>
> > - bell towers are tagged with man_made=campanile (shouldn't it be
> >> man_made=tower + tower:type=bell_tower?) and without the building tag.
> See
> >> https://wiki.openstreetmap.org/wiki/Tag:tower:type%3Dbell_tower
> >
> >
> > I found it in the wiki https://wiki.openstreetmap.org
> > /wiki/Tag:man_made%3Dcampanile
> >
> >
> This has been discussed in the past in the talk-it ML.
> The tag man_made=campanile is documented in the wiki but is used only 791
> times. Moreover the picture refers to the Swedish Klockstapel which is
> completely different from a "campanile". The normal tagging for a campanile
> is man_made=tower + tower:type= bell_tower (used 10595 times). Even the
> man_made=campanile wiki page suggest to use this tagging.


Ok, at the beginning when I found "Campanile" I said "this is
perfect!!" and I haven't search further...

> some buildings are split in different parts (still tagged as building=*)
> >> and you assign different heights to them. I'm not an expert about this
> but
> >> it seems this is not the right procedure. Please read
> >> https://wiki.openstreetmap.org/wiki/Key:height#Height_of_buildings and
> >> https://wiki.openstreetmap.org/wiki/Simple_3D_buildings
> >
> >
> > Was identified all single buildings that have different height to add in
> a
> > future mapping phase other tag to improve the detail map (level, color,
> > roof_,shape, etc.). That was made with a manually split procedure but I
> > have splited only the building (not the building part).
> >
> >
> Your tagging is wrong. Look at the following example.
> [image: Inline image 1]
> This is a house. It is a single building. This also means you should have
> only one building tag on the building outline.
> But you made two buildings (i.e. with two building tags): one for the lower
> part (a multi polygon) and one for the higher part (a closed way). But
> different parts must be tagged with building:part as explained on
> https://wiki.openstreetmap.org/wiki/Simple_3D_buildings


Yes now I have understud and you are absolutely right, I fixed that and the
other 

Re: [Talk-it] Tabellone con foto

[liste DOT girarsi AT posteo DOT eu]

Il 09/02/2018 21:39, demon.box ha scritto:

ciao, che board_type potrei mettere a questo tipo di bacheca
fotografica/storica?



grazie



Per me history, come quello dell'altra volta, anche se contiene foto mi 
pare sempre rientri in un contesto di informazione storica.



--
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|
Simone Girardelli

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

[Talk-it] Tabellone con foto

[demon.box]

ciao, che board_type potrei mettere a questo tipo di bacheca
fotografica/storica?

 

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-us] OpenStreetMap US Board Elections

[Ian Dees]

Hello,

I invite all my fellow US-based OpenStreetMap enthusiasts to run for the
board of OpenStreetMap US. We initially announced that the deadline for
nominations was the 4th of February, but so few people nominated that we
extended it to the 11th (this Sunday).

Please check out the original blog post announcing the election in January:

http://www.openstreetmap.us/2018/01/board-elections/

and the updated blog post from today:

http://www.openstreetmap.us/2018/02/board-elections-extra-time/

Nominate yourself on the wiki page here:

https://wiki.openstreetmap.org/wiki/Foundation/Local_Chapters/United_States/Elections/2017#Candidates

Let us know if you have any questions, and we look forward to hearing from
you all at our townhall with the candidates next week!

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

[Talk-TW] 樹木消失問題

[Dennis Raylin Chen]

Dear all

先前Miller Liu不知道為了什麼原因，把台灣地圖上能看到的樹林都刪除了

像是台大椰林大道的樹木

https://www.openstreetmap.org/changeset/53688054#map=12/24.9941/121.4810
https://www.openstreetmap.org/changeset/53685400
https://www.openstreetmap.org/changeset/52682153#map=8/23.856/121.398
https://www.openstreetmap.org/changeset/53628628#map=11/25.0297/121.6951
https://www.openstreetmap.org/changeset/53630421#map=8/23.995/121.034
https://www.openstreetmap.org/changeset/53663846
https://www.openstreetmap.org/changeset/53249016#map=14/25.0082/121.5520
https://www.openstreetmap.org/changeset/5305
https://www.openstreetmap.org/changeset/50714300
https://www.openstreetmap.org/changeset/53196001#map=8/24.231/120.600
https://osmcha.mapbox.com/changesets/53581600
https://osmcha.mapbox.com/changesets/53665006
https://osmcha.mapbox.com/changesets/52818017
https://osmcha.mapbox.com/changesets/50942593
https://osmcha.mapbox.com/changesets/52984166

https://trello.com/c/Dxaq5IYM/1010-%E8%A7%A3%E6%B1%BA%E5%8F%B0%E5%A4%A7%E6%A4%B0%E6%9E%97%E5%A4%A7%E9%81%93%E6%A8%B9%E6%B6%88%E5%A4%B1%E5%95%8F%E9%A1%8C

如果有人曾標記樹木，但現在地圖上看不到，很可能被刪除了
要把樹木放上去的話，請告訴我當初編輯的changeset，嘗試恢復看看

Dennis
___
Talk-TW mailing list
Talk-TW@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-tw

Re: [Talk-it] Incoerenza della wiki e difficoltà nel suo aggiornamento (era: Oratorio)

[Martin Koppenhoefer]

2018-02-09 16:51 GMT+01:00 Simone Saviolo :

> Il giorno 9 febbraio 2018 16:04, Martin Koppenhoefer <
> dieterdre...@gmail.com> ha scritto:
>
> In che modo è una feature?
>
>

rispecchia il consenso, e se assente, si può capire.




> Taginfo è un tool per navigare la giungla.
>>
>
> Sentite, io mappo dal 2009, quando il progetto aveva 5 anni. Allora si
> diceva che il progetto doveva crescere. Ora ne ha quasi 15, di anni, e
> invece di crescere esplode ogni giorno di più. La giungla si infittisce, e
> quando qualcuno offre un machete insorge qualcun altro che dice che i nuovi
> utenti potrebbero tagliarsi con la lama, oppure che la rigogliosità della
> vegetazione è la principale ricchezza di questa giungla.
>
> Il che è pure vero nel Borneo o nel Mato Grosso, ma in un progetto
> informatico no.
>


il progetto informatico è la parte backend, frontend, app, db, ecc. mentre
OSM è un progetto social ;-)

Anch'io ci sto da 10 anni, e devo dire che non mi lamento del progresso.

Si, è vero che il wiki non è sempre e in ogni caso d'aiuto, ma alla fine
nella maggiorparte dei casi si trova lo stato della mappa anche descritto e
definito nel wiki.

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

Re: [Talk-it] Incoerenza della wiki e difficoltà nel suo aggiornamento (era: Oratorio)

[Simone Saviolo]

Il giorno 9 febbraio 2018 16:04, Martin Koppenhoefer  ha scritto:

> un db a parte non sarebbe male (si sta anche cercando di farlo con i tag
> wikidata), ma per le definizioni mi sembra meglio un wiki, perché è
> trasparente. Un db è troppo complesso, e si prenderebbe "l'autorità di
> interpretazione" ("Deutungshoheit"). Si potrebbe avere solo un significato,
> mentre il wiki consente di avere più significati concorrenti (ciò che voi
> lamentate non è necessariamente un bug, è anche un feature). Oppure si
> consente al db di essere "schizofrenico" come il wiki, ma come risultato
> non si otterebbe più risposte chiare. ;-)
>

In che modo è una feature?

Taginfo è un tool per navigare la giungla.
>

Sentite, io mappo dal 2009, quando il progetto aveva 5 anni. Allora si
diceva che il progetto doveva crescere. Ora ne ha quasi 15, di anni, e
invece di crescere esplode ogni giorno di più. La giungla si infittisce, e
quando qualcuno offre un machete insorge qualcun altro che dice che i nuovi
utenti potrebbero tagliarsi con la lama, oppure che la rigogliosità della
vegetazione è la principale ricchezza di questa giungla.

Il che è pure vero nel Borneo o nel Mato Grosso, ma in un progetto
informatico no.

Ciao,

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

Re: [Talk-ca] Talk-ca Digest, Vol 120, Issue 23

[Jonathan Brown]

I concur. Take it one step further. Show different examples of good, bad and 
ugly building models based on explicit criteria. This will help us “educate” 
those who are keen on participating. Another consideration is accessibility 
strategies for those disabilities. 

Jonathan 

From: talk-ca-requ...@openstreetmap.org
Sent: Friday, February 9, 2018 7:01 AM
To: talk-ca@openstreetmap.org
Subject: Talk-ca Digest, Vol 120, Issue 23

Send Talk-ca mailing list submissions to
talk-ca@openstreetmap.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.openstreetmap.org/listinfo/talk-ca
or, via email, send a message with subject or body 'help' to
talk-ca-requ...@openstreetmap.org

You can reach the person managing the list at
talk-ca-ow...@openstreetmap.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Talk-ca digest..."


Today's Topics:

   1. Re: BC2020i and Mapathons with High Schools (OSM Volunteer stevea)
   2. Re: BC2020i - Solving the licensing issues (Tracey P. Lauriault)


--

Message: 1
Date: Thu, 8 Feb 2018 16:00:17 -0800
From: OSM Volunteer stevea 
To: talk-ca 
Subject: Re: [Talk-ca] BC2020i and Mapathons with High Schools
Message-ID: 
Content-Type: text/plain;   charset=us-ascii

I'd love to see in OSM (with a nod by STATCAN?) a Canadian "model building" 
(one will do), linked in the wiki.  Richly-tagged and well done, to provide a 
standard to shoot for.  To close a small, tight QA loop, as it were.  "Here is 
what we'd like to see more of."  Start small, document it.  That seems a fairly 
low bar to step over.

Later,
SteveA


--

Message: 2
Date: Thu, 8 Feb 2018 20:39:33 -0500
From: "Tracey P. Lauriault" 
To: "Alasia, Alessandro (STATCAN)" ,
James McKinney 
Cc: "talk-ca@openstreetmap.org" 
Subject: Re: [Talk-ca] BC2020i - Solving the licensing issues
Message-ID:

Content-Type: text/plain; charset="utf-8"

This is great! And it reflects the recommendations provided at the first
consultation meetings with your management at Satistics Canada. I believe
there is merit in talking with the municipalities from whom you are
accessing the data, simply as a courtesy, but also as a way to enlist them
as part of the project, and potentially they may have a better and more up
to date dataset than what they share in their open data. And may even have
other data of use.

OSM resembles ordnance survey as was part of the original raison d'etre
When it started in the UK, but that does not preclude the possibility of
incorporating administrative boundaries such as wards, and less formal
boundaries such as neighbourhoods, and potentially even other cachtment are
boundaries such as school boards, and police districts and so on.

I am including James McKinney in this conversation because he did some work
in compiling quite a few municipal base files when he was the ed for Open
North.

And there most definitely will be variable quality, and ontologies! Vive la
difference!

Nice work and kudos to you and your team.
TRacey


On Wednesday, February 7, 2018, Alasia, Alessandro (STATCAN) <
alessandro.ala...@canada.ca> wrote:

> Dear all,
>
> It is fantastic to see all these exchanges about BC2020i! There are a lot
> of great ideas and improvements being made. I cannot follow up on each
> point, though I wanted to update you regarding one area of specific
> relevance: the attempt to find a solution to the licensing issue for
> building related datasets. I believe this is one area where my team can
> contribute to support the BC2020i.
>
> With my team, I am looking into the feasibility of compiling all available
> municipal open data files into one single file and then releasing this
> single file under one common license, specifically the open data licence of
> the Canadian federal government. This would, hopefully, solve the license
> compatibility issue. We are still exploring this possibility but are
> moderately optimistic.
>
> So far we started with the "easy" task: compiling all the known files – a
> special thanks to those who contributed to the tables on the BC2020i wiki
> page! With that and other OD sources, we compiled an
> "OpenAddressRepository" file of nearly 11 million records (georeferenced)
> and an "OpenBuildingRepository" file of nearly 3.2 million polygons (still
> in progress). Preliminary analysis suggests that the coverage and geocoding
> are very promising. More importantly, given that the files all originate
> from official municipal sources, there should be no reason to doubt the
> quality of the data.
>
> The 

Re: [Talk-it] Incoerenza della wiki e difficoltà nel suo aggiornamento (era: Oratorio)

[Martin Koppenhoefer]

2018-02-08 12:01 GMT+01:00 Lorenzo "Beba" Beltrami :

> Ciao Martin,
> sono d'accordo con te sul caso specifico dei social_facility e sul fatto
> che noi riempiamo un database "alla cieca" rispetto a quello che cerca
> l'utente (e la trovo una cosa non sbagliata).
>
> Quello che però Enrico lamentava è che nella wiki a volte ci sono delle
> informazioni riportate in una pagina generica e non in una specifica o
> viceversa.
>


nel wiki si scrivono tante cose, le pagine dei features (tag: e key: come
https://wiki.openstreetmap.org/wiki/Key:highway ) sono quelli che
definiscono i tag, le altre servono a riassumere, ma non devono
contradirele pagine di definizione, e se lo fanno si dovrebbe correggere.




> Questo è un problema di coerenza del dato (nell'esempio il dato
> "deprecated" per il tag amenity=social_facility).
> Faccio un esempio per vedere se riesco ad essere più chiaro.
> Mettiamo caso che in futuro si voglia eliminare la categoria ridondante
> amenity=social_facility. Questa cosa va indicata sia nella pagina della
> chiave amenity, che in quella del tag amenity=social_facility, in tutte le
> sottopagine social_facility=*, in tutte le guide discorsive, ecc. ecc.
>


cosa intendi con "si voglia eliminare"? I casi dove i tag diffusi sono
stati "eliminati" sono quasi inesistenti, e se un tag "più o meno
funziona", anche se ci sono alternative "migliori" (da un certo punto di
vista), continuerà ad esistere.



>
> Sarebbe bello avere un database centralizzato (e machine readable) che
> contenga i dati (e magari anche le varie traduzioni) per la documentazione.
> Con questo db potresti poi creare dinamicamente le pagine del wiki e, nel
> caso ci sia un aggiornamento, verrebbe tutto aggiornato in automatico.
>


un db a parte non sarebbe male (si sta anche cercando di farlo con i tag
wikidata), ma per le definizioni mi sembra meglio un wiki, perché è
trasparente. Un db è troppo complesso, e si prenderebbe "l'autorità di
interpretazione" ("Deutungshoheit"). Si potrebbe avere solo un significato,
mentre il wiki consente di avere più significati concorrenti (ciò che voi
lamentate non è necessariamente un bug, è anche un feature). Oppure si
consente al db di essere "schizofrenico" come il wiki, ma come risultato
non si otterebbe più risposte chiare. ;-)




> A volte si usa Taginfo per questo (vedi la creazione automatica di alcune
> liste di tag sul wiki[1]).
>



si, ma taginfo non dà significato o definizioni chiare, come il sistema di
cui tu scrivi. Taginfo è un tool per navigare la giungla.

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

Re: [Talk-br] Como mapear Polícia Rodoviária?

[Fidelis Assis]

Fazendo um resumo, interpreto como:

1- Usar "operator" para caracterizar polícia rodoviária pelo nome do
operador não teve objeções. Até ensejou generalizações que podem ser úteis
para outros tipos de extração de dados, como sugeriu santamariense;

2- Colocar um nome genérico como "Polícia Rodoviária
Federal|Estadual|Municipal", etc na tag "name" não é uma boa prática;

Se for isso mesmo, seria aceitável alterar todas as tags "name" onde hoje
estão nomes genéricos para a tag "operator"?

Abraços,
-- Fidelis
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-es] Complemento de JOSM para visualizar conjuntos de cambios

[dcapillae]

Hola,

Rub21 acaba de publicar un artículo [1] en su diario personal de OSM con una
reseña del complemento «changeset-viewer» para JOSM [2]. El complemento
permite visualizar uno o varios conjuntos de cambios directamente en JOSM.
Aún no lo he probado, pero parece que puede ser de gran ayuda en tareas de
control de calidad [3].

[1] https://www.openstreetmap.org/user/Rub21/diary/43285
[2] https://github.com/JOSM/changeset-viewer
[3] https://wiki.openstreetmap.org/wiki/ES:Control_de_calidad



-
Daniel Capilla
OSM user: dcapillae 
--
Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html

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

Re: [Talk-it] problemi del motore di ricerca con i tag, addr:place

[Martin Koppenhoefer]

appena trovato, forse qualcuno ci aiuta in questo GSoC:
https://wiki.openstreetmap.org/wiki/Google_Summer_of_Code/2018/Project_Ideas#Nominatim

;-)

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

Re: [Talk-it] problemi del motore di ricerca con i tag, addr:place

[Martin Koppenhoefer]

2018-02-09 8:31 GMT+01:00 marco.baietto :

>
>
> Certo, ce ne sono molti, per esempio i comuni di Caprile o Portula (BI)
> hanno la toponomastica basata quasi completamente su Frazioni. Ti metto un
> paio di esempi:
> - se cerchi "63 Castagnea Portula" ti trova solo la località generica, non
> il civico:https://www.openstreetmap.org/search?query=63%20Castagnea%
> 20Portula#map=14/45.6788/8.1638
> se ti sbagli e scrivi "63 Frazione Castagnea Portula" non trova nulla
>
> - stessa cosa se cerchi "33 Uccelli Caprile":
> https://www.openstreetmap.org/search?query=33%20Uccelli%
> 20Caprile#map=14/45.6962/8.2179
>
> L'unico modo che ho trovato per farlo funzionare è che il nodo
> "place:hamlet" abbia il tag name identico al tag addr:place (esempio,
> addr:place=Frazione Uccelli e name=Frazione Uccelli; non come adesso dove
> nel nodo place:hamlet c'è name=Uccelli), ma non è corretto (name=* tag is
> supposed to contain solely name
> , not to
> describe the type or location of the object or one of its other properties
> (such as height, elevation, operator, access restrictions,
> classification/certification/quality labels...)).
>



si, questo penso sia un requisito: il tag addr:place deve contenere lo
stesso identico nome di un place=* di qui fa parte.
Sembra un problema del tagging negli esimpi sopra.

Guarda per esempio questo oggetto:

https://www.openstreetmap.org/node/5107139653
in addr:place c'è "Frazione Uccelli" mentre in place=hamlet name="Uccelli".

Al mio modesto parere _dovrebbe_ comunque funzionare la ricerca anche così
com'è ora (perché non serve il place object per trovare un indirizzo il
quale è inserito completamente).

Non so se esiste già un ticket per questo problema, casomai ne potresti
inserire uno qui (facendo riferimento ad un oggetto inserito correttamente
ma non trovato):
https://github.com/openstreetmap/Nominatim/issues

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

Re: [Talk-it] [Talk-it-cai] Proposta utilizzo scala CAI

[matteocalosi]

Per dare la mia prospettiva su alcuni tag che sono stati definiti poco utili:
per me sac_scale e trail_visibility sono, insieme alla corretta relazione
escursionistica, i tag cruciali da aggiungere su ogni tratto di sentiero se
noti e le tre cose principali che un escursionista che consulti la mappa
deve avere a disposizione. Per qualche motivo c'è un problema annoso a
includerli nei rendering da browser (ma c'è almeno 4umaps che lo fa) ma ogni
app mobile che si possa definire come utile per l'escursionismo li
visualizzerà. Poi nessuno viene a sgridare se non si fa ma non vedo come si
possa definire una perdita di tempo.


cai_scale è sicuramente un dato utile e lo aggiungo alle relazioni quando
ufficialmente esiste ma, come è stato già fatto notare, dovrebbe essere
evidente da una qualsiasi mappa escursionistica cartacea che ad interessare
il lettore è soprattutto la scala di difficoltà per singoli tratti di
percorso, non per l'intero sentiero (quando presente quest'ultima è
solitamente elencata in un riquadro apposito di elenco sentieri, non sulla
mappa). E questa difficoltà è comunemente rilevata non seguendo una
difficoltà "ufficiale" ma percorrendo i sentieri sul campo e dando una
valutazione soggettiva, proprio come fatto per le tag OSM, anche se magari
con una maggiore competenza media nel dare tali valutazioni.


Poi è ovvio che sac_scale manchi di verificabilità (ha pure la sua sezione
nell'articolo https://wiki.openstreetmap.org/wiki/Verifiability) ma la cosa
mi sembra inevitabile nel concetto stesso di difficoltà escursionistica. 


L'eccessivo spezzettamento della difficoltà taggando le singole way è
effettivamente a volte un problema. Io personalmente la taggo "da bivio a
bivio" usando il grado di difficoltà massimo presente fra due possibili
punti di fuga ma è una preferenza personale, non esistono linee guida al
riguardo.



--
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] [Talk-it-cai] Proposta utilizzo scala CAI

[angelo mornata]

 Secondo me le 2 cose dovrebbero convivere, perché è insindacabile la necessità 
di sapere sin dall'inizio qual' è  il grado di difficoltà maggiore, è questo lo 
assolve egregiamente la relazione con le scale CAI, altrettanto importante è 
sapere dove esattamente è il punto più difficile è che tipo di difficoltà si 
tratta...passaggio di primo o di quinto grado, tratto di catena, di quanti 
metri... in base alle mie forze in quel momento potrei decidere di abbandonare 
l' ascensione, qui Sac scale serve egregiamente a definirlo.
Ciao
Angelo



Inviato da smartphone Samsung Galaxy.

 Messaggio originale 
Da: danbag 
Data: 09/02/18 10:05 (GMT+01:00)
A: openstreetmap list - italiano 
Oggetto: Re: [Talk-it] [Talk-it-cai] Proposta utilizzo scala CAI

Ringrazio dei chiarimenti che altro non fanno che confermare la mia idea di non 
perder tempo a inserire dati "inutili.
Mi permetto a proposito della scala CAI e  Sac di aggiungere una cosa la scala 
CAI fa come dici tu però quella Sac è attribuibile alla singola way. Alcuni qui 
volevano convincermi ad inserire il dato Sac nella singola way.
Ciao

 Messaggio originale 
Da: Cascafico Giovanni 
Data: 09/02/18 09:45 (GMT+01:00)
A: openstreetmap list - italiano 
Oggetto: Re: [Talk-it] [Talk-it-cai] Proposta utilizzo scala CAI

Il giorno 9 febbraio 2018 08:50, Dino Michelini 
> ha scritto:
Ciao  questo argomento se ne parlò anche tempo fa. Nel tuo ragionamento 
richiami molti problemi di cui ad es. 24 associazioni nazionali alpine 
discutono da tempo: classificazione difficoltà, segnavia, rendering su mappa, 
ecc.
Classificazione difficioltà. La scala escursionistica CAI parte da un 
presupposto diverso dal tuo: infatti, non indica la difficolta per ogni singolo 
tratto (way) di un itinerario ma il grado di difficoltà più alto che si 
incontrerà seguendo il percorso. [...]
Secondo me se non si conosce con certezza il grado di difficolta del tratto X 
ma si opera una valutazione personale è meglio non metter nulla piuttosto che 
qualcosa di sbagliato.

+1 su tutto: questo dovrebbe essere chiaro a chiunque mappi in OSM qualsiasi 
elemento, non solo un sentiero. Ma se qualcuno vuole basarsi su OSM per fare la 
sua mappa col suo rendering sfruttando la classificazione CAI, credo abbia il 
diritto di uscire e mappare la scala che ha rilevato.
Se il CAI considera un tale approccio sbagliato, può chiedere di eliminare la 
proposta di etichettatura o limitarne l'uso alla sola relazione.

Rendering. Che motivi esistono per visualizzare ad es. con colore/tratto 
diverso ogni singolo tratto di way dove sac_scale/cai_scale cambino? In Italia, 
dal punto di vista escursionistico nessuno mentre dal punto di vista grafico 
otterresti un rendering di difficile lettura, pensa ad es. alla mappa 
visualizzata ad es. su uno schermo GPS. Anche il sito del catasto dei sentieri 
della Valle d'Aosta (http://geonavsct.partout.it/pub/geosentieri/) la 
visualizzazione dei sentieri classificati EE e EEA non riporta il dettaglio del 
singolo tratto ma visualizza l'intera relazione/itinerario. Ad es. nei GPS 
Garmin le relazioni che sono ben visualizzate in WMT sono assenti per problemi 
dei Garmin, ciò nonostante ancora non mi sono perso. :)

Una casa editrice di Udine, molto popolare tra gli escursionisti, usa da sempre 
un rendering che differenzia in tre livelli di difficoltà. Qui [1] puoi vedere 
la resa del tratto continuo, tratteggiato, puntinato. La lettura non mi pare 
difficile (risoluzione jpg a parte).
In una mappa digitale zoommabile, la resa sarebbe ancora più chiara; il 
problema semmai è di chi progetta mappe per schermi da 3", che talvolta ha la 
pretesa di vendere realtà virtaule, molto sexy ma poco utilizzabile.

[1] http://digilander.libero.it/sergiocecchi/2001-32.jpg

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

Re: [Talk-it] [Talk-it-cai] Proposta utilizzo scala CAI

[Marcello]

Un po' in ritardo... dico il mio pensiero, almeno per come interpreto io
lo spirito di OpenStreetMap.

Il tuo ragionamento lo accetto se per il tuo uso avessi bisogno delle
tue 50 relazioni e basta, ma se ne utilizzi anche altre potrebbero
essere il frutto di ore "perse" da qualcun altro per inserirle, che
forse non aveva nessun interesse diretto a quelle relazioni.
Non so se c'è qualcuno, per quanto con migliaia di edit alle spalle, che
possa dire di aver contribuito alla mappa (anzi, al database) più di
quanto ne trae di utile, se ognuno mettesse solo ciò che è utile per sé
sicuramente avremmo un database molto più povero.

Ciao
Marcello

Il 09/02/2018 07:56, dan...@libero.it ha scritto:
> Un pò in ritardo...chiarisco.
>
> Io uso OSM e Waymarked Trails (WMT) come uno scrittore di libri.
> Un libro viene scritto per essere letto, l'autore non si preoccupa della 
> tipografia e dei problemi del tipografo, io inserisco percorsi che vengono 
> utilizzati dagli escursionisti e non mi interesso ai problemi di OSM ed al 
> suo database. Ho inserito una cinquantina di relazioni in OSM e sono 
> ottimamente visualizzate e fruite per mezzo di WMT ed in un vicino futuro 
> verrano riprese in INFOMONT del CAI.
>
> Qualche numero:
> 50 relazioni, facciamo 5 way a relazione, facciamo 5 tag "inutili" a way, 60 
> secondi per tag (ma sono pochi):
> 50 x 5 x 5 x 60 / 3600 = 21 ore "perse" secondo la mia ottica, non sono 
> nenche tante, ma preferisco impiegarle per rilevare sul campo qualche nuovo 
> percorso e inserirlo come relazione.
>
> Ciao a tutti
>
>
>


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

Re: [Talk-it] [Talk-it-cai] Proposta utilizzo scala CAI

[danbag]

Ringrazio dei chiarimenti che altro non fanno che confermare la mia idea di non 
perder tempo a inserire dati "inutili.Mi permetto a proposito della scala CAI e 
 Sac di aggiungere una cosa la scala CAI fa come dici tu però quella Sac è 
attribuibile alla singola way. Alcuni qui volevano convincermi ad inserire il 
dato Sac nella singola way.Ciao 
 Messaggio originale Da: Cascafico Giovanni 
 Data: 09/02/18  09:45  (GMT+01:00) A: openstreetmap list 
- italiano  Oggetto: Re: [Talk-it] [Talk-it-cai] 
Proposta utilizzo scala CAI 
Il giorno 9 febbraio 2018 08:50, Dino Michelini  ha 
scritto:


Ciao  questo argomento se ne parlò anche tempo fa. Nel tuo ragionamento 
richiami molti problemi di cui ad es. 24 associazioni nazionali alpine 
discutono da tempo: classificazione difficoltà, segnavia, rendering su mappa, 
ecc. 
Classificazione difficioltà. La scala escursionistica CAI parte da un 
presupposto diverso dal tuo: infatti, non indica la difficolta per ogni singolo 
tratto (way) di un itinerario ma il grado di difficoltà più alto che si 
incontrerà seguendo il percorso. [...] 
 Secondo me se non si conosce con certezza il grado di difficolta del tratto X 
ma si opera una valutazione personale è meglio non metter nulla piuttosto che 
qualcosa di sbagliato.

+1 su tutto: questo dovrebbe essere chiaro a chiunque mappi in OSM qualsiasi 
elemento, non solo un sentiero. Ma se qualcuno vuole basarsi su OSM per fare la 
sua mappa col suo rendering sfruttando la classificazione CAI, credo abbia il 
diritto di uscire e mappare la scala che ha rilevato. 
Se il CAI considera un tale approccio sbagliato, può chiedere di eliminare la 
proposta di etichettatura o limitarne l'uso alla sola relazione.

Rendering. Che motivi esistono per visualizzare ad es. con colore/tratto 
diverso ogni singolo tratto di way dove sac_scale/cai_scale cambino? In Italia, 
dal punto di vista escursionistico nessuno mentre dal punto di vista grafico 
otterresti un rendering di difficile lettura, pensa ad es. alla mappa 
visualizzata ad es. su uno schermo GPS. Anche il sito del catasto dei sentieri 
della Valle d'Aosta (http://geonavsct.partout.it/pub/geosentieri/) la 
visualizzazione dei sentieri classificati EE e EEA non riporta il dettaglio del 
singolo tratto ma visualizza l'intera relazione/itinerario. Ad es. nei GPS 
Garmin le relazioni che sono ben visualizzate in WMT sono assenti per problemi 
dei Garmin, ciò nonostante ancora non mi sono perso. :)


Una casa editrice di Udine, molto popolare tra gli escursionisti, usa da sempre 
un rendering che differenzia in tre livelli di difficoltà. Qui [1] puoi vedere 
la resa del tratto continuo, tratteggiato, puntinato. La lettura non mi pare 
difficile (risoluzione jpg a parte).
In una mappa digitale zoommabile, la resa sarebbe ancora più chiara; il 
problema semmai è di chi progetta mappe per schermi da 3", che talvolta ha la 
pretesa di vendere realtà virtaule, molto sexy ma poco utilizzabile.

[1] http://digilander.libero.it/sergiocecchi/2001-32.jpg


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

Re: [Talk-it] [Talk-it-cai] Proposta utilizzo scala CAI

[danbag]

Non voglio assolutamente far prevalere le mie idee ma solo spiegare a chi 
voleva convincermi  delle sue. Ed ho spiegato perché non lo faccio. Tutto qui. 
Perché boria ecc.Ciao
 Messaggio originale Da: Francesco Pelullo 
 Data: 09/02/18  09:15  (GMT+01:00) A: dan...@libero.it, 
openstreetmap list - italiano  Oggetto: Re: 
[Talk-it] [Talk-it-cai] Proposta utilizzo scala CAI 
Ciao
Ti quoto interamente perché vorrei che rileggessi quello che scrivi.
In tanti anni di mailing lista, non avevo mai letto un messaggio scritto con 
tanta boria e tanta pienezza di sé.
Sono tre o quattro volte che citi queste famose CINQUANTA relazioni manco 
fossero 50 sfumature di qualcosa.
Prendi atto che le persone verso cui tenti di far prevalere le tue idee sono in 
questa lista da anni, e magari creano 100 relazioni alla settimana o mantengono 
in funzione servizi di cui tu ignori persino l'esistenza.
OSM è un database condiviso, se ti va di contribuire con "quacchecosa" fai 
pure, sei il benvenuto, ma non spammare la lista tentando di convincermi che 
sarebbe meglio impegnarsi in questo o in quello. Impegnati, e basta.
Se non ti sta bene, vai per la tua strada. Nessuno ti costringe. Ma non 
insistere a tentare di prevalere. Mi urta.
Ciao lista e scusate la botta di sangue alla testa.
/niubii/


Il 09 feb 2018 07:56,   ha scritto:
Un pò in ritardo...chiarisco.



Io uso OSM e Waymarked Trails (WMT) come uno scrittore di libri.

Un libro viene scritto per essere letto, l'autore non si preoccupa della 
tipografia e dei problemi del tipografo, io inserisco percorsi che vengono 
utilizzati dagli escursionisti e non mi interesso ai problemi di OSM ed al suo 
database. Ho inserito una cinquantina di relazioni in OSM e sono ottimamente 
visualizzate e fruite per mezzo di WMT ed in un vicino futuro verrano riprese 
in INFOMONT del CAI.



Qualche numero:

50 relazioni, facciamo 5 way a relazione, facciamo 5 tag "inutili" a way, 60 
secondi per tag (ma sono pochi):

50 x 5 x 5 x 60 / 3600 = 21 ore "perse" secondo la mia ottica, non sono nenche 
tante, ma preferisco impiegarle per rilevare sul campo qualche nuovo percorso e 
inserirlo come relazione.



Ciao a tutti





> Il 7 febbraio 2018 alle 12.15 Luca Delucchi  ha scritto:

>

>

> 2018-02-07 9:42 GMT+01:00 danbag :

> > ...dimenticavo..

> > I tag che si potrebbero aggiungere ad una way oltre alla scala sac nella

> > descrizione di un sentiero sono anche tipo di fondo, tipo di vegetazione,

> > stato di percorribilita, ecc tutte utilissime...ma inutili come già spiegato

> > se perdo tempo a inserirle e non sono fruibili

>

> ma per te non sono fruibili ma un altro le puoi fruire visto che i

> dati sono disponibile se invece non le carichi non sono fruibili per

> nessuno. Quando potranno essere fruibili anche a te dovrai fare un

> lavoro molto più lungo che inserirle ora. Comunque ti ripeto non

> voglio convicerti...

>

> > Arriciao

> >

>

> --

> ciao

> Luca

>

> www.lucadelu.org



___

Talk-it mailing list

Talk-it@openstreetmap.org

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



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

Re: [Talk-it] [Talk-it-cai] Proposta utilizzo scala CAI

[Cascafico Giovanni]

Il giorno 9 febbraio 2018 08:50, Dino Michelini  ha
scritto:

> Ciao  questo argomento se ne parlò anche tempo fa. Nel tuo ragionamento
> richiami molti problemi di cui ad es. 24 associazioni nazionali alpine
> discutono da tempo: classificazione difficoltà, segnavia, rendering su
> mappa, ecc.
> *Classificazione difficioltà*. La scala escursionistica CAI parte da un
> presupposto diverso dal tuo: infatti, non indica la difficolta per ogni
> singolo tratto (way) di un itinerario ma il grado di difficoltà più alto
> che si incontrerà seguendo il percorso. [...]
>
Secondo me se non si conosce con certezza il grado di difficolta del tratto
> X ma si opera una valutazione personale è meglio non metter nulla piuttosto
> che qualcosa di sbagliato.
>

+1 su tutto: questo dovrebbe essere chiaro a chiunque mappi in OSM
qualsiasi elemento, non solo un sentiero. Ma se qualcuno vuole basarsi su
OSM per fare la sua mappa col suo rendering sfruttando la classificazione
CAI, credo abbia il diritto di uscire e mappare la scala che ha rilevato.
Se il CAI considera un tale approccio sbagliato, può chiedere di eliminare
la proposta di etichettatura o limitarne l'uso alla sola relazione.

*Rendering*. Che motivi esistono per visualizzare ad es. con colore/tratto
> diverso ogni singolo tratto di way dove sac_scale/cai_scale cambino? In
> Italia, dal punto di vista escursionistico nessuno mentre dal punto di
> vista grafico otterresti un rendering di difficile lettura, pensa ad es.
> alla mappa visualizzata ad es. su uno schermo GPS. Anche il sito del
> catasto dei sentieri della Valle d'Aosta (http://geonavsct.partout.it/
> pub/geosentieri/) la visualizzazione dei sentieri classificati EE e EEA
> non riporta il dettaglio del singolo tratto ma visualizza l'intera
> relazione/itinerario. Ad es. nei GPS Garmin le relazioni che sono ben
> visualizzate in WMT sono assenti per problemi dei Garmin, ciò nonostante
> ancora non mi sono perso. :)
>

Una casa editrice di Udine, molto popolare tra gli escursionisti, usa da
sempre un rendering che differenzia in tre livelli di difficoltà. Qui [1]
puoi vedere la resa del tratto continuo, tratteggiato, puntinato. La
lettura non mi pare difficile (risoluzione jpg a parte).
In una mappa digitale zoommabile, la resa sarebbe ancora più chiara; il
problema semmai è di chi progetta mappe per schermi da 3", che talvolta ha
la pretesa di vendere realtà virtaule, molto sexy ma poco utilizzabile.

[1] http://digilander.libero.it/sergiocecchi/2001-32.jpg
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] problemi del motore di ricerca con i tag addr:place

[Andreas Lattmann]

>dei VVFF non ha ne le competenze nè le risorse per affrontare il 
>problema in questo modo.

Soprattutto economiche, se no consiglierei di appoggiarsi ai servizi mapbox 
cloudmade ecc. (A pagamento)

Purtroppo, non credo che in OSMF ci siano abbastanza programmatori per migrare 
da nominatim ad x.
Possibile che nel mondo FLOSS non ci siano programmatori ruby che possano 
integrare le altre soluzioni?


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: [Talk-it] [Talk-it-cai] Proposta utilizzo scala CAI

[Francesco Pelullo]

Ciao

Ti quoto interamente perché vorrei che rileggessi quello che scrivi.

In tanti anni di mailing lista, non avevo mai letto un messaggio scritto
con tanta boria e tanta pienezza di sé.

Sono tre o quattro volte che citi queste famose CINQUANTA relazioni manco
fossero 50 sfumature di qualcosa.

Prendi atto che le persone verso cui tenti di far prevalere le tue idee
sono in questa lista da anni, e magari creano 100 relazioni alla settimana
o mantengono in funzione servizi di cui tu ignori persino l'esistenza.

OSM è un database condiviso, se ti va di contribuire con "quacchecosa" fai
pure, sei il benvenuto, ma non spammare la lista tentando di convincermi
che sarebbe meglio impegnarsi in questo o in quello. Impegnati, e basta.

Se non ti sta bene, vai per la tua strada. Nessuno ti costringe. Ma non
insistere a tentare di prevalere. Mi urta.

Ciao lista e scusate la botta di sangue alla testa.

/niubii/



Il 09 feb 2018 07:56,  ha scritto:

Un pò in ritardo...chiarisco.

Io uso OSM e Waymarked Trails (WMT) come uno scrittore di libri.
Un libro viene scritto per essere letto, l'autore non si preoccupa della
tipografia e dei problemi del tipografo, io inserisco percorsi che vengono
utilizzati dagli escursionisti e non mi interesso ai problemi di OSM ed al
suo database. Ho inserito una cinquantina di relazioni in OSM e sono
ottimamente visualizzate e fruite per mezzo di WMT ed in un vicino futuro
verrano riprese in INFOMONT del CAI.

Qualche numero:
50 relazioni, facciamo 5 way a relazione, facciamo 5 tag "inutili" a way,
60 secondi per tag (ma sono pochi):
50 x 5 x 5 x 60 / 3600 = 21 ore "perse" secondo la mia ottica, non sono
nenche tante, ma preferisco impiegarle per rilevare sul campo qualche nuovo
percorso e inserirlo come relazione.

Ciao a tutti


> Il 7 febbraio 2018 alle 12.15 Luca Delucchi  ha
scritto:
>
>
> 2018-02-07 9:42 GMT+01:00 danbag :
> > ...dimenticavo..
> > I tag che si potrebbero aggiungere ad una way oltre alla scala sac nella
> > descrizione di un sentiero sono anche tipo di fondo, tipo di
vegetazione,
> > stato di percorribilita, ecc tutte utilissime...ma inutili come già
spiegato
> > se perdo tempo a inserirle e non sono fruibili
>
> ma per te non sono fruibili ma un altro le puoi fruire visto che i
> dati sono disponibile se invece non le carichi non sono fruibili per
> nessuno. Quando potranno essere fruibili anche a te dovrai fare un
> lavoro molto più lungo che inserirle ora. Comunque ti ripeto non
> voglio convicerti...
>
> > Arriciao
> >
>
> --
> ciao
> Luca
>
> www.lucadelu.org

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