Re: [Talk-us] Labeling forestry service roads/tracks

[Tod Fitch]

Thank you for the clarification.

> On Jul 20, 2020, at 6:08 PM, Clifford Snow  wrote:
> 
> The legend is just for the USFS road layer that is served by Mapbox on JOSM.
> 



signature.asc
Description: Message signed with OpenPGP
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-GB] POI files of Pub/Restaurant chain

[Kai Michael Poppe - OSM]

Hi Rob,

thanks for the nudge, they have a nice amount of brands, it would be great to 
be able to use their data freely :)

@all,

where would I document the request (and the eventual permission) in the Wiki?
It seems that under https://wiki.openstreetmap.org/wiki/Permissions#Europe 
there's no entry for the UK... Or should they go to 
https://wiki.openstreetmap.org/wiki/Contributors#United_Kingdom?

Kai

On 16.07.2020 22:14, Rob Nickerson wrote:
> Harvester is one of many brands owned by M: https://www.mbplc.com/
> 
> Try writing to the parent group as you might get permission for all of their 
> brands.
> 
> Best regards
> Rob
> 
> P.s. sorry for lack of threaded email. I'm still struggling with nabble.
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
> 

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

Re: [talk-au] Working with local government

[Andrew Harvey]

That's exactly how I see it working too. Eventually we could probably put
together a document of best practice, suggestions for the workflow as a
guide for anyone else looking to set this up.

On Tue, 21 Jul 2020 at 14:04, Andrew Hughes  wrote:

> Hi All,
>
> We expect to encounter the same problem at the NHVR if we begin to use OSM.
>
> My (possibly unfounded) initial thoughts are based around linking the OSM
> & Source feature outside OSM in something similar to a "join" table. The
> join might be on attribution (id), geometry or both. Then, you have to
> accept that the link/join will break and a process is needed to detect
> breakages when they happen so they can be repaired (a mix of automated &
> manual).
>
> Someone else might be able to comment on this with more clarity.
>
> The way I see it, you can't stop the breakage. You have to accept it and
> deal with change.
>
> A Hughes
>
>
> On Sat, 18 Jul 2020 at 23:10, Sebastian Spiess  wrote:
>
>> On 9/7/20 7:52 pm, Mateusz Konieczny via Talk-au wrote:
>>
>>
>>
>>
>> Jul 9, 2020, 06:50 by greg.dutkow...@gmail.com:
>>
>> Hi,
>> Bicycle Network Tasmania are trying to improve the quality of cycling
>> infrastructure information in OSM.
>> Much has been done by volunteers in various jurisdictions, and we have
>> done lots locally, but the tagging is quite complex for cycle paths and not
>> always correct.
>> Local councils are responsible for much of the infrastructure, but they
>> usually have little interaction with OSM.
>> It would be most efficient if the councils GIS data worked in tandem with
>> OSM data so that they kept each other up to date, each storing the info
>> that is most useful for them. For instance, for bike parking, there is
>> little utility in OSM storing the asset numbers and other info that the
>> councils use to maintain their assets (although the ref tag could be used
>> as a foreign key to help keep the two in sych).
>> The Hobart councils we work with are concerned with the quality of the
>> data in OSM and the ability of anyone to change it.
>> Does anyone know of any examples we could learn from of local government
>> itself working to keep OSM data up to date?
>> Thanks.
>>
>> One of the easiest things that local government may do is to
>>
>> 1) publish their datasets on an open license allowing to use it by mappers
>> 2) react to reports of mistakes in their data
>>
>> Both work relatively well in Poland for address data - with publishing
>> required by
>> national law (though still ignored be many local governments)
>>
>> Note that (1) is useful for mappers even if data quality is unsufficient
>> to import it
>> into OSM. I am using a bit noisy bicycle parking in locating unmapped ones
>> (often location, description and real location mismatches significantly,
>> but
>> almost always it allows me to find something that was missing in OSM)
>>
>> ___
>> Talk-au mailing 
>> listTalk-au@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-au
>>
>> Hi, indeed great to see you reach out.
>>
>> Yes I agree that a good approach is to make the data open. However, I
>> understand Greg is asking if there are working concepts on how to maintain
>> a link between local government GIS (which might have additional
>> information) and OSM data.
>>
>> Once the relevant information has been entered into OSM, how is the
>> council to track the data? e.g. to see if tags get modified, nodes moved,
>> added.
>>
>> e.g. worst case is that a nicely mapped and tagged area gets re-done by
>> someone. This results in new node and way numbers.
>>
>> A good example would be a single node gets expanded by OSM users.
>>
>> In both cases the data is diverging from another. How to keep track? Are
>> there concepts/solutions?
>>
>> Yes
>> ___
>> 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-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Working with local government

[Andrew Hughes]

Hi All,

We expect to encounter the same problem at the NHVR if we begin to use OSM.

My (possibly unfounded) initial thoughts are based around linking the OSM &
Source feature outside OSM in something similar to a "join" table. The join
might be on attribution (id), geometry or both. Then, you have to accept
that the link/join will break and a process is needed to detect breakages
when they happen so they can be repaired (a mix of automated & manual).

Someone else might be able to comment on this with more clarity.

The way I see it, you can't stop the breakage. You have to accept it and
deal with change.

A Hughes


On Sat, 18 Jul 2020 at 23:10, Sebastian Spiess  wrote:

> On 9/7/20 7:52 pm, Mateusz Konieczny via Talk-au wrote:
>
>
>
>
> Jul 9, 2020, 06:50 by greg.dutkow...@gmail.com:
>
> Hi,
> Bicycle Network Tasmania are trying to improve the quality of cycling
> infrastructure information in OSM.
> Much has been done by volunteers in various jurisdictions, and we have
> done lots locally, but the tagging is quite complex for cycle paths and not
> always correct.
> Local councils are responsible for much of the infrastructure, but they
> usually have little interaction with OSM.
> It would be most efficient if the councils GIS data worked in tandem with
> OSM data so that they kept each other up to date, each storing the info
> that is most useful for them. For instance, for bike parking, there is
> little utility in OSM storing the asset numbers and other info that the
> councils use to maintain their assets (although the ref tag could be used
> as a foreign key to help keep the two in sych).
> The Hobart councils we work with are concerned with the quality of the
> data in OSM and the ability of anyone to change it.
> Does anyone know of any examples we could learn from of local government
> itself working to keep OSM data up to date?
> Thanks.
>
> One of the easiest things that local government may do is to
>
> 1) publish their datasets on an open license allowing to use it by mappers
> 2) react to reports of mistakes in their data
>
> Both work relatively well in Poland for address data - with publishing
> required by
> national law (though still ignored be many local governments)
>
> Note that (1) is useful for mappers even if data quality is unsufficient
> to import it
> into OSM. I am using a bit noisy bicycle parking in locating unmapped ones
> (often location, description and real location mismatches significantly,
> but
> almost always it allows me to find something that was missing in OSM)
>
> ___
> Talk-au mailing 
> listTalk-au@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-au
>
> Hi, indeed great to see you reach out.
>
> Yes I agree that a good approach is to make the data open. However, I
> understand Greg is asking if there are working concepts on how to maintain
> a link between local government GIS (which might have additional
> information) and OSM data.
>
> Once the relevant information has been entered into OSM, how is the
> council to track the data? e.g. to see if tags get modified, nodes moved,
> added.
>
> e.g. worst case is that a nicely mapped and tagged area gets re-done by
> someone. This results in new node and way numbers.
>
> A good example would be a single node gets expanded by OSM users.
>
> In both cases the data is diverging from another. How to keep track? Are
> there concepts/solutions?
>
> Yes
> ___
> 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-us] Labeling forestry service roads/tracks

[Tod Fitch]

> On Jul 20, 2020, at 4:48 PM, Tod Fitch  wrote:
> 
> 
>> On Jul 20, 2020, at 4:35 PM, Clifford Snow > > wrote:
>> 
>> On Mon, Jul 20, 2020 at 3:46 AM > > wrote:
>> Clifford,
>> 
>> Could you repost the legend? It's hard/impossible to make out the
>> surface reliably from aerial photos.
>> 
>> Sure - here is a link 
>> https://mycloud.snowandsnow.us/index.php/s/7zQNGbyNQqBMj2S 
>> 
> 
> Looks a bit different than the legend on my April 2020, Coconino National 
> Forest Travel Map:
> 
> https://cloud.fitchfamily.org/index.php/s/eKCYzc4TfjMMfdN 
> 
> 
> —Tod

Oops. Deleted it off my cloud after sending email. Here is it again: 
https://cloud.fitchfamily.org/index.php/s/9nrCyifxX2swSH8

Just looked at a map for the Los Padres and for the Sabino Canyon Recreational 
area in the Santa Catalina Mountains of the Coronado NF. Those legends are 
different yet.

Is there a national standard that these forests are ignoring?
Is it on a FS region basis?
Is it on a forest basis?
Does it vary based on when a map was published?
I don’t see a consistent pattern with the FS maps I have at hand.

—Tod



signature.asc
Description: Message signed with OpenPGP
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Labeling forestry service roads/tracks

[Tod Fitch]

> On Jul 20, 2020, at 4:35 PM, Clifford Snow  wrote:
> 
> On Mon, Jul 20, 2020 at 3:46 AM  > wrote:
> Clifford,
> 
> Could you repost the legend? It's hard/impossible to make out the
> surface reliably from aerial photos.
> 
> Sure - here is a link 
> https://mycloud.snowandsnow.us/index.php/s/7zQNGbyNQqBMj2S 
> 

