[Tagging] what is the "temp" tag?

[Frederik Ramm]

Hi,

https://taginfo.openstreetmap.org/keys/temp#values

any guesses as to what this might mean?

I stumbled across it when reverting some vandalism on
https://www.openstreetmap.org/way/784166844 but that street has been
split so many times by people adding turn restrictions that the "person
creating v1 of something" is just the person who split something and if
I asked them what they meant by temp=tag they'll probably just shrug.

Bye
Frederik

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

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

Re: [Tagging] what is the "temp" tag?

[Alessandro Sarretta]

I'm just guessing, and I try with a sort of placeholder for saying that 
some tag is "temporary"... even if this sounds not really useful :-)


Ale

On 05/08/20 10:41, Frederik Ramm wrote:

Hi,

https://taginfo.openstreetmap.org/keys/temp#values

any guesses as to what this might mean?

I stumbled across it when reverting some vandalism on
https://www.openstreetmap.org/way/784166844 but that street has been
split so many times by people adding turn restrictions that the "person
creating v1 of something" is just the person who split something and if
I asked them what they meant by temp=tag they'll probably just shrug.

Bye
Frederik



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

Re: [Tagging] Rio de la Plata edit war

[Alan Mackie]

On Wed, 5 Aug 2020 at 01:34,  wrote:

>
>
> - Mensaje original -
> > De: "Joseph Eisenberg" 
> > Para: "Tag discussion, strategy and related tools" <
> tagging@openstreetmap.org>
> > Enviados: Martes, 4 de Agosto 2020 16:56:31
> > Asunto: Re: [Tagging] Rio de la Plata edit war
>
> > The graphics in this document are mainly models of current flow, rather
> than
> > actual measurements, but it is mentioned that the average current flow,
> > neglecting wind, is only 0.1 m/s in the Rio de la Plata. Since winds of
> 5 m/s
> > are routine according to the paper, the currents vary strongly based on
> winds
> > and tides.
> > See for example the figura on pages 26 to 37 which show the modeled
> variation
> > with different wind direction. I don't see a modeling of the affect of
> tides -
> > this appears to be the average current over the tidal cycle? But I admit
> I have
> > not visited this area.
>
> Sure its a model, but the model is validated by drifting bouys, as you can
> check in page 37.
> i just translated here.
> "The drift buoy trajectories launched in the summer of 2003 and reported
> by Piola et al (2003) showed, in consistency with the modeled solutions,
> relatively low average speeds (20-30 cm / s) in the middle part of the
> river and higher speeds in the outer sector, mainly towards the Uruguayan
> coast, where they exceeded 60 cm / s (Fig. 33)."
>
> > My main objection is the inclusion of Bahia Samborombon in the estuary.
> The
> > charts and satellite images show very little influence from river water
> in that
> > area, as well as in the section of coast east of Montevideo.
>
> You are misreading the imagery. What generaly available imagery shows in
> this area is a change of colour, which is dark brown to the NW, and more
> clear to the SE. This is caused for the change of turbidity, located near
> the 5m isobath.
>
> The figures in both the document linked by muralito and the one previously
linked by Andy seem to show that flow outside of the line from Montevideo
to Punta Piedras is largely dominated by wind and ocean conditions and not
by the river flow. Visible sediment in the water was discounted earlier for
defining outer limits as it often persists far into areas clearly
considered ocean (see Christoph's example off the coast of China), but
photos showing the sediment also show it starting to disperse after this
point. Some wind directions seem to dominate the flow even further
upstream.

As this discussion continues I think this looks more and more like a river
that drains into a sheltered bay than one that drains directly into the
ocean.

> – Joseph Eisenberg
>
> > On Tue, Aug 4, 2020 at 12:42 PM < mural...@montevideo.com.uy > wrote:
>
> >> - Mensaje original -
> >> > De: "Kevin Kenny" < kevin.b.ke...@gmail.com >
> >> > Para: "Tag discussion, strategy and related tools" <
> tagging@openstreetmap.org >
> >> > Enviados: Martes, 4 de Agosto 2020 16:28:55
> >> > Asunto: Re: [Tagging] Rio de la Plata edit war
>
> >> > On Tue, Aug 4, 2020 at 3:18 PM Joseph Eisenberg <
> joseph.eisenb...@gmail.com >
> >> > wrote:
>
> >> >> These rules would exclude the lower Rio De La Plata and the lower
> part of the
> >> >> mouth of the Saint Lawrence river, as well as other wide estuaries
> where winds
> >> >> and tides have more influence on surface water flow than does the
> discharge of
> >> >> the river. It would not prevent mapping the Hudson mouth at the
> southern tip of
> >> >> Manhattan, because the flow is strong all the way to New York
> Harbor, if I
> >> >> understand correctly.
>
> >> > The Hudson definitely reverses flow. One of its names among the First
> Peoples
> >> > translates to 'the river flows both ways.' The division in the flow
> lies less
> >> > in the fraction of the tidal cycle than the speed of the current. It
> flows
> >> > 'upstream' for half the time, 'downstream' for half, but the
> downstream current
> >> > is considerably swifter.
>
> >> Rio de la Plata would not be excluded, as you can read in the document
> [8] i
> >> linked in my first mail, for example, see some graphics of the flow of
> the
> >> river in page 25.
> >> [8] DINAMA. Salinidad
> >>
> https://www.dinama.gub.uy/oan/documentos/uploads/2016/12/patrones_circulacion.pdf
>
> >> Regaards,
> >> M.
>
> >>
> ---
>
> >> Con el nuevo beneficio fiscal, tu facturación electrónica puede ser sin
> costo.
>
> >> Informate si aplicás aquí.
>
> >> mvdfactura.uy
>
> >>
> ---
>
> >> ___
> >> Tagging mailing list
> >> Tagging@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/tagging
>
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > h

Re: [Tagging] what is the "temp" tag?

[Jarek Piórkowski]

On Wed, 5 Aug 2020 at 04:41, Frederik Ramm  wrote:
> https://taginfo.openstreetmap.org/keys/temp#values
>
> any guesses as to what this might mean?
>
> I stumbled across it when reverting some vandalism on
> https://www.openstreetmap.org/way/784166844 but that street has been
> split so many times by people adding turn restrictions that the "person
> creating v1 of something" is just the person who split something and if
> I asked them what they meant by temp=tag they'll probably just shrug.

Going back in edit history, the earliest I found was
https://www.openstreetmap.org/way/213444942/history v1 from
https://www.openstreetmap.org/changeset/15525007 in 2013. Doubt you'll
get answers for that, especially considering the edit seemed wonky
anyway with overlapping highways. I agree it's probably some
"temporary tag".

Some of the other values _could_ be temperatures, but doubt it's
anything widely useful.

--Jarek

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

[Tagging] Apparent conflicting/redundant access tags

[Mike Thompson]

Hello,

If:
access=no
foot=yes

Does this mean that all access except foot travel is prohibited, or is it
an error?

If:
access=yes
bicycle=no

Does this mean that all access except bicycle travel is allowed, or is an
error?

Here is one example of the first case:
https://www.openstreetmap.org/way/834296397

Mike
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Apparent conflicting/redundant access tags

[Paul Johnson]

On Wed, Aug 5, 2020 at 3:45 PM Mike Thompson  wrote:

> Hello,
>
> If:
> access=no
> foot=yes
>
> Does this mean that all access except foot travel is prohibited, or is it
> an error?
>

Correct, only pedestrians are allowed.


> If:
> access=yes
> bicycle=no
>
> Does this mean that all access except bicycle travel is allowed, or is an
> error?
>

Correct, everything but bicycles allowed.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Apparent conflicting/redundant access tags

[Mike Thompson]

On Wed, Aug 5, 2020 at 2:59 PM Tod Fitch  wrote:

> My reading of the wiki [1] indicates that the more specific tag overrides
> the less specific tag.
>
So,
access=yes
foot=yes

would then be redundant.  I don't have an example, but I have seen that too.



> And the transport mode section [2] of that has examples very much like
> those in your question.
>
> So:
> access=no
> foot=yes
>
> Means that all access other than foot is prohibited.
>
> And:
> access=yes
> bicycle=no
>
> Means you can walk, drive or ride a horse, etc. but you can’t bicycle.
>
Makes sense, as long as that is what the consensus is.

However, access=yes is a pretty broad statement.  There may be modes of
transport not yet contemplated (or which the mapper, and even the land
manager is not aware of) which in the future will be prohibited.


> For what its worth, I just had a question along this same line for a trail
> in a local wilderness park that I edited a year or so ago. All I did was
> split the way and keep the existing tagging (which I agreed with). But
> apparently the Strava app had a problem with the tagging (access=no,
> foot=designated, bicycle=designated), so I guess my reading of the wiki
> doesn’t match all data consumers implementations.
>
Even the default renderer treats it different if access=no, and one or more
other modes =yes.  Not that we should tag for the renderer, but it
indicates that perhaps the maintainers of the default rendering style may
not (yet) have incorporated this understanding.

Mike
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Apparent conflicting/redundant access tags

[Mateusz Konieczny via Tagging]

Aug 5, 2020, 22:44 by miketh...@gmail.com:

> Hello,
>
> If:
> access=no 
> foot=yes 
>
> Does this mean that all access except foot travel is prohibited
>
yes

> , or is it an error? 
>
No, it is a correct tagging - though usually there is a better way to achieve 
this
(highway=footway / highway=pedestrian - maybe with bicycle=no)

> If:
> access=yes   
> bicycle=no   
>
> Does this mean that all access except bicycle travel is allowed
>
Yes

> , or is an error?
>
No, see OSM Wiki page about access (if anything is unclear let us know what is 
unclear).

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

Re: [Tagging] Apparent conflicting/redundant access tags

[Mateusz Konieczny via Tagging]

Aug 5, 2020, 22:58 by t...@fitchfamily.org:

> so I guess my reading of the wiki doesn’t match all data consumers 
> implementations.
>
Yes, in many cases support is limited. Routers are usually dealing it with 
fairly well,
but for example iD editor is missing support for example for vehicle tag,
default map style is in general considering access tag only (as there is no 
good idea how to
do it otherwise), maybe Strava is also looking only at access tag?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Apparent conflicting/redundant access tags

[Martin Koppenhoefer]

Am Mi., 5. Aug. 2020 um 23:21 Uhr schrieb Mike Thompson :

>
> However, access=yes is a pretty broad statement.  There may be modes of
> transport not yet contemplated (or which the mapper, and even the land
> manager is not aware of) which in the future will be prohibited.
>


+1, "access=*" is a pretty broad statement. Generally the suggestion is to
use more specific tags for access and not "access", e.g. vehicle=no or
motor_vehicle=no.
While "access=*" is not an error, the situations where it is used could
often be better tagged with either "vehicle" or "motor_vehicle".

For example, from a strict reading of the wiki, "access=no" and "foot=yes"
would also imply emergency=no, disabled=no, dog=no, ski=no,
inline_skates=no and any other transport mode that we will introduce in the
future
(emergency might be hyperbole, the wiki also states: "Note that emergency
vehicles are generally not restricted by *legal* access rules"

Cheers
Martin

https://wiki.openstreetmap.org/wiki/Key:access
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rio de la Plata edit war

[Joseph Eisenberg]

Here's another issue I would like mural...@montevideo.com.uy to address:

In Venezuela the second largest city is on a body of water called "Lago de
Maracaibo":

https://www.openstreetmap.org/relation/11334852

As mentioned in Wikipedia, local Venezolanos often refer to this as a lake
(lago), not an estuary or bay:

*Lake Maracaibo* (Spanish
: *Lago
de Maracaibo*, pronounced [ˈlaɣo ðe maɾaˈkajβo]
 ([image: About this sound]
listen

)) is a large brackish  tidal bay
(or tidal estuary ) in Venezuela
 and an "inlet of the Caribbean Sea
".[1]
[2]
[3]
[4]
 It is sometimes
considered a lake  rather than a bay
 or lagoon
.[5]
[6]
[7]
[8]
[9]

[10] [11]
[12]
[13]
 It is connected
to the Gulf of Venezuela 
 by Tablazo Strait , which is
5.5 kilometres (3.4 mi) wide at the northern end.
https://en.wikipedia.org/wiki/Lake_Maracaibo

So, does this mean that Lago de Maracaibo could be mapped as natural=water
or waterway=riverbank instead, if local mappers feel it is a lake rather
than a tidal bay / estuary?

(It is currently mapped with natural=coastline and with a relation tagged
as natural=bay, like most other similar features in OpenStreetMap, with the
exception of the Rio de la Plata)

– Joseph Eisenberg

On Wed, Aug 5, 2020 at 2:52 AM Alan Mackie  wrote:
>
>
>
> On Wed, 5 Aug 2020 at 01:34,  wrote:
>>
>>
>>
>> - Mensaje original -
>> > De: "Joseph Eisenberg" 
>> > Para: "Tag discussion, strategy and related tools" <
tagging@openstreetmap.org>
>> > Enviados: Martes, 4 de Agosto 2020 16:56:31
>> > Asunto: Re: [Tagging] Rio de la Plata edit war
>>
>> > The graphics in this document are mainly models of current flow,
rather than
>> > actual measurements, but it is mentioned that the average current flow,
>> > neglecting wind, is only 0.1 m/s in the Rio de la Plata. Since winds
of 5 m/s
>> > are routine according to the paper, the currents vary strongly based
on winds
>> > and tides.
>> > See for example the figura on pages 26 to 37 which show the modeled
variation
>> > with different wind direction. I don't see a modeling of the affect of
tides -
>> > this appears to be the average current over the tidal cycle? But I
admit I have
>> > not visited this area.
>>
>> Sure its a model, but the model is validated by drifting bouys, as you
can check in page 37.
>> i just translated here.
>> "The drift buoy trajectories launched in the summer of 2003 and reported
by Piola et al (2003) showed, in consistency with the modeled solutions,
relatively low average speeds (20-30 cm / s) in the middle part of the
river and higher speeds in the outer sector, mainly towards the Uruguayan
coast, where they exceeded 60 cm / s (Fig. 33)."
>>
>> > My main objection is the inclusion of Bahia Samborombon in the
estuary. The
>> > charts and satellite images show very little influence from river
water in that
>> > area, as well as in the section of coast east of Montevideo.
>>
>> You are misreading the imagery. What generaly available imagery shows in
this area is a change of colour, which is dark brown to the NW, and more
clear to the SE. This is caused for the change of turbidity, located near
the 5m isobath.
>>
> The figures in both the document linked by muralito and the one
previously linked by Andy seem to show that flow outside of the line from
Montevideo to Punta Piedras is largely dominated by wind and ocean
conditions and not by the river flow. Visible sediment in the water was
discounted earlier for defining outer limits as it often persists far into
areas clearly considered ocean (see Christoph's example off the coast of
China), 

Re: [Tagging] Rio de la Plata edit war

[muralito]

- Mensaje original -
> De: "Joseph Eisenberg" 
> Para: "Tag discussion, strategy and related tools" 
> Enviados: Miércoles, 5 de Agosto 2020 19:46:06
> Asunto: Re: [Tagging] Rio de la Plata edit war

> Here's another issue I would like mural...@montevideo.com.uy to address:
> In Venezuela the second largest city is on a body of water called "Lago de
> Maracaibo":

> https://www.openstreetmap.org/relation/11334852

> As mentioned in Wikipedia, local Venezolanos often refer to this as a lake
> (lago), not an estuary or bay:

> Lake Maracaibo ( Spanish : Lago de Maracaibo , pronounced [ˈlaɣo ðe 
> maɾaˈkajβo]
> ( listen ) ) is a large brackish tidal bay (or tidal estuary ) in Venezuela 
> and
> an "inlet of the Caribbean Sea ". [1] [2] [3] [4] It is sometimes considered a
> lake rather than a bay or lagoon . [5] [6] [7] [8] [9] [10] [11] [12] [13] It
> is connected to the Gulf of Venezuela by Tablazo Strait , which is 5.5
> kilometres (3.4 mi) wide at the northern end.
> https://en.wikipedia.org/wiki/Lake_Maracaibo

> So, does this mean that Lago de Maracaibo could be mapped as natural=water or
> waterway=riverbank instead, if local mappers feel it is a lake rather than a
> tidal bay / estuary?

> (It is currently mapped with natural=coastline and with a relation tagged as
> natural=bay, like most other similar features in OpenStreetMap, with the
> exception of the Rio de la Plata)

I have never been there, but from the aerial photos it is clearly on the 
continent and there is nothing oceanic, despite having communication with the 
sea, so it should not be labeled natural = coastline in the same way that the 
Great Lakes or other large endorheic lakes no matter how big they are. In fact 
apparently some renderers adapted and if they draw the polygons natural = water 
at low zoom levels. 

I'm convinced that the problem is the renderer, not the data. If the map shows 
what people expect they do not look the details and do not find the errors in 
the data, like this case, that a possible error goes unnoticed.

It would be one of the many examples where, in my opinion, the coastline is 
poorly located in OSM, but I don't know what is the position of the Venezuelan 
OSM community.

I also asked for other places like Elbe River, or River Crouch, where the 
natural=coastline is placed more than 26 km from the sea. Very weird. This is 
the opposite problem in the data, but people does not notice because in small 
zooms the renderer seems to simplifies the coastline details, and this 
coastline is not even a pixel in zoom 5 or 6.



> – Joseph Eisenberg

> On Wed, Aug 5, 2020 at 2:52 AM Alan Mackie < aamac...@gmail.com > wrote:



> > On Wed, 5 Aug 2020 at 01:34, < mural...@montevideo.com.uy > wrote:



> >> - Mensaje original -
> >> > De: "Joseph Eisenberg" < joseph.eisenb...@gmail.com >
> >> > Para: "Tag discussion, strategy and related tools" < 
> >> > tagging@openstreetmap.org >
> >> > Enviados: Martes, 4 de Agosto 2020 16:56:31
> >> > Asunto: Re: [Tagging] Rio de la Plata edit war

> >> > The graphics in this document are mainly models of current flow, rather 
> >> > than
> >> > actual measurements, but it is mentioned that the average current flow,
> >> > neglecting wind, is only 0.1 m/s in the Rio de la Plata. Since winds of 
> >> > 5 m/s
> >> > are routine according to the paper, the currents vary strongly based on 
> >> > winds
> >> > and tides.
> >> > See for example the figura on pages 26 to 37 which show the modeled 
> >> > variation
> >> > with different wind direction. I don't see a modeling of the affect of 
> >> > tides -
> >> > this appears to be the average current over the tidal cycle? But I admit 
> >> > I have
> >> > not visited this area.

>>> Sure its a model, but the model is validated by drifting bouys, as you can 
>>> check
> >> in page 37.
> >> i just translated here.
>>> "The drift buoy trajectories launched in the summer of 2003 and reported by
>>> Piola et al (2003) showed, in consistency with the modeled solutions,
>>> relatively low average speeds (20-30 cm / s) in the middle part of the river
>>> and higher speeds in the outer sector, mainly towards the Uruguayan coast,
> >> where they exceeded 60 cm / s (Fig. 33)."

> >> > My main objection is the inclusion of Bahia Samborombon in the estuary. 
> >> > The
> >> > charts and satellite images show very little influence from river water 
> >> > in that
> >> > area, as well as in the section of coast east of Montevideo.

>>> You are misreading the imagery. What generaly available imagery shows in 
>>> this
>>> area is a change of colour, which is dark brown to the NW, and more clear to
>>> the SE. This is caused for the change of turbidity, located near the 5m
> >> isobath.

>> The figures in both the document linked by muralito and the one previously
>> linked by Andy seem to show that flow outside of the line from Montevideo to
>> Punta Piedras is largely dominated by wind and ocean conditions and not by 
>> the
>> ri

Re: [Tagging] Apparent conflicting/redundant access tags

[Tod Fitch]

My reading of the wiki [1] indicates that the more specific tag overrides the 
less specific tag. And the transport mode section [2] of that has examples very 
much like those in your question.

So:
access=no
foot=yes

Means that all access other than foot is prohibited.

And:
access=yes
bicycle=no

Means you can walk, drive or ride a horse, etc. but you can’t bicycle.

For what its worth, I just had a question along this same line for a trail in a 
local wilderness park that I edited a year or so ago. All I did was split the 
way and keep the existing tagging (which I agreed with). But apparently the 
Strava app had a problem with the tagging (access=no, foot=designated, 
bicycle=designated), so I guess my reading of the wiki doesn’t match all data 
consumers implementations.

Cheers,

Tod

[1] https://wiki.openstreetmap.org/wiki/Key:access
[2] https://wiki.openstreetmap.org/wiki/Key:access#Transport_mode_restrictions

> On Aug 5, 2020, at 1:44 PM, Mike Thompson  wrote:
> 
> Hello,
> 
> If:
> access=no
> foot=yes
> 
> Does this mean that all access except foot travel is prohibited, or is it an 
> error?
> 
> If:
> access=yes
> bicycle=no
> 
> Does this mean that all access except bicycle travel is allowed, or is an 
> error?
> 
> Here is one example of the first case:
> https://www.openstreetmap.org/way/834296397 
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Apparent conflicting/redundant access tags

[Jarek Piórkowski]

On Wed, 5 Aug 2020 at 17:20, Mike Thompson  wrote:
> On Wed, Aug 5, 2020 at 2:59 PM Tod Fitch  wrote:
>> My reading of the wiki [1] indicates that the more specific tag overrides 
>> the less specific tag.
>
> So,
> access=yes
> foot=yes
>
> would then be redundant.  I don't have an example, but I have seen that too.

Technically yes, but there are some cases when tagging redundancy is
worth it or even useful for clarity.

For example, if it's in an area where you might expect access=* or
foot=* to be no, access=yes can be used to confirm that the way _is_
in fact open to the public (signed public route through a private
area, perhaps? like a golf course or a quarry?) and foot=yes can be
used to confirm that pedestrians do have access there as well (perhaps
it's on a motorway but pedestrians are allowed for some reason?).

You can also use this to communicate the actual value of the access=*
tag to your fellow mappers. In an area where access is unclear, if you
tag access=yes, you are saving other mappers from wondering if the way
is actually public, or if it has not yet been surveyed/edited to add
access=private. (In programming terms, access=yes is true, access=no
is false, and lack of an access=* tag is null)

> However, access=yes is a pretty broad statement.  There may be modes of 
> transport not yet contemplated (or which the mapper, and even the land 
> manager is not aware of) which in the future will be prohibited.

If the land manager is not aware of a mode of transport, are they
really in position to prohibit it right now? And in the future,
pedestrians could be prohibited too, and tagging would have to change
as well.

--Jarek

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