Re: [Tagging] tagging the landuse of resevoirs & basins.

[John Willis via Tagging]

> On Apr 15, 2020, at 10:40 AM, Joseph Eisenberg  
> wrote:
> 
>> I suggest landuse=industrial + industrial=water
> 
> Perhaps industrial=water_management or =flood_control or something
> elsemore specific would be better?

 good values, water_management might be good. Some of these are for purely 
storm surge control (to prevent short term flooding), but canals and aqueducts 
often have controlled land in certain places and are not related to storms. 

https://www.openstreetmap.org/#map=19/36.28920/137.88271 


Here is a place where an aqueduct crosses a river. the office next to it is the 
local “drainage” office that handles the aqueduct. 

the land around the crossing has two overflow drains that lead to the river. 

I could merely map the grass and riverbank areas, letting the fences and water 
features imply the usage, but I could also try to show that this junction is:

- a man-made feature
-for management of the water features inside the area
- has no other uses beyond water management. (no parks, etc).
- an area people normally don’t enter except for maintenance. 
- this one also has access control (fencing, gates, etc)

To me, this is another use of this landuse. 

> 
> I would mainly do this for areas covered in concrete, asphal, stones,
> roads, levees and other obvious man-made features, surrounded by a
> fence or wall probably? And map the fence with barrier=fence lines if
> known.

They often have fences or other barrier= features along with access ways. 

Smaller ones are defined by the bordering boundaries (farmland, residential 
walls, road guardrails, etc).  

All my examples were chosen because they basically have this.  One doesn’t - 
but still is a man-made structure.