Looks a bit different than the legend on my April 2020, Coconino National 
Forest Travel Map:

https://cloud.fitchfamily.org/index.php/s/eKCYzc4TfjMMfdN

—Tod





signature.asc
Description: Message signed with OpenPGP
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Labeling forestry service roads/tracks

[Clifford Snow]

The legend is just for the USFS road layer that is served by Mapbox on JOSM.


Sent from my Android phone.

On Mon, Jul 20, 2020, 4:48 PM Tod Fitch  wrote:

>
> On Jul 20, 2020, at 4:35 PM, Clifford Snow 
> wrote:
>
> On Mon, Jul 20, 2020 at 3:46 AM  wrote:
>
>> Clifford,
>>
>> Could you repost the legend? It's hard/impossible to make out the
>> surface reliably from aerial photos.
>>
>
> Sure - here is a link
> https://mycloud.snowandsnow.us/index.php/s/7zQNGbyNQqBMj2S
>
>
> Looks a bit different than the legend on my April 2020, Coconino National
> Forest Travel Map:
>
> https://cloud.fitchfamily.org/index.php/s/eKCYzc4TfjMMfdN
>
> —Tod
>
>
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Labeling forestry service roads/tracks

[Clifford Snow]

On Mon, Jul 20, 2020 at 3:46 AM  wrote:

> Clifford,
>
> Could you repost the legend? It's hard/impossible to make out the
> surface reliably from aerial photos.
>

Sure - here is a link
https://mycloud.snowandsnow.us/index.php/s/7zQNGbyNQqBMj2S
-- 
@osm_washington
www.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Labeling forestry service roads/tracks

[Kerry Irons]

They apply calcium chloride solution as a dust control agent.  CaCl2, AKA 
“cackle 2”

 

 

From: Mike Thompson  
Sent: Monday, July 20, 2020 6:51 PM
To: brad 
Cc: talk-us 
Subject: Re: [Talk-us] Labeling forestry service roads/tracks

 

 

 

On Mon, Jul 20, 2020 at 7:10 AM brad mailto:bradha...@fastmail.com> > wrote:

Hmmm, interesting.   I'm not sure they compact very many roads around 
here (CO).  

I have lived, or spent time in, rural parts of four states (MN, IA, OH and CO) 
and I have never seen an unpaved road compacted.  They get graded once a year 
perhaps to remove the wash boards, and some have a coating of something applied 
to keep the dust down.

 

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

Re: [Talk-us] Labeling forestry service roads/tracks

[Mike Thompson]

On Mon, Jul 20, 2020 at 7:10 AM brad  wrote:

> Hmmm, interesting.   I'm not sure they compact very many roads around
> here (CO).

I have lived, or spent time in, rural parts of four states (MN, IA, OH and
CO) and I have never seen an unpaved road compacted.  They get graded once
a year perhaps to remove the wash boards, and some have a coating of
something applied to keep the dust down.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Labeling forestry service roads/tracks

[Mike Thompson]

On Mon, Jul 20, 2020 at 4:46 AM  wrote:

> Mike,
>
> Good idea on the route references. What should the network be set to?
>
> Others on this list are better able to answer that question, but my
opinion is network=US:FS:
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Labeling forestry service roads/tracks

[Dave Swarthout]

Brad, using Alaska as an example, these roads are in fact, compacted by
vehicles driving on them. I have occasionally seen a power-roller or
sheepsfoot roller used to compact rural roads but such specialized gear is
mostly used during the building of larger highways. Typically a road is
built up with different sized gravels on top of a geotextile base. The
last, top-most layer is a mixture of fine-grained gravel, clay and normal
soil which is bladed smooth by a power grader. If the top-layer is
correctly composed, which depends somewhat on its proximity to a supply of
the proper materials, such a road can be quite nice to drive on. However,
rain will degrade that surface eventually and it will need to be
resurfaced. This is done on a fairly regular basis, but not IMO often
enough. And of course, they are dusty in dry weather and messy in wet
weather. The best time by far for driving on them is in winter.

I have never seen any such road compacted with equipment after the first
construction. The geotextile layer is critical to prevent heavy damage from
frost heave. All unpaved roads are built with geotextile, even driveways,
because otherwise they would simply sink out of sight in the spring thaws.
I live in Thailand half the year and always think to myself how easy it is
here to create a road. Simply scrape the area free of vegetation and large
rocks, build a form, dump some concrete over wire mesh inside the form,
smooth it a bit and you're done. Later on, do you need water for a home
across the street? Just lay the pipe atop the concrete, put a ridge of
asphalt or cement to hold it in place and you're all set. Water pipes in
Alaska must be a minimum of 4-feet below grade.

Hope this helps.

On Mon, Jul 20, 2020 at 8:09 PM brad  wrote:

> Hmmm, interesting.   I'm not sure they compact very many roads around
> here (CO).  Maybe a regional difference.  It seems like they put a thick
> layer of gravel on and let the traffic compact it.   Not fun to ride on
> with a bike, or a motorcycle.
> Do rocks tend to come to the surface of a compacted road and create a
> ball bearing interface?   If they grade it after initial construction,
> do they subsequently compact it again too?
>
> On 7/19/20 9:27 PM, Kevin Kenny wrote:
> >
> > On Sun, Jul 19, 2020 at 9:29 PM brad  > > wrote:
> >
> > Thanks for diving in.   If it's a very minor unimproved road and
> > not clearly service, I usually tag it track.   I would suggest
> > adding some indication of road quality.   If it's an improved
> > gravel road, I consider surface=gravel sufficient.   If it's
> > rougher than an improved gravel road, surface=unpaved (in my area
> > the surface is usually a mix of dirt, rocks, gravel, so unpaved
> > seems best),   and smoothness=very_bad (high clearance), or
> > horrible (4wd)
> > [https://wiki.openstreetmap.org/wiki/Key:smoothness], or
> > 4wd_only=yes .
> >
> >
> > A nit: most 'improved' gravel roads are surface=compacted.  'gravel'
> > is like rail ballast; a compacted surface ordinarily has a mix of fine
> > gravel and even finer material such as sand, and is rolled. Americans
> > will often refer to a compacted road as a 'dirt' or 'gravel' road but
> > the difference is like night and day when you're driving on one!
> >
> > For the rougher stuff, 'smoothness' is essential. Consider also
> > 'tracktype', which addresses more the firmness of the surface rather
> > than its smoothness. A clay surface may be lovely in a dry season and
> > impassable in a wet one, despite having a fast enough slump that the
> > surface is deceptively smooth.
> >
> > Some National Forests separate Forest Highway (a regular access road)
> > and Forest Road (usually a logging track, might be inaccessible in any
> > given season, and often passable only to logging trucks and similar
> > high-clearance off-road vehicles). I don't know if any of them overlay
> > the numbering of the two systems.
> >
> > _Please_ create route relations!
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-it] Riprendo vecchia discussione, spiazzo deposito tronchi.

[Martin Koppenhoefer]

sent from a phone

> On 20. Jul 2020, at 22:38, liste DOT girarsi AT posteo DOT eu 
>  wrote:
> 
> storage=pile_log


log_pile

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

Re: [Talk-it] Denominazione di strade interne

[Martin Koppenhoefer]

sent from a phone

> On 20. Jul 2020, at 23:04, Vittorio Bertola  wrote:
> 
> Quindi direi proprio che un nome esiste ed è pure ufficiale, sia su carta che 
> sul posto. E poi, capisci che se l'unica indicazione che sappiamo dare per 
> arrivare in via Sansovino 243 interno 55 interno L è prendere via Sansovino, 
> girare a destra in via Sansovino, superare le prime due traverse sulla 
> sinistra (via Sansovino e via Sansovino) per girare poi nella terza ossia in 
> via Sansovino, la navigazione può non essere chiarissima :-)


esatto, se c’è un nome, mettilo così come pensi, questo è come funziona :)

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

[Talk-GB] UPRN tag proposal page

[Rob Nickerson]

Hi all,

As discussed at the State of the Map online workshop, I took away an action
to draft a proposal page for ref:GB:uprn. This page is now up online.

https://wiki.openstreetmap.org/wiki/Proposed_features/ref:GB:uprn

This is the first one of these I have done in a long time so hopefully I
got it right.

At this stage, please highlight any "red flags" that would prevent us from
moving to the voting stage. Feel free to also edit the page directly,
however I'm of the view that less is more in this case as it keeps it short
for people to read and also reduces the chance that something is added that
others do not agree with (which would be bad during the voting stage).

If there are no red flags I will move for a vote.

P.S. My thanks to Nick for drafting the initial text.
P.P.S If anyone wants to start a page for USRN, please feel free to,
otherwise I will attempt this later in the week.

Best regards,
*Rob*
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-it] Denominazione di strade interne

[Vittorio Bertola via Talk-it]

Il 2020-07-20 21:38 Martin Koppenhoefer ha scritto:

sent from a phone

On 20. Jul 2020, at 20:31, Vittorio Bertola via Talk-it 
 wrote:


vorrei chiedere se esista una linea guida per il tag name delle strade 
corrispondenti a interni, perché qui non ne ho trovato traccia:


https://wiki.openstreetmap.org/wiki/IT:Editing_Standards_and_Conventions#Nomi_delle_strade



in realtà credo che nella maggior parte dei percorsi “interni” non ci
siano nomi, i nomi si assegnano principalmente a strade pubbliche, per
le vie interne di una proprietà può decidere il proprietario se dare
un nome e se renderlo pubblico.


Non è detto che siano strade private: molti interni sono stati 
comunalizzati negli anni senza dargli un nuovo nome (perché 
costringerebbe a cambiare i documenti di chi ci abita). Per esempio, il 
caso in questione è questo:


