Re: [Talk-us] Off-highway vehicle recreation areas

[Joseph Eisenberg]

A leisure=park is supposed to be similar to a town park; an area with
managed vegetation where you might walk around or recreate. An OHV area is
not like this: "A park is an area of open space for recreational use,
usually designed and in semi-natural state with grassy areas, trees and
bushes. ... This tag is intended for (usually urban) parks with managed
greenery, located within settlements and nearly always open to general
public."

The tag leisure=sports_centre might be appropriate for an area that is
specifically developed and designed for ATVs and motorcycles.

"A *sports centre* is a distinct facility where sports take place within an
enclosed area. It can be a building (indoor sports centre), just outside
(outdoor sports centre) or contain indoor and outdoor sports features mixed
together."

However, if this is a large semi-natural area that just happens to have a
number of track or trails, then it's similar to a forested area with hiking
trails or mountain bike paths. In this case it might or might not be part
of a boundary=protected_area

In the case of the Hungary Valley SVRA, it is managed by the California
State Parks system: https://www.parks.ca.gov/?page_id=405 - I believe this
is a boundary=protected_area

-- Joseph Eisenberg

On Sat, Jun 6, 2020 at 12:54 PM brad  wrote:

> Good question.   At first glance I don't think Leisure=park is wrong.  The
> wiki is characteristically narrow since it says that it is green.
> leisure=sports_center or landuse=recreation_ground would be better.
> leisure=pitch doesn't seem right even thought the sport=motocross wiki page
> references it.   These OHV areas are typically more than a simple motocross
> track.   leisure=nature_reserve sure doesn't seem right!
>
> On 6/5/20 4:55 PM, Tod Fitch wrote:
>
> I have noticed a couple of off-highway vehicle recreation areas that are 
> tagged with things that seem incorrect to me: As generic parks or as 
> protected areas.
>
> Consider the Hungry Valley State Vehicle Recreation Area [1][2][3][4] and the 
> Wildomar OHV Area [5][6].
>
> My problem is that I can’t tell from the wiki and taginfo what might more 
> appropriate or more accepted tagging. It seems there is tagging for tracks 
> used for motocross. And people have used access tags for ATVs. But I don't 
> see a documented tagging for an area that contains a trail system for use by 
> multiple types of off-highway vehicles. I have some thoughts on what might be 
> appropriate, but would rather hear from others.
>
> Thanks!
>
> --Tod
>
> [1] 
> https://www.riderplanet-usa.com/atv/trails/info/california_10003/ride_413b.htm
> [2] https://www.openstreetmap.org/relation/6179378
> [3] https://www.openstreetmap.org/way/367714413
> [4] https://www.openstreetmap.org/way/367714414
> [5] 
> https://www.riderplanet-usa.com/ATV/trails/info/california_03947/ride_7684.htm
> [6] https://www.openstreetmap.org/way/248540505
>
>
> ___
> Talk-us mailing 
> listTalk-us@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-us
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] USFS Roads - name and ref

[Paul Johnson]

On Sat, Jun 6, 2020 at 4:15 PM Bob Gambrel  wrote:

> Paul's in depth answer of my question was very helpful. Luckily I am not
> concentrating on road/highway routes. I like the concept of:
>
> We should be moving forward towards
> all routes being tagged in a route relation so we can phase out route
> attributes on ways, freeing those up for *the way's attributes.*
>
> That intuitively makes sense. It seems to me that most routes these days
> are really a collection of ways (collected by the route relation).
>

This was *literally* a reason relations became a thing in API 0.5.  Though
the design problem being solved was mostly "The UK has Sustrans and MOT
routes and existing ref=* can't deal with both", not that "EU routes also
cross through the UK" and "the US has three national networks, at least 70
state networks, over 200 indian networks, and nearly 4000 county networks
for highways, not counting the potential for nearly the same number of the
same for cyclists".  Not a problem yet but wouldn't surprise me, especially
now that a lot of places are moving bicycle infrastructure from "nice to
have if we have money left over" to "no hurry, 20 years ago is fine" thanks
to COVID19, that we might need to make route=bicycle relations have the
same network=* tags as route=road, down the line.


> I explained this to some city planners, newer to OSM than I was, with
> three examples (an Interstate that actually includes a Ferry, clearly not
> part of a single paved way, a bus route traversing many different streets,
> and the MRT (Miss. River Trail) which consists of streets, highways, bike
> paths, ...)
>

There's an Interstate that traverses a ferry??  I knew of two drawbridges
and six traffic signals but a ferry's a new one on me.  But yeah, routes
are frequently highway=* agnostic within the limits of the type of vehicle
that the route is intended for, for the most part (granted, Historic Route
66 has at least one staircase in it now).
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] USFS Roads - name and ref

[Bob Gambrel]

Paul's in depth answer of my question was very helpful. Luckily I am not
concentrating on road/highway routes. I like the concept of:

We should be moving forward towards
all routes being tagged in a route relation so we can phase out route
attributes on ways, freeing those up for *the way's attributes.*

That intuitively makes sense. It seems to me that most routes these days
are really a collection of ways (collected by the route relation). I
explained this to some city planners, newer to OSM than I was, with three
examples (an Interstate that actually includes a Ferry, clearly not part of
a single paved way, a bus route traversing many different streets, and the
MRT (Miss. River Trail) which consists of streets, highways, bike paths,
...)

Keeping the data important to the way on the way and the data relevant to
the route in the relation is perfect. (Well at least very good)
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Rail tagging in US (and North America): operator=* and reporting_marks=*

[stevea]