> (You can also map the vegetation of the area (grass, scrub, woodland)
> if it's present, especially if this covers a large area.

I often do, but most of these are totally surrounded by concrete/asphalt (and 
often times fences to keep people from drowning).

> That would
> make more sense than describing a large are of woods as
> industrial=flood_control if it is outside of the levees/dykes and
> wouldn't actually be flooded.)

I’m not interested (for this tag) to map any natural features - just the land 
altered and/or fenced that surrounds the basin/reservoir.

it’s to map the constructed objects that surround the water feature. 

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

Re: [Tagging] tagging the landuse of resevoirs & basins.

[Joseph Eisenberg]

> I suggest landuse=industrial + industrial=water

Perhaps industrial=water_management or =flood_control or something
elsemore specific would be better?

I would mainly do this for areas covered in concrete, asphal, stones,
roads, levees and other obvious man-made features, surrounded by a
fence or wall probably? And map the fence with barrier=fence lines if
known.

(You can also map the vegetation of the area (grass, scrub, woodland)
if it's present, especially if this covers a large area. That would
make more sense than describing a large are of woods as
industrial=flood_control if it is outside of the levees/dykes and
wouldn't actually be flooded.)

-- Joseph Eisenberg

On 4/15/20, John Willis via Tagging  wrote:
> When mapping stormwater reservoirs and basins here in Japan, they often have
> a mappable landuse around them - the land around the basin is controlled,
> often with an access road and and fence of some type.
>
> Mapping the water feature is easy, but what is the landuse of the entire
> facility? it is 10% larger than the basin itself.
>
>
> Here is a good example - the small amount of land around this basin
> “belongs” to the basin. the access road belongs to it. It is not a park nor
> are the access roads for private property. they are just there to access the
> basin in an emergency (a breach, cleaning etc).
>
> https://www.openstreetmap.org/way/791956035
>   <-mapped landuse example
>
> other examples that could be mapped in a similar fashion:
> https://www.openstreetmap.org/#map=17/36.28832/139.42927
> 
> https://www.openstreetmap.org/#map=18/36.27943/139.43071
> 
> https://www.openstreetmap.org/#map=18/36.29622/139.39674
> 
> https://www.openstreetmap.org/#map=18/36.34744/139.32669
> 
> https://www.openstreetmap.org/#map=17/36.05560/139.60083
> 
>
>
>
> In many instances, emergency stormwater basins are in parks or large
> factories - making them a feature of that larger landuse.
> I'm not talking about these.
>
> Examples of what I’m not talking about:
> https://www.openstreetmap.org/#map=16/36.2707/139.4148
> 
> https://www.openstreetmap.org/#map=17/36.22028/139.64998
> 
> https://www.openstreetmap.org/#map=16/36.1037/139.6329
> 
>
>
> I’m talking about the dedicated land only used for the man-made basins and
> no other usage, controlled via barriers, and mappable via imagery.
>
> I suggest landuse=industrial + industrial=water  or similar for all man-made
> water related features that isn’t a plant of some kind (ones dedicated to
> filtering, treating, or pumping the water).
>
> similar to landuse=railway, there is more land dedicated to these features
> than just the mappable feature itself.
>
> https://taginfo.openstreetmap.org/keys/?key=industrial#values
> 
>
> taginfo says this combination currently has 60 uses (#2 for all “water”
> values), and “water_storage” has 1.
>
> thoughts?
>
> Javbw

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

[Tagging] tagging the landuse of resevoirs & basins.

[John Willis via Tagging]

When mapping stormwater reservoirs and basins here in Japan, they often have a 
mappable landuse around them - the land around the basin is controlled, often 
with an access road and and fence of some type. 

Mapping the water feature is easy, but what is the landuse of the entire 
facility? it is 10% larger than the basin itself.


Here is a good example - the small amount of land around this basin “belongs” 
to the basin. the access road belongs to it. It is not a park nor are the 
access roads for private property. they are just there to access the basin in 
an emergency (a breach, cleaning etc). 

https://www.openstreetmap.org/way/791956035 
  <-mapped landuse example

other examples that could be mapped in a similar fashion:
https://www.openstreetmap.org/#map=17/36.28832/139.42927 

https://www.openstreetmap.org/#map=18/36.27943/139.43071 

https://www.openstreetmap.org/#map=18/36.29622/139.39674 

https://www.openstreetmap.org/#map=18/36.34744/139.32669 

https://www.openstreetmap.org/#map=17/36.05560/139.60083 




In many instances, emergency stormwater basins are in parks or large factories 
- making them a feature of that larger landuse.
I'm not talking about these. 

Examples of what I’m not talking about:
https://www.openstreetmap.org/#map=16/36.2707/139.4148 

https://www.openstreetmap.org/#map=17/36.22028/139.64998 

https://www.openstreetmap.org/#map=16/36.1037/139.6329 



I’m talking about the dedicated land only used for the man-made basins and no 
other usage, controlled via barriers, and mappable via imagery. 

I suggest landuse=industrial + industrial=water  or similar for all man-made 
water related features that isn’t a plant of some kind (ones dedicated to 
filtering, treating, or pumping the water). 

similar to landuse=railway, there is more land dedicated to these features than 
just the mappable feature itself. 

https://taginfo.openstreetmap.org/keys/?key=industrial#values 


taginfo says this combination currently has 60 uses (#2 for all “water” 
values), and “water_storage” has 1. 

thoughts?

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

Re: [Tagging] insurance health

[Joseph Eisenberg]

OK, but are there any countries in the world where you can would
normally buy health insurance in the same place as car or home or life
insurance?

If not, then this is a theoretical problem only.

"if you  want to  ask "how many insurance offices are there and what
is the breakdown by type", it's much more natural to search one key..."

It's all one key either way ("office"), and database users already are
very accustomed to searching for more than one tag to find a set of
similar things. It only takes a few more seconds to add another tag to
an Overpass-API query.

But it takes more time for each mapper to add 2 tags instead of one.
Mapper time is the most precious resource in OpenStreetMap: we don't
have enough mappers, and most are working for free, for fun.

Let's make things as easy as possible for mappers: one tag for one main feature.

-- Joseph Eisenberg

On 4/15/20, António Madeira  wrote:
> I agree that a logical breakdown of the insurance field should be
> preferred rather than creating several type of insurance offices.
> I would rather use office=insurance + insurance="type" than
> office=health_insurance;car_insurance;house_insurance;etc.
>
>
> Às 21:16 de 14/04/2020, Greg Troxel escreveu:
>> Agustin Rissoli  writes:
>>
>>> In Argentina we want to correctly tagging offices of companies dedicated
>>> to
>>> what we call prepaid medicine, by paying a monthly fee you access a
>>> series
>>> of medical benefits.
>>> We are hesitating between these tags:
>>>
>>> office=health_insurance
>>> It has no wiki, it has 185 uses, the majority in Belgium since it was
>>> created in 2013, they even have a preset in JOSM.
>>>
>>> office=insurance + insurance=health
>>> It has a wiki, curiously created by a Belgian user in 2018, it has 66
>>> uses.
>>> It is the only documented insurance=* key.
>> While I see Joseph's point about what is normal, I think that's an
>> artifact of some, perhaps many societies.
>>
>> I think if this is an office selling insurance of any kind, it should
>> have office=insurance and then a subtag.  I don't think it helps map
>> data users to make a second top-level tag.  Basically I think tags
>> should follow semantics as much as possible, when that's reasonable.
>>
>> For what it's worth, around me, also in the US, my impression is that
>> most "insurance offices" are really "property and casualty insurance
>> offices".  This is for your car, and your house.  But typically not life
>> insurance so much, and not health.  (I am not sure about professional
>> liability and business interruption insurance.)
>>
>> As always, we should step back and ask "when we add these tags, who will
>> use them, and why".  I see two points:
>>
>>some kind of overall statistics of types of businesses
>>
>>wanting to find a particular thing
>>
>> In the case of office=insurance insurance=health, if that's what you
>> want, you can find it by searching for that just as well as searching
>> for office=health_insurance.
>>
>> But if you  want to  ask "how many insurance offices are there and what
>> is the breakdown by type", it's much more natural to search one key and
>> switch on subtag, then to consult some information -- which we don't
>> really have a way to maintain -- that says office=insurance,
>> office=health_insurance and office=foo_insurance are all types of
>> insurance offices.
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

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

Re: [Tagging] insurance health

[António Madeira]

I agree that a logical breakdown of the insurance field should be
preferred rather than creating several type of insurance offices.
I would rather use office=insurance + insurance="type" than
office=health_insurance;car_insurance;house_insurance;etc.


Às 21:16 de 14/04/2020, Greg Troxel escreveu:

Agustin Rissoli  writes:


In Argentina we want to correctly tagging offices of companies dedicated to
what we call prepaid medicine, by paying a monthly fee you access a series
of medical benefits.
We are hesitating between these tags:

office=health_insurance
It has no wiki, it has 185 uses, the majority in Belgium since it was
created in 2013, they even have a preset in JOSM.

office=insurance + insurance=health
It has a wiki, curiously created by a Belgian user in 2018, it has 66 uses.
It is the only documented insurance=* key.

While I see Joseph's point about what is normal, I think that's an
artifact of some, perhaps many societies.

I think if this is an office selling insurance of any kind, it should
have office=insurance and then a subtag.  I don't think it helps map
data users to make a second top-level tag.  Basically I think tags
should follow semantics as much as possible, when that's reasonable.

For what it's worth, around me, also in the US, my impression is that
most "insurance offices" are really "property and casualty insurance
offices".  This is for your car, and your house.  But typically not life
insurance so much, and not health.  (I am not sure about professional
liability and business interruption insurance.)

As always, we should step back and ask "when we add these tags, who will
use them, and why".  I see two points:

   some kind of overall statistics of types of businesses

   wanting to find a particular thing

In the case of office=insurance insurance=health, if that's what you
want, you can find it by searching for that just as well as searching
for office=health_insurance.

But if you  want to  ask "how many insurance offices are there and what
is the breakdown by type", it's much more natural to search one key and
switch on subtag, then to consult some information -- which we don't
really have a way to maintain -- that says office=insurance,
office=health_insurance and office=foo_insurance are all types of
insurance offices.

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



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

Re: [Tagging] insurance health

[Greg Troxel]

Agustin Rissoli  writes:

> In Argentina we want to correctly tagging offices of companies dedicated to
> what we call prepaid medicine, by paying a monthly fee you access a series
> of medical benefits.
> We are hesitating between these tags:
>
> office=health_insurance
> It has no wiki, it has 185 uses, the majority in Belgium since it was
> created in 2013, they even have a preset in JOSM.
>
> office=insurance + insurance=health
> It has a wiki, curiously created by a Belgian user in 2018, it has 66 uses.
> It is the only documented insurance=* key.

While I see Joseph's point about what is normal, I think that's an
artifact of some, perhaps many societies.

I think if this is an office selling insurance of any kind, it should
have office=insurance and then a subtag.  I don't think it helps map
data users to make a second top-level tag.  Basically I think tags
should follow semantics as much as possible, when that's reasonable.

For what it's worth, around me, also in the US, my impression is that
most "insurance offices" are really "property and casualty insurance
offices".  This is for your car, and your house.  But typically not life
insurance so much, and not health.  (I am not sure about professional
liability and business interruption insurance.)

As always, we should step back and ask "when we add these tags, who will
use them, and why".  I see two points:

  some kind of overall statistics of types of businesses

  wanting to find a particular thing

In the case of office=insurance insurance=health, if that's what you
want, you can find it by searching for that just as well as searching
for office=health_insurance.

But if you  want to  ask "how many insurance offices are there and what
is the breakdown by type", it's much more natural to search one key and
switch on subtag, then to consult some information -- which we don't
really have a way to maintain -- that says office=insurance,
office=health_insurance and office=foo_insurance are all types of
insurance offices.

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

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

[Warin]

Problem.

The present description does not distinguish this 
'*amenity=refugee_site*' from amenity=social_facility and 
social_facility=shelter.



I would think amenity=refugee_site is an area set aside for the 
non-temporary residential use of refugees. *

*

The meaning of 'temporary' is not stated in the wiki for 
social_facility=shelter so there will be some uncertainty as to where 
teh different lies.


*
*

Possibly the 'area' can be used? A**social_facility=shelter could from 
the wording be considered a single structure? The 'amenity=refugee_site' 
could be stipulated as many structures i.e. mare than 3?




On 14/4/20 5:41 pm, Manon Viou wrote:


Hello,
Actually RFC for refugee site location mapping started March 25,
Since this day, we received and exchanged on the proposal and made 
changes to the former proposal, that’s what RFC is all about no?  ,
I do not know if according to this changes, we have to restart the RFC 
period?
We will restart RFC period if needed, let me know ! we haven’t 
received much comments on the latest proposal modifications, please 
let us know if this works for you or if amendments have to be done ( 
Proposed features/Refugee Site Location 2 
) 


Have a great day,
Manon


Le 11 avril 2020 à 00:03, Warin <61sundow...@gmail.com> a écrit :

The minimum an RFC is required to be open is 2 weeks.

Same with voting.


On 11/4/20 1:54 am, Manon Viou wrote:

Hello all,

We have modified the proposed features/Refugee Site Location 2 
 according 
to discussions regarding how to best tag places sheltering refugee 
and/or internally displace persons. Thank you to the contributors 
who help finding a solution to have a consistent tagging in place 
for refugee location.

We are now suggesting to use the tag *amenity=refugee_site *
The tag can be used alternatively on nodes or on areas:

  * If the extent of the site is difficult to identify (proximity to
other villages, suburban area, etc.) it is recommended to use a
node.
  * If the extent of the site can be clearly identified from the
imagery or field data collection, it is recommended to use an
area. Please note this extent does not have to match the
official boundary of a camp (which doesn’t necessarily coincide
to its physical limitations), as defined by government and
specialized agencies, for which a dedicated tag can be used.

Both approaches can be completed by mapping the landuse=residential 
of the area and if appropriate a tag place (place=neighbourhood, 
place=suburb, place=village) can be added in the area of the refugee 
site.


Please have a look at this new proposal and share your comments 
quickly if you have any. *We will close RFC period soon*.


Best regards,

Manon

CartONG- Humanitarian mapping and information management 



Manon Viou



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

Re: [Tagging] Feature Proposal - RFC - traffic_signals=crossing_on_demand

[Jarek Piórkowski]

On Tue, 14 Apr 2020 at 10:00,  wrote:
> So in which cases "highway=traffic_signals + crossing=traffic_signals on the 
> same node" should be used? Only for the "crossing only-traffic lights" I 
> mentioned?

Yeah, personally I would agree with that. Only on
pedestrian/cycle-crossing-only traffic lights.
https://www.openstreetmap.org/node/2771622922 as an example.

I think that if you're going to the extent of mapping separate stop
lines on all ways leading into the intersection, you can also separate
the car stop line node from the pedestrian crossing node. (And if
you're not, highway=traffic_signals on the main intersection node
still works.) So don't use highway=traffic_signals +
crossing=traffic_signals, except for a pedestrian-crossing-only light.

--Jarek

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

Re: [Tagging] Refining heritage tag

[António Madeira via Tagging]

Thanks, Paul.
I'll contact them then.


Às 17:44 de 14/04/2020, Paul Allen escreveu:

On Tue, 14 Apr 2020 at 21:02, António Madeira mailto:antoniomade...@gmx.com>> wrote:


Às 10:15 de 14/04/2020, Paul Allen escreveu:


They're the ones you'd have to convince to alter their code to
handle your
proposed change.


You mean this?
https://wiki.openstreetmap.org/wiki/Open_Historical_Map


That's where it's documented.  The map is here:gk.historic.place
  If
you've not played with it before, here's a place where I've added most
of the heritage info:
http://gk.historic.place/historische_objekte/l/en/index.html?zoom=16=52.03846=-4.46621=3=HaHbHcSaHe

The "problem" with criteria is that it seems to be used with
numbers or abbreviations, like a list that corresponds to some
longer definitions.


That's how others have done it, listing what those abbreviations mean
on the wiki
page.  But there's nothing (I can see) that says you have to restrict
yourself to
abbreviations.

Since heritage=* is largely ruled over by the historical places
people, the best
place to get an opinion is https://www.openstreetmap.org/user/lutz
In the end, he and his team decide how the historical places map interpret
the tags.

--
Paul


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


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

Re: [Tagging] Refining heritage tag

[Paul Allen]

On Tue, 14 Apr 2020 at 21:02, António Madeira 
wrote:

>
> Às 10:15 de 14/04/2020, Paul Allen escreveu:
>
>
> They're the ones you'd have to convince to alter their code to handle your
> proposed change.
>
>
> You mean this?
> https://wiki.openstreetmap.org/wiki/Open_Historical_Map
>

That's where it's documented.  The map is here: gk.historic.place  If
you've not played with it before, here's a place where I've added most
of the heritage info:
http://gk.historic.place/historische_objekte/l/en/index.html?zoom=16=52.03846=-4.46621=3=HaHbHcSaHe

The "problem" with criteria is that it seems to be used with numbers or
> abbreviations, like a list that corresponds to some longer definitions.
>

That's how others have done it, listing what those abbreviations mean on
the wiki
page.  But there's nothing (I can see) that says you have to restrict
yourself to
abbreviations.

Since heritage=* is largely ruled over by the historical places people, the
best
place to get an opinion is https://www.openstreetmap.org/user/lutz
In the end, he and his team decide how the historical places map interpret
the tags.

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

Re: [Tagging] Refining heritage tag

[António Madeira]

Às 10:15 de 14/04/2020, Paul Allen escreveu:

On Tue, 14 Apr 2020 at 04:33, António Madeira via Tagging
mailto:tagging@openstreetmap.org>> wrote:

- is ref:xxx=* a good solution to add the official reference
code/number?


No.  But that's what we have.  With hindsight we'd have done it
differently.  But
it's now been used so often it would be very difficult to fix all the
existing uses.

More importantly, heritage/historic tagging was started by the
Historic Place
project and they're the only ones (that I know of) that make use of
those tags.
They're the ones you'd have to convince to alter their code to handle your
proposed change.


You mean this?
https://wiki.openstreetmap.org/wiki/Open_Historical_Map



- we've adopted the tag protection_title=* to define the
protection category of the heritage, although the German wiki
clearly states this is used for natural areas only. Would it be
better to create another tag or is OK to adapt this one, since
this is also a protected feature?

It's a protected feature but not a protected natural area.  The wiki page
for it says it requires boundary=national_park or
boundary=protected_area so
it shouldn't be used this way.  That said, other people have used it
that way.
Would xxx:criteria fit your usage?


The "problem" with criteria is that it seems to be used with numbers or
abbreviations, like a list that corresponds to some longer definitions.
For example: we could create a criteria list with 1, 2, 3, 4 which would
correspond to the 4 levels of heritage existing in Portugal, but how
would data consumers know what those numbers mean? Or if you use
abbreviations, like MN, IIP, etc. we would have the same problem.
The protection_title=* seemed to solve that, but it's not 100% accurate.
I don't want to use it if it's not correct, so maybe we could create
something like heritage:designation=* which would go in line with the
heritage scheme.



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

Re: [Tagging] insurance health

[Agustin Rissoli]

Yes, it is also so here, these companies are entirely specialized in
health, the regulation and management is completely different from a
conventional insurer.
We did a search with the name of one of the best known companies, they are
mapped with a wide variety of tags, but one of the most used is company.



> --
>
> Message: 2
> Date: Tue, 14 Apr 2020 15:03:04 +0900
> From: Joseph Eisenberg 
> To: "Tag discussion, strategy and related tools"
> 
> Subject: Re: [Tagging] insurance health
> Message-ID:
>  x4umopvda2aipb7emhxbsuw-uxfvq96nhvlhia...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> I would use office=health_insurance
>
> In my experience (mostly in the USA), an office=insurance will sell
> you life insurance, house or rental insurance, car insurance, travel
> insurance and some other kinds, but will usually not sell health
> insurance, while a health insurance office is likely to specialize.
>
> Is that also true in Argentina?
>
> (If you want to use a subtag, another option would be office=company
> (very common tag) + company=health_insurance or something like that)
>
> -- Joseph Eisenberg
>
> On 4/14/20, Agustin Rissoli  wrote:
> > In Argentina we want to correctly tagging offices of companies dedicated
> to
> > what we call prepaid medicine, by paying a monthly fee you access a
> series
> > of medical benefits.
> > We are hesitating between these tags:
> >
> > office=health_insurance
> > It has no wiki, it has 185 uses, the majority in Belgium since it was
> > created in 2013, they even have a preset in JOSM.
> >
> > office=insurance + insurance=health
> > It has a wiki, curiously created by a Belgian user in 2018, it has 66
> uses.
> > It is the only documented insurance=* key.
> >
> > What do you think would be the correct use?
> >
> > --
> > *AGUS*!  :)
> >
>
>
>
> --
>
> --
*AGUS*!  :)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - traffic_signals=crossing_on_demand