https://www.openstreetmap.org/way/783013632

Questo è solo il primo pezzo di "corso Romania interno 501", una strada 
pubblica di circa due chilometri che serve diversi stabilimenti e da 
ora, con una ulteriore ramificazione, tre rotonde e un nuovo ponte, è 
anche il secondo accesso principale a tutta la zona di Torino a nord 
dell'autostrada. Magari tra un po' gli daranno un nome, ma non è detto.


Ma anche quando restano privati, a Torino questi passaggi sono 
generalmente aperti al pubblico (talvolta sono vie di comunicazione tra 
due parti del quartiere) e hanno la loro brava targa toponomastica 
standard, solo che c'è scritto "via XYZ [interno] 123". Se mi passi il 
link all'altra mappa, questo è l'inizio di via Sansovino 243, che è un 
interno di quasi un chilometro con sei sotto-interni come traverse:


https://goo.gl/maps/ASgZ9ETT8LH3tnFCA

E lo stesso nome è riportato sulle mappe catastali:

http://geoportale.comune.torino.it/geodati/pdf/carta_tecnica/1000/BN/cart063_BN.pdf

Quindi direi proprio che un nome esiste ed è pure ufficiale, sia su 
carta che sul posto. E poi, capisci che se l'unica indicazione che 
sappiamo dare per arrivare in via Sansovino 243 interno 55 interno L è 
prendere via Sansovino, girare a destra in via Sansovino, superare le 
prime due traverse sulla sinistra (via Sansovino e via Sansovino) per 
girare poi nella terza ossia in via Sansovino, la navigazione può non 
essere chiarissima :-)


Ciao,
--
vb.   Vittorio Bertola - vb [a] bertola.eu   <
>now blogging & more at http://bertola.eu/   <

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

Re: [Talk-it] Riprendo vecchia discussione, spiazzo deposito tronchi.

[liste DOT girarsi AT posteo DOT eu]

Il 20/07/20 16:18, Lorenzo Mastrogiacomi ha scritto:
> Non mi piace l'uso di amenity=parking perchè in contrasto con il suo
> significato di parcheggio per veicoli. È chiaro che non si può usare
> come parcheggio:
> https://imgur.com/a/7zY9V
> 
> Come tag principale sceglierei un man_made=storage o storage_area o
> storage_qualcosaltro.
> 
> 
> Per indicare il materiale stoccato (wood o timber, non so cosa è meglio
> per il legname grezzo) forse si dovrebbe usare la chiave content=* già
> usata per altri tipo di stoccaggio, lasciando storage=* per specificare
> il tipo/metodo di stoccaggio come suggeriva anche Martin nella vecchia
> discussione.
> 

Facendo ricerca su internet, con solo log, trovo solo capanni per
accatastare legna da ardere, o stock sempre della stessa cosa.

Invece con "pile of log" trovo spesso cataste di tronchi prevalentemente.

Quindi starei sui vostri suggerimenti con:


access=private;forestry

man_made=storage

storage=pile_log

surface=compacted

operator=*


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

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

Re: [Talk-it] Denominazione di strade interne

[Martin Koppenhoefer]

sent from a phone

> On 20. Jul 2020, at 20:31, Vittorio Bertola via Talk-it 
>  wrote:
> 
> vorrei chiedere se esista una linea guida per il tag name delle strade 
> corrispondenti a interni, perché qui non ne ho trovato traccia:
> 
> https://wiki.openstreetmap.org/wiki/IT:Editing_Standards_and_Conventions#Nomi_delle_strade


in realtà credo che nella maggior parte dei percorsi “interni” non ci siano 
nomi, i nomi si assegnano principalmente a strade pubbliche, per le vie interne 
di una proprietà può decidere il proprietario se dare un nome e se renderlo 
pubblico. 

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

Re: [OSM-legal-talk] Disclaimer regarding data in Virginia (US)?

[Mateusz Konieczny via legal-talk]

Jul 20, 2020, 20:35 by mwoehlke.fl...@gmail.com:

> OSM surely incorporates data in Virginia which was not prepared by suitably 
> licensed entities (per 
> https://law.lis.virginia.gov/vacode/title54.1/chapter4/section54.1-402/).
>
> According to Virginia law, OSM must therefore display the following notice:
>
>> Any determination of topography or contours, or any depiction of
>> physical improvements, property lines or boundaries is for general
>> information only and shall not be used for the design, modification,
>> or construction of improvements to real property or for flood plain
>> determination.
>>
> Is this notice already displayed somewhere? If not, where should it be 
> displayed?
>
Not a lawyer, but...

(1) https://law.lis.virginia.gov/vacode/54.1-402/ is a better link

Note 
"preparing documentation pursuant to subsection C of § 54.1-402 
 shall note the following"

So this disclaimer is necessary not for all maps, but only ones used in 
documentation
intended for a specific purposes.

So probably this disclaimer is not necessary on typical OSM based maps.
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

[OSM-legal-talk] Disclaimer regarding data in Virginia (US)?

[Matthew Woehlke]

OSM surely incorporates data in Virginia which was not prepared by 
suitably licensed entities (per 
https://law.lis.virginia.gov/vacode/title54.1/chapter4/section54.1-402/).


According to Virginia law, OSM must therefore display the following notice:


Any determination of topography or contours, or any depiction of
physical improvements, property lines or boundaries is for general
information only and shall not be used for the design, modification,
or construction of improvements to real property or for flood plain
determination.
Is this notice already displayed somewhere? If not, where should it be 
displayed?


(Note: I came across this while considering PWC GIS data for import; 
n.b. 
https://wiki.openstreetmap.org/wiki/Contributors#Prince_William_County.)


--
Matthew

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

[Talk-it] Denominazione di strade interne

[Vittorio Bertola via Talk-it]

Salve a tutti,

vorrei chiedere se esista una linea guida per il tag name delle strade 
corrispondenti a interni, perché qui non ne ho trovato traccia:


https://wiki.openstreetmap.org/wiki/IT:Editing_Standards_and_Conventions#Nomi_delle_strade

Attualmente, almeno a Torino, gli interni sono mappati con lo stesso 
nome della via principale, ossia un tratto di strada denominato "corso 
XYZ interno 123" (su cui affacciano civici "corso XYZ interno 123/1", 
"corso XYZ interno 123/2" e così via) ha name="corso XYZ" esattamente 
come il corso principale. Il problema è che in questo modo, specialmente 
quando ci sono interni lunghi e complessi, diventa difficile distinguere 
a prima vista la strada principale dall'interno, e anche la navigazione 
si trova a dover gestire cose come "prosegui su corso XYZ, poi svolta a 
destra in corso XYZ".


Forse sarebbe meglio che questi tratti di strada avessero name="corso 
XYZ interno 123", come peraltro hanno ad esempio sulle mappe del piano 
regolatore comunale.


Ciao,
--
vb.   Vittorio Bertola - vb [a] bertola.eu   <
>now blogging & more at http://bertola.eu/   <

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

Re: [Talk-us] Interested in importing address points in New York State

[Kevin Kenny]

On Mon, Jul 20, 2020 at 1:27 PM Mateusz Konieczny via Talk-us <
talk-us@openstreetmap.org> wrote:

>
> Jul 20, 2020, 15:32 by o...@dead10ck.com:
>
> I was going to make a subpage of New York with the title of "NYS GIS
> Clearinghouse", and include a link to it in the Potential Data sources
> page. I'm not sure if it's possible to upload and serve arbitrary files in
> the wiki; if so, I was going to upload that raw email file.
>
> Is this email a text-only email? That I would create a page where
> section/text would quote it.
>
> I moved page to
> https://wiki.openstreetmap.org/wiki/New_York/NYS_GIS_Clearinghouse
>
> It is just stub, so feel free to expand it.
>


I don't have time just at the moment for extensive Wiki editing. (Maybe
tonight.)

It's worth noting that the NYSDEC data sets listed under
https://wiki.openstreetmap.org/wiki/Potential_Datasources#Statewide are
also hosted at gis.ny.gov and fall under the same rubric. (The obsolete
metadata are still present, by the way - but it appears that the only part
of the metadata that actually gets updated is the calendar date of the most
recent update.) I'm sure, for instance, that 'Microsoft Windows XP version
5.1 (Build 2600) Service Pack 3', is no longer the native data set
environment!

It might also be worth noting that
https://gis.ny.gov/gisdata/inventories/details.cfm?DSID=430 (New York State
Historic Sites and Park Boundaries) has been used extensively in revising
and correcting state park boundaries, which were also compared with what
mappers had already mapped, with the data from county GIS systems, and with
data from adjoining mapped parcels. For instance, Harriman, Bear Mountain,
and Storm King state parks share boundaries with West Point and with the
NGO-owned-and-operated Black Rock Forest. Hudson Highlands State Park
shares a boundary with Camp Smith. Moreau Lake State park shares a boundary
with a brownfield [a closed state prison] and with a small DEC parcel. John
Brown Farm State Historic Site borders the Lake Placid Olympic ski complex
and the Saranac Lakes Wild Forest. In some cases, _no_extant GIS system had
the correct boundary, and an alignment was created specifically for OSM:
https://www.openstreetmap.org/user/ke9tv/diary/42951 illustrates the
process for one of these. In other cases, more information was needed, so
boundaries were intentionally left  unconflated and their inconsistencies
unresolved - the border between the Allegany Indian reservation and
Allegany State Park is one of these.