I point out for those who might not know this:  rail tagging, despite excellent 
efforts by the ORM folks (largely in Germany, I understand) to encourage OSM to 
follow global tagging conventions for ORM, have already quite seriously 
fractured (necessarily) into country-specific tagging standards.  (Or in the 
case of North America, three-country-specific, as while there are differences 
in these three countries, they are relatively minor and do share a lot of 
commonality, quite intentionally, because of the large amount of interchange 
traffic between them).  This country-specificity is in both our tagging and in 
our wiki, and again, quite extensively.

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

Re: [Talk-us] Rail tagging in US (and North America): operator=* and reporting_marks=*

[stevea]

Volker (hello!) discusses that the tag (used in the USA, but not extensively) 
of "reporting_marks" isn't (I paraphrase him a bit) "as international as OSM 
might like it," and proposes presumed-better tag "operator_identifier" (I 
correct a minor spelling error in his posted suggestion).  Volker also mentions 
that this tag seems to be meant for rolling stock, asking on what sorts of OSM 
data the tag will be applied.

Meanwhile, Chuck (hello!) answers that reporting_marks will be applied to ways 
(perhaps not as originally intended to identify the owner / operator of rolling 
stock) but that this use of reporting_marks (or operator_identifier, it isn't 
yet decided) is semantically an excellent OSM syntactic synonym for 
"short_name_of_operator."  (I agree).

I'm of mixed opinion on this.  On the one hand, I agree with Volker that 
"regional tagging" (as in all of North America, as "reporting_marks" are used 
in all three countries) should be discouraged in OSM in favor of more worldwide 
standards / tagging, especially as they already exist (though, 
"operator_identifier" comes up empty in taginfo).  However, as this tag doesn't 
yet exist (in Europe or elsewhere), that diminishes its value, except going 
forward (and there's nothing wrong with that).  And, the tag "reporting_marks" 
(also, "reporting_mark" is used more often, though primarily by one mapper, 
Chuck and I have discussed these two tags should be conflated into 
"reporting_marks" as a single tag) already DOES exist, and it IS an existing 
"regional standard."  So, I'm sitting on the fence, seeing both potential 
solutions have merit.

What I think might work is for North American rail mapping to continue to 
"standardize" on using "reporting_marks" as a tag with a value that effectively 
stands in for "short_name_of_operator" (and we should wiki-document this) and 
others should chime in (please) with what I agree with Chuck is a good use of 
this simple (and widespread:  in all of Canada, USA and Mexico, which 
interchange a lot of rail with each other) "rail standard," 
regional-to-North-America though it is.  If Germany or European and / or Asian 
/ African / South American countries want to something like this, they might 
get started now, using (as I propose North America does) using their own flavor 
of "reporting_marks" (as originally intended to identify rolling stock) as a 
novel and useful method to identify carriers (owners / operators) on OSM ways 
as a synonym for short_name_of_operator.  Then, at some point in the future 
when there can be some global OSM harmonization of these, a proposal to roll 
them all into "operator_identifier" (which suits me just fine) can take place 
as a good idea that will standardize this sort of tagging worldwide.

But in the meantime, I think it a good idea for these to develop locally / 
regionally, with the terminology to both mappers and those familiar with 
railroad terminology (as it is used locally / regionally) being used.  That 
will "root" and better establish these tags, I believe this is (almost?) 
necessary (first).  The globalization / standardization can happen later.  This 
seems a workable approach, though I'd like to hear from others who might posit 
that a "no, let's globalize such tagging immediately" approach is better.

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

Re: [Talk-us] USFS Roads - name and ref

[Paul Johnson]

On Sat, Jun 6, 2020 at 3:46 PM Bob Gambrel  wrote:

> Paul Johnson says
>
> Ultimately consider adding a route relation with network=US:NSFR:Forest
> Name:FH/FR as well so we can finally kill off route tagging on things that
> are not routes.
>
>
> I am not doing any mapping for forest roads, but the above caught my eye.
> I am doing a lot of bike path/trail mapping as well as mapping cycle
> routes. I understand the idea of adding a route relation. What confuses me
> a little above is:
>
>  so we can finally kill off route tagging on things that
> are not routes.
>
> I think you might be saying that there are ways that seem to have a route
> name in the name field and they shouldn't. Instead they should have the way
> be part of a relation that has the name of the route.
>

Route name and route ref.  Pennsylvania and Oregon (at a minimum) have
state highways and state routes, that are not always (particularly on older
roads) the same.  Oregon, for example, has a lot of state highways, *all of
which are numbered*, that have no state route, and most of the 20 or so
oldest routes now traverse multiple different highways, with only routes
created after about 2000 having the same highway and route number
consistently and no plans to retcon.  Right now, practice is to ignore the
ref (even if no route traverses it) that the state actually uses for the
way, and instead ref=* gets tagged with the route that traverses over it
(or leave it off if there is no route).  This isn't orthogonal, *at all*,
with how anything else is tagged.  The ref=* on the way in this case, is
not an attribute that belongs to the way.  It belongs to the route.  I get
*why* it's that way, but the introduction of relations as a basic primitive
10 years ago obsoleted this practice.  We should be moving forward towards
all routes being tagged in a route relation so we can phase out route
attributes on ways, freeing those up for *the way's attributes.*

Please be patient if I am using some wrong terms above. Still learning
> the OSM lingo. I am really just trying to understand the last part of what
> you said. (Especially if you think it might apply to cycle routes too)
>

No problem.  The takeaway is, yes, go ahead and use the existing ref=*
practice on the way, but please also create the route relation if it
doesn't exist yet.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] USFS Roads - name and ref

[Bob Gambrel]

Paul Johnson says

Ultimately consider adding a route relation with network=US:NSFR:Forest
Name:FH/FR as well so we can finally kill off route tagging on things that
are not routes.


I am not doing any mapping for forest roads, but the above caught my eye. I
am doing a lot of bike path/trail mapping as well as mapping cycle routes.
I understand the idea of adding a route relation. What confuses me a little
above is:

 so we can finally kill off route tagging on things that
are not routes.

I think you might be saying that there are ways that seem to have a route
name in the name field and they shouldn't. Instead they should have the way
be part of a relation that has the name of the route.

Please be patient if I am using some wrong terms above. Still learning
the OSM lingo. I am really just trying to understand the last part of what
you said. (Especially if you think it might apply to cycle routes too)
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] USFS Roads - name and ref