[Lukas-458]

"My understanding of the detailed-intersection-tagging
norms was that this should have highway=traffic_signals on the stop
line for cars, and highway=crossing+crossing=traffic_signals on the
middle of the pedestrian crossing"

 

Yes, this was actually exact that what were in my thoughts. But I think that not all mappers know that or follow that practice. So that's why my original purpose was to ban highway=traffic_signals + crossing=traffic_signals on the same node, but I know that's not possible and that's also what I don't want anymore to reach.

But what I see is, that we have to clarify much more WHEN, so in which case, highway=traffic_signals + crossing=traffic_signals on the same node should be seen as "accepted"/"good mapping practice" and in which cases not. I think it has to come more clear in the wiki that highway=traffic_signals + crossing=traffic_signals on the same node in NOT a "shortcut" or "mapping practice" for detailed intersection tagging/mapping.

 

Is it right tht we agree with that? So in which cases "highway=traffic_signals + crossing=traffic_signals on the same node" should be used? Only for the "crossing only-traffic lights" I mentioned?

 

--Lukas

 
 

Gesendet: Dienstag, 14. April 2020 um 15:43 Uhr
Von: "Jarek Piórkowski" 
An: "Tag discussion, strategy and related tools" 
Betreff: Re: [Tagging] Feature Proposal - RFC - traffic_signals=crossing_on_demand