Since everything was redrawn when I reworked the NY State Parks, I didn't
call that one an 'import' - it was manual editing with reference to
multiple (OSM and external) data sources.

-- 
73 de ke9tv/2, Kevin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Labeling forestry service roads/tracks

[Matthew Woehlke]

On 19/07/2020 18.47, tj-osmw...@lowsnr.net wrote:

Editing in Boundary County, Idaho in the Panhandle, I've been extending
the forest landuse area around Bonners Ferry and have come across a
difficulty in classifying forest roads.

It seems that many have been automatically imported and have
highway=residential, which is just plain wrong.


FWIW, this seems to be endemic in TIGER data. I often suspect that 
everything that isn't a primary or secondary gets marked "residential".



For roads that appear metalled (paved) and/or access mines, quarries,
communication towers etc. I label highway=service, for roads that are
unpaved or sometimes seem to almost fade out I label highway=track. For
roads that appear to be public access (e.g. to go to a lake) but are
obviously even more minor than tertiary roads I label highway=unclassified.


Sounds about right, at least for the first and last. I'm less certain 
about "highway=track". (Not saying it's *wrong*, just that I don't know, 
vs. the others which sound correct to me.) Well, modulo Mike's comment; 
where I've been using "highway=unclassified" is for things that really 
don't look like service roads (e.g. that connect to other road networks) 
but likewise are clearly not residential. For example, 
https://www.openstreetmap.org/way/20453748.



TIGER seems to be at best very coarse, at worst fictional.


Yup, that is known to be the case. As I understand it, TIGER was created 
mainly for census-taking, and so as long as someone on the ground could 
look at the map and figure out more or less how to get to the houses on 
a particular road, that is "good enough". Positional accuracy in that 
respect isn't nearly as important as *connectivity* accuracy, which 
partly explains the quality, but even connectivity can be dodgy. (As you 
noted, it's not unusual to be missing entire roads, or to have roads 
that don't really exist, and that's *before* we start worrying about 
changes that have happened since.)


--
Matthew

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

Re: [Talk-us] Interested in importing address points in New York State

[Mateusz Konieczny via Talk-us]

Jul 20, 2020, 15:32 by o...@dead10ck.com:

> Thanks Mateusz, I actually tried to make a page, but I am encountering some 
> strange behavior from the wiki. When I try to edit or add a page, a text box 
> appears that says "confirmation code," with no other explanation. I don't get 
> an email with a confirmation code, so I have no idea what it wants.
>
Have you tried disabling adblock or adblock-like protection?

Some sort of CAPTCHa should appear on the screen (probably because it was 
scared by creation
a page with links).


> I was going to make a subpage of New York with the title of "NYS GIS 
> Clearinghouse", and include a link to it in the Potential Data sources page. 
> I'm not sure if it's possible to upload and serve arbitrary files in the 
> wiki; if so, I was going to upload that raw email file.
>
Is this email a text-only email? That I would create a page where section/text 
would quote it.

I moved page to 
https://wiki.openstreetmap.org/wiki/New_York/NYS_GIS_Clearinghouse

It is just stub, so feel free to expand it.

I have not edited Potential Data sources page
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] ref et ref:FR

[leni]

Le 20/07/2020 à 00:39, Yves P. a écrit :

Je propose de supprimer la colonne Tag2Link, ce greffon n'étant plus utilisé.


le greffon n'est plus nécessaire, car il a été intégré dans JOSM 
(https://josm.openstreetmap.de/wiki/Fr%3AHelp/Action/Tag2Link) n'en 
connaissant pas l'utilisation je n'ai pas d'avis, vous me confirmez que 
la colonne n'est plus nécessaire ?


leni




__
Yves



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

Re: [OSM-ja] JOSMの不具合？

[K.Sakanoshita]

坂ノ下です。

不具合報告ありがとうございます。

> ちなみに私はこのようなウェイの共有は割と積極的に分離していってますので、ご理解を。

そうですね。私も海岸線と森林がウェイを共有する必要性は高くないと思います。
※私も巨大マルチポリゴンな森林は少しずつ削って普通の森に変えていたりします。

それでは。


On 2020/07/20 10:05, OKADA Tsuneo wrote:

岡田です。

JOSMで編集していて不都合な状態が発生しましたので、情報共有のために書いておきます。

coastlineとwoodのエリアをそれぞれマルチポリゴンのouter wayとして共有しているような
ウェイ（例：way#131253072）があるのですが、
このwoodエリアのマルチポリゴンのメンバーを更新する（例：innerを追加する）際に
「ツール＞マルチポリゴンの更新」のメニューを選択すると、
ダウンロード済みのデータで共有しているcoastlineのウェイから「natural=coastline」のタグが勝手に消されてしまいます。

例：下図でa,bはポイント、w1、w2、w3はウェイでa,bで接続。
w1・w3がnatural=coastlineでマルチポリゴンとして島を形成し、
w1・w2が別のマルチポリゴンでnatural=woodエリアを形成している時に
w1・w2で囲まれた領域内で別の閉じたウェイw4を作成し、w4とw2のウェイを選択した状態で
   「ツール＞マルチポリゴンの更新」のメニューを選択すると、 w1のウェイの natural=coastline
が消えてしまう、という感じです。
　┌── a───┐
　｜　 ｜　 ｜
　w1　w2　w3
　｜　 ｜　 ｜
　└──b───┘

おそらく、マルチポリゴンのウェイ自身にはnatural=woodのようなタグを記述しない仕様のために
親切心でwayからnaturalなどのタグを消してくれているのかもしれませんが、coastlineはウェイに
タグを書くので、これだと困りますね。

私が編集中のデータでcoastlineのタグが消えたのを気づかずに登録してしまっていたので
危ないところでした。
幸い指摘してくれた人がいたので気づいて修正しましたが。（changeset#88111385）

海岸線と森林エリアでウェイを共有しているところはほとんどはありませんが、
宮城県の牡鹿半島付近のようにたまに共有しているところがありますので、
ご注意下さい。

ちなみに私はこのようなウェイの共有は割と積極的に分離していってますので、ご理解を。


--
岡田常雄(OKADA Tsuneo)
tsuneo.ok...@gmail.com 

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



--
/*
 * K.Sakanoshita (http://www.netfort.gr.jp/~saka/)
 * (Phone) barsa...@gmail.com / (PC) s...@netfort.gr.jp
 */

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

Re: [Talk-GB] Local Wildlife Sites

[Jez Nicholson]

ooo! nice detail.

The 'Local Wildlife Sites' seem to be more wide-ranging than the Wildlife
Trust's own sites, they appear to be 'important' green areas throughout the
area.
https://data.gov.uk/search?q=Local+Wildlife+Sites%5Bpublisher%5D=%5Btopic%5D=%5Bformat%5D==best
lists
a number of areas. They may be a synonym for SINCS
https://en.wikipedia.org/wiki/Site_of_Nature_Conservation_Interest

On Mon, Jul 20, 2020 at 5:03 PM Chris Hill  wrote:

>
> On 20/07/2020 15:52, Jez Nicholson wrote:
> > Does anyone have any experience with
> > https://www.wildlifetrusts.org/local-wildlife-sites ?
> >
> > I've had an inquiry about including Brighton & Hove LWSes on OSM.
> >
> >
> I am a member of Yorkshire Wildlife Trust so I had a conversation with
> them about their reserves a few years ago. They sent me some data. It
> was entirely based on OS data, so I couldn't use any of it in OSM. I
> surveyed North Cave wetlands, a large reserve close to me. You can see
> my efforts here https://www.openstreetmap.org/#map=16/53.7846/-0.6634
> Most of the names are from my own knowledge.
>
> I think each trust is independent, with a loose affiliation to the
> national group.
>
> I've added one or two smaller reserves in outline that I have visites
> with a few lakes and woods as you would expect. It can sometimes be hard
> to know the extent of a reserve just from aerial imagery and surveys can
> be awkward because the sites usually want people to stay on paths to
> avoid wildlife disturbance.
>
> --
> cheers
> Chris Hill (chillly)
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Local Wildlife Sites

[Chris Hill]

On 20/07/2020 15:52, Jez Nicholson wrote:
Does anyone have any experience with 
https://www.wildlifetrusts.org/local-wildlife-sites ?


I've had an inquiry about including Brighton & Hove LWSes on OSM.


I am a member of Yorkshire Wildlife Trust so I had a conversation with 
them about their reserves a few years ago. They sent me some data. It 
was entirely based on OS data, so I couldn't use any of it in OSM. I 
surveyed North Cave wetlands, a large reserve close to me. You can see 
my efforts here https://www.openstreetmap.org/#map=16/53.7846/-0.6634 
Most of the names are from my own knowledge.


I think each trust is independent, with a loose affiliation to the 
national group.


I've added one or two smaller reserves in outline that I have visites 
with a few lakes and woods as you would expect. It can sometimes be hard 
to know the extent of a reserve just from aerial imagery and surveys can 
be awkward because the sites usually want people to stay on paths to 
avoid wildlife disturbance.


--
cheers
Chris Hill (chillly)


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

Re: [Talk-it] Riprendo vecchia discussione, spiazzo deposito tronchi.

[Volker Schmidt]

Penso che il materiale nel deposito dovrebbe essere "log" (tronco)

On Mon, 20 Jul 2020, 16:19 Lorenzo Mastrogiacomi, 
wrote:

> Il giorno dom, 19/07/2020 alle 20.47 +0200, liste DOT girarsi AT posteo
> DOT eu ha scritto:
>
> Riporto in vita una vecchia discussione da me avviata che alla fine non
>
> aveva portato a conclusioni certe [0], escludo a priori spiazzi
>
> utilizzati come slarghi o aree non perfezionate per tale scopo.
>
>
> Riprendo il mio ragionamento fatto ieri, ovvero si identifica un'area
>
> definita con tanto di segnaletica verticale a specificare lo spiazzo per
>
> deposito/carico legname, spiazzo appartenente, in questo caso al Comune,
>
> fatto apposta solo per permettere ciò, metto le due foto per idealizzare
>
> anche se con qualche differenza, quanto messo nella discussione avviata
>
> in precedenza per capire di cosa si sta parlando e per non confondere
>
> con catasta di legname/scarti di una segheria [1] [2].
>
>
> Dunque il mio ragionamento mi porta a pensare questo spiazzo come un
>
> parcheggio apposito, in quanto si tratta di deposito/stoccaggio
>
> temporaneo, ovvero vengono accatastati tronchi da parte di operatori
>
> boschivi,ai fini di permettere il carico a fine di vendita o successivo
>
> spostamento, per esempio.
>
>
> Guardando su taginfo, ravanando un pò coi tag, ho trovato un possibile
>
> parking=depot (89 occorrenze) [3], e depot:type=wood/tree_trunks [4],
>
> che io apporterei come valore log_timber.
>
>
> Esiste un occorenza anche come landuse=timber/timber_yard [6], che non
>
> mi sembra appropriata, e landuse=depot/storage [7][8], già detto nella
>
> precedente discussione, non adatti.
>
>
> Poi ho pensato anche una chiave depot:type=storage [9], con insieme una
>
> chiave=valore, storage=timber, oppure storage=timber_log, oppure
>
> storage=log/wood_log.
>
>
>
>
> Mettendo in ordine se può funzionare, metterei:
>
>
> access=private;forestry
>
>
> amenity=parking
>
>
> parking=depot
>
>
> depot:type=timber/timber_log/wood
>
>
>
>
> In variazione:
>
>
> depot:type=storage
>
>
> storage=timber/timber_log/wood
>
>
>
>
> Chiedo a voi se può funzionare, oppure se è il caso chiedo in lista
>
> tagging, considerato che nella maggior parte del territorio nazionale
>
> italiano alpino/appenninico e penso anche transalpino, questo tipo di
>
> depositi/parcheggi son comuni, magari è il caso di, possibilmente,
>
> uniformare i tag.
>
>
> Per gli spazi/spiazzi/parcheggi usati per deposito di tronchi derivati
>
> da Vaia, oltre a quelli creati appositamente per questo scopo, non mi ci
>
> metto perchè credo sia tardi per un tag Vaia:*:*, anche perchè alla
>
> prossima tempesta ci sarà un'altro nome e credo impossibile stare dietro
>
> a tutto ciò.
>
>
> Grazie a chi risponderà.
>
>
>
> Non mi piace l'uso di amenity=parking perchè in contrasto con il suo
> significato di parcheggio per veicoli. È chiaro che non si può usare come
> parcheggio:
> https://imgur.com/a/7zY9V
>
> Come tag principale sceglierei un man_made=storage o storage_area o
> storage_*qualcosaltro.*
>
> Per indicare il materiale stoccato (wood o timber, non so cosa è meglio
> per il legname grezzo) forse si dovrebbe usare la chiave content=* già
> usata per altri tipo di stoccaggio, lasciando storage=* per specificare il
> tipo/metodo di stoccaggio come suggeriva anche Martin nella vecchia
> discussione.
>
>
> Ciao
> Lorenzo
> ___
> 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-GB] Local Wildlife Sites