[Paul Johnson]

On Sat, Jun 6, 2020 at 3:24 PM brad  wrote:

> On 6/6/20 9:24 AM, Paul Johnson wrote:
>
> On Sat, Jun 6, 2020 at 8:24 AM Mike Thompson  wrote:
>
>> ref:
>> The wiki states that these should be ref=FR + . In
>> practice:
>> * ref:usfs=FS + 
>> * ref=FS + 
>> Most of the changesets that added a "ref:usfs" tag include a very helpful
>> comment that this issue was discussed on the tagging list at sometime in
>> the past and that this was the consensus, e.g. [2].  If this continues to
>> be the consensus, can we change the wiki?
>>
>>
> ref=FS 
>
> Ultimately consider adding a route relation with network=US:NSFR:Forest
> Name:FH/FR as well so we can finally kill off route tagging on things that
> are not routes.  Not sure we really need the FH/FR distinction, however,
> since within the same forest, they're all the same network: The 2 digit
> routes are major, the 3 digits are minor (like parking lots and
> campgrounds) and the 4 digits are usually only usable by log trucks and
> 4x4s.  Trails are another matter.
>
> I prefer ref=FS xxx   too.   I think the tagging discussion that suggested
> ref:usfs was using that for the route relation.
>

 Why would that even be necessary to have a ref:usfs subkey on a route
relation, though?  It's already in the NFSR network.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] USFS Roads - name and ref

[brad]

On 6/6/20 9:24 AM, Paul Johnson wrote:
On Sat, Jun 6, 2020 at 8:24 AM Mike Thompson > wrote:


ref:
The wiki states that these should be ref=FR + . In practice:
* ref:usfs=FS + 
* ref=FS + 
Most of the changesets that added a "ref:usfs" tag include a very
helpful comment that this issue was discussed on the tagging list
at sometime in the past and that this was the consensus, e.g.
[2].  If this continues to be the consensus, can we change the wiki?


ref=FS 

Ultimately consider adding a route relation with 
network=US:NSFR:Forest Name:FH/FR as well so we can finally kill off 
route tagging on things that are not routes.  Not sure we really need 
the FH/FR distinction, however, since within the same forest, they're 
all the same network: The 2 digit routes are major, the 3 digits are 
minor (like parking lots and campgrounds) and the 4 digits are usually 
only usable by log trucks and 4x4s.  Trails are another matter.


I prefer ref=FS xxx   too.   I think the tagging discussion that 
suggested ref:usfs was using that for the route relation.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Off-highway vehicle recreation areas

[stevea]

Tod Fitch  writes:

> I have noticed a couple of off-highway vehicle recreation areas that are 
> tagged with things that seem incorrect to me: As generic parks or as 
> protected areas.

The one near me (way/40263471, Hollister Hills State Vehicular Recreation Area, 
SVRA) I myself have tagged landuse=recreation_ground, but I've been taken to 
task for doing that, as it isn't one of these as our wiki defines it, even 
though the name of it seems like a good match (it isn't).  However, I suffer 
from the same problem, as I don't know what a better tag is, either.  
California State Parks (who manages them) prioritizes them as "recreation 
opportunity," although their web site says "provisions in California law 
require actions to stabilize soils and to provide for healthy wildlife 
populations in OHV recreation areas."  So there are some leisure=nature_reserve 
aspect to these, one could argue (but this is for the restoration of the lands 
for the primary purpose of offering the ORV recreational opportunity).  I agree 
with you that neither leisure=park nor boundary=protected_area are appropriate 
on these sorts of areas.  They are specifically set aside (by the state) as 
areas for rather intensive landuse by off-road vehicles, and they can be quite 
extensive.  Hungry Valley SVRA is about 30 square miles in area, with well over 
100 miles of ORV trails, not something small by any definition.

> Consider the Hungry Valley State Vehicle Recreation Area [1][2][3][4] and the 
> Wildomar OHV Area [5][6].

It appears we are both in California and "suffer" from "how best to tag?" about 
these.  Nor (as is Hungry Valley) is BOTH boundary=protected_area (it isn't) 
and leisure=nature_reserve correct.  Plain and simply, "not."

Hungry Valley even has at least two "inholdings" (areas internal to the SVRA) 
which ARE boundary=protected_areas, the Freeman Canyon and Gorman Cultural 
Preserves.  Oddly, these are tagged boundary=national_park, which isn't quite 
correct, either.  Located between two major earthquake faults, Hungry Valley is 
quite interesting geologically.

> My problem is that I can’t tell from the wiki and taginfo what might more 
> appropriate or more accepted tagging. It seems there is tagging for tracks 
> used for motocross. And people have used access tags for ATVs. But I don't 
> see a documented tagging for an area that contains a trail system for use by 
> multiple types of off-highway vehicles. I have some thoughts on what might be 
> appropriate, but would rather hear from others.

I'm coming up empty of "what to do?" but I am finding quite a few of these with 
quite-poorly tagged boundaries.  Surely, OSM can do better than this, but Tod 
asks an excellent question:  "with what tags, please?"

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

Re: [OSM-talk-fr] Institut d'éducation motrice

[Yves P.]

> Le type:FR:FINESS=192 n'est pas renseigné sur 
> https://wiki.openstreetmap.org/wiki/FR:Comment_cartographier_un_(sant%C3%A9) 
> 
> et je n'ai aucune idée de ce que cela représente. C'est comme les IME / ITEP 
> ???
Oui, avec le type FINESS pour faire la différence.

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

[OSM-talk-fr] Institut d'éducation motrice

[Georges Dutreix via Talk-fr]

Bonjour,

Quelqu'un a-t-il une idée pour étiqueter cette structure :
http://finess.sante.gouv.fr/fininter/jsp/actionDetailEtablissement.do?noFiness=370104457
https://www.openstreetmap.org/way/803460696

Le type:FR:FINESS=192 n'est pas renseigné sur 
https://wiki.openstreetmap.org/wiki/FR:Comment_cartographier_un_(sant%C3%A9)
et je n'ai aucune idée de ce que cela représente. C'est comme les IME / 
ITEP ???


merci
georges







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

Re: [Talk-us] Off-highway vehicle recreation areas

[brad]

Good question.   At first glance I don't think Leisure=park is wrong.  
The wiki is characteristically narrow since it says that it is green.   
leisure=sports_center or landuse=recreation_ground would be better.   
leisure=pitch doesn't seem right even thought the sport=motocross wiki 
page references it.   These OHV areas are typically more than a simple 
motocross track. leisure=nature_reserve sure doesn't seem right!


On 6/5/20 4:55 PM, Tod Fitch wrote:

I have noticed a couple of off-highway vehicle recreation areas that are tagged 
with things that seem incorrect to me: As generic parks or as protected areas.

Consider the Hungry Valley State Vehicle Recreation Area [1][2][3][4] and the 
Wildomar OHV Area [5][6].

My problem is that I can’t tell from the wiki and taginfo what might more 
appropriate or more accepted tagging. It seems there is tagging for tracks used 
for motocross. And people have used access tags for ATVs. But I don't see a 
documented tagging for an area that contains a trail system for use by multiple 
types of off-highway vehicles. I have some thoughts on what might be 
appropriate, but would rather hear from others.

Thanks!

--Tod

[1] 
https://www.riderplanet-usa.com/atv/trails/info/california_10003/ride_413b.htm
[2] https://www.openstreetmap.org/relation/6179378
[3] https://www.openstreetmap.org/way/367714413
[4] https://www.openstreetmap.org/way/367714414
[5] 
https://www.riderplanet-usa.com/ATV/trails/info/california_03947/ride_7684.htm
[6] https://www.openstreetmap.org/way/248540505


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


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

Re: [Talk-it] Completare le mappe e Wikipedia

[Laurentius]

On mer, 2020-06-03 at 22:23 +0200, Maurizio Napolitano wrote:
> Il progetto è anche un po'  "vecchietto" e nel frattempo è stato
> 
> superato dall'integrazione con wikidata.

In tema di integrazione con Wikidata, è comodo anche questo, che
agevola il collegamento dagli oggetti di OpenStreetMap agli elementi di
Wikidata:
https://osm.wikidata.link/

Lorenzo


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

Re: [OSM-talk] river - stream

[Dave F via talk]

Do you have an example?

Whether it's a bridge or tunnel is fairly easily defined by determining 
which is taking the load.
If a tunnel's structure was removed, would whitewater's above it 
collapse? If 'yes' then it's a tunnel.


DaveF


On 06/06/2020 16:48, Martin Koppenhoefer wrote:


sent from a phone


On 5. Jun 2020, at 15:44, Dave F via talk  wrote:

There can't be both a tunnel and bridge. It's one or the other. This goes for 
all scenarios, including roads.


you can have both, but it is rare...
and it depends on your definitions of course  (e.g. you might call it an 
enclosed bridge or sth. like this). In engineering standards, tunnels are not 
only dug structures but also completely enclosed linear ways with certain 
length (e.g. in Germany it’s from 80m onwards according to concrete standards, 
IIRR), which can also in exceptional cases lead over a bridge.

Cheers Martin





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

Re: [OSM-talk] river - stream

[Martin Koppenhoefer]

sent from a phone

> On 5. Jun 2020, at 15:44, Dave F via talk  wrote:
> 
> There can't be both a tunnel and bridge. It's one or the other. This goes for 
> all scenarios, including roads.


you can have both, but it is rare...
and it depends on your definitions of course  (e.g. you might call it an 
enclosed bridge or sth. like this). In engineering standards, tunnels are not 
only dug structures but also completely enclosed linear ways with certain 
length (e.g. in Germany it’s from 80m onwards according to concrete standards, 
IIRR), which can also in exceptional cases lead over a bridge.

Cheers Martin 



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

Re: [OSM-talk-fr] Attributions manquantes sur Mon GR !

[Vincent Bergeot]

Le 06/06/2020 à 16:21, Georges Dutreix via Talk-fr a écrit :

Bonjour,

Est-ce sûr ?
Si ce sont des données OSM, elles ne sont pas récentes.
Je viens de tester, ils n'affichent pas un bâtiment qui a été touché 
la dernière fois il y a 8 ans dans OSM.


concernant l'affichage par défaut, je ne peux pas dire (et je n'ai pas 
cherché à savoir)


Cependant lorsque je choisis OpenStreetMap comme fond de carte :

 * cela va chercher les tuiles sur les serveurs de la fondation (F12
   sur firefox permet de voir dans l'onglet réseau la provenance des
   tuiles quand on joue à zoomer et dézoomer)
 * et donc je m'attends à ce moment à trouver l'attribution

Pour l'affichage par défaut cela renvoie sur des serveurs esri, je n'ai 
pas cherché plus que cela








Le 05/06/2020 à 12:22, Vincent Bergeot a écrit :

Le 04/06/2020 à 21:01, Yves P. a écrit :

Bonsoir,

https://www.mongr.fr permet d'afficher des itinéraires avec 
différents fonds de plan, dont OSM 


Mais pas de trace du mot OpenStreetMap dans leur site, et encore 
moins d'attributions 


prise de contact faite par le formulaire







__
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



--
Vincent Bergeot

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

[Talk-it] Aggiornamento civici comune di Fiè allo Sciliar BZ

[Lorenzo Mastrogiacomi]

Ciao.

Ho ricevuto una richiesta di aggiornamento dei civici per il comune in
oggetto (inviata a me perché sono l'ultimo che li ha modificati visto
che un paio di anni fa ho convertito gli apostrofi in accenti).

I civici sono stati importati nel 2014 e l'import dovrebbe essere
quello documentato qui:
https://wiki.openstreetmap.org/wiki/AltoAdige_-_S%C3%BCdtirol/OpenGisData_HouseNumber_Import2

C'è per caso qualche attività in corso oppure è già stato fatto
qualcosa per altri comuni della provincia?

Riporto la richiesta:
Buongiorno,


visto che Lei ha modificato l’ultima volta i numeri civici nella comune
di Fiè allo Sciliar volevo chiedere se sarebbe possible di aggiornarli
a quelli nuovi.


I numeri civici nuovi sono disponibile e possono essere esportati da: 
http://geocatalogo.retecivica.bz.it/geokatalog/#! 1. Selezionare Dati:
numeri civici 2. Download -> Modalità di selezione: luogo 3. Download
-> luogo: Fie’ allo Sciliar, (Comune Amministrativo), comune di Fie’
allo Sciliar 4. Download -> Dati vettoriali: geoJSON 5. Download
->Scarica


Se Lei mi potrebbe dare anche il suo indirizzo E-Mail poterei inoltrare
il suo contatto anche alle comune di Fiè allo Sciliar per eventuali
ulteriori dettagli.


Cordiali Saluti, Thomas Mair Vigili Volontari Aica di Fié



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

Re: [Talk-us] USFS Roads - name and ref

[Paul Johnson]

On Sat, Jun 6, 2020 at 8:24 AM Mike Thompson  wrote:

> ref:
> The wiki states that these should be ref=FR + . In
> practice:
> * ref:usfs=FS + 
> * ref=FS + 
> Most of the changesets that added a "ref:usfs" tag include a very helpful
> comment that this issue was discussed on the tagging list at sometime in
> the past and that this was the consensus, e.g. [2].  If this continues to
> be the consensus, can we change the wiki?
>
>
ref=FS 

Ultimately consider adding a route relation with network=US:NSFR:Forest
Name:FH/FR as well so we can finally kill off route tagging on things that
are not routes.  Not sure we really need the FH/FR distinction, however,
since within the same forest, they're all the same network: The 2 digit
routes are major, the 3 digits are minor (like parking lots and
campgrounds) and the 4 digits are usually only usable by log trucks and
4x4s.  Trails are another matter.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] USFS Roads - name and ref

[Max Erickson]

Abbreviations are predominant in US highway refs, so I think that it is
fine to use one in USFS road refs.

At some point in time I had used ref=USFS xxx but changed stuff that I had
edited to ref=FS xxx. The usage of FS in Michigan is largely a product of
either my editing directly or my discussion with other mappers (and looking
at Overpass Turbo and Taginfo, something like 45% of all refs with the
string "FS" in them...).

I don't remember really, but I think I started with USFS because it was
nearly entirely unambiguous, and then I switched because the usage of FS
was more common.

ref:usfs=FS looks wrong to me, if usfs is in the key, then it doesn't
belong repeated in the value (unless there's 2 reference systems in use,
which there are, https://en.wikipedia.org/wiki/Forest_Highway is not the
same thing as the Forest Service logging roads)).

The use of ref:usfs also has the problem that it hides useful data on
general purpose maps that don't specifically use it.

If ref is to be used, I expect you won't arrive at any real consensus about
what to use as a prefix, because it's easy to have an opinion about it
(bikeshedding basically). I guess if enough people pick one we might get
close.


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

Re: [OSM-talk-fr] Attributions manquantes sur Mon GR !

[Georges Dutreix via Talk-fr]

Bonjour,

Est-ce sûr ?
Si ce sont des données OSM, elles ne sont pas récentes.
Je viens de tester, ils n'affichent pas un bâtiment qui a été touché la 
dernière fois il y a 8 ans dans OSM.





Le 05/06/2020 à 12:22, Vincent Bergeot a écrit :

Le 04/06/2020 à 21:01, Yves P. a écrit :

Bonsoir,

https://www.mongr.fr permet d'afficher des itinéraires avec 
différents fonds de plan, dont OSM 


Mais pas de trace du mot OpenStreetMap dans leur site, et encore 
moins d'attributions 


prise de contact faite par le formulaire







__
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: [Talk-it] bike lanes su openstreetmap

[Volker Schmidt]

Grazie, Fabio, per gli esempi extra-Padovani.
Avevo visto la nota su "Advisory". Il problema è che le nuove corsie non lo
sono per motivo dell'obbligo per bici di andare sempre sulla parte più a
destra della strada. (non ricordo più la dicitura esatta, ma la dicitura è
diversa di quella per il traffico motorizzato).
Se avete altre foto di corsie nuove fatemi sapere, per favore.

On Sat, 6 Jun 2020, 11:40 Fabio Bettani,  wrote:

> Voglio precisare che ho già visto (dal vivo o in foto) diverse bike lane
> realizzate secondo questa nuova norma in varie città d'Italia (Milano,
> Genova, Roma, e in progetto a Bologna, dove già però ce n'erano alcune
> pre-Covid), e quella pericolosità al momento l'ho vista solo a Padova.
> A Genova, per esempio, si vede chiaramente la distanza tra pista e
> parcheggio:
> https://www.ilsecoloxix.it/genova/2020/05/17/news/mascherina-obbligatoria-in-citta-spiagge-vietato-prendere-il-sole-1.38856152
> Insomma, non direi che la pericolosità è una caratteristica intrinseca
> delle nuove bike lane.
>
> Resta vero, come dice Volker, che la differenza tra una bike lane e una
> ciclabile dev'essere tradotta bene in mappa.
> Su questo la wiki di OSM mi sembra chiara:
>
> "Some countries have two different types of cycle lanes: One with a strict
> segregation that is reserved exclusively to cyclists* and one with a soft
> segregation, usually a dashed line**. To distinguish between these two
> types of cycle lanes, the cycle lane can additionally be tagged with
> cycleway:lane=exclusive or cycleway:lane=advisory".
> La prima (*) sembrerebbe corrispondere alla pista ciclabile lato strada,
> la seconda (**) alla bike lane.
>
> Occhio, però, perché sul terreno la situazione può cambiare ogni 30 metri.
> Per esempio, guardando corso Buenos Aires su
> https://www.milanocam.it/BuenosAires_1/, osservando il lato destro, direi
> che la pista è inizialmente una cycleway:lane=exclusive (linea continua),
> poi diventa una cycleway:lane=advisory (linea tratteggiata) e poi, dopo il
> semaforo, si trasforma in una highway=cicleway nel tratto in cui devia
> dalla strada principale per passare a destra dei parcheggi...
> Anche in via Carracci a Bologna (di cui non ho foto: è una realizzazione
> degli ultimi mesi) si alternano tutte queste caratteristiche nel giro di
> poche decine di metri.
>
> --
> Fabio
>
>
> Il giorno ven 5 giu 2020 alle ore 18:31 Volker Schmidt 
> ha scritto:
>
>> Sono risultato del  recente decreto legge 20200520
>>  (art.
>> 229)
>> Testo nel DL:
>>
>> " Corsia ciclabile: parte longitudinale della carreggiata, posta a
>> destra, delimitata mediante una striscia bianca discontinua, valicabile e
>> ad uso promiscuo, idonea a permettere la circolazione sulle strade
>> urbane dei velocipedi nello stesso senso di marcia degli altri veicoli e
>> contraddistinta dal simbolo del velocipede. La Corsia ciclabile è parte
>> della ordinaria corsia veicolare, con destinazione alla circolazione dei
>> velocipedi"
>>
>> Volker
>>
>> On Fri, 5 Jun 2020 at 12:32, Cascafico Giovanni 
>> wrote:
>>
>>> Ma sono il risultato di una pianificazione affrettata dall'emergenza
>>> covid? Oppure un progetto calato dall'alto senza consultare l'utilizzatore?
>>>
>>> Il ven 5 giu 2020, 10:23 Volker Schmidt  ha scritto:
>>>
 Commentio off topic per OSM:
 Penso queste mini corsie modello Padova siano veramente peggio di
 niente. Danno uno falso invito ai ciclisti di non tenere la distanza di
 sicurezza dalle auto parcheggiate (pericolo di dooring) e invitano gli
 automobilisti in movimento di no rispettare la dovuta distanza laterale
 dalle bici.

 On Fri, 5 Jun 2020, 09:33 emmexx,  wrote:

> On 6/4/20 11:02 PM, Volker Schmidt wrote:
> >
> > Il problema che vedo, è che se noi seguiamo la prassi tedesca da
> > utilizzare cycleway=lane per "nuove" e tradizionali, perdiamo il
> fatto,
> > importante per un router per bici, che le nuove sono notevolmente
> meno
> > sicure per le bici delle tradizionali.
>
> Comunque per il ciclista sono meglio queste di nulla. Lascerei comunque
> che i routing scelgano prioritariamente queste corsie ciclabili. Magari
> in Germania o altrove ci sono valide alternative, in Italia no.
>
> Si può aggiungere un tag ad hoc.
>
> [OT] Comunque per chiarire come utilizzare queste corsie, non è
> consentito ad altri veicoli di utilizzarle a caso ma di attraversarle,
> ad esempio per poter parcheggiare nella zona di sosta che si trova
> accanto alla corsia.
> Si vede bene la cosa nella webcam di Milanocam linkata dall'OP, sul
> lato
> destro. Ad un primo tratto di corsia ciclabile "tradizionale" con linee
> bianca e gialla continue, segue un tratto con linee tratteggiate dove
> sono presenti parcheggi e altri servizi a cui le auto devono poter
> accedere (al momento).
>
> ciao
>

[Talk-us] USFS Roads - name and ref

[Mike Thompson]

Hello,

This question concerns ways maintained/operated by the US Forest Service
(USFS) and signed with vertical  markers, e.g. [0]. These signs typically
display a three digit number, with an optional decimal point (dot/period)
followed by another number and/or a letter.

Name:
The wiki [1] states that these should name=Forest Road + .
In practice, either from other mappers, or from the original TIGER import,
I have seen:
* just what is on the sign
* Fire Road + 
* FR + 
* Forest Development Road + 
* FDR + 
* Forest Service Road + 
* FS + 
* United States Forest Service Road + 
* ...(many more variations)
Does the wiki reflect the consensus of the US mapper community (which I am
part of) on how these should be named, or should they be named in some
other manner? To complicated matters, it seems that the Forest Service
itself is not consistent and the exact wording of a name will depend on
what brochure, map board, or dataset from the Forest Service you are
looking at. I don't really have a preference, except to say 1) Many of the
above examples include abbreviations, which OSM generally refrains from,
and 2) I think we should be consistent.

ref:
The wiki states that these should be ref=FR + . In
practice:
* ref:usfs=FS + 
* ref=FS + 
Most of the changesets that added a "ref:usfs" tag include a very helpful
comment that this issue was discussed on the tagging list at sometime in
the past and that this was the consensus, e.g. [2].  If this continues to
be the consensus, can we change the wiki?


Mike




[0] Left sign in this image:
https://wiki.openstreetmap.org/wiki/File:US_Forest_Service_Vertical_Marker.png
[1]
wiki.openstreetmap.org/wiki/United_States_roads_tagging#Tagging_Forest_Roads
[2] https://www.openstreetmap.org/changeset/73470389
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-it] relazioni tra relazioni ( raggruppare le alte via delle dolomiti)

[mbranco2]

Ciao Andrea,

abbiamo parlato varie volte delle relazioni padre (super relazioni)  e del
tipo di relazioni type=network.

Ripeto anche qui che secondo me non è il caso di farle (perché non fare
allora relazioni per le alte vie della Valle d'Aosta, o delle Alpi
Orientali / Occidentali, o europee...)

Lo spiega molto bene questa autorevole pagina wiki [1], autorevole perché
scritta da "quelli che hanno inventato le relazioni"  :-)

[1]
https://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories



Il giorno gio 4 giu 2020 alle ore 18:50 Andrea Manica <
andrea.man...@gmail.com> ha scritto:

> Ciao a tutti ,chiedo un supporto
> ho completato l'inserimento di questa alta via delle dolomiti (la numero
> 9):
>
> https://hiking.waymarkedtrails.org/#route?id=11094256=11!46.5615!12.0426
> vi chiederei se manca qualcosa (o se ci sono degli errori) nella creazione
> della relazione.
> ma principalmente vi chiederei se è possibile creare una relazione padre
> che contiene tutte le altevia delle Dolomiti.
> qui la prima https://hiking.waymarkedtrails.org/#route?id=177743 etc.
> qualcosa come Rete delle alteVia delle Dolomiti che le racchiuda tutte e
> 10 (o almeno le 7 descritte attualmente)
>
> Grazie mille
> Andrea
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[OSM-talk-be] Mappen van fietssnelwegen, mapping of cycling highways

[Jo]

English below

Hallo,

Het mappen van fietssnelwegen op OSM is een beetje een uitdaging.
Persoonlijk heb ik graag routerelaties die een continue reeks van ways
zijn, maar de fietssnelwegen liggen er nagenoeg nergens over hun volle
lengte. Ik vind het interessant om de geplande fietssnelwegen nu al op de
kaart te kunnen zetten, maar anderzijds wil ik ook aangeven wat de
alternatieve omleidingen zijn, aangenaam fietsbaar zonder al teveel omweg.

Ik meen dat ik nu een goede oplossing gevonden heb: superroute-relaties.

Hiermee kunnen we de deeltrajecten in route-relaties stoppen, al dan niet
met proposed (zodat ze in stippellijn op de cyclemap getoond worden).

Deze route-relaties kunnen dan in superroutes worden opgenomen. Hier en
daar is het ook zo dat fietssnelwegen elkaar overlappen. F2 en F44, F3 en
F8. Ook voor deze gemeenschappelijke stukken zijn afgesplitste
route-relaties een goede oplossing.

josm-latest laat sinds een dikke maand toe om te zien dat
superroute-relaties continu zijn. (als de laatste way in de vorige route
zijn laatste node gemeenschappelijk heeft met de eerste way zijn eerste
node).

Ik ben gaandeweg alles aan het omzetten. F3, F8, F24, F25, F26 en nog een
paar zijn al klaar. Gisteren F2 gedaan, nu ben ik bezig met F44.

Dit is een goede query om ze te downloaden in JOSM:

[out:xml][timeout:190][bbox:{{bbox}}];
(
  nwr["cycle_network"="cycle_highway"];
);
(._;>;);
out meta;

(expert mode activeren en dan 2e tab, download from Overpass)

Hi,

Mapping cycling highways on OSM is a bit of a challenge. Personally I like
for route relations to have continuous sequences of ways, but there are
very few cycle highways that are already realised over their full length. I
think it's interesting to already include the planned cycling highways, but
their practical use for routing is negligent. So it seems important to me
to also include how to get from A to B today, following ways that are nice
to ride along with overly big detours.

I think I found a good solution to have my cookie and eat it too:
superroute relations.

This allows us to put the different parts in separate route relations.
Those composed of highway=proposed/proposed=cycleway tagged with
state=proposed, so they are shown in a dashed line on the cyclemap
rendering.

Then those route relations can be used to compose superroute relations. It
also happens that cycle highways overlap, f.e.  F2 en F44 in Gent, F3 en F8
in Leuven. Also for these parts it's interesting to split them off in
separate route relations.

For about a month, maybe 2 now, josm-latest also shows continuity for
superroute relations.

This is a good query to download them in JOSM:

[out:xml][timeout:190][bbox:{{bbox}}];
(
  nwr["cycle_network"="cycle_highway"];
);
(._;>;);
out meta;

(activate expert mode and then 2nd tab, download from Overpass)

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

Re: [Talk-it] bike lanes su openstreetmap

[Fabio Bettani]

Voglio precisare che ho già visto (dal vivo o in foto) diverse bike lane
realizzate secondo questa nuova norma in varie città d'Italia (Milano,
Genova, Roma, e in progetto a Bologna, dove già però ce n'erano alcune
pre-Covid), e quella pericolosità al momento l'ho vista solo a Padova.
A Genova, per esempio, si vede chiaramente la distanza tra pista e
parcheggio:
https://www.ilsecoloxix.it/genova/2020/05/17/news/mascherina-obbligatoria-in-citta-spiagge-vietato-prendere-il-sole-1.38856152
Insomma, non direi che la pericolosità è una caratteristica intrinseca
delle nuove bike lane.

Resta vero, come dice Volker, che la differenza tra una bike lane e una
ciclabile dev'essere tradotta bene in mappa.
Su questo la wiki di OSM mi sembra chiara:

"Some countries have two different types of cycle lanes: One with a strict
segregation that is reserved exclusively to cyclists* and one with a soft
segregation, usually a dashed line**. To distinguish between these two
types of cycle lanes, the cycle lane can additionally be tagged with
cycleway:lane=exclusive or cycleway:lane=advisory".
La prima (*) sembrerebbe corrispondere alla pista ciclabile lato strada, la
seconda (**) alla bike lane.

Occhio, però, perché sul terreno la situazione può cambiare ogni 30 metri.
Per esempio, guardando corso Buenos Aires su
https://www.milanocam.it/BuenosAires_1/, osservando il lato destro, direi
che la pista è inizialmente una cycleway:lane=exclusive (linea continua),
poi diventa una cycleway:lane=advisory (linea tratteggiata) e poi, dopo il
semaforo, si trasforma in una highway=cicleway nel tratto in cui devia
dalla strada principale per passare a destra dei parcheggi...
Anche in via Carracci a Bologna (di cui non ho foto: è una realizzazione
degli ultimi mesi) si alternano tutte queste caratteristiche nel giro di
poche decine di metri.

--
Fabio


Il giorno ven 5 giu 2020 alle ore 18:31 Volker Schmidt 
ha scritto:

> Sono risultato del  recente decreto legge 20200520
>  (art.
> 229)
> Testo nel DL:
>
> " Corsia ciclabile: parte longitudinale della carreggiata, posta a
> destra, delimitata mediante una striscia bianca discontinua, valicabile e
> ad uso promiscuo, idonea a permettere la circolazione sulle strade urbane
> dei velocipedi nello stesso senso di marcia degli altri veicoli e
> contraddistinta dal simbolo del velocipede. La Corsia ciclabile è parte
> della ordinaria corsia veicolare, con destinazione alla circolazione dei
> velocipedi"
>
> Volker
>
> On Fri, 5 Jun 2020 at 12:32, Cascafico Giovanni 
> wrote:
>
>> Ma sono il risultato di una pianificazione affrettata dall'emergenza
>> covid? Oppure un progetto calato dall'alto senza consultare l'utilizzatore?
>>
>> Il ven 5 giu 2020, 10:23 Volker Schmidt  ha scritto:
>>
>>> Commentio off topic per OSM:
>>> Penso queste mini corsie modello Padova siano veramente peggio di
>>> niente. Danno uno falso invito ai ciclisti di non tenere la distanza di
>>> sicurezza dalle auto parcheggiate (pericolo di dooring) e invitano gli
>>> automobilisti in movimento di no rispettare la dovuta distanza laterale
>>> dalle bici.
>>>
>>> On Fri, 5 Jun 2020, 09:33 emmexx,  wrote:
>>>
 On 6/4/20 11:02 PM, Volker Schmidt wrote:
 >
 > Il problema che vedo, è che se noi seguiamo la prassi tedesca da
 > utilizzare cycleway=lane per "nuove" e tradizionali, perdiamo il
 fatto,
 > importante per un router per bici, che le nuove sono notevolmente meno
 > sicure per le bici delle tradizionali.

 Comunque per il ciclista sono meglio queste di nulla. Lascerei comunque
 che i routing scelgano prioritariamente queste corsie ciclabili. Magari
 in Germania o altrove ci sono valide alternative, in Italia no.

 Si può aggiungere un tag ad hoc.

 [OT] Comunque per chiarire come utilizzare queste corsie, non è
 consentito ad altri veicoli di utilizzarle a caso ma di attraversarle,
 ad esempio per poter parcheggiare nella zona di sosta che si trova
 accanto alla corsia.
 Si vede bene la cosa nella webcam di Milanocam linkata dall'OP, sul lato
 destro. Ad un primo tratto di corsia ciclabile "tradizionale" con linee
 bianca e gialla continue, segue un tratto con linee tratteggiate dove
 sono presenti parcheggi e altri servizi a cui le auto devono poter
 accedere (al momento).

 ciao
 maxx

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

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

[OSM-talk-ie] OpenStreetMap Ireland Annual General Meeting

[Ciarán Staunton]

Date for your diary: 27th June 2020 will be the osmIRL annual general
meeting.


The meeting will be virtual, since the Covid-19 threat will still prevent
gatherings of more than 6 people on that date. Subscribers will get a
formal invitation shortly, but other community members are welcome to view
and participate in parts of the meeting. Full details to follow.


Virus-free.
www.avg.com

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