On Tue, 14 Apr 2020 at 06:23,  wrote:
>
> To response on the mentioning:
> "Currently the wiki page says "traffic_signals=crossing_on_demand makes
> it easy to mark all traffic lights which do only control a crossing",
> again I personally find highway=traffic_signals +
> crossing=traffic_signals sufficient for that"
>
> Yes, that's true. I agree with that, but my point is, that not only those traffic lights, which do control only a crossing, a mapped like this. Mappers use it just as a shortcut for traffic light and crossing, no matter in which relation between each other they are. That is not wrong, but it does not really show for what the lane traffic lights are "resposible". Please have a look at https://www.openstreetmap.org/node/1339612951 and many many others in this city. The traffic lights of course control the crossing, yes, but they control the junction nearby, too.
> So looking at highway=traffic_signals + crossing=traffic_signals on the same node also makes it not possible to see only those crossings where n junction or something else is, as I see it at the moment.

Hm, that's tagging I haven't seen before. My suggestion would be to
not tag like that (the proposed new tag would suggest retagging of
this anyway). My understanding of the detailed-intersection-tagging
norms was that this should have highway=traffic_signals on the stop
line for cars, and highway=crossing+crossing=traffic_signals on the
middle of the pedestrian crossing - e.g.
https://www.openstreetmap.org/node/1822620449 or
https://www.openstreetmap.org/node/393547028

--Jarek

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




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

Re: [Tagging] Feature Proposal - RFC - traffic_signals=crossing_on_demand

[Jarek Piórkowski]

On Tue, 14 Apr 2020 at 06:23,  wrote:
>
> To response on the mentioning:
> "Currently the wiki page says "traffic_signals=crossing_on_demand makes
> it easy to mark all traffic lights which do only control a crossing",
> again I personally find highway=traffic_signals +
> crossing=traffic_signals sufficient for that"
>
> Yes, that's true. I agree with that, but my point is, that not only those 
> traffic lights, which do control only a crossing, a mapped like this. Mappers 
> use it just as a shortcut for traffic light and crossing, no matter in which 
> relation between each other they are. That is not wrong, but it does not 
> really show for what the lane traffic lights are "resposible". Please have a 
> look at https://www.openstreetmap.org/node/1339612951 and many many others in 
> this city. The traffic lights of course control the crossing, yes, but they 
> control the junction nearby, too.
> So looking at highway=traffic_signals + crossing=traffic_signals on the same 
> node also makes it not possible to see only those crossings where n junction 
> or something else is, as I see it at the moment.

Hm, that's tagging I haven't seen before. My suggestion would be to
not tag like that (the proposed new tag would suggest retagging of
this anyway). My understanding of the detailed-intersection-tagging
norms was that this should have highway=traffic_signals on the stop
line for cars, and highway=crossing+crossing=traffic_signals on the
middle of the pedestrian crossing - e.g.
https://www.openstreetmap.org/node/1822620449 or
https://www.openstreetmap.org/node/393547028

--Jarek

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

Re: [Tagging] Refining heritage tag

[Paul Allen]

On Tue, 14 Apr 2020 at 04:33, António Madeira via Tagging <
tagging@openstreetmap.org> wrote:

- is ref:xxx=* a good solution to add the official reference code/number?
>

No.  But that's what we have.  With hindsight we'd have done it
differently.  But
it's now been used so often it would be very difficult to fix all the
existing uses.

More importantly, heritage/historic tagging was started by the Historic
Place
project and they're the only ones (that I know of) that make use of those
tags.
They're the ones you'd have to convince to alter their code to handle your
proposed change.

- the same for xxx:inscription_date=*. Wouldn't it be more consistent to
> use heritage:xxx:inscription_date=* ?
>

See above.

- we've adopted the tag protection_title=* to define the protection
> category of the heritage, although the German wiki clearly states this is
> used for natural areas only. Would it be better to create another tag or is
> OK to adapt this one, since this is also a protected feature?
>

It's a protected feature but not a protected natural area.  The wiki page
for it says it requires boundary=national_park or boundary=protected_area so
it shouldn't be used this way.  That said, other people have used it that
way.
Would xxx:criteria fit your usage?

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

Re: [Tagging] city limit sign end

[Alexey Zakharenkov]

 14.04.2020, 13:19, "Martin Koppenhoefer" :  Am Di., 14. Apr. 2020 um 11:18 Uhr schrieb Volker Schmidt :OK, we seem to agree that city-limit-begin sign needs to have angle or cardinal direction values and not forward|backward, because it is often or nearly always, on a joining node of two ways due to the implied speed limit in agglomerations, which is the rule in many European countries,  it doesn't need to have these tags, it is sufficient to place them at the side of the highway and the direction will be implicit. If you make them part of the highway it is desirable to indicate the direction explicitly (and I agree that direction information for the node depending on the way direction of one or more ways at the time of tagging is not desirable). One more question arises. Should we accept "traffic_sign=city_limit + direction=S" as incorrect tag combination? It's equivalent to "traffic_sign=city_limit + city_limit=both + direction=S", but to which city_limit of "both" the direction tag refers: to city_limit=begin or city_limit=end? I've mapped many such signs implicitly supposing the direction attribute applies to "begin".  Best regards,Alexey ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - traffic_signals=crossing_on_demand

[Lukas-458]

Hmm, yes I know there a several values for traffic_signals, but the main value "signal" comes just from the default value by iD which wasn't discussed, I think many of you will know about it. I chose the key "traffic_signals" because as the wiki says, it says something about the function of the traffic signal or for what is it "responsible". I think traffic_signals:_on_demand_=yes could be an option maybe, but it still would miss the goal to mark all those traffic signals, which do control ONLY a crossing. Many traffic lights are activated "on demand", but also those, which are at a junction, too.

 

"To me it seems there are different aspects that could occur on the same traffic signal controlled crossing"

Hmm. As I saw it, the existing "traffic_signals" values which are documented (so NOT traffic_signals=signal which does nothing say at all) specify "special" traffic signals. Nothing where different aspects appear really on the same one, or am I wrong? I do not even know what traffic_signals=signal wants to say to us.

 

"Also, there can be huge differences between different "on demand" crossings, some of them almost instantly turn red for vehicular traffic after you push the button, others may have long waiting times even when you push."

 

Yes that's true, but traffic_signals=crossing_on_demand does not say anything about that. It's only saying for what the traffic lights are responsible.Maybe we would need another key like "waiting_time" for that then, but I think it often depends on traffic situation and maybe can be changed during the daytime by a controlling center etc.

 
 

Gesendet: Dienstag, 14. April 2020 um 12:27 Uhr
Von: "Martin Koppenhoefer" 
An: "Tag discussion, strategy and related tools" 
Betreff: Re: [Tagging] Feature Proposal - RFC - traffic_signals=crossing_on_demand



 
 


Am Mo., 13. Apr. 2020 um 14:16 Uhr schrieb :




Hi,

oh sorry you are confused. Maybe it's too much text I think. But your conclusion is completely correct, yes.

 





 

 

Did you have a look at the currently used values for traffic_signals? https://taginfo.openstreetmap.org/keys/traffic_signals#values

94% are tagged with "signal"

1,3% "traffic_lights"

1,2% "pedestrian_crossing"

0,6% "blinker"

0,4% "ramp_meter"

 

According to the wiki, the tag "Gives details about the type or function of traffic signals."

https://wiki.openstreetmap.org/wiki/Key%3Atraffic_signals

 

To me it seems there are different aspects that could occur on the same traffic signal controlled crossing, mixed into the same key, and your proposal would add just another property as a "main type"?

Have you considered something like traffic_signals:_on_demand_=yes?

 

Also, there can be huge differences between different "on demand" crossings, some of them almost instantly turn red for vehicular traffic after you push the button, others may have long waiting times even when you push.

Not sure if recording these times might seem a bit too much detail though ;-)

 

Cheers

Martin

 

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




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

Re: [Tagging] Feature Proposal - RFC - traffic_signals=crossing_on_demand

[Martin Koppenhoefer]

Am Mo., 13. Apr. 2020 um 14:16 Uhr schrieb :

> Hi,
> oh sorry you are confused. Maybe it's too much text I think. But your
> conclusion is completely correct, yes.
>
>


Did you have a look at the currently used values for traffic_signals?
https://taginfo.openstreetmap.org/keys/traffic_signals#values
94% are tagged with "signal"
1,3% "traffic_lights"
1,2% "pedestrian_crossing"
0,6% "blinker"
0,4% "ramp_meter"

According to the wiki, the tag "Gives details about the type or function of
traffic signals."
https://wiki.openstreetmap.org/wiki/Key%3Atraffic_signals

To me it seems there are different aspects that could occur on the same
traffic signal controlled crossing, mixed into the same key, and your
proposal would add just another property as a "main type"?
Have you considered something like traffic_signals:on_demand=yes?

Also, there can be huge differences between different "on demand"
crossings, some of them almost instantly turn red for vehicular traffic
after you push the button, others may have long waiting times even when you
push.
Not sure if recording these times might seem a bit too much detail though
;-)

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

Re: [Tagging] Feature Proposal - RFC - traffic_signals=crossing_on_demand

[Lukas-458]

To response on the mentioning:


"Currently the wiki page says "traffic_signals=crossing_on_demand makes
it easy to mark all traffic lights which do only control a crossing",
again I personally find highway=traffic_signals +
crossing=traffic_signals sufficient for that" 

 

Yes, that's true. I agree with that, but my point is, that not only those traffic lights, which do control only a crossing, a mapped like this. Mappers use it just as a shortcut for traffic light and crossing, no matter in which relation between each other they are. That is not wrong, but it does not really show for what the lane traffic lights are "resposible". Please have a look at https://www.openstreetmap.org/node/1339612951 and many many others in this city. The traffic lights of course control the crossing, yes, but they control the junction nearby, too.

So looking at highway=traffic_signals + crossing=traffic_signals on the same node also makes it not possible to see only those crossings where n junction or something else is, as I see it at the moment.

 

Gesendet: Dienstag, 14. April 2020 um 12:12 Uhr
Von: lukas-...@web.de
An: tagging@openstreetmap.org
Betreff: Re: [Tagging] Feature Proposal - RFC - traffic_signals=crossing_on_demand



Hi,

the difference would be that traffic signals which control a junction but a crossing too, can have buttons for pedestrians as well as traffic signals which do only control a crossing. At least here in Germany. With looking at button_operated, you cannot clear whether the traffic lights are controlling a crossng only and not a junction.

 

Soon I will add some photos you mentioned it would be a bit clearer maybe then.

 

Lukas

 
 

Gesendet: Dienstag, 14. April 2020 um 11:03 Uhr
Von: "Volker Schmidt" 
An: "Tag discussion, strategy and related tools" 
Betreff: Re: [Tagging] Feature Proposal - RFC - traffic_signals=crossing_on_demand



What's the difference between

 

highway=traffic_signals plus button_poperated=yes

and

highway=traffic_signals plus traffic_signals=crossing_on_demand

 

?

 

 


On Tue, 14 Apr 2020 at 02:55, Jarek Piórkowski  wrote:

On Mon, 13 Apr 2020 at 12:56, Paul Allen  wrote:
> On Mon, 13 Apr 2020 at 17:43,  wrote:
>> The second goal my proposal wants to message is to deprecate tagging "crossing=traffic_signals" together with "highway=traffic_signals" on the same node. Especially if you're saying this is a full crossing mapped. It breaks the highway=crossing - tagging scheme we use for all other types of crossing (except crossing=no). Some mappers use "crossing=traffic_signals" together with "highway=traffic_signals" on the same node als a shortcut for "lane traffic signal" and "foot traffic signal" because it is rendered as two traffic signals in JOSM. Or for mapping traffic signals for crossing cyclists. But I think in every case it is better to use two different (nearby) nodes for that.
>
> Am I misunderstanding you?  You propose using two nearby nodes for
> https://goo.gl/maps/3Sg5ndQ2ZCMBN9uy9  You can just see the yellow
> pedestrian-control box at the left.  It controls the crossing (marked with studs)
> going from left to right across the picture.  The same lights that tell motorists
> to stop for pedestrians also control traffic flow at the T junction ahead.  The
> same set of lights is both a highway traffic signal and a crossing traffic signal.
> This sort of thing is not uncommon in the UK, with the same set of lights
> being used for both purposes.

My understanding was that traffic signals=crossing on demand is meant
for things like https://www.openstreetmap.org/node/2771622922 (
https://www.mapillary.com/map/im/2oyFQXVHvy2r-XypCZTECg ) however I
might be wrong? Or https://www.openstreetmap.org/node/1416834957 (
https://www.mapillary.com/map/im/DkuEFqSbOuQPGMtABsFFCA ) including
cyclists? (Esri is good for satellite imagery of these)

Personally I find highway=traffic_signals + crossing=traffic_signals
on one node sufficient for these crossings.

Currently the wiki page says "traffic_signals=crossing_on_demand makes
it easy to mark all traffic lights which do only control a crossing",
again I personally find highway=traffic_signals +
crossing=traffic_signals sufficient for that - maybe I'm missing
something. Of course any new tags can be proposed. But I would suggest
adding some real-world photos of crossings that would be tagged with
crossing_on_demand to the wiki page.

--Jarek

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

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




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




___
Tagging mailing list

Re: [Tagging] city limit sign end

[Martin Koppenhoefer]

Am Di., 14. Apr. 2020 um 11:18 Uhr schrieb Volker Schmidt :

> OK,
>
> we seem to agree that city-limit-begin sign needs to have angle or
> cardinal direction values and not forward|backward, because it is often or
> nearly always, on a joining node of two ways due to the implied speed limit
> in agglomerations, which is the rule in many European countries,
>


it doesn't need to have these tags, it is sufficient to place them at the
side of the highway and the direction will be implicit. If you make them
part of the highway it is desirable to indicate the direction explicitly
(and I agree that direction information for the node depending on the way
direction of one or more ways at the time of tagging is not desirable).

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

Re: [Tagging] Feature Proposal - RFC - traffic_signals=crossing_on_demand

[Lukas-458]

Hi,

the difference would be that traffic signals which control a junction but a crossing too, can have buttons for pedestrians as well as traffic signals which do only control a crossing. At least here in Germany. With looking at button_operated, you cannot clear whether the traffic lights are controlling a crossng only and not a junction.

 

Soon I will add some photos you mentioned it would be a bit clearer maybe then.

 

Lukas

 
 

Gesendet: Dienstag, 14. April 2020 um 11:03 Uhr
Von: "Volker Schmidt" 
An: "Tag discussion, strategy and related tools" 
Betreff: Re: [Tagging] Feature Proposal - RFC - traffic_signals=crossing_on_demand



What's the difference between

 

highway=traffic_signals plus button_poperated=yes

and

highway=traffic_signals plus traffic_signals=crossing_on_demand

 

?

 

 


On Tue, 14 Apr 2020 at 02:55, Jarek Piórkowski  wrote:

On Mon, 13 Apr 2020 at 12:56, Paul Allen  wrote:
> On Mon, 13 Apr 2020 at 17:43,  wrote:
>> The second goal my proposal wants to message is to deprecate tagging "crossing=traffic_signals" together with "highway=traffic_signals" on the same node. Especially if you're saying this is a full crossing mapped. It breaks the highway=crossing - tagging scheme we use for all other types of crossing (except crossing=no). Some mappers use "crossing=traffic_signals" together with "highway=traffic_signals" on the same node als a shortcut for "lane traffic signal" and "foot traffic signal" because it is rendered as two traffic signals in JOSM. Or for mapping traffic signals for crossing cyclists. But I think in every case it is better to use two different (nearby) nodes for that.
>
> Am I misunderstanding you?  You propose using two nearby nodes for
> https://goo.gl/maps/3Sg5ndQ2ZCMBN9uy9  You can just see the yellow
> pedestrian-control box at the left.  It controls the crossing (marked with studs)
> going from left to right across the picture.  The same lights that tell motorists
> to stop for pedestrians also control traffic flow at the T junction ahead.  The
> same set of lights is both a highway traffic signal and a crossing traffic signal.
> This sort of thing is not uncommon in the UK, with the same set of lights
> being used for both purposes.

My understanding was that traffic signals=crossing on demand is meant
for things like https://www.openstreetmap.org/node/2771622922 (
https://www.mapillary.com/map/im/2oyFQXVHvy2r-XypCZTECg ) however I
might be wrong? Or https://www.openstreetmap.org/node/1416834957 (
https://www.mapillary.com/map/im/DkuEFqSbOuQPGMtABsFFCA ) including
cyclists? (Esri is good for satellite imagery of these)

Personally I find highway=traffic_signals + crossing=traffic_signals
on one node sufficient for these crossings.

Currently the wiki page says "traffic_signals=crossing_on_demand makes
it easy to mark all traffic lights which do only control a crossing",
again I personally find highway=traffic_signals +
crossing=traffic_signals sufficient for that - maybe I'm missing
something. Of course any new tags can be proposed. But I would suggest
adding some real-world photos of crossings that would be tagged with
crossing_on_demand to the wiki page.

--Jarek

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

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




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

Re: [Tagging] Rarely verified and third-party data staleness in OpenStreetMap

[European Water Project]

Two illustrations based on data from Taginfo, have been added to the
staleness wiki. They show very highly concentrated tag and key
distributions.


https://wiki.openstreetmap.org/wiki/Rarely_verified_and_third-party_data_staleness_in_OpenStreetMap#OpenStreetMap_Key.2FTag_distribution_analysis


While it doesn’t seem clear whether or not these highly concentrated
distributions imply data staleness or quality, I decided to share the
illustrations because the results seemed surprising:



The total number of keys present on 57 or fewer tags in the OpenStreetMap
database represent 80% of the 76,177 keys (60,952/76,177).

74,938 out of 76,177 keys are used on just 1% of all tags in the
OpenStreetMap database.

Just 42 keys out of 76,177 keys are present on 80% of all tags
(1.7Bn/2.1Bn) in the OpenStreetMap database.


Best regards,


Stuart

On Tue, 7 Apr 2020 at 08:09, European Water Project <
europeanwaterproj...@gmail.com> wrote:

> Dear Martin,
>
> Yes, using external tables unioned to objects by opaque keys is not a very
> KISS solution. A more KISS solution would be to keep tag meta data close to
> or even better within the element itself.
>
> Assuming all tag values are stored in zero based arrays, could we not add
> a 2 byte last updated/creation date meta data value to the [-1] index. The
> overhead would be minimal, the overall OSM data structure would not have to
> be modified.
>
> Best regards,
>
> Stuart
>
> On Tue, 7 Apr 2020 at 01:30, Martin Koppenhoefer 
> wrote:
>
>>
>>
>> sent from a phone
>>
>> On 6. Apr 2020, at 16:51, Paul Allen  wrote:
>>
>> or use https://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID
>>
>>
>> I didn't even know that existed.  I'm not sure I trust such IDs to survive
>> intensive editing by newbies who can delete an object then add it
>> with quite different tags.
>>
>>
>>
>> these IDs are defined through their significant properties, if these get
>> “messed up” you may hope that someone else will fix it sooner or later.
>>
>>  Compared to this, an ID_mySpecial_App=123 tag has much more potential
>> for breakage, because following editors don’t know what it refers to (e.g.
>> the physical place or the business/service?), and often don’t know how to
>> deal with it when some properties have changed, or when they split them:
>> keep it on all parts, some parts or remove it? To solve this you’d have to
>> know what mySpecialApp does and how it uses the IDs.
>>
>> And we’d end up with a lot of different opaque foreign keys cluttering up
>> the same objects, in some cases, even if we required the linked db to be
>> free and open.
>> On the other hand there are already people adding references to
>> proprietary databases, e.g. 8 facebook urls, 2000 google ids, 500
>> foursquare. The trick is to offer message relaying and use a contact: tag
>> ;-)
>>
>> Cheers Martin
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] city limit sign end

[Volker Schmidt]

OK,

we seem to agree that city-limit-begin sign needs to have angle or cardinal
direction values and not forward|backward, because it is often or nearly
always, on a joining node of two ways due to the implied speed limit in
agglomerations, which is the rule in many European countries,

But this leaves the tagging of the city-limit-exit sign. May I repeat my
earlier question: is there any solution for this apart from the "German"
solution  pointed out
by Alexey?

On Tue, 14 Apr 2020 at 11:01, Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 13. Apr 2020, at 00:52, Marc M.  wrote:
> >
> > we do the same for stop, give_away, ...
> > and those ways may also be splitted
> > if both ways are in the same direction,
>
>
> this is equally disputed and should be discouraged as well
>
>
> > the direction is just
> > as understandable as on a node in the middle of a way.
>
>
> does it take the direction from all ways through a node or from which is
> it taken?
>
> Cheers Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - traffic_signals=crossing_on_demand

[Volker Schmidt]

What's the difference between

highway=traffic_signals plus button_poperated=yes
and
highway=traffic_signals plus traffic_signals=crossing_on_demand

?


On Tue, 14 Apr 2020 at 02:55, Jarek Piórkowski  wrote:

> On Mon, 13 Apr 2020 at 12:56, Paul Allen  wrote:
> > On Mon, 13 Apr 2020 at 17:43,  wrote:
> >> The second goal my proposal wants to message is to deprecate tagging
> "crossing=traffic_signals" together with "highway=traffic_signals" on the
> same node. Especially if you're saying this is a full crossing mapped. It
> breaks the highway=crossing - tagging scheme we use for all other types of
> crossing (except crossing=no). Some mappers use "crossing=traffic_signals"
> together with "highway=traffic_signals" on the same node als a shortcut for
> "lane traffic signal" and "foot traffic signal" because it is rendered as
> two traffic signals in JOSM. Or for mapping traffic signals for crossing
> cyclists. But I think in every case it is better to use two different
> (nearby) nodes for that.
> >
> > Am I misunderstanding you?  You propose using two nearby nodes for
> > https://goo.gl/maps/3Sg5ndQ2ZCMBN9uy9  You can just see the yellow
> > pedestrian-control box at the left.  It controls the crossing (marked
> with studs)
> > going from left to right across the picture.  The same lights that tell
> motorists
> > to stop for pedestrians also control traffic flow at the T junction
> ahead.  The
> > same set of lights is both a highway traffic signal and a crossing
> traffic signal.
> > This sort of thing is not uncommon in the UK, with the same set of lights
> > being used for both purposes.
>
> My understanding was that traffic signals=crossing on demand is meant
> for things like https://www.openstreetmap.org/node/2771622922 (
> https://www.mapillary.com/map/im/2oyFQXVHvy2r-XypCZTECg ) however I
> might be wrong? Or https://www.openstreetmap.org/node/1416834957 (
> https://www.mapillary.com/map/im/DkuEFqSbOuQPGMtABsFFCA ) including
> cyclists? (Esri is good for satellite imagery of these)
>
> Personally I find highway=traffic_signals + crossing=traffic_signals
> on one node sufficient for these crossings.
>
> Currently the wiki page says "traffic_signals=crossing_on_demand makes
> it easy to mark all traffic lights which do only control a crossing",
> again I personally find highway=traffic_signals +
> crossing=traffic_signals sufficient for that - maybe I'm missing
> something. Of course any new tags can be proposed. But I would suggest
> adding some real-world photos of crossings that would be tagged with
> crossing_on_demand to the wiki page.
>
> --Jarek
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] city limit sign end

[Martin Koppenhoefer]

sent from a phone

> On 13. Apr 2020, at 00:52, Marc M.  wrote:
> 
> we do the same for stop, give_away, ...
> and those ways may also be splitted
> if both ways are in the same direction,


this is equally disputed and should be discouraged as well


> the direction is just
> as understandable as on a node in the middle of a way.


does it take the direction from all ways through a node or from which is it 
taken?

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

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

[Manon Viou]

 
 
  
   
Hello,
   
   
Actually RFC for refugee site location mapping started March 25,
   
   
Since this day, we received and exchanged on the proposal and made changes to the former proposal, that’s what RFC is all about no?  ,
   
   
I do not know if according to this changes, we have to restart the RFC period?
   
   
We will restart RFC period if needed, let me know ! we haven’t received much comments on the latest proposal modifications, please let us know if this works for you or if amendments have to be done (
Proposed features/Refugee Site Location 2)
   
   
Have a great day,
   
   
Manon
   
   

   
  
  
   Le 11 avril 2020 à 00:03, Warin <61sundow...@gmail.com> a écrit : 
   
   
   
The minimum an RFC is required to be open is 2 weeks.
   
   

   
   
Same with voting.
   
   

   
   

   
   
On 11/4/20 1:54 am, Manon Viou wrote: 

   
   

 
  Hello all,
 
 
  
 
 
  We have modified the  
  proposed features/Refugee Site Location 2 according to discussions regarding how to best tag places sheltering refugee and/or internally displace persons. Thank you to the contributors who help finding a solution to have a consistent tagging in place for refugee location. 
  We are now suggesting to use the tag 
  amenity=refugee_site 
 
 
  
   The tag can be used alternatively on nodes or on areas:
  
  
   If the extent of the site is difficult to identify (proximity to other villages, suburban area, etc.) it is recommended to use a node.
   If the extent of the site can be clearly identified from the imagery or field data collection, it is recommended to use an area. Please note this extent does not have to match the official boundary of a camp (which doesn’t necessarily coincide to its physical limitations), as defined by government and specialized agencies, for which a dedicated tag can be used.
  
  
   Both approaches can be completed by mapping the landuse=residential of the area and if appropriate a tag place (place=neighbourhood, place=suburb, place=village) can be added in the area of the refugee site. 
  
  
   
  Please have a look at this new proposal and share your comments quickly if you have any. 
  We will close RFC period soon.
 
 
  
 
 
  Best regards,
 
 
  
 Manon


 
 Manon Viou
 Coordinatrice projet Missing Maps
  m_v...@cartong.org |  manon.viou +33 (0)4 79 26 28 82 |  +33 (0)7 83889839
  Chambéry, France - Lon: 05°55'24''N | Lat: 45°30'20''E


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

   
   ___ 
   Tagging mailing list 
   Tagging@openstreetmap.org 
   https://lists.openstreetmap.org/listinfo/tagging 
   
  
  
    
  
  
   
   Manon Viou
   Coordinatrice projet Missing Maps
m_v...@cartong.org |  manon.viou +33 (0)4 79 26 28 82 |  +33 (0)7 83889839
    Chambéry, France - Lon: 05°55'24''N | Lat: 45°30'20''E
   
 


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

Re: [Tagging] insurance health

[Joseph Eisenberg]

I would use office=health_insurance

In my experience (mostly in the USA), an office=insurance will sell
you life insurance, house or rental insurance, car insurance, travel
insurance and some other kinds, but will usually not sell health
insurance, while a health insurance office is likely to specialize.

Is that also true in Argentina?

(If you want to use a subtag, another option would be office=company
(very common tag) + company=health_insurance or something like that)

-- Joseph Eisenberg

On 4/14/20, Agustin Rissoli  wrote:
> In Argentina we want to correctly tagging offices of companies dedicated to
> what we call prepaid medicine, by paying a monthly fee you access a series
> of medical benefits.
> We are hesitating between these tags:
>
> office=health_insurance
> It has no wiki, it has 185 uses, the majority in Belgium since it was
> created in 2013, they even have a preset in JOSM.
>
> office=insurance + insurance=health
> It has a wiki, curiously created by a Belgian user in 2018, it has 66 uses.
> It is the only documented insurance=* key.
>
> What do you think would be the correct use?
>
> --
> *AGUS*!  :)
>

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