[Jez Nicholson]

Does anyone have any experience with
https://www.wildlifetrusts.org/local-wildlife-sites ?

I've had an inquiry about including Brighton & Hove LWSes on OSM.

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

Re: [Talk-it] Riprendo vecchia discussione, spiazzo deposito tronchi.

[Lorenzo Mastrogiacomi]

Il giorno dom, 19/07/2020 alle 20.47 +0200, liste DOT girarsi AT posteo
DOT eu ha scritto:
> Riporto in vita una vecchia discussione da me avviata che alla fine
> nonaveva portato a conclusioni certe [0], escludo a priori
> spiazziutilizzati come slarghi o aree non perfezionate per tale
> scopo.
> Riprendo il mio ragionamento fatto ieri, ovvero si identifica
> un'areadefinita con tanto di segnaletica verticale a specificare lo
> spiazzo perdeposito/carico legname, spiazzo appartenente, in questo
> caso al Comune,fatto apposta solo per permettere ciò, metto le due
> foto per idealizzareanche se con qualche differenza, quanto messo
> nella discussione avviatain precedenza per capire di cosa si sta
> parlando e per non confonderecon catasta di legname/scarti di una
> segheria [1] [2].
> Dunque il mio ragionamento mi porta a pensare questo spiazzo come
> unparcheggio apposito, in quanto si tratta di
> deposito/stoccaggiotemporaneo, ovvero vengono accatastati tronchi da
> parte di operatoriboschivi,ai fini di permettere il carico a fine di
> vendita o successivospostamento, per esempio.
> Guardando su taginfo, ravanando un pò coi tag, ho trovato un
> possibileparking=depot (89 occorrenze) [3], e
> depot:type=wood/tree_trunks [4],che io apporterei come valore
> log_timber.
> Esiste un occorenza anche come landuse=timber/timber_yard [6], che
> nonmi sembra appropriata, e landuse=depot/storage [7][8], già detto
> nellaprecedente discussione, non adatti.
> Poi ho pensato anche una chiave depot:type=storage [9], con insieme
> unachiave=valore, storage=timber, oppure storage=timber_log,
> oppurestorage=log/wood_log.
> 
> 
> Mettendo in ordine se può funzionare, metterei:
> access=private;forestry
> amenity=parking
> parking=depot
> depot:type=timber/timber_log/wood
> 
> 
> In variazione:
> depot:type=storage
> storage=timber/timber_log/wood
> 
> 
> Chiedo a voi se può funzionare, oppure se è il caso chiedo in
> listatagging, considerato che nella maggior parte del territorio
> nazionaleitaliano alpino/appenninico e penso anche transalpino,
> questo tipo didepositi/parcheggi son comuni, magari è il caso di,
> possibilmente,uniformare i tag.
> Per gli spazi/spiazzi/parcheggi usati per deposito di tronchi
> derivatida Vaia, oltre a quelli creati appositamente per questo
> scopo, non mi cimetto perchè credo sia tardi per un tag Vaia:*:*,
> anche perchè allaprossima tempesta ci sarà un'altro nome e credo
> impossibile stare dietroa tutto ciò.
> Grazie a chi risponderà.

Non mi piace l'uso di amenity=parking perchè in contrasto con il suo
significato di parcheggio per veicoli. È chiaro che non si può usare
come parcheggio:
https://imgur.com/a/7zY9V

Come tag principale sceglierei un man_made=storage o storage_area o
storage_qualcosaltro.


Per indicare il materiale stoccato (wood o timber, non so cosa è meglio
per il legname grezzo) forse si dovrebbe usare la chiave content=* già
usata per altri tipo di stoccaggio, lasciando storage=* per specificare
il tipo/metodo di stoccaggio come suggeriva anche Martin nella vecchia
discussione.


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

Re: [Talk-us] Interested in importing address points in New York State

[Skyler Hawthorne]

Thanks Mateusz, I actually tried to make a page, but I am encountering some 
strange behavior from the wiki. When I try to edit or add a page, a text 
box appears that says "confirmation code," with no other explanation. I 
don't get an email with a confirmation code, so I have no idea what it wants.


I was going to make a subpage of New York with the title of "NYS GIS 
Clearinghouse", and include a link to it in the Potential Data sources 
page. I'm not sure if it's possible to upload and serve arbitrary files in 
the wiki; if so, I was going to upload that raw email file.

--
Skyler
On July 20, 2020 03:24:18 Mateusz Konieczny via Talk-us 
 wrote:




Jul 20, 2020, 05:12 by kevin.b.ke...@gmail.com:
On Thu, Jul 16, 2020 at 12:46 PM Mateusz Konieczny via Talk-us 
 wrote:

Once you write this diary entry (or OSM Wiki page) please post
it to the mailing list!

Here you go:  https://www.openstreetmap.org/user/ke9tv/diary/393684

Feel free to repost, wikify, share as appropriate!
For now I created tiny 
https://wiki.openstreetmap.org/wiki/E911_data_in_New_York

to make this easier to search.

For start - what would be the best name for that page?
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us


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

Re: [Talk-us] Labeling forestry service roads/tracks

[brad]

Hmmm, interesting.   I'm not sure they compact very many roads around 
here (CO).  Maybe a regional difference.  It seems like they put a thick 
layer of gravel on and let the traffic compact it.   Not fun to ride on 
with a bike, or a motorcycle.
Do rocks tend to come to the surface of a compacted road and create a 
ball bearing interface?   If they grade it after initial construction, 
do they subsequently compact it again too?


On 7/19/20 9:27 PM, Kevin Kenny wrote:


On Sun, Jul 19, 2020 at 9:29 PM brad > wrote:


Thanks for diving in.   If it's a very minor unimproved road and
not clearly service, I usually tag it track.   I would suggest
adding some indication of road quality.   If it's an improved
gravel road, I consider surface=gravel sufficient.   If it's
rougher than an improved gravel road, surface=unpaved (in my area
the surface is usually a mix of dirt, rocks, gravel, so unpaved
seems best),   and smoothness=very_bad (high clearance), or
horrible (4wd) 
[https://wiki.openstreetmap.org/wiki/Key:smoothness], or 
4wd_only=yes .


A nit: most 'improved' gravel roads are surface=compacted.  'gravel' 
is like rail ballast; a compacted surface ordinarily has a mix of fine 
gravel and even finer material such as sand, and is rolled. Americans 
will often refer to a compacted road as a 'dirt' or 'gravel' road but 
the difference is like night and day when you're driving on one!


For the rougher stuff, 'smoothness' is essential. Consider also 
'tracktype', which addresses more the firmness of the surface rather 
than its smoothness. A clay surface may be lovely in a dry season and 
impassable in a wet one, despite having a fast enough slump that the 
surface is deceptively smooth.


Some National Forests separate Forest Highway (a regular access road) 
and Forest Road (usually a logging track, might be inaccessible in any 
given season, and often passable only to logging trucks and similar 
high-clearance off-road vehicles). I don't know if any of them overlay 
the numbering of the two systems.


_Please_ create route relations!



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

[Talk-br] Reversão da inserção em massa de bicycle e class:bicycle nas rodovias do país

[Fernando Trebien]

Envio essa mensagem para documentar a reversão de uma edição em massa,
seguindo o código de conduta. [1]

Ontem nos grupos do Telegram Classificação e Avançado foi discutida a
necessidade de reverter os changesets 88054258, 88055043, 88055062 e
88205409 que adicionaram a 20 mil linhas de rodovias as seguintes
etiquetas: bicycle=yes + class:bicycle=-2 +
class:bicycle:roadcycling=1 . A opinião geral é de que deveriam ser
revertidos completamente devido aos erros encontrados no valor da
etiqueta bicycle e mais de uma cidade. O valor inserido descreveu como
permitidas para ciclistas rodovias em diferentes cidades com
sinalização no local proibindo o acesso deles.

Além disso, a etiqueta class:bicycle é descrita no wiki como disputada
por questões de verificabilidade. [2] Dos 28060 usos da etiqueta
class:bicycle no mundo, 19482 são no Brasil, aparentemente todas
inseridas por esse usuário nesses changesets.

[1] 
https://wiki.openstreetmap.org/wiki/Pt:Código_de_conduta_de_edições_automatizadas
[2] https://wiki.openstreetmap.org/wiki/Pt:Verificabilidade

-- 
Fernando Trebien

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

Re: [Talk-it] facebook compra mapillary

[Lorenzo Mastrogiacomi]

Il giorno lun, 20/07/2020 alle 14.21 +0200, Andrea Musuruane ha
scritto:
> Ciao,
> 
> Il lun 20 lug 2020, 13:51   ha scritto:
> > Per chi non l'avesse letto su weeklyosm, c'è questo strumento per
> > copiare le proprie immagini da Mapillary a OpenStreetCam.
> > https://osm.svimik.com/photosync/C’è un thread di discussione sul
> > forum di Mapillary.
> > https://forum.mapillary.com/t/mapillary-openstreetcam-synchronization-tool/4246/3
> > Lo sto usando e funziona molto bene. In pochi passaggi è impostato
> > e si può chiudere lasciandolo fare tutto da solo(ci vorranno giorni
> > per completare l'upload su OSC che è piuttosto lento al momento).
> 
> Perché Grab dovrebbe essere meglio di Facebook?
> 
> Ciao,
> 
> Andrea
> 

Nessuno dei due è meglio :) Quindi a questo punto preferisco non
favorirne uno e caricare le immagini che ho su entrambi.
Ma è una cosa che avrei voluto fare anche prima di Grab e Facebook. Lo
faccio adesso perché è semplice.

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

Re: [Talk-it] facebook compra mapillary

[Andrea Musuruane]

Ciao,

Il lun 20 lug 2020, 13:51  ha scritto:

> Per chi non l'avesse letto su weeklyosm, c'è questo strumento per copiare
> le proprie immagini da Mapillary a OpenStreetCam.
>
> https://osm.svimik.com/photosync/
>
> C’è un thread di discussione sul forum di Mapillary.
>
> https://forum.mapillary.com/t/mapillary-openstreetcam-synchronization-tool/4246/3
>
>
> Lo sto usando e funziona molto bene. In pochi passaggi è impostato e si può 
> chiudere lasciandolo fare tutto da solo
>
> (ci vorranno giorni per completare l'upload su OSC che è piuttosto lento al 
> momento).
>
>
Perché Grab dovrebbe essere meglio di Facebook?

Ciao,

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

Re: [talk-au] Working with local government

[Andrew Harvey]

On Mon, 20 Jul 2020 at 12:33, David Wales  wrote:

> Is there any reason against using a custom tag as a linking key?
>
> e.g. some_import_object_id=123456
>
> Then when you need to update the data, you can match the key in OSM with
> the key in the source data.


It can be a deterrent to mappers, they may see these external ids and think
oh I don't understand that, maybe it's special and I shouldn't touch it,
maybe it is owner by someone else and they update it directly.

Similar to what Mateusz said, if the community can't verify it, how do we
know it's right? What should we do if things change on the ground? How do
we know if the ID still applies to the new tag? In my opinion a better
solution for a private linkage is for the 3rd party database to point
directly to the OSM node/way/relation ID. The external database should
monitor for changes to those IDs and then review after each change if the
linkage is correct or needs changing.

Though still the private ID method has been used for imports of the past,
and I'm not saying it can't be used, but there are disadvantages and valid
concerns.

On Mon, 20 Jul 2020 at 14:08, Greg Dutkowski 
wrote:

> Hi,
> I was thinking of using the ref tag to store the council ID for the
> object, and then the council could use the OSMID in their database.
> What I was looking for was tools or approaches for keeping the two in
> sync. The foreign keys in each system are part of that.
> The conflation tools Andew Harvey pointed to may be a way to go.
> OSM is so big and diverse it is hard to get your head around all of the
> possibilities, so contacts with people who are making conflation work would
> be ideal.
>

I haven't tried those tools before, but my outsider view is that they are
too low level and not mature. I would love to see something similar to
Maproulette or Tasking Manager from an ease of use and non-technical setup
point of view but for maintaining linkages with external datasets.

I wrote recently about a conflation I did to compare government traffic
lights data https://www.openstreetmap.org/user/aharvey/diary/393663 and I
avoided any coding in that process.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-it] facebook compra mapillary

[lomastrolo]

Il giorno gio, 18/06/2020 alle 22.53 +0200, Martin Koppenhoefer ha
scritto:
> Appena saputo, Facebook ha comprato Mapillary. Dopo Openstreetcam (venduto da 
> Telenav a Grab) è il secondo acquisto di streetview che non promette bene.
> 
> Se li avete affidato le vostre foto forse sarebbe una buona idea scaricarsi 
> tutto finché si può...
> 
> 
> Ciao Martin 
> 

Per chi non l'avesse letto su weeklyosm, c'è questo strumento per copiare le 
proprie immagini da Mapillary a OpenStreetCam.
https://osm.svimik.com/photosync/
C’è un thread di discussione sul forum di Mapillary.
https://forum.mapillary.com/t/mapillary-openstreetcam-synchronization-tool/4246/3

Lo sto usando e funziona molto bene. In pochi passaggi è impostato e si può 
chiudere lasciandolo fare tutto da solo
(ci vorranno giorni per completare l'upload su OSC che è piuttosto lento al 
momento).


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

Re: [Talk-us] Labeling forestry service roads/tracks

[tj-osmwiki]

Mike,

Good idea on the route references. What should the network be set to?

On 2020/07/20 7:56, Mike Thompson wrote:
> 
> 
> On Sun, Jul 19, 2020 at 4:49 PM  > wrote:
> 
>  For
> roads that appear to be public access (e.g. to go to a lake) but are
> obviously even more minor than tertiary roads I label
> highway=unclassified.
> 
> highway=unclassified are for roads that connect small towns, or for
> "local traffic", while access to a lake could be considered "local
> traffic", I would think it would be better if these would be
> highway=service, or highway=track.
> 
> 
> The US Topo map gives forest road references so I add ref FS .
> 
> That is what I have been doing as well. Some are recommending that they
> be made into route relations, which I am starting to do.
> 
> 
> TIGER seems to be at best very coarse, at worst fictional.
> 
> +1 
> 
> Mike

-- 
Mark Brown
8-3-17-803 Shimorenjaku, Mitaka, Tokyo 181-0013
Tel/fax: 0422 42 3151
Mobile: 090 8774 7483 (Japan)
+44 843 849 0359 (UK, VoIP)

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

Re: [Talk-us] Labeling forestry service roads/tracks

[tj-osmwiki]

Clifford,

Could you repost the legend? It's hard/impossible to make out the
surface reliably from aerial photos.

On 2020/07/20 14:18, Clifford Snow wrote:
> If you are using JOSM there is a USFS road layer. The color of the way
> indicates surface and highway classification if I remember correctly. I
> posted the legend on Slack a couple of years ago. 
> 
> The TIGER import data quality varied from region to region. Even today
> in Washington State it's bad, so bad that I don't recommend using it. My
> guess is that it's low priority for counties to update Feds, especially
> when their budgets are already tight. There is even one county in
> Washington State that they don't even have a current road layer. 
> 
> Best,
> Clifford
> 
> On Sun, Jul 19, 2020 at 3:48 PM  > wrote:
> 
> Hi folks,
> 
> Editing in Boundary County, Idaho in the Panhandle, I've been extending
> the forest landuse area around Bonners Ferry and have come across a
> difficulty in classifying forest roads.
> 
> It seems that many have been automatically imported and have
> highway=residential, which is just plain wrong.
> 
> For roads that appear metalled (paved) and/or access mines, quarries,
> communication towers etc. I label highway=service, for roads that are
> unpaved or sometimes seem to almost fade out I label highway=track. For
> roads that appear to be public access (e.g. to go to a lake) but are
> obviously even more minor than tertiary roads I label
> highway=unclassified.
> 
> Is there a more consistent recommended method?
> 
> The US Topo map gives forest road references so I add ref FS .
> 
> TIGER seems to be at best very coarse, at worst fictional.
> 
> Thanks.
> 
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-us
> 
> 
> 
> -- 
> @osm_washington
> www.snowandsnow.us 
> OpenStreetMap: Maps with a human touch
> 
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
> 

-- 
Mark Brown
8-3-17-803 Shimorenjaku, Mitaka, Tokyo 181-0013
Tel/fax: 0422 42 3151
Mobile: 090 8774 7483 (Japan)
+44 843 849 0359 (UK, VoIP)

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

[Talk-GB] Surveying rural buildings

[Nick]

Dear all

I have been mapping a few properties using Bing maps with local 
knowledge supplemented by some physical measuring (tape measure or 
simply pacing). I now want to ramp up my mapping but the challenge 
especially in rural areas is that sometimes the outline of a building is 
not clear - either obscured (e.g. trees) or unclear (e.g. decking or car 
ports). Also some aerial imagery is offset. Also, most of the properties 
are not along public roads. So my question is what are the preferred 
methods for surveying that others are using?


I had thought perhaps a) simply sketches coupled with approximate 
geolocation (GPS assuming I can get a decent fix on a mobile phone) but 
perhaps b) using GPS linked to a laser rangefinder (e.g. identify 
corners of buildings from a distance) or c) sophisticated cameras (3D)? 
I realise that different mappers will be happy with different levels of 
precision but wonder if in the UK how we can balance cost, time and 
accuracy by selecting the best approaches.


Supplementary question, do you include or exclude conservatories, car 
ports etc. from the main structure of the property?


I guess at the back of my mind is what do people perceive as the purpose 
of mapping (hope I have not opened a can of worms).


Any thoughts/suggestions gratefully received

Nick

P.S. I am aware of some documentation e.g. 
https://wiki.openstreetmap.org/wiki/Accuracy



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

Re: [OSM-talk-fr] Siège des EPCI

[Vincent Bergeot]

Bonjour,

Le 19/07/2020 à 13:09, Gaël Simon a écrit :

Bonjour,
De nombreuses relations EPCI n’indiquent pas leur siège avec le rôle 
admin_centre. Par contre beaucoup ont un tag wikidata qui indique l’emplacement 
de ce siège. Ajouter l’admin_center a-t-il alors un intérêt ou ces informations 
sont-elles redontantes ?


en fait je pense que cela va surtout dépendre du degré de dépendance à 
une autre base !


Si c'est wikidata qui dit le siège social, cela signifie que OSM ne 
suffit pas !


Cela interroge ce que l'on met dans l'un, dans l'autre ou dans les 2 !


Par ailleurs, j’ai fini de cartographier les EPIC de type PETR (pôles 
d’équilibre territorial et rural).


Merci pour le PETR Pays Adour Landes Océanes, quel plaisir de le 
trouver. Je n'ai pas trouvé de page wiki correspondante, j'ai peut-être 
mal cherché ou je veux bien donner un coup de main pour la "créer" !


actuellement 9 : 
https://taginfo.openstreetmap.fr/tags/local_authority%3AFR=PETR


Bonne journée

--
Vincent Bergeot


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

Re: [Talk-GB] TPT / NCN62 (was: Re: National Cycle Network removal/reclassification)

[Paul Berry]

>  It'd be a lot of work for relatively little reward though - presumably
that's why no-one's stepped up to tidy things up yet.

Andy,

I'm quite happy to pick this up as I've been mapping parts of the route
local to me anyway so assessing what is and isn't the TPT shouldn't be that
arduous. It's at least wholly or partly the NCN 56, 62, 627 and there are
probably more bits and pieces out there...

Thanks for the tips. I'll start there.

Regards,
*Paul*

On Sat, 18 Jul 2020 at 19:18, Andy Townsend  wrote:

> On 18/07/2020 17:06, Adam Snape wrote:
>
> On the subject of overlapping relations. I've recently noticed that the
> NCN 62 relation has been named Transpennine trail which is true for much,
> but not all of the route. The TPT ends at Southport, yet NCN 62 continues
> further North. At the eastern end of the TPT goes far beyond the end of NCN
> 62 which ends at Selby. They need to be two separate relations.
>
> The Trans-Pennine Trail is a bit confusing, both on the ground and in
> OSM.  A quick query in OSM south of Selby turns up this:
>
> https://www.openstreetmap.org/relation/12763
>
> "ref=62; name=Trans Pennine Trail"
>
> and this:
>
>
> https://www.openstreetmap.org/relation/1761919#map=10/53.7874/-0.6265=H
>
> "ref=TPT; name=Trans Pennine Trail"
>
> and also this:
>
>
> https://www.openstreetmap.org/relation/10521621#map=10/53.6371/-1.2158=H
>
> "name=Trans Pennine Trail (Wombwell to Selby)"
>
> It essentially goes all over the place, and doesn't correspond to one
> particular NCN (see
> https://www.transpenninetrail.org.uk/?doing_wp_cron=1595095458.735897064208984375
> ).  The Chesterfield end has two braids and partially corresponds to what
> is or was NCN 67.
>
> The superroute I believe is https://www.openstreetmap.org/relation/4139041
>
>
> If NCN 62 isn't properly called the Transpennine Trail I'd remove that
> name from it and explain in a note on the relation why.  My recollection is
> that NCN62 and TPT signage is separate, but it's a while since I've seen
> any so I may be wrong.
>
> The best approach for tidying would I think be to:
>
>- Find anything not in the superroute and figure out what the status
>actually is.
>- Ensure that routes in the superroute are split where tags change
>(e.g. bits with NCN 62 signage and bits without)
>
> It'd be a lot of work for relatively little reward though - presumably
> that's why no-one's stepped up to tidy things up yet.
>
> Best Regards,
>
> Andy
>
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-it] Sondaggio OpenStreetMap Italia

[Anisa Kuci]

Ciao Marco,

grazie mille a te per il lavoro che ci hai messo per fare questa classifica!

Anisa



On 7/17/20 1:32 PM, mbranco2 wrote:

Grazie Anisa del tuo lavoro, interessante.

Oltre a notare che non hanno risposto mappatori di San Marino e 
Vaticano (forse hanno una loro mailing list? :-) ), ho provato a 
rapportare i mappatori che hanno risposto al numero di abitanti della 
loro regione; questa la classifica (il rapporto è fatto su 100.000 
abitanti) :


 Valle d'Aosta  1,592
 Trentino-Alto Adige1,119
 Friuli-Venezia Giulia  0,658
 Umbria 0,567
 Piemonte   0,551
 Liguria0,451
 Molise 0,327
 Abruzzo0,305
Lombardia   0,299
 Toscana0,295
 Veneto 0,285
 Marche 0,262
 Emilia-Romagna 0,224
 Lazio  0,204
 Sardegna   0,183
 Sicilia0,080
 Puglia 0,074
 Campania   0,017
 Basilicata 0
 Calabria   0


Il giorno gio 16 lug 2020 alle ore 19:46 Anisa Kuci 
mailto:anisa.k...@wikimedia.it>> ha scritto:


Ciao a tutti,

in questo link

trovate le slide con le statistiche del sondaggio rivolto alla
comunità di OSM Italia.

Chiedo scusa per il ritardo e spero davvero che troverete i
risultati interessanti quanto li ho trovati io.

Penso che siano un buon punto di partenza per riflettere su molte
cose riguardanti la situazione attuale di OSM Italia e vedere dove
possiamo lavorare di più.

Nell'ultimo slide trovate un link di un pad creato per commenti o
altre idee che volete condividere. :)

Vi ringrazio tantissimo per tutte le vostre risposte, per le idee
e proposte e per il tempo dedicato al sondaggio!

Buona serata e buona mappatura,

Anisa


On 7/12/20 2:15 PM, Anisa Kuci wrote:


Ciao a tutti,

vorrei proporre un incontro aperto a tutta la comunità OSM
italiana dove condividerò con voi una presentazione dei risultati
del sondaggio che vi ho inviato qualche settimana fa.

Le risposte sono state molte e le statistiche sono molto
interessanti. Vi prego di partecipare all'incontro in modo da
poterne discutere insieme.

Propongo il *15 luglio (mercoledì) alle 17:00*. Ci troviamo in
questa  stanza Jitsi.

La presentazione con i risultati sarà pubblicata nella lista
talk-it - ovviamente senza i dati personali di nessuno - dopo
l'incontro, così chiunque voglia può tornare a vederli in dettaglio.

Grazie a tutti e buona domenica!

A presto,

Anisa



On 6/19/20 7:20 PM, Anisa Kuci wrote:


Ciao,

C'è tempo fino a lunedì (22 giugno) per compilare il sondaggio
(APERTO A TUTTI I MEMBRI DELLA COMUNITÀ OSM ITALIA) con le
vostre opinioni!

Condivido di nuovo il link:
https://sondaggio.wikimedia.it/index.php/724728?lang=it

Buon weekend,

Anisa

On 6/16/20 12:32 PM, Anisa Kuci wrote:


Ciao a tutti,

questo è solo un gentile promemoria per chi non ha compilato il
questionario che rimane attivo fino 22 Giugno.

Più risposte avremo, meglio sapremo quali sono gli argomenti
più importanti per la comunità.

Vi ringrazio in anticipo!

Buona giornata,

Anisa

On 6/8/20 4:46 PM, Anisa Kuci wrote:


Ciao a tutti,

in collaborazione con i coordinatori di OSM Italia abbiamo
preparato un'indagine con argomenti e attività diverse.

Chiedo gentilmente a tutta la comunità di OSM Italia di
compilare il sondaggio
 in
modo da poter creare un'idea degli argomenti più importanti su
cui lavorare.

Se volete condividerlo nei gruppi regionali, per favore
segnalatemi dove è stato fatto.

Il sondaggio sarà disponibile per due settimane a partire da
oggi (fino al 22 giugno).

Fatemi sapere se avete domande!

Buona mappatura,

Anisa


-- 
Anisa Kuci

Responsabile OpenStreetMap e Wikidata
Wikimedia Italia - Associazione per la diffusione della conoscenza libera
Via Bergognone 34 - 20144 Milano
Tel. (+39) 02 97677170 |anisa.k...@wikimedia.it   
 |www.wikimedia.it  

DAI ALLA CONOSCENZA LIBERA UN NUOVO NOME. IL TUO.
Devolvi il 5x1000 a Wikimedia Italia:
nella tua dichiarazione dei redditi inserisci il Codice Fiscale 94039910156

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

Responsabile OpenStreetMap e Wikidata
Wikimedia Italia - Associazione per la diffusione della conoscenza libera
Via Bergognone 34 - 20144 Milano
Tel. (+39) 02 97677170 |anisa.k...@wikimedia.it   
 |www.wikimedia.it  

DAI ALLA 

Re: [talk-au] Working with local government

[David Wales]

I imagine this approach would work better on nodes than on ways.
But I imagine that the number of keys with changed nodes would be much
fewer than the total number of keys, allowing the unchanged nodes to be
easily updated, and reducing the conflation burden.

On 20/7/20 5:24 pm, Mateusz Konieczny via Talk-au wrote:
> (1) pollution of tags by such keys is irritating
> (2) people may split, move, delete, edit or copy such tag
>
> wikidata key is slightly better - but requires wikidata entries
>
> Jul 20, 2020, 04:33 by daviewa...@disroot.org:
>
> Is there any reason against using a custom tag as a linking key?
>
> e.g. some_import_object_id=123456
>
> Then when you need to update the data, you can match the key in
> OSM with the key in the source data.
>
> On 19 July 2020 11:21:04 pm AEST, Andrew Harvey
>  wrote:
>
>
>
> On Sun, 19 Jul 2020 at 22:28, Greg Dutkowski
> mailto:greg.dutkow...@gmail.com>>
> wrote:
>
> Hi,
> Thanks for everyone's input.
> Sebastien best understood what I am trying to do.
> It seems inefficient for local government to make their
> data open and then hope the OSM community translates it to
> OSM tagging. 
>
> Better for local government to put their data directly
> into OSM and maintain a two way link to their data.
>
>
> While that is certainly welcome, I would never have an
> expectation of it. I expectat that all public funded works are
> made open without restrictions on use (of course subject to
> privacy concerns or other special considerations) so at least
> the OSM community can use it if we like, anything above and
> beyond this is a welcome contribution.
>
> If a local government is thinking about this, I'd just say
> engage with us so we can all work together.
>  
>
> Examples and tools from anyone who is trying to keep
> external data in sync with OSM will be most useful.
>
>
> There are some conflation tools
> at https://wiki.openstreetmap.org/wiki/Category:Conflation but
> they appear to all need a lot of coding to get up and running.
>
>
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au



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

Re: [Talk-us] Labeling forestry service roads/tracks

[Dave Swarthout]

Kevin wrote::
A nit: most 'improved' gravel roads are surface=compacted.  'gravel' is
like rail ballast; a compacted surface ordinarily has a mix of fine gravel
and even finer material such as sand, and is rolled. Americans will often
refer to a compacted road as a 'dirt' or 'gravel' road but the difference
is like night and day when you're driving on one!

I must admit, this one really got me. For much of life when I lived in New
York state, where Kevin and I are from, locals called all unpaved roads
"dirt roads". When I started using OSM, I realized that the definition of
"dirt" here is closer to "ground" so I began to use either unpaved or
gravel for the surfaces of rural roads in Alaska and Thailand. Eventually,
I found out that gravel means the type of stones found on railroads, which
is big chunks of crushed rock and that the surface of the improved roads I
was tagging was actually surface=compacted with tracktype=grade2. The type
of mapping I do is 90% armchair mapping so it's difficult to ascertain
these characteristics so I default to surface=unpaved in most cases. Alaska
is an exception because most rural roads below the tertiary class are
well-prepared, unpaved compacted surface roads. These I feel confidant to
tag with surface=compacted and tracktype=grade2

My 2 cents.

On Mon, Jul 20, 2020 at 12:20 PM Clifford Snow 
wrote:

> If you are using JOSM there is a USFS road layer. The color of the way
> indicates surface and highway classification if I remember correctly. I
> posted the legend on Slack a couple of years ago.
>
> The TIGER import data quality varied from region to region. Even today in
> Washington State it's bad, so bad that I don't recommend using it. My guess
> is that it's low priority for counties to update Feds, especially when
> their budgets are already tight. There is even one county in Washington
> State that they don't even have a current road layer.
>
> Best,
> Clifford
>
> On Sun, Jul 19, 2020 at 3:48 PM  wrote:
>
>> Hi folks,
>>
>> Editing in Boundary County, Idaho in the Panhandle, I've been extending
>> the forest landuse area around Bonners Ferry and have come across a
>> difficulty in classifying forest roads.
>>
>> It seems that many have been automatically imported and have
>> highway=residential, which is just plain wrong.
>>
>> For roads that appear metalled (paved) and/or access mines, quarries,
>> communication towers etc. I label highway=service, for roads that are
>> unpaved or sometimes seem to almost fade out I label highway=track. For
>> roads that appear to be public access (e.g. to go to a lake) but are
>> obviously even more minor than tertiary roads I label
>> highway=unclassified.
>>
>> Is there a more consistent recommended method?
>>
>> The US Topo map gives forest road references so I add ref FS .
>>
>> TIGER seems to be at best very coarse, at worst fictional.
>>
>> Thanks.
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>
>
> --
> @osm_washington
> www.snowandsnow.us
> OpenStreetMap: Maps with a human touch
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk] "helpful" remote correctional edits (or "please don't correct bank ATMs in the Sahara desert" - was: Re: Planned revert of added surface and tracktype tags without local knowledge in va

[Martin Koppenhoefer]

sent from a phone

> On 19. Jul 2020, at 23:27, Jóhannes Birgir Jensson  wrote:
> 
> no doubt many of our gravel tracks were correct at the time and have now been 
> paved or bound.


I have thought about this, the tags were added in 2017 and  while the asphalt 
didn’t look as if it was paved yesterday, it’s not completely excluded that the 
road was paved in between 

Cheers Martin 




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

Re: [talk-au] Working with local government

[Mateusz Konieczny via Talk-au]

(1) pollution of tags by such keys is irritating
(2) people may split, move, delete, edit or copy such tag

wikidata key is slightly better - but requires wikidata entries

Jul 20, 2020, 04:33 by daviewa...@disroot.org:

> Is there any reason against using a custom tag as a linking key?
>
> e.g. some_import_object_id=123456
>
> Then when you need to update the data, you can match the key in OSM with the 
> key in the source data.
>
> On 19 July 2020 11:21:04 pm AEST, Andrew Harvey  
> wrote:
>
>>
>>
>> On Sun, 19 Jul 2020 at 22:28, Greg Dutkowski <>> greg.dutkow...@gmail.com>> 
>> > wrote:
>>
>>> Hi,
>>> Thanks for everyone's input.
>>> Sebastien best understood what I am trying to do.
>>> It seems inefficient for local government to make their data open and then 
>>> hope the OSM community translates it to OSM tagging. 
>>>
>>> Better for local government to put their data directly into OSM and 
>>> maintain a two way link to their data.
>>>
>>
>> While that is certainly welcome, I would never have an expectation of it. I 
>> expectat that all public funded works are made open without restrictions on 
>> use (of course subject to privacy concerns or other special considerations) 
>> so at least the OSM community can use it if we like, anything above and 
>> beyond this is a welcome contribution.
>>
>> If a local government is thinking about this, I'd just say engage with us so 
>> we can all work together.
>>  
>>
>>> Examples and tools from anyone who is trying to keep external data in sync 
>>> with OSM will be most useful.
>>>
>>
>> There are some conflation tools at >> 
>> https://wiki.openstreetmap.org/wiki/Category:Conflation>>  but they appear 
>> to all need a lot of coding to get up and running.
>>

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

Re: [Talk-us] Interested in importing address points in New York State

[Mateusz Konieczny via Talk-us]

Jul 20, 2020, 05:12 by kevin.b.ke...@gmail.com:

> On Thu, Jul 16, 2020 at 12:46 PM Mateusz Konieczny via Talk-us <> 
> talk-us@openstreetmap.org> > wrote:
>
>> Once you write this diary entry (or OSM Wiki page) please post
>> it to the mailing list!
>>
>
> Here you go:  > https://www.openstreetmap.org/user/ke9tv/diary/393684
>
>  Feel free to repost, wikify, share as appropriate!
>
For now I created tiny https://wiki.openstreetmap.org/wiki/E911_data_in_New_York
to make this easier to search. 

For start - what would be the best name for that page?
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us