Re: [Tagging] Topographic Prominence for Peaks

[Warin]

I don't think OSM can use wikipedia as a source?
Something about incompatible licences.

How to calculate prominence will need to documented in OSM rather than refer to 
wikipoedia.


On 23/09/18 11:04, Joseph Eisenberg wrote:

For most peaks, it's only necessary to know the elevation of the
nearby saddles and peaks to find the prominence. For example, walk to
the top of the hill and record the elevation. Look around and find any
taller nearby peaks. If there is only 1 taller hill, walk down the
ridge line to the lowest point between the first hill and the taller
hill, then record the saddle elevation. Prominence is then elevation
of the first peak minus the elevation of the saddle.

It's more difficult for very prominent peaks, where the "key col" or
lowest saddle may be 1000's of kilometers away, but all of these peaks
already have prominence calculated and listed on Wikipedia:
https://en.wikipedia.org/wiki/List_of_peaks_by_prominence,
https://en.wikipedia.org/wiki/List_of_islands_by_highest_point,
https://en.wikipedia.org/wiki/List_of_Ultras_of_Africa

I just remembered that there was an abandoned proposal for this tag.
How do I revive the proposal? Just start editing the page,
https://wiki.openstreetmap.org/wiki/Proposed_features/key:prominence
Or make a new page?

Joseph

On 9/23/18, Warin <61sundow...@gmail.com> wrote:

On 23/09/18 10:00, Joseph Eisenberg wrote:

I've been tagging peaks (natural=peak) with the key
prominence=

Prominence is a natural feature with a use similar to elevation. When
I see ele=*, I know how high the top of the peak is, but not how tall
the peak is compared to the surrounding land. For example, a hill in
my valley may have ele=2000m, but it isn't a mountain: it's a 300m
hill that rises out of surrounding land at 1700m.

Prominence is calculated by subtracting the elevation of the lowest
saddle (or "col") from the elevation of the peak:

https://en.wikipedia.org/wiki/Topographic_prominence

"The prominence of a peak is the minimum height necessary to descend
to get from the summit to any higher terrain" or "the height of the
peak’s summit above the lowest contour line encircling it but
containing no higher summit within it."

Both of these definitions are the same for all peaks except for the
highest peak on a landmass, eg Mount Everest in Eurasia: in this case
use the second definition, which means that the tallest peak on a
(super-)continent or island is the same as it's elevation.

This started when I became interested in "peak bagging", where hikers
and climbers record the peaks they have summited. There are separate
categories based on the prominence of a peak. Gunungbagging.com in
Indonesia lists elevation, prominence and names for many peaks here in
Indonesia, and the site authors gave permission for the data to be
added to Openstreetmap.

There are other lists of prominent peaks for the rest of the world,
but please check if you can use the data based on the license, before
adding it to OSM.

Elevation and prominence can both be calculated from SRTM data, eg by
using Opentopomap tiles and finding the highest contour lines around a
peak, and the lowest near a saddle.

Prominence and elevation can be calculated by computer with good data,
but for my part of the world the SRTM data is not high enough quality
to get good results without cross-checking against aerial imagery.
Also the calculations are not simple, and are not precise for sharply
pointed peaks or deeply carved saddles, therefore I believe it will be
useful to include this data directly in tags.

I also find that calculation the prominence of peaks has encouraged me
to add more ridge lines and saddle points (with elevations), which
should make the database more useful in mountainous areas.

Do you think I should write up a formal proposal for this tag?


Yes to documenting it.

The evaluation of 'prominence' would be to some local area .. what is the
size of that area?


Some will say a formal proposal is 'best'. It is up to you to decide what is
'best'.
But by all means discuss it here.


___
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] JOSM error for a bus lane conditional

[Warin]

Hi,


There is a past entry of

lanes:bus:conditional=1 @ (Mo-Fr 06:00-10:00,15:00-19:00)


That JOSM says is incorrect. There is a declared 2 lanes there on the way.

What is wrong with that tagging? One lane for buses between 6 to 10 and 
15 to 19 hundred hours.




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

Re: [Tagging] Topographic Prominence for Peaks

[Peter Elderson]

Edi & change status, I would say. Seems a pretty clear case, just maybe not
something many mappers or users are very concerned with. But that's not a
problem as long as there is a clear definition, solid data and a steady
group of mappers/users. I would say, just do it and document it.

Op zo 23 sep. 2018 om 03:05 schreef Joseph Eisenberg <
joseph.eisenb...@gmail.com>:

> For most peaks, it's only necessary to know the elevation of the
> nearby saddles and peaks to find the prominence. For example, walk to
> the top of the hill and record the elevation. Look around and find any
> taller nearby peaks. If there is only 1 taller hill, walk down the
> ridge line to the lowest point between the first hill and the taller
> hill, then record the saddle elevation. Prominence is then elevation
> of the first peak minus the elevation of the saddle.
>
> It's more difficult for very prominent peaks, where the "key col" or
> lowest saddle may be 1000's of kilometers away, but all of these peaks
> already have prominence calculated and listed on Wikipedia:
> https://en.wikipedia.org/wiki/List_of_peaks_by_prominence,
> https://en.wikipedia.org/wiki/List_of_islands_by_highest_point,
> https://en.wikipedia.org/wiki/List_of_Ultras_of_Africa
>
> I just remembered that there was an abandoned proposal for this tag.
> How do I revive the proposal? Just start editing the page,
> https://wiki.openstreetmap.org/wiki/Proposed_features/key:prominence
> Or make a new page?
>
> Joseph
>
> On 9/23/18, Warin <61sundow...@gmail.com> wrote:
> > On 23/09/18 10:00, Joseph Eisenberg wrote:
> >> I've been tagging peaks (natural=peak) with the key
> >> prominence=
> >>
> >> Prominence is a natural feature with a use similar to elevation. When
> >> I see ele=*, I know how high the top of the peak is, but not how tall
> >> the peak is compared to the surrounding land. For example, a hill in
> >> my valley may have ele=2000m, but it isn't a mountain: it's a 300m
> >> hill that rises out of surrounding land at 1700m.
> >>
> >> Prominence is calculated by subtracting the elevation of the lowest
> >> saddle (or "col") from the elevation of the peak:
> >>
> >> https://en.wikipedia.org/wiki/Topographic_prominence
> >>
> >> "The prominence of a peak is the minimum height necessary to descend
> >> to get from the summit to any higher terrain" or "the height of the
> >> peak’s summit above the lowest contour line encircling it but
> >> containing no higher summit within it."
> >>
> >> Both of these definitions are the same for all peaks except for the
> >> highest peak on a landmass, eg Mount Everest in Eurasia: in this case
> >> use the second definition, which means that the tallest peak on a
> >> (super-)continent or island is the same as it's elevation.
> >>
> >> This started when I became interested in "peak bagging", where hikers
> >> and climbers record the peaks they have summited. There are separate
> >> categories based on the prominence of a peak. Gunungbagging.com in
> >> Indonesia lists elevation, prominence and names for many peaks here in
> >> Indonesia, and the site authors gave permission for the data to be
> >> added to Openstreetmap.
> >>
> >> There are other lists of prominent peaks for the rest of the world,
> >> but please check if you can use the data based on the license, before
> >> adding it to OSM.
> >>
> >> Elevation and prominence can both be calculated from SRTM data, eg by
> >> using Opentopomap tiles and finding the highest contour lines around a
> >> peak, and the lowest near a saddle.
> >>
> >> Prominence and elevation can be calculated by computer with good data,
> >> but for my part of the world the SRTM data is not high enough quality
> >> to get good results without cross-checking against aerial imagery.
> >> Also the calculations are not simple, and are not precise for sharply
> >> pointed peaks or deeply carved saddles, therefore I believe it will be
> >> useful to include this data directly in tags.
> >>
> >> I also find that calculation the prominence of peaks has encouraged me
> >> to add more ridge lines and saddle points (with elevations), which
> >> should make the database more useful in mountainous areas.
> >>
> >> Do you think I should write up a formal proposal for this tag?
> >>
> >
> > Yes to documenting it.
> >
> > The evaluation of 'prominence' would be to some local area .. what is the
> > size of that area?
> >
> > 
> > Some will say a formal proposal is 'best'. It is up to you to decide
> what is
> > 'best'.
> > But by all means discuss it here.
> >
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
> >
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Vr gr Peter Elderson
___
Tagging mailing list

Re: [Tagging] Topographic Prominence for Peaks

[Joseph Eisenberg]

For most peaks, it's only necessary to know the elevation of the
nearby saddles and peaks to find the prominence. For example, walk to
the top of the hill and record the elevation. Look around and find any
taller nearby peaks. If there is only 1 taller hill, walk down the
ridge line to the lowest point between the first hill and the taller
hill, then record the saddle elevation. Prominence is then elevation
of the first peak minus the elevation of the saddle.

It's more difficult for very prominent peaks, where the "key col" or
lowest saddle may be 1000's of kilometers away, but all of these peaks
already have prominence calculated and listed on Wikipedia:
https://en.wikipedia.org/wiki/List_of_peaks_by_prominence,
https://en.wikipedia.org/wiki/List_of_islands_by_highest_point,
https://en.wikipedia.org/wiki/List_of_Ultras_of_Africa

I just remembered that there was an abandoned proposal for this tag.
How do I revive the proposal? Just start editing the page,
https://wiki.openstreetmap.org/wiki/Proposed_features/key:prominence
Or make a new page?

Joseph

On 9/23/18, Warin <61sundow...@gmail.com> wrote:
> On 23/09/18 10:00, Joseph Eisenberg wrote:
>> I've been tagging peaks (natural=peak) with the key
>> prominence=
>>
>> Prominence is a natural feature with a use similar to elevation. When
>> I see ele=*, I know how high the top of the peak is, but not how tall
>> the peak is compared to the surrounding land. For example, a hill in
>> my valley may have ele=2000m, but it isn't a mountain: it's a 300m
>> hill that rises out of surrounding land at 1700m.
>>
>> Prominence is calculated by subtracting the elevation of the lowest
>> saddle (or "col") from the elevation of the peak:
>>
>> https://en.wikipedia.org/wiki/Topographic_prominence
>>
>> "The prominence of a peak is the minimum height necessary to descend
>> to get from the summit to any higher terrain" or "the height of the
>> peak’s summit above the lowest contour line encircling it but
>> containing no higher summit within it."
>>
>> Both of these definitions are the same for all peaks except for the
>> highest peak on a landmass, eg Mount Everest in Eurasia: in this case
>> use the second definition, which means that the tallest peak on a
>> (super-)continent or island is the same as it's elevation.
>>
>> This started when I became interested in "peak bagging", where hikers
>> and climbers record the peaks they have summited. There are separate
>> categories based on the prominence of a peak. Gunungbagging.com in
>> Indonesia lists elevation, prominence and names for many peaks here in
>> Indonesia, and the site authors gave permission for the data to be
>> added to Openstreetmap.
>>
>> There are other lists of prominent peaks for the rest of the world,
>> but please check if you can use the data based on the license, before
>> adding it to OSM.
>>
>> Elevation and prominence can both be calculated from SRTM data, eg by
>> using Opentopomap tiles and finding the highest contour lines around a
>> peak, and the lowest near a saddle.
>>
>> Prominence and elevation can be calculated by computer with good data,
>> but for my part of the world the SRTM data is not high enough quality
>> to get good results without cross-checking against aerial imagery.
>> Also the calculations are not simple, and are not precise for sharply
>> pointed peaks or deeply carved saddles, therefore I believe it will be
>> useful to include this data directly in tags.
>>
>> I also find that calculation the prominence of peaks has encouraged me
>> to add more ridge lines and saddle points (with elevations), which
>> should make the database more useful in mountainous areas.
>>
>> Do you think I should write up a formal proposal for this tag?
>>
>
> Yes to documenting it.
>
> The evaluation of 'prominence' would be to some local area .. what is the
> size of that area?
>
> 
> Some will say a formal proposal is 'best'. It is up to you to decide what is
> 'best'.
> But by all means discuss it here.
>
>
> ___
> 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] Topographic Prominence for Peaks

[Warin]

On 23/09/18 10:00, Joseph Eisenberg wrote:

I've been tagging peaks (natural=peak) with the key
prominence=

Prominence is a natural feature with a use similar to elevation. When
I see ele=*, I know how high the top of the peak is, but not how tall
the peak is compared to the surrounding land. For example, a hill in
my valley may have ele=2000m, but it isn't a mountain: it's a 300m
hill that rises out of surrounding land at 1700m.

Prominence is calculated by subtracting the elevation of the lowest
saddle (or "col") from the elevation of the peak:

https://en.wikipedia.org/wiki/Topographic_prominence

"The prominence of a peak is the minimum height necessary to descend
to get from the summit to any higher terrain" or "the height of the
peak’s summit above the lowest contour line encircling it but
containing no higher summit within it."

Both of these definitions are the same for all peaks except for the
highest peak on a landmass, eg Mount Everest in Eurasia: in this case
use the second definition, which means that the tallest peak on a
(super-)continent or island is the same as it's elevation.

This started when I became interested in "peak bagging", where hikers
and climbers record the peaks they have summited. There are separate
categories based on the prominence of a peak. Gunungbagging.com in
Indonesia lists elevation, prominence and names for many peaks here in
Indonesia, and the site authors gave permission for the data to be
added to Openstreetmap.

There are other lists of prominent peaks for the rest of the world,
but please check if you can use the data based on the license, before
adding it to OSM.

Elevation and prominence can both be calculated from SRTM data, eg by
using Opentopomap tiles and finding the highest contour lines around a
peak, and the lowest near a saddle.

Prominence and elevation can be calculated by computer with good data,
but for my part of the world the SRTM data is not high enough quality
to get good results without cross-checking against aerial imagery.
Also the calculations are not simple, and are not precise for sharply
pointed peaks or deeply carved saddles, therefore I believe it will be
useful to include this data directly in tags.

I also find that calculation the prominence of peaks has encouraged me
to add more ridge lines and saddle points (with elevations), which
should make the database more useful in mountainous areas.

Do you think I should write up a formal proposal for this tag?



Yes to documenting it.

The evaluation of 'prominence' would be to some local area .. what is the size 
of that area?


Some will say a formal proposal is 'best'. It is up to you to decide what is 
'best'.
But by all means discuss it here.


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

[Tagging] Topographic Prominence for Peaks

[Joseph Eisenberg]

I've been tagging peaks (natural=peak) with the key
prominence=

Prominence is a natural feature with a use similar to elevation. When
I see ele=*, I know how high the top of the peak is, but not how tall
the peak is compared to the surrounding land. For example, a hill in
my valley may have ele=2000m, but it isn't a mountain: it's a 300m
hill that rises out of surrounding land at 1700m.

Prominence is calculated by subtracting the elevation of the lowest
saddle (or "col") from the elevation of the peak:

https://en.wikipedia.org/wiki/Topographic_prominence

"The prominence of a peak is the minimum height necessary to descend
to get from the summit to any higher terrain" or "the height of the
peak’s summit above the lowest contour line encircling it but
containing no higher summit within it."

Both of these definitions are the same for all peaks except for the
highest peak on a landmass, eg Mount Everest in Eurasia: in this case
use the second definition, which means that the tallest peak on a
(super-)continent or island is the same as it's elevation.

This started when I became interested in "peak bagging", where hikers
and climbers record the peaks they have summited. There are separate
categories based on the prominence of a peak. Gunungbagging.com in
Indonesia lists elevation, prominence and names for many peaks here in
Indonesia, and the site authors gave permission for the data to be
added to Openstreetmap.

There are other lists of prominent peaks for the rest of the world,
but please check if you can use the data based on the license, before
adding it to OSM.

Elevation and prominence can both be calculated from SRTM data, eg by
using Opentopomap tiles and finding the highest contour lines around a
peak, and the lowest near a saddle.

Prominence and elevation can be calculated by computer with good data,
but for my part of the world the SRTM data is not high enough quality
to get good results without cross-checking against aerial imagery.
Also the calculations are not simple, and are not precise for sharply
pointed peaks or deeply carved saddles, therefore I believe it will be
useful to include this data directly in tags.

I also find that calculation the prominence of peaks has encouraged me
to add more ridge lines and saddle points (with elevations), which
should make the database more useful in mountainous areas.

Do you think I should write up a formal proposal for this tag?

-Joseph

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

Re: [Tagging] Area of Firestations / Area of Ambulancestations

[Warin]

On 23/09/18 07:54, Martin Koppenhoefer wrote:


sent from a phone


On 22. Sep 2018, at 17:53, Colin Smale  wrote:

Opening_hours should cover this, i.e. when can the public just turn up and 
speak to someone. But that is not going to be an emergency.


maybe service_times could cover it, opening_hours are about something different.


I think opening hours is ok.

A plumber's office may only be open certain hours, but may offer an 'emergency' 
service.

That means the office has 'opening hours'.

I would imagine it could be similar with fire stations, they can have opening 
hours but that does not stop them responding in an emergency outside the 
'office' hours.


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

Re: [Tagging] Area of Firestations / Area of Ambulancestations

[Colin Smale]

On 2018-09-22 23:54, Martin Koppenhoefer wrote:

> sent from a phone
> 
>> On 22. Sep 2018, at 17:53, Colin Smale  wrote:
>> 
>> Opening_hours should cover this, i.e. when can the public just turn up and 
>> speak to someone. But that is not going to be an emergency.
> 
> maybe service_times could cover it, opening_hours are about something 
> different.

I agree they are different but the wiki infers that service_times are
more individual times (i.e. not periods) and the German wiki says that
service_times are for religous services! To my mind, opening_hours still
seems to fit best. After all. in that regard a police station is no
different to a shop, is it?___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Area of Firestations / Area of Ambulancestations

[Martin Koppenhoefer]

sent from a phone

> On 22. Sep 2018, at 17:53, Colin Smale  wrote:
> 
> Opening_hours should cover this, i.e. when can the public just turn up and 
> speak to someone. But that is not going to be an emergency.


maybe service_times could cover it, opening_hours are about something different.


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

Re: [Tagging] maxspeed:type vs source:maxspeed // StreetComplete

[Martin Koppenhoefer]

sent from a phone

> On 22. Sep 2018, at 23:48, Tobias Zwick  wrote:
> 
> What do you mean, what is the difference?
> 
> maxspeed:conditional=xx @ (weight > yy) would be the former or the latter?


in German: zulässiges Gesamtgewicht vs. Gewicht
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] maxspeed:type vs source:maxspeed // StreetComplete

[Tobias Zwick]

What do you mean, what is the difference?

maxspeed:conditional=xx @ (weight > yy) would be the former or the latter?

On 22/09/2018 16:20, Martin Koppenhoefer wrote:
> 
> 
> sent from a phone
> 
>> On 22. Sep 2018, at 14:22, Tobias Zwick  wrote:
>>
>> But let's look at some other countries for the default urban speed limit.
> 
> 
> are these actual weight numbers, or max gross weight?
> 
> 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] Emergency=levee_breach_materials

[Anton Klim]

Why not levee_repair?
Good to know they have a name and a list

2018-09-22 9:12 GMT+01:00 John Willis :

>
>
> On Sep 21, 2018, at 4:09 PM, Anton Klim  wrote:
>
> Do these have anything to identify them, like a ref?
>
>
> I found a sign cycling today.
>
> 奥戸防災ステーション
>
> Okudo (village) "Disaster prevention station"
>
> The "river" is implied - "river disaster prevention station" is a huge
> mouthful.
>
> The government has a PDF listing of a hundred of them and their addresses.
> These might be the very large stations with a highground and a helipad, not
> just a cache of breakwater blocks and gravel.
>
> I will investigate further, but levee_breach_materials might be the most
> flexible for uses elsewhere.
>
> http://www.mlit.go.jp/river/toukei_chousa/kasen_db/pdf/2018/4-2-3.pdf
>
>
> Javbw
>
>
> ___
> 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 - Voting - Toll Gantry

[Martin Koppenhoefer]

sent from a phone

> On 22. Sep 2018, at 23:12, Volker Schmidt  wrote:
> 
> The proposed highway=toll_gantry is one possibility.
> It woud prefer something like
> highway=gantry
> gantry=traffic_signals | speed_camera | automatic_toll_collection | ...


then I would go for man_made (tagging the naked structure and adding functions 
with other tags), but we already have different tagging established for those 
you mention, only the automatic toll collection is missing.

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

Re: [Tagging] Feature Proposal - Voting - Toll Gantry

[Volker Schmidt]

In OSM at present there are some twenty gantries for toll collection tagged
as highway=toll_bridge. They should be retagged as gantries with equipment
for toll collection or whatever their purpose is. The proposed
highway=toll_gantry is one possibility.
It woud prefer something like
highway=gantry
gantry=traffic_signals | speed_camera | automatic_toll_collection | ...

On 22 September 2018 at 23:01, Colin Smale  wrote:

> On 2018-09-22 22:50, Volker Schmidt wrote:
>
> A toll_bridge [1] is a bridge for which you have to pay to pass,
> highway=toll_bridge should be a highway that is a toll-bridge, not a
> mechanical structure that is installed above a road to check the passing
> traffic. This would be a gantry [2] https://en.wikipedia.org/wiki/
> Gantry_(road_sign)
>
>
> Exactly. A toll bridge should be highway=motorway (or whatever) +
> bridge=yes + toll=yes in OSM.
>
> A gantry is only the structure; it might carry all manner of devices in
> any combination, and even if it had no devices on it, it would still be a
> gantry...
>
>
>
> ___
> 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 - Voting - Toll Gantry

[Martin Koppenhoefer]

sent from a phone

> On 22. Sep 2018, at 22:50, Volker Schmidt  wrote:
> 
> A toll_bridge [1] is a bridge for which you have to pay to pass, 
> highway=toll_bridge should be a highway that is a toll-bridge, not a 
> mechanical structure that is installed above a road to check the passing 
> traffic.


I see, thank you for this remark. For highways that are toll bridges we already 
have a tag: toll=yes on the highway. It will have the highway class the road 
has, so we won’t be able to use highway=toll_bridge for toll bridges (but I 
agree that “toll bridge” apparently in English has not  the same meaning as is 
the German term Mautbrücke (meaning both, toll bridge and gantry)).

The 64 instances of highway=toll_bridge are all tagged on nodes: 
https://taginfo.openstreetmap.org/tags/highway=toll_bridge

what about 
highway=gantry or toll_gantry or man_made=gantry?
The latter has most usage, 2127:
https://taginfo.openstreetmap.org/tags/man_made=gantry

Cheers,
Martin___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature proposal - RFC - assembly_point:purpose

[John Willis]

> On Sep 22, 2018, at 11:03 PM, Daniele Santini  wrote:
> 
> edit the proposal substituting the old tag and values with the new tags or 
> create a new proposal with the new tags?

If you feel the original proposal (or the discussion around it) is valuable, 
start a new one. If it is of minor or no importance, just rewrite the existing 
page. You can note "originally started as assembly_point:purpose=tsunami, etc., 
 "

Under "rationale", you can use it as an example where assigning a single value 
is not flexible enough to accurately tag the multi-use nature of most 
assembly_points. 

This will also document the originally proposed tag's role in refining the 
currently proposed one, and show up in OSM searches without leading to a dead 
proposal page. 

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

Re: [Tagging] Feature Proposal - Voting - Toll Gantry

[Colin Smale]

On 2018-09-22 22:50, Volker Schmidt wrote:

> A toll_bridge [1] is a bridge for which you have to pay to pass, 
> highway=toll_bridge should be a highway that is a toll-bridge, not a 
> mechanical structure that is installed above a road to check the passing 
> traffic. This would be a gantry [2] 
> https://en.wikipedia.org/wiki/Gantry_(road_sign)

Exactly. A toll bridge should be highway=motorway (or whatever) +
bridge=yes + toll=yes in OSM. 

A gantry is only the structure; it might carry all manner of devices in
any combination, and even if it had no devices on it, it would still be
a gantry...___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - Toll Gantry

[Volker Schmidt]

A toll_bridge [1] is a bridge for which you have to pay to pass,
highway=toll_bridge should be a highway that is a toll-bridge, not a
mechanical structure that is installed above a road to check the passing
traffic. This would be a gantry [2]
https://en.wikipedia.org/wiki/Gantry_(road_sign)

[1] https://en.wikipedia.org/wiki/Toll_bridge
[2] https://en.wikipedia.org/wiki/Gantry_(road_sign)




On 22 September 2018 at 16:13, Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 19. Sep 2018, at 23:23, Jonathon McClung 
> wrote:
> >
> > The tag barrier=toll_booth is currently not specific. In fact, when it
> is used in the case of a non-barrier electronic toll gantry, it is
> misleading.
>
>
>
> maybe it is even mistagged? Looking at taginfo I see 64
> highway=toll_bridge. According to the longstanding definition for
> barrier=toll_booth it is „A place where a road usage toll or fee is
> collected.“
>
> Now „collected“ is not actually true for systems that wirelessly check
> whether you have paid or not (a subscription), it is only intended for
> places where you actually pay (or spend your prepaid, even wirelessly).
>
> the barrier key somehow implies either you pay or you don’t pass
>
>
>
> > In its relation to routing software there is currently no standard way
> to tell the routing software that this “toll booth” is not a barrier.
>
>
> and maybe no booth either? To me highway=toll_bridge seems a good tag, as
> it is self explanatory and combinable with barrier tags.
>
> 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] maxspeed:type vs source:maxspeed // StreetComplete

[SelfishSeahorse]

On Wednesday, September 19, 2018, Tobias Zwick  wrote:
>>> Anyway, for a beginner : is one key even better ? -> should we allow
>>> “maxspeed=no_sign” ? Or/and “maxspeed=default” ?
>>
>> Way too ambiguous to be remotely workable in North America.
>
> Is it? I think what djakk is arguing for, and me as well, is to separate
> the information stored in "source:maxspeed":
> 
>
> 1. Information about whether there is a sign or not (=whether a
>default speed applies or not)
>
> 2. Auxiliary information, if necessary, to automatically infer the
>speed limit from the given OSM tags.

+1. This seems to be the best solution for unsigned speed limits.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Why isn't the amenity=parking object part of the relation ?

[SelfishSeahorse]

On Friday, September 14, 2018, Martin Koppenhoefer 
wrote:
> Here is an example for a site with a parking where you can't use a
multipolygon (as the shop is a node), ignore the "role" name, I just made
it up and it is not standard, and there are no other tags on the site for
the moment.
> https://www.openstreetmap.org/relation/7040820

I've never used site relations for customer parkings of shops, but only
tagged such parkings operator= (+ access=customers). Now i'm
wondering if this is enough, especially as  usually isn't
unique.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Area of Firestations / Area of Ambulancestations

[Philip Barnes]

On 22 September 2018 16:53:23 BST, Colin Smale  wrote:
>On 2018-09-22 17:24, Martin Koppenhoefer wrote:
>
>> The thing about a (non-) emergency police station could be that some
>police stations close (at night, at noon, on weekends), so you would
>not rely on them for emergencies.
>
>In an emergency you don't go to the {police,ambulance,fire} station,
>you
>dial 112 / 999 / 911. What is the use of having the "emergency" tag? 
>Opening_hours should cover this, i.e. when can the public just turn up
>and speak to someone. But that is not going to be an emergency. 
>
>There are also "remote police stations" with a video link to a main
>location.

Fire Stations have what is known as a 'Running Call' phone outside which 
connects you to the control room. I assume the police and ambulance stations do 
too. 

Although in these days of mobile phones I doubt they have much use. Where I am 
at the moment (pub) is about 100m from the fire station, but I would use my 
mobile if I needed the fire brigade. 



-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

Re: [Tagging] Area of Firestations / Area of Ambulancestations

[Colin Smale]

On 2018-09-22 17:24, Martin Koppenhoefer wrote:

> The thing about a (non-) emergency police station could be that some police 
> stations close (at night, at noon, on weekends), so you would not rely on 
> them for emergencies.

In an emergency you don't go to the {police,ambulance,fire} station, you
dial 112 / 999 / 911. What is the use of having the "emergency" tag? 
Opening_hours should cover this, i.e. when can the public just turn up
and speak to someone. But that is not going to be an emergency. 

There are also "remote police stations" with a video link to a main
location.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] maxspeed:type vs source:maxspeed // StreetComplete

[Thilo Haug OSM]

You just forgot to mention the table would solve this :-)
https://wiki.openstreetmap.org/wiki/Default_speed_limits#The_table

And there should be a link to it on these pages :
https://wiki.openstreetmap.org/wiki/Speed_limits#Country_code.2Fcategory_conversion_table
https://wiki.openstreetmap.org/wiki/Key:maxspeed

Perhaps there should also be a new value maxspeed=default,
to express the road's speed limit refers to this table
(where "default" links to the wiki page) ?

Am 22.09.18 um 14:32 schrieb Colin Smale:
>
> Well said, I agree wholeheartedly. A local, anecdotal view is in
> itself not enough to produce a data model that works for everyone.
>
>  
>
>
> On 2018-09-22 14:22, Tobias Zwick wrote:
>
>> Tagging an implicit speed limit explicitly for example in town with
>> maxspeed=50 is straightforward enough for Germany. It seems natural that
>> no specialist knowledge is required for that kind of thing. For a German.
>>
>> But let's look at some other countries for the default urban speed limit.
>>
>> Spain (ES):
>> maxspeed=50
>> maxspeed:hazmat=40
>>
>> Chile (CL):
>> maxspeed=60
>> maxspeed:bus=50
>> maxspeed:hgv=50
>>
>> Hungary (HR):
>> maxspeed=50
>> maxspeed:tricycle=40
>>
>> Kerala in India (IN-KL):
>> maxspeed=50
>> maxspeed:conditional=40 @ (weight > 7.5)
>> maxspeed:trailer=40
>> maxspeed:bus_articulated=40
>> maxspeed:hgv_articulated=40
>> maxspeed:bus:conditional=40 @ (weight > 7.5)
>> maxspeed:hgv:conditional=40 @ (weight > 7.5)
>> maxspeed:tricycle=30
>>
>> Punjab in India (IN-PB):
>> maxspeed=50
>> maxspeed:trailer=35
>> maxspeed:bus_articulated=30
>> maxspeed:hgv_articulated=30
>> maxspeed:hgv=45
>> maxspeed:hgv:conditional=40 @ (weight > 6)
>> maxspeed:conditional=40 @ (weight > 6)
>> maxspeed:trailer:conditional=30 @ (weight > 6)
>> maxspeed:motorcycle=35
>> maxspeed:goods=45
>> maxspeed:goods:conditional=40 @ (weight > 6)
>>
>> Malta (MT):
>> maxspeed=50
>> maxspeed:bus=40
>> maxspeed:hgv=30
>> maxspeed:goods=40
>> maxspeed:goods:conditional=30 @ (weight > 3)
>>
>> Poland (PL):
>> maxspeed=50
>> maxspeed:conditional=60 @ (23:00-05:00)
>>
>> Zambia (ZM):
>> maxspeed=50
>> maxspeed:conditional=40 @ (weight > 2.275)
>> maxspeed:trailer=40
>> maxspeed:hgv=40
>>
>> Because the maxspeed tag applies to all vehicles except overridden for a
>> specific vehicle type or a conditional, specifying only maxspeed=50 in
>> any of the above cases has to be considered wrong or at least
>> incomplete. In other words, the tags you see above would need to be
>> added in the case the speed limit is given explicitly. It is not so
>> straightforward then anymore.
>>
>> So, maybe not for Germany, but as you see, in other places, this *is*
>> specialist knowledge. No regular car driver in Punjab will be able to
>> enumerate all these maxspeed rules. And, taking a less extreme example,
>> I think the Polish OSM contributors wouldn't want to add this
>> maxspeed:conditional=60 @ (23:00-05:00) to every single unsigned street
>> in urban areas.
>>
>> Also, note this is only the urban speed limit, trust me, the default
>> speed limit "for all other roads" (=rural) can be much more complex.
>>
>> Actually, don't trust me, see for yourself in the document I link all
>> the time in the hope people would read it:
>> https://wiki.openstreetmap.org/wiki/Default_speed_limits
>>
>> We can not get to any results or any progress on the matter of default
>> speed limits (or for any topic, for that matter) if everyone just keeps
>> arguing out of his best knowledge about his home region or country only.
>>
>> "It works for me" is simply not good enough for a global project.
>>
>> Cheers
>> Tobias
>>
>> On 22/09/2018 01:03, Martin Koppenhoefer wrote:
>>>
>>>
>>> sent from a phone
>>>
 On 19. Sep 2018, at 21:16, Tobias Zwick >>> > wrote:

 This is a good argument against tagging an explicit maxspeed=X when
 there is actually no speed limit sign around (X is what the OSM mapper
 by his knowledge about the law thinks should be the default limit
 here).
>>>
>>>
>>> everything that you map will be according to your understanding of
>>> it, I cannot see a good argument for not tagging implicit limits,
>>> even more as there is judgement needed based on the situation
>>> (something humans can do much better than computers). Every holder
>>> of a driving license should have the requisites to recognize the
>>> speed limit on a given piece of road in their local area, so it
>>> doesn't require specialist knowledge.
>>>
>>> We already have a reliable way to distinguish implicit from explicit
>>> limits (we even have several of them), if you want to treat them
>>> differently in your app, you can do it.
>>>
>>> There actually is a speed limit on most roads, including those
>>> without explicit signage. Omitting it will leave us in the situation
>>> that it really becomes unclear whether there is no sign or nobody
>>> has bothered to enter it.
>>>
>>> Cheers,
>>> Martin
>>> 

Re: [Tagging] Area of Firestations / Area of Ambulancestations

[Thilo Haug OSM]

Hi all,

I think this should be discussed here (centrally) :
https://wiki.openstreetmap.org/wiki/Talk:WikiProject_Emergency_Cleanup#amenity.3D.2A_vs._emergency.3D.2A

Generally I don't understand why the parameters can't be "mixed"
(a police station is a police station, whether for emergency or not,
same for ambulance).
Then you could add the offered "services" ("below" the "main" tag).

So the discussion shouldn't be in which case to use amenity or emergency
(how to differentiate them),
but how to establish a namespace which allows to express all of the
possible "mixtures".
In any language the meaning of a sentence is based on the context in
which words are used,
so why not a structured mixture of possible expressions instead of too
generic ones ?

I think we should broaden the usage of namespaces
and define the way how they should be used (in general),
also expand the examples of already used namespaces :
https://wiki.openstreetmap.org/wiki/Namespace#Example_namespace_uses

This might IMHO avoid a lot of discussions about "generic" tags
as it would provide a kind of "grammar" to express details.

Cheers,
Thilo

Am 22.09.18 um 10:11 schrieb dktue:
>
>
> Am 22.09.2018 um 00:29 schrieb Warin:
>> On 21/09/18 23:52, Martin Koppenhoefer wrote:
>>>
>>> sent from a phone
>>>
 On 21. Sep 2018, at 11:28, dktue  wrote:

 but: it's not amenity=ambulance_station we're using at the moment.
 We're using emergency=ambulance_station -- so: How do we solve this?
>>>
>>> I’m not sure what an ambulance station is, but not all of the
>>> features I have in mind (a place where ambulances and their staff
>>> are parked and waiting for orders, usually with a coordinating
>>> office and radio unit) are emergency related. Some organizations
>>> only provide ambulance transports for people with special requirements.
>>>
>>
>> Here 'patent transport' is provided by the same organisation that
>> provides ambulances.
>>
>> They are co-located and have very similar vehicles, different colours
>> and lettering. The staff that man them have less training.
>>
>>
>> If they were completely separate then I'd use different tags. But
>> what tags to use?
>> Not emergency as they are scheduled and not urgent. Amenity?
>> amenity=patient_transport?
>>
> Same here -- some organisation provide emergency medical services
> _and_ patient transport, some do only emergency medical services and
> some do only patient transport. I think there really is a need to
> differentiate that.
>
> ___
> 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] maxspeed:type vs source:maxspeed // StreetComplete

[Martin Koppenhoefer]

sent from a phone

> On 22. Sep 2018, at 14:22, Tobias Zwick  wrote:
> 
> But let's look at some other countries for the default urban speed limit.


are these actual weight numbers, or max gross weight?

Cheers,
Martin

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

Re: [Tagging] Feature Proposal - Voting - Toll Gantry

[Martin Koppenhoefer]

sent from a phone

> On 19. Sep 2018, at 23:23, Jonathon McClung  wrote:
> 
> The tag barrier=toll_booth is currently not specific. In fact, when it is 
> used in the case of a non-barrier electronic toll gantry, it is misleading.



maybe it is even mistagged? Looking at taginfo I see 64 highway=toll_bridge. 
According to the longstanding definition for barrier=toll_booth it is „A place 
where a road usage toll or fee is collected.“

Now „collected“ is not actually true for systems that wirelessly check whether 
you have paid or not (a subscription), it is only intended for places where you 
actually pay (or spend your prepaid, even wirelessly). 

the barrier key somehow implies either you pay or you don’t pass 



> In its relation to routing software there is currently no standard way to 
> tell the routing software that this “toll booth” is not a barrier.


and maybe no booth either? To me highway=toll_bridge seems a good tag, as it is 
self explanatory and combinable with barrier tags.

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

Re: [Tagging] Feature proposal - RFC - assembly_point:purpose

[Daniele Santini]

> Message: 7
> Date: Sat, 22 Sep 2018 06:42:30 +0900
> From: John Willis 
> To: "Tag discussion, strategy and related tools"
> 
> Subject: Re: [Tagging] Feature proposal - RFC - assembly_point:purpose
> Message-ID: <688ef169-5441-4a7b-819f-3764eac4c...@mac.com>
> Content-Type: text/plain; charset=us-ascii
>
>
>
> > On Sep 22, 2018, at 5:17 AM, Volker Schmidt  wrote:
> >
> > Problem: most assembly points are multi-purpose around here. At least
> fire and earthquake. And they are not marked with a purpose.
>
>
> Very true - I think most people assume an assembly point is "safe", as the
> location is chosen because it is low-risk for many types of disasters.
>
> Perhaps we need to have a few assembly_point:foobar=yes, in case people
> want to map a specific aspect of one - especially if it is *not* good for
> one aspect.
>
> Tsunami (height in M)
> Earthquake
> Fire
> Landslide
> Flood (out of the path of a possible dam breach, levee break, or flash
> floods.
> Tornado (assumed no, yes has to be explicit)
>
> With certian assembly points, the idea it is "safe" from a tsunami is very
> important. Tornadoes will be basements/bunkers/buried shelters, possibly
> fallout shelters.
>
> But this would be a very small minority of assembly_points. Most will have
> no :foobar=tags.
>
> Perhaps if we can say :tsunami=25 means it is 25m above sea level (the
> safe top of the structure) or tsunami=yes/no to say at least go/don't go
> here. Same with tornado.
>
> Many of the assembly points in Japan are chosen specifically because they
> will not be flooded if a nearby dam bursts, to be away from known landslide
> risks, and to have no tall buildings nearby to fall in an earthquake.
>
> :Purpose=foobar locks you into a certian purpose, Whereas :tsunami=yes
> just means it is "safe" from a tsunami - *if you care to map that*.
>
> Besides tornado, all are implied yes, so an the assembly point inherits
> all the implied traits.
>
> Javbw.
>
This makes sense.
Should I edit the existng proposal adding this alternative, edit the
proposal substituting the old tag and values with the new tags or create a
new proposal with the new tags?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] maxspeed:type vs source:maxspeed // StreetComplete

[Colin Smale]

Well said, I agree wholeheartedly. A local, anecdotal view is in itself
not enough to produce a data model that works for everyone.

On 2018-09-22 14:22, Tobias Zwick wrote:

> Tagging an implicit speed limit explicitly for example in town with
> maxspeed=50 is straightforward enough for Germany. It seems natural that
> no specialist knowledge is required for that kind of thing. For a German.
> 
> But let's look at some other countries for the default urban speed limit.
> 
> Spain (ES):
> maxspeed=50
> maxspeed:hazmat=40
> 
> Chile (CL):
> maxspeed=60
> maxspeed:bus=50
> maxspeed:hgv=50
> 
> Hungary (HR):
> maxspeed=50
> maxspeed:tricycle=40
> 
> Kerala in India (IN-KL):
> maxspeed=50
> maxspeed:conditional=40 @ (weight > 7.5)
> maxspeed:trailer=40
> maxspeed:bus_articulated=40
> maxspeed:hgv_articulated=40
> maxspeed:bus:conditional=40 @ (weight > 7.5)
> maxspeed:hgv:conditional=40 @ (weight > 7.5)
> maxspeed:tricycle=30
> 
> Punjab in India (IN-PB):
> maxspeed=50
> maxspeed:trailer=35
> maxspeed:bus_articulated=30
> maxspeed:hgv_articulated=30
> maxspeed:hgv=45
> maxspeed:hgv:conditional=40 @ (weight > 6)
> maxspeed:conditional=40 @ (weight > 6)
> maxspeed:trailer:conditional=30 @ (weight > 6)
> maxspeed:motorcycle=35
> maxspeed:goods=45
> maxspeed:goods:conditional=40 @ (weight > 6)
> 
> Malta (MT):
> maxspeed=50
> maxspeed:bus=40
> maxspeed:hgv=30
> maxspeed:goods=40
> maxspeed:goods:conditional=30 @ (weight > 3)
> 
> Poland (PL):
> maxspeed=50
> maxspeed:conditional=60 @ (23:00-05:00)
> 
> Zambia (ZM):
> maxspeed=50
> maxspeed:conditional=40 @ (weight > 2.275)
> maxspeed:trailer=40
> maxspeed:hgv=40
> 
> Because the maxspeed tag applies to all vehicles except overridden for a
> specific vehicle type or a conditional, specifying only maxspeed=50 in
> any of the above cases has to be considered wrong or at least
> incomplete. In other words, the tags you see above would need to be
> added in the case the speed limit is given explicitly. It is not so
> straightforward then anymore.
> 
> So, maybe not for Germany, but as you see, in other places, this *is*
> specialist knowledge. No regular car driver in Punjab will be able to
> enumerate all these maxspeed rules. And, taking a less extreme example,
> I think the Polish OSM contributors wouldn't want to add this
> maxspeed:conditional=60 @ (23:00-05:00) to every single unsigned street
> in urban areas.
> 
> Also, note this is only the urban speed limit, trust me, the default
> speed limit "for all other roads" (=rural) can be much more complex.
> 
> Actually, don't trust me, see for yourself in the document I link all
> the time in the hope people would read it:
> https://wiki.openstreetmap.org/wiki/Default_speed_limits
> 
> We can not get to any results or any progress on the matter of default
> speed limits (or for any topic, for that matter) if everyone just keeps
> arguing out of his best knowledge about his home region or country only.
> 
> "It works for me" is simply not good enough for a global project.
> 
> Cheers
> Tobias
> 
> On 22/09/2018 01:03, Martin Koppenhoefer wrote: 
> 
> sent from a phone
> 
> On 19. Sep 2018, at 21:16, Tobias Zwick  wrote:
> 
> This is a good argument against tagging an explicit maxspeed=X when
> there is actually no speed limit sign around (X is what the OSM mapper
> by his knowledge about the law thinks should be the default limit here). 
> 
> everything that you map will be according to your understanding of it, I 
> cannot see a good argument for not tagging implicit limits, even more as 
> there is judgement needed based on the situation (something humans can do 
> much better than computers). Every holder of a driving license should have 
> the requisites to recognize the speed limit on a given piece of road in their 
> local area, so it doesn't require specialist knowledge.
> 
> We already have a reliable way to distinguish implicit from explicit limits 
> (we even have several of them), if you want to treat them differently in your 
> app, you can do it.
> 
> There actually is a speed limit on most roads, including those without 
> explicit signage. Omitting it will leave us in the situation that it really 
> becomes unclear whether there is no sign or nobody has bothered to enter it.
> 
> 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___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] maxspeed:type vs source:maxspeed // StreetComplete

[Tobias Zwick]

Tagging an implicit speed limit explicitly for example in town with
maxspeed=50 is straightforward enough for Germany. It seems natural that
no specialist knowledge is required for that kind of thing. For a German.

But let's look at some other countries for the default urban speed limit.

Spain (ES):
maxspeed=50
maxspeed:hazmat=40

Chile (CL):
maxspeed=60
maxspeed:bus=50
maxspeed:hgv=50

Hungary (HR):
maxspeed=50
maxspeed:tricycle=40

Kerala in India (IN-KL):
maxspeed=50
maxspeed:conditional=40 @ (weight > 7.5)
maxspeed:trailer=40
maxspeed:bus_articulated=40
maxspeed:hgv_articulated=40
maxspeed:bus:conditional=40 @ (weight > 7.5)
maxspeed:hgv:conditional=40 @ (weight > 7.5)
maxspeed:tricycle=30

Punjab in India (IN-PB):
maxspeed=50
maxspeed:trailer=35
maxspeed:bus_articulated=30
maxspeed:hgv_articulated=30
maxspeed:hgv=45
maxspeed:hgv:conditional=40 @ (weight > 6)
maxspeed:conditional=40 @ (weight > 6)
maxspeed:trailer:conditional=30 @ (weight > 6)
maxspeed:motorcycle=35
maxspeed:goods=45
maxspeed:goods:conditional=40 @ (weight > 6)

Malta (MT):
maxspeed=50
maxspeed:bus=40
maxspeed:hgv=30
maxspeed:goods=40
maxspeed:goods:conditional=30 @ (weight > 3)

Poland (PL):
maxspeed=50
maxspeed:conditional=60 @ (23:00-05:00)

Zambia (ZM):
maxspeed=50
maxspeed:conditional=40 @ (weight > 2.275)
maxspeed:trailer=40
maxspeed:hgv=40

Because the maxspeed tag applies to all vehicles except overridden for a
specific vehicle type or a conditional, specifying only maxspeed=50 in
any of the above cases has to be considered wrong or at least
incomplete. In other words, the tags you see above would need to be
added in the case the speed limit is given explicitly. It is not so
straightforward then anymore.

So, maybe not for Germany, but as you see, in other places, this *is*
specialist knowledge. No regular car driver in Punjab will be able to
enumerate all these maxspeed rules. And, taking a less extreme example,
I think the Polish OSM contributors wouldn't want to add this
maxspeed:conditional=60 @ (23:00-05:00) to every single unsigned street
in urban areas.

Also, note this is only the urban speed limit, trust me, the default
speed limit "for all other roads" (=rural) can be much more complex.

Actually, don't trust me, see for yourself in the document I link all
the time in the hope people would read it:
https://wiki.openstreetmap.org/wiki/Default_speed_limits

We can not get to any results or any progress on the matter of default
speed limits (or for any topic, for that matter) if everyone just keeps
arguing out of his best knowledge about his home region or country only.

"It works for me" is simply not good enough for a global project.

Cheers
Tobias

On 22/09/2018 01:03, Martin Koppenhoefer wrote:
> 
> 
> sent from a phone
> 
>> On 19. Sep 2018, at 21:16, Tobias Zwick  wrote:
>>
>> This is a good argument against tagging an explicit maxspeed=X when
>> there is actually no speed limit sign around (X is what the OSM mapper
>> by his knowledge about the law thinks should be the default limit here).
> 
> 
> everything that you map will be according to your understanding of it, I 
> cannot see a good argument for not tagging implicit limits, even more as 
> there is judgement needed based on the situation (something humans can do 
> much better than computers). Every holder of a driving license should have 
> the requisites to recognize the speed limit on a given piece of road in their 
> local area, so it doesn’t require specialist knowledge.
> 
> We already have a reliable way to distinguish implicit from explicit limits 
> (we even have several of them), if you want to treat them differently in your 
> app, you can do it.
> 
> There actually is a speed limit on most roads, including those without 
> explicit signage. Omitting it will leave us in the situation that it really 
> becomes unclear whether there is no sign or nobody has bothered to enter it.
> 
> 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] RFC - landcover clearing

[Warin]

On 22/09/18 17:39, Mateusz Konieczny wrote:


22. Sep 2018 00:38 by 61sundow...@gmail.com 
:


On 21/09/18 23:16, Mateusz Konieczny wrote:

I am not sure why landcover=clearing is described as better
than other.

If someone wants to leave gixme, the fixme key or OSM note is
the best solution.


Best solution for what?


For marking clearing to be mapped. Obviously, mapping it properly

would be better. But fixme/notes at least in theory can be processed 
by other mappers,


in case of clearings - also by armchair mappers.



But then the feature is harder to find in the data base.
Note that clearings have already been marked as landuse=clearing.



I have no idea why encouraging landcover=clearing would be preferable.



In preference to landuse=clearing.





6. Aug 2018 02:11 by 61sundow...@gmail.com
:

and stop land covers becoming regarded as a legitimate use
of the key landuse.


too late for that, see landuse=forest


So landuse=sand
landuse=dirt
landuse=rock
landuse=scrub
landuse=valley
landuse=peak
landuse=cliff
landuse=tunnel

will all be fine to use?
I don't think so.

No, because there are already tags for tagging that.

Despite that people are using landuse=sand, landuse=scrub... and it is 
probably because of the use of landuse=forest and landuse=grass that 
suggests this misuse.


And there are no tags for clearing.. so they use landuse=clearing.

And round the circle we go again.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Emergency=levee_breach_materials

[John Willis]

> On Sep 21, 2018, at 4:09 PM, Anton Klim  wrote:
> 
> Do these have anything to identify them, like a ref?

I found a sign cycling today. 

奥戸防災ステーション

Okudo (village) "Disaster prevention station" 

The "river" is implied - "river disaster prevention station" is a huge 
mouthful. 

The government has a PDF listing of a hundred of them and their addresses. 
These might be the very large stations with a highground and a helipad, not 
just a cache of breakwater blocks and gravel. 

I will investigate further, but levee_breach_materials might be the most 
flexible for uses elsewhere. 

http://www.mlit.go.jp/river/toukei_chousa/kasen_db/pdf/2018/4-2-3.pdf


Javbw 

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

Re: [Tagging] Area of Firestations / Area of Ambulancestations

[dktue]

Am 22.09.2018 um 00:29 schrieb Warin:

On 21/09/18 23:52, Martin Koppenhoefer wrote:


sent from a phone


On 21. Sep 2018, at 11:28, dktue  wrote:

but: it's not amenity=ambulance_station we're using at the moment. 
We're using emergency=ambulance_station -- so: How do we solve this?


I’m not sure what an ambulance station is, but not all of the 
features I have in mind (a place where ambulances and their staff are 
parked and waiting for orders, usually with a coordinating office and 
radio unit) are emergency related. Some organizations only provide 
ambulance transports for people with special requirements.




Here 'patent transport' is provided by the same organisation that 
provides ambulances.


They are co-located and have very similar vehicles, different colours 
and lettering. The staff that man them have less training.



If they were completely separate then I'd use different tags. But what 
tags to use?
Not emergency as they are scheduled and not urgent. Amenity? 
amenity=patient_transport?


Same here -- some organisation provide emergency medical services _and_ 
patient transport, some do only emergency medical services and some do 
only patient transport. I think there really is a need to differentiate 
that.


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

Re: [Tagging] RFC - landcover clearing

[Mateusz Konieczny]

22. Sep 2018 00:38 by 61sundow...@gmail.com :


> > On 21/09/18 23:16, Mateusz Konieczny  wrote:
> > 
>> >> I am not sure why landcover=clearing is described as better   
>>  than other.>>   
>>   >>   >> If someone wants to leave gixme, the fixme key or OSM note 
>> isthe best solution. 
>>   >> 
> 
> Best solution for what?
>




For marking clearing to be mapped. Obviously, mapping it properly

would be better. But fixme/notes at least in theory can be processed by other 
mappers,

in case of clearings - also by armchair mappers.




I have no idea why encouraging landcover=clearing would be preferable.


 


> 
> 
>>   
>>   >>   6. Aug 2018 02:11 by >> 61sundow...@gmail.com 
>> >> :
>>   
>>  
>>   
>>> and stop landcovers becoming regarded as a legitimate use of the 
>>> key landuse.
>>>   
>>   
>>
>>   
>>   
>> too late for that, see landuse=forest 
>>   
>> 
> 
> So landuse=sand
> landuse=dirt
> landuse=rock
> landuse=scrub
> landuse=valley
> landuse=peak
> landuse=cliff
> landuse=tunnel
> 
> will all be fine to use? 
> I don't think so. 
>

 

No, because there are already tags for tagging that.

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