Re: [Tagging] Extremely complicated conditional values

[Johnparis]

I'd try something similar to this example:

access:conditional=destination @ (weight>5.5)

So in your case you would have

maxspeed:advisory:conditional=18 @ (weight>=37.5)
maxspeed:advisory:conditional=22 @ (weight>=35 AND weight<37.5)
maxspeed:advisory:conditional=26 @ (weight>=32.5 AND weight<35)
maxspeed:advisory:conditional=37 @ (weight>=30 AND weight<32.5)

(... the standard for weight being short tons in the USA...)

John


On Thu, Apr 25, 2019 at 4:36 AM Paul Johnson  wrote:

> Is there a condition value calculator that can help me come up with sane
> tagging for this?
>
> https://openstreetcam.org/details/955279/18672/track-info
>
> This is a chart of advised speeds in MPH for HGVs on a motorway in Oregon
> based on weight in pounds.  I'm at a complete loss of how to tag for this
> save for conditional values but I am banging my head on coming up anything
> cogent reading through
> https://wiki.openstreetmap.org/wiki/Conditional_restrictions short of 
> maxspeed:advisory:hgv=18
> mph (which technically fits the most stringent value but a little
> hamfisted given that sign).
>
> Can I get a hint on this?
> ___
> 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] Extremely complicated conditional values

[Johnparis]

I suppose, given that they all have the same tag, that the values would
need to be concatenated with semicolons:


maxspeed:advisory:conditional=18 @ (weight>=37.5);22 @ (weight>=35 AND
weight<37.5);26 @ (weight>=32.5 AND weight<35);37 @ (weight>=30 AND
weight<32.5)

On Thu, Apr 25, 2019 at 10:28 AM Johnparis  wrote:

> I'd try something similar to this example:
>
> access:conditional=destination @ (weight>5.5)
>
> So in your case you would have
>
> maxspeed:advisory:conditional=18 @ (weight>=37.5)
> maxspeed:advisory:conditional=22 @ (weight>=35 AND weight<37.5)
> maxspeed:advisory:conditional=26 @ (weight>=32.5 AND weight<35)
> maxspeed:advisory:conditional=37 @ (weight>=30 AND weight<32.5)
>
> (... the standard for weight being short tons in the USA...)
>
> John
>
>
> On Thu, Apr 25, 2019 at 4:36 AM Paul Johnson  wrote:
>
>> Is there a condition value calculator that can help me come up with sane
>> tagging for this?
>>
>> https://openstreetcam.org/details/955279/18672/track-info
>>
>> This is a chart of advised speeds in MPH for HGVs on a motorway in Oregon
>> based on weight in pounds.  I'm at a complete loss of how to tag for this
>> save for conditional values but I am banging my head on coming up anything
>> cogent reading through
>> https://wiki.openstreetmap.org/wiki/Conditional_restrictions short of 
>> maxspeed:advisory:hgv=18
>> mph (which technically fits the most stringent value but a little
>> hamfisted given that sign).
>>
>> Can I get a hint on this?
>> ___
>> 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] Incorrectly tagging locks on rivers as canals

[Dave F via Tagging]

The water flowing through it is still river water.

On 24/04/2019 20:47, François Lacombe wrote:

Hi Dave

I'm happy to tag as canal the man_made space between two lock gates.
This is often concrete lined and sized accordingly to allow boats to pass
through.

The main difference with rivers going through cities is it's often the
original natural course.
A canal is built by man, Thames river wasn't built by man I think,
Locks usually does.

To me it's more confusing to tag lock gates and dams in waterway key
instead of man_made but it's another topic

All the best

François

Le mer. 24 avr. 2019 à 20:40, Dave F via Tagging 
a écrit :


Hi

This maybe UK specific but it's a tagging problem & maybe wider spread.

To allow navigation, rivers occasional have lock gates, usually as a
separate channel. Some contributors tag these incorrectly as
waterway=canal for the centre line.

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

However, they are still rivers, they just have canalized sections. If
this logic was applied to all lengths of river every one that passes
through a city, such as the East River, Seine or Thames would be tagged
as canal, which is of course, ridiculous.

Canals are man-made channels to allow water to flow where it naturally
wouldn't
If the locks were removed from rivers the water would still flow.

Canal is a noun.
Canalise is a verb.

Cheers
DaveF


___
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] Incorrectly tagging locks on rivers as canals

[Richard Fairhurst]

DaveF wrote:
> The water flowing through it is still river water.

The water flowing down lots of canals is ultimately river water :) - the
Llangollen Canal is fed by the River Dee, the Mon & Brec by the Usk, and so
on.

Generally, where a lock has been built, this is in an artificial cut
slightly away from the main flow of the river. This is usually referred to
as the "lock cut". In some places this is not that much longer than the lock
itself (often the case on the Thames), whereas in others it can be
significantly longer (the Aire & Calder/Calder & Hebble). Meanwhile, the
main course continues over the weir.

As "cut" is usually a synonym for "canal" and they're artificially
constructed, it's fairly justifiable to describe a lock cut as
waterway=canal, I think. I guess you could put the whole lot in a river
navigation relation if that... floats your boat?

cheers
Richard




--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

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

Re: [Tagging] Incorrectly tagging locks on rivers as canals

[Philip Barnes]

On 25/04/2019 11:25, Richard Fairhurst wrote:

DaveF wrote:

The water flowing through it is still river water.

The water flowing down lots of canals is ultimately river water :) - the
Llangollen Canal is fed by the River Dee, the Mon & Brec by the Usk, and so
on.


In the case of the Llangollen, The Dee does not simply supply to keep 
the canal topped up. The canal is used to carry water from The Dee for 
the public water supply in Cheshire.


There is a lot of water passing through the lock bypasses along here.

Phil (trigpoint)


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

Re: [Tagging] Incorrectly tagging locks on rivers as canals

[Philip Barnes]

On 25/04/2019 11:25, Richard Fairhurst wrote:

DaveF wrote:

The water flowing through it is still river water.

The water flowing down lots of canals is ultimately river water :) - the
Llangollen Canal is fed by the River Dee, the Mon & Brec by the Usk, and so
on.


In the case of the Llangollen, The Dee does not simply supply to keep 
the canal topped up. The canal is used to carry water from The Dee for 
the public water supply in Cheshire.


There is a lot of water passing through the lock bypasses along here.

Phil (trigpoint)


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

Re: [Tagging] Incorrectly tagging locks on rivers as canals

[Dave F via Tagging]

Have these diversions been given a 'XYZ Canal' name? if not then it's a 
river.


I think the duck test needs to be applied.

DaveF

On 25/04/2019 11:25, Richard Fairhurst wrote:

DaveF wrote:

The water flowing through it is still river water.

The water flowing down lots of canals is ultimately river water :) - the
Llangollen Canal is fed by the River Dee, the Mon & Brec by the Usk, and so
on.

Generally, where a lock has been built, this is in an artificial cut
slightly away from the main flow of the river. This is usually referred to
as the "lock cut". In some places this is not that much longer than the lock
itself (often the case on the Thames), whereas in others it can be
significantly longer (the Aire & Calder/Calder & Hebble). Meanwhile, the
main course continues over the weir.

As "cut" is usually a synonym for "canal" and they're artificially
constructed, it's fairly justifiable to describe a lock cut as
waterway=canal, I think. I guess you could put the whole lot in a river
navigation relation if that... floats your boat?

cheers
Richard




--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
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] Extremely complicated conditional values

[Tobias Zwick]

Even shorter, because if there are conflicting rules in the conditional, the 
last one is taken, says the wiki. (Not sure if this is really implemented in 
applications that work with that data though):

maxspeed:advisory:conditional=37 mph @ (weight>=6 lbs);26 mph @ 
(weight>=65000 lbs);22 mph @ (weight>=7 lbs);18 mph @ (weight>=75000 lbs 
AND weight<=8)

Notes:
- I'd always specify units as they are used on the sign for better 
confirmability
- to be precise, I guess you'd need to add "AND axles>=5" in every conditional 

Tobias

Am 25. April 2019 10:34:21 MESZ schrieb Johnparis :
>I suppose, given that they all have the same tag, that the values would
>need to be concatenated with semicolons:
>
>
>maxspeed:advisory:conditional=18 @ (weight>=37.5);22 @ (weight>=35 AND
>weight<37.5);26 @ (weight>=32.5 AND weight<35);37 @ (weight>=30 AND
>weight<32.5)
>
>On Thu, Apr 25, 2019 at 10:28 AM Johnparis  wrote:
>
>> I'd try something similar to this example:
>>
>> access:conditional=destination @ (weight>5.5)
>>
>> So in your case you would have
>>
>> maxspeed:advisory:conditional=18 @ (weight>=37.5)
>> maxspeed:advisory:conditional=22 @ (weight>=35 AND weight<37.5)
>> maxspeed:advisory:conditional=26 @ (weight>=32.5 AND weight<35)
>> maxspeed:advisory:conditional=37 @ (weight>=30 AND weight<32.5)
>>
>> (... the standard for weight being short tons in the USA...)
>>
>> John
>>
>>
>> On Thu, Apr 25, 2019 at 4:36 AM Paul Johnson 
>wrote:
>>
>>> Is there a condition value calculator that can help me come up with
>sane
>>> tagging for this?
>>>
>>> https://openstreetcam.org/details/955279/18672/track-info
>>>
>>> This is a chart of advised speeds in MPH for HGVs on a motorway in
>Oregon
>>> based on weight in pounds.  I'm at a complete loss of how to tag for
>this
>>> save for conditional values but I am banging my head on coming up
>anything
>>> cogent reading through
>>> https://wiki.openstreetmap.org/wiki/Conditional_restrictions short
>of maxspeed:advisory:hgv=18
>>> mph (which technically fits the most stringent value but a little
>>> hamfisted given that sign).
>>>
>>> Can I get a hint on this?
>>> ___
>>> 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] Incorrectly tagging locks on rivers as canals

[Paul Allen]

On Thu, 25 Apr 2019 at 13:00, Dave F via Tagging 
wrote:

> Have these diversions been given a 'XYZ Canal' name? if not then it's a
> river.
>
> I think the duck test needs to be applied.
>

So does the presence of ducks make it a river and the absence of ducks make
it a canal?

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

Re: [Tagging] Incorrectly tagging locks on rivers as canals

[Richard Fairhurst]

DaveF wrote:
> Have these diversions been given a 'XYZ Canal' name? if not then 
> it's a river.

hahahahaha

cheers
Richard



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

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

Re: [Tagging] Incorrectly tagging locks on rivers as canals

[Philip Barnes]

On Thursday, 25 April 2019, Paul Allen wrote:
> On Thu, 25 Apr 2019 at 13:00, Dave F via Tagging 
> wrote:
> 
> > Have these diversions been given a 'XYZ Canal' name? if not then it's a
> > river.
> >
> > I think the duck test needs to be applied.
> >
> 
> So does the presence of ducks make it a river and the absence of ducks make
> it a canal?
> 
Only if the Llangollen is a river, but judging by the flow rate...

Phil (trigpoint)

-- 
Sent from my Sailfish device
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Incorrectly tagging locks on rivers as canals

[François Lacombe]

Le jeu. 25 avr. 2019 à 12:03, Dave F via Tagging 
a écrit :

> The water flowing through it is still river water.
>

Many artificial man made infrastructure involve natural water taken from
rivers and streams.
The point of waterway isn't only to tag water but the kind of way it is
flowing in (without dealing with usage which is adressed with usage=*)

Lock sections don't get "canal" as name but "lock".
Then waterway=canal + lock=yes sounds correct

All the best

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

[Tagging] Feature proposal - RFC - Railway/Power traction substations

[François Lacombe]

Hi all,

I wrote this proposal focused on power conversion in traction substations.
https://wiki.openstreetmap.org/wiki/Proposed_features/Traction_substations_extension

It is proposed to use a new key conversion=* to indicate which kind of
power conversion operates inside a substation.
As explained in rationale, no voltage=* nor frequency=* can be used as
reliable information to deduce it at the substation scale.
conversion=no explicitly means no power=converter device will be found in
the substation perimeter (for instance, high speed lines modern 25kV AC
traction systems)

This is an occasion to improve Paris railway substations mapping which
expose a few different situations
63 kV AC => 1500 V DC
63 kV AC => 25 kV AC
225 kV AC => 25 kV AC

Feel free to add opinions and concerns in Talk page

All the best

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

Re: [Tagging] Incorrectly tagging locks on rivers as canals

[Volker Schmidt]

Going back to the original example, I would say, not only the lock but the
entire cut, in particular way https://www.openstreetmap.org/way/24335
should be tagged as waterway=canal. This scheme applies to most river-lock
arrangements, the "cuts" are nearly almost artificial canals.
At least this seems obvious to me for those cases were the "natural" river
bed is still there but blocked by a weir, and the the navigation channel
goes through a lock using an "artificial" canal.

But I also see problems with this approach regarding the distinction
between natural bed and artificial canals. If we take one of the biggest
rivers in Europe: The Rhine downstream from Basel and to Bingen has been
re-bedded nearly completely (see https://en.wikipedia.org/wiki/Upper_Rhine)
and, by the above arguments, should be re-tagged as canal, which seems
absurd.
So maybe the concepts ar not as well defined as I thought.



On Thu, 25 Apr 2019 at 18:18, François Lacombe 
wrote:

>
> Le jeu. 25 avr. 2019 à 12:03, Dave F via Tagging <
> tagging@openstreetmap.org> a écrit :
>
>> The water flowing through it is still river water.
>>
>
> Many artificial man made infrastructure involve natural water taken from
> rivers and streams.
> The point of waterway isn't only to tag water but the kind of way it is
> flowing in (without dealing with usage which is adressed with usage=*)
>
> Lock sections don't get "canal" as name but "lock".
> Then waterway=canal + lock=yes sounds correct
>
> All the best
>
> François
> ___
> 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] Incorrectly tagging locks on rivers as canals

[Andy Mabbett]

On Wed, 24 Apr 2019 at 20:47, François Lacombe
 wrote:

> The main difference with rivers going through cities is it's often the
> original natural course.

The River Tame, in North Birmingham and in the urban areas north of
the city, has several sections, some concrete-sided and some looking
entirely natural, that are nowhere near its original course.

Indeed, one natural-looking section runs through what is in effect a
giant pond-liner, keeping it separated from the groundwater, which is
poisoned by heavy metal as the result of past industrial activity.

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

Re: [Tagging] Incorrectly tagging locks on rivers as canals

[François Lacombe]

Le jeu. 25 avr. 2019 à 18:49, Andy Mabbett  a
écrit :

> The River Tame, in North Birmingham and in the urban areas north of
> the city, has several sections, some concrete-sided and some looking
> entirely natural, that are nowhere near its original course.
>

Ok this is a good point

Despite waterway=* tag doesn't regard the usage it is made of water, there
is always a purpose and the water is useful.
In case of Tame (or Thames in London, Seine in Paris, Rhine...), the water
isn't channelized for a given purpose then I would rather call it a river
(Rhine and Rhone rivers do have side channels for hydropower, locks...)

To me, current tagging is defined as follow:
waterway=river/stream => "natural" water course
waterway=canal => artificial water channel for a given purpose
waterway=drain => useless water evacuation (mainly rain)

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

Re: [Tagging] Feature Proposal - RFC - Baby changing table

[Valor Naram]

There's no discussion concerning the proposal of "baby changing table" anymore. What's happening? Should I start the voting process? Are all words said?Answer "no" (with or without any reason) and I won't start the voting.CheersSören alias Valor Naram Original Message Subject: [Tagging] Feature Proposal - RFC - Baby changing tableFrom: Valor Naram To: tagging@openstreetmap.orgCC: Definition: A tag to mark the possibility to change the baby's nappy Proposal page: https://wiki.openstreetmap.org/wiki/Proposed_features/baby_changing_tablesPlease join the discussion and I will spend time to make changes.CheerioSören alias Valor Naram
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Why should we avoid overusage of amenity=* tag?

[Philip Barnes]

On Wednesday, 24 April 2019, Warin wrote:
> On 25/04/19 04:39, Dave F wrote:
> >
> >
> > On 21/04/2019 01:12, Warin wrote:
> >>
> >>
> >> I am all for the introduction of the key education=*
> >>
> >>
> >> It makes sense, adds detail - improves the map data base.
> >
> > True.
> >
> > The one that irks me is amenity=cafe. It isn't there for the benefit 
> > of the community; it is a commercial enterprise & should be tagged as 
> > a shop.
> 
> +1
> 
> The same can be said for a pub, restaurant, etc.
>   They are all  commercial enterprises, if they did not make money they 
> would not exist.
>   There 'service' to the community is there to help them make money.
> 
Although one of the descriptions that an estate agent will use when describing 
a property is close to the amenities. The big 4 Ps that are used to describe 
the amenities that make a village sustainable are Primary School, Parish 
Church, Post Office and Pub.

Once any go, then the community is dieing. The pub is a major amenity, that is 
why communities will club together to operate and keep the pub open.

So it may be a business, but it is also one of the prime amenities. 

Phil (trigpoint)

-- 
Sent from my Sailfish device
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Incorrectly tagging locks on rivers as canals

[Mateusz Konieczny]

25 Apr 2019, 19:03 by fl.infosrese...@gmail.com:

> To me, current tagging is defined as follow:
> waterway=river/stream => "natural" water course
> waterway=canal => artificial water channel for a given purpose
> waterway=drain => useless water evacuation (mainly rain)
>
I would use river/stream not only for "natural" water course.

In Europe nearly no major rivers meander freely, all rivers crossing cities
have strictly maintained course.

I see no reason to tag channelized river/stream as waterway=canal
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Baby changing table

[Martin Koppenhoefer]

sent from a phone

> On 22. Apr 2019, at 01:49, marc marc  wrote:
> 
> I know the tag description, thanks :)
> the question is "can we expect to have changing tables on a regular 
> basis that are different from what we can expect with other tags,
> which would justify encouraging people to put a description ?


I don’t mind encouraging or not a description, as long as it is in the wiki 
alone it won’t change anything, you can add description tags to anything where 
you feel it is appropriate and generally we should use it mainly for exceptions 
where structured tagging doesn’t seem appropriate.
As I understand it this wouldn’t often be a description of the table object but 
more likely a description of the context or circumstances, e.g. if you’d have 
to ask the staff, or get the table in one place and use it in the next room, 
etc.

What about changing tables as a feature property? For example in Germany there 
are chain shops (drugstores) which offer changing tables as a free service to 
their clients (including napkins). You might not want to position it in the 
shop (the shop might be mapped as a node) but just give the information that 
they offer the service. changing_table=* would seem to be the right tag for 
this property, what about the table as a feature/osm object?
The proposal lacks a definition at the moment, a sentence what the tag should 
mean.

I would prefer “baby_changing_table” as it makes it clearer what it is about 
(think about it, you also gave the proposal this title, and not just changing 
table).

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

Re: [Tagging] Incorrectly tagging locks on rivers as canals

[Martin Koppenhoefer]

sent from a phone

> On 25. Apr 2019, at 18:45, Volker Schmidt  wrote:
> 
> The Rhine downstream from Basel and to Bingen has been re-bedded nearly 
> completely (see https://en.wikipedia.org/wiki/Upper_Rhine) and, by the above 
> arguments, should be re-tagged as canal, which seems absurd.
> So maybe the concepts ar not as well defined as I thought.


this is true for a lot of other rivers as well. I think the distinction is 
whether the bed is still somewhere near the old position, then it is not 
considered a canal, while a waterway that cuts through the natural topology and 
diverts water into areas where there wouldn’t normally be, or in directions it 
wouldn’t normally flow, then it is clearly a canal (intended on the scale of 
the waterway, not just locally).

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

Re: [Tagging] Incorrectly tagging locks on rivers as canals

[Graeme Fitzpatrick]

Getting away from the discussion of river v canal & back to the original
problem pictured
https://www.openstreetmap.org/way/347369154 , why is it "River Wey
Navigation" while the river itself is just "Wey"
https://www.openstreetmap.org/way/243353339#map=16/51.2572/-0.5605?
Shouldn't they both either be "River Wey" or just "Wey"?

& is the unnamed river to the South
https://www.openstreetmap.org/way/23216681, the natural Wey?

Thanks

Graeme


On Fri, 26 Apr 2019 at 06:12, Mateusz Konieczny 
wrote:

> 25 Apr 2019, 19:03 by fl.infosrese...@gmail.com:
>
> To me, current tagging is defined as follow:
> waterway=river/stream => "natural" water course
> waterway=canal => artificial water channel for a given purpose
> waterway=drain => useless water evacuation (mainly rain)
>
> I would use river/stream not only for "natural" water course.
>
> In Europe nearly no major rivers meander freely, all rivers crossing cities
> have strictly maintained course.
>
> I see no reason to tag channelized river/stream as waterway=canal
> ___
> 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] Why should we avoid overusage of amenity=* tag?

[Warin]

On 26/04/19 04:10, Philip Barnes wrote:

On Wednesday, 24 April 2019, Warin wrote:

On 25/04/19 04:39, Dave F wrote:


On 21/04/2019 01:12, Warin wrote:


I am all for the introduction of the key education=*


It makes sense, adds detail - improves the map data base.

True.

The one that irks me is amenity=cafe. It isn't there for the benefit
of the community; it is a commercial enterprise & should be tagged as
a shop.

+1

The same can be said for a pub, restaurant, etc.
   They are all  commercial enterprises, if they did not make money they
would not exist.
   There 'service' to the community is there to help them make money.


Although one of the descriptions that an estate agent will use when describing 
a property is close to the amenities. The big 4 Ps that are used to describe 
the amenities that make a village sustainable are Primary School, Parish 
Church, Post Office and Pub.


Bank, Supermarket, Post Office, Doctor, garage and pub. ... Church? Not a 
frequent requirement.




Once any go, then the community is dieing. The pub is a major amenity, that is 
why communities will club together to operate and keep the pub open.

So it may be a business, but it is also one of the prime amenities.



The supermarket is also a sign of a healthy community. Once the last one of 
them goes it is all down hill from there.
Communities have drawn together to keep a bank, a supermarket and a garage 
going locally. They have also drawn together to keep a doctor.
They don't draw together for a church.


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

Re: [Tagging] Incorrectly tagging locks on rivers as canals

[Paul Allen]

On Thu, 25 Apr 2019 at 22:16, Graeme Fitzpatrick 
wrote:

> Getting away from the discussion of river v canal & back to the original
> problem pictured
> https://www.openstreetmap.org/way/347369154 , why is it "River Wey
> Navigation" while the river itself is just "Wey"
>

Canals, when used for boats, are often known as navigation canals.  And
sometimes
referred to as just navigations.

It looks to me like the River Wey Navigation might be a canal to shorten
the route for river traffic
(or maybe because the river at that point wasn't deep enough and it was
cheaper to construct
a canal than dredge the river).  Which would make sense.  Which is why I'm
probably wrong,
because things rarely make sense.

& is the unnamed river to the South
> https://www.openstreetmap.org/way/23216681, the natural Wey?
>

It could be the curd. :)

Actually, it may not be the natural Wey.  Not going by the OS 1:25k
historic layer.  Which is
incomplete.   But the same layer is available from NLS (easy to select with
JOSM, but if you're
using iD then use https://geo.nls.uk/mapdata2/os/25000/{zoom}/{x}/{-y}.png
as your custom
layer (I have asked iD to use the NLS version instead but the iD team just
respond by
saying they don't want that historic layer there anyway because they think
it confuses people).
It looks like the natural river got diverted at some point after the canal
was built in order to
make room for roads.  But that is a wild guess on my part.

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

Re: [Tagging] Feature Proposal - RFC - Baby changing table

[marc marc]

Le 25.04.19 à 22:52, Martin Koppenhoefer a écrit :
> I don’t mind encouraging or not a description, as long as it is in the wiki 
> alone it won’t change anything

for those who read the wiki, I think the tags listed there have
an influence, it's supposed to be the ones someone has expressed
an interest in. it can also influence preset-maker.

if we list 11 tags on the page simply because the word has said
in the thread, whereas there are 2 useful tags, when a contributor
will read the documentation, either he will find it too complex/long,
or he will waste his time filling in elements that no one uses.
at least the list should be splited with a section "tags without
any known use/funny tagging/advanced tagging".
As a contributor and user of these data, I am sad to see
that the useful is drowned in the futil.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Baby changing table

[marc marc]

no:) (or more exactly: it has been said but I say it again
in case you missed it)

I notice that the page has almost doubled in size :(
I wonder if you shouldn't split the proposal into two:

a minimalist proposal that takes the rela data from the diaper=* tag
and provides a better schema to encode it, an idea that I fully support.

another proposal to promote all other information (fee: there are really 
paid changing tables in the free toilets ? presence of straps or
a pillow: there is really a parent who will base his choice on this 
criterion ? changing_table:wheelchair:description:xx : there is really
a utility that a contributor describe in his own language that the 
changing table is inaccessible like all those I have seen ?
maybe my experience is not diversified enough

furthermore the proposal was based on the principle of harmonizing tags 
with what is done for other objects, but now it introduces 
inconsistencies (features=bench <> bench=yes for example)


Le 25.04.19 à 19:16, Valor Naram a écrit :
> There's no discussion concerning the proposal of "baby changing table" 
> anymore. What's happening? Should I start the voting process? Are all 
> words said?
> 
> Answer "no" (with or without any reason) and I won't start the voting.
> 
> 
> Cheers
> 
> Sören alias Valor Naram
> 
> 
>  Original Message 
> Subject: [Tagging] Feature Proposal - RFC - Baby changing table
> From: Valor Naram
> To: tagging@openstreetmap.org
> CC:
> 
> 
> *Definition:* A tag to mark the possibility to change the baby's nappy
> *Proposal page:*
> https://wiki.openstreetmap.org/wiki/Proposed_features/baby_changing_tables
> 
> Please join the discussion and I will spend time to make changes.
> 
> Cheerio
> 
> Sören alias Valor Naram
> 
> 
> ___
> 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 results - Police facilites

[Martin Koppenhoefer]

sent from a phone

> On 23. Apr 2019, at 09:45, Lionel Giard  wrote:
> 
> There isn't any EU police or military force (that's still a political 
> discussion but there is none at the moment). The only existing thing is the 
> international cooperation that is increased between neighboring countries and 
> some special rules allowing one police force to pursue a suspect in the other 
> countries for some times (if they cross the border). Apart from that, it is 
> as everywhere : police force(s) separated by country. 


well there is for example Europol which is a self described law enforcement 
agency of the EU. And there are „missions“ with a joint command: 
https://en.wikipedia.org/wiki/List_of_military_and_civilian_missions_of_the_European_Union#List

These are minor numbers compared to the national forces in the member states, 
but there is more than „nothing“.

Cheers, Martin 

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

[Tagging] Feature Proposal - RFC - Tag:natural=mesa and Tag:natural=butte

[Joseph Eisenberg]

I have created 2 proposal pages for natural=mesa and natural=butte

A mesa is defined as "A flat-topped elevated landform surrounded by
cliffs". A mesa may also be known as a table or tableland, potrero or
tepui. See http://en.wikipedia.org/wiki/en:mesa

A butte is defined as "a hill with a flat top surrounded by cliffs."
The width of the flat top is less than the relative height of the
hill. See http://en.wikipedia.org/wiki/en:butte

So in contrast with a natural=butte, in a natural=mesa the width of
the flat area is greater than its height above the surrounding
terrain.

I believe both of these features may be mapped as a node or as an area
with a closed way.

In contrast two these 2 features which are surrounded by cliffs or
steep escarpments, the tag natural=plateau (already in use <100 times)
is often used for large features that do not have clear boundaries,
and therefore cannot be verifiably mapped as an area.

I've also made a proposal page to help define natural=plateau, and
suggest that it not be used with relations or areas.

About the values of the tags, "mesa" and "butte"

While one might use "table" or "tableland", these terms are somewhat
ambiguous, and can be used for very large features. In contrast, the
terms "mesa" and "butte" are fairly well defined in English, even
though they are loan words from Spanish and French. There are few of
these features in England, so it's not surprising that new words were
needed.

See:

https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:natural%3Dmesa

https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:natural%3Dbutte

https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:natural%3Dplateau

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

[Tagging] Feature Proposal - Voting - Key:golf_cart

[Joseph Eisenberg]

It has been over 2 weeks since the RFC for
https://wiki.openstreetmap.org/wiki/Proposed_features/Key:golf_cart

This key is already in use over 16,000 times to define access
restrictions for golf carts on highway ways (especially highway=path
and highway=service), highway=crossing and amenity=parking.

Voting will clarify that using a highway tag, such as highway=path or
highway=service with golf_cart=designated is the preferred way to tag
a golf cart path on a golf course.

Please see the discussion page. There were no major issues, and the
minor questions and suggestions have been addressed
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Key:golf_cart

Then log in and scroll to the bottom to vote:
https://wiki.openstreetmap.org/wiki/Proposed_features/Key:golf_cart#Voting

Voting will be open till 11 May 2019

- Joseph E.

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

Re: [Tagging] Feature Proposal - RFC - Camp_site=camp_pitch

[Joseph Eisenberg]

I'm afraid that using camp_site=camp_pitch as a subtag on
tourism=camp_site features, and using "tourism=pitch" for separate
tagging would combine the same disadvantages as using
camp_site=camp_pitch as an independent feature, plus the disadvantages
of adopting a new tag under the tourism key.

Your suggestion would require redefining "camp_site=camp_pitch" to be
a subkey of "tourism=camp_site" even though it is mainly used by
itself to map individual pitches.

Then we would need to retag all of the other "camp_site=camp_pitch"
objects - but not necessarily the ones that are also tagged with
tourism=camp_site. This would be confusing and still would require a
large amount of retagging of features that were used by dozens of
mappers over the past few years.

And if "tourism=camp_pitch" were the new approved tag, it could still
be accidentally used instead of "tourism=camp_site" for individual
features (I almost mixed that up just while typing this).

I still think it's easiest for us to approve the fairly popular tag
"camp_site=camp_pitch", which is already supported by some editors,
since the alternatives also have some disadvantages.

Joseph

On 4/24/19, Martin Koppenhoefer  wrote:
>> On 23. Apr 2019, at 15:00, Joseph Eisenberg 
>> What do you mean by "camp_pitch as a subtype of camp site"? Are you
>> proposing something like this: Proposed_features/Key:camp_pitch
>
> no, I was referring to key camp_site=* as key for subtypes of camp sites.
> “camp_pitch” could be seen as one of the subtypes of camp sites (a site
> consisting of one pitch)

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

Re: [Tagging] Feature Proposal - RFC - Tag:natural=mesa and Tag:natural=butte

[Warin]

On 26/04/19 11:48, Joseph Eisenberg wrote:

I have created 2 proposal pages for natural=mesa and natural=butte

A mesa is defined as "A flat-topped elevated landform surrounded by
cliffs". A mesa may also be known as a table or tableland, potrero or
tepui. See http://en.wikipedia.org/wiki/en:mesa

A butte is defined as "a hill with a flat top surrounded by cliffs."
The width of the flat top is less than the relative height of the
hill. See http://en.wikipedia.org/wiki/en:butte

So in contrast with a natural=butte, in a natural=mesa the width of
the flat area is greater than its height above the surrounding
terrain.

I believe both of these features may be mapped as a node or as an area
with a closed way.

In contrast two these 2 features which are surrounded by cliffs or
steep escarpments, the tag natural=plateau (already in use <100 times)
is often used for large features that do not have clear boundaries,
and therefore cannot be verifiably mapped as an area.

I've also made a proposal page to help define natural=plateau, and
suggest that it not be used with relations or areas.

About the values of the tags, "mesa" and "butte"

While one might use "table" or "tableland", these terms are somewhat
ambiguous, and can be used for very large features. In contrast, the
terms "mesa" and "butte" are fairly well defined in English, even
though they are loan words from Spanish and French. There are few of
these features in England, so it's not surprising that new words were
needed.

See:

https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:natural%3Dmesa


need to make it clear in the description how it differs from plateau/butte e.g.

Flat topped area with sudden elevation, wider or longer than it is high
but horizontal dimension less than 1.6 km.



https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:natural%3Dbutte


need to make it clear in the description how it differs from plateau/mesa e.g.
Flat topped area with sudden elevation, higher that width or length



https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:natural%3Dplateau


The smallest horizontal dimension of a plateau could be 1.6 km ( 1 mile). This 
would distinguish it from mesa/butte.


Note definitions are rough and need some more thought than I gave above.


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

Re: [Tagging] Feature Proposal - RFC - Baby changing table

[Valor Naram]

I've already made a suggestion to split the wiki pages into two parts:The first one describes the key "changing_table" as a replacement for "diaper". This section will compare the old tagging with the new tagging without introducing new subkeys.The second one describes the extensions (adding of more information which are fully optional to provide) Original Message Subject: Re: [Tagging] Feature Proposal - RFC - Baby changing tableFrom: marc marc To: tagging@openstreetmap.orgCC: no:) (or more exactly: it has been said but I say it againin case you missed it)I notice that the page has almost doubled in size :(I wonder if you shouldn't split the proposal into two:a minimalist proposal that takes the rela data from the diaper=* tagand provides a better schema to encode it, an idea that I fully support.another proposal to promote all other information (fee: there are really paid changing tables in the free toilets ? presence of straps ora pillow: there is really a parent who will base his choice on this criterion ? changing_table:wheelchair:description:xx : there is reallya utility that a contributor describe in his own language that the changing table is inaccessible like all those I have seen ?maybe my experience is not diversified enoughfurthermore the proposal was based on the principle of harmonizing tags with what is done for other objects, but now it introduces inconsistencies (features=bench <> bench=yes for example)Le 25.04.19 à 19:16, Valor Naram a écrit :> There's no discussion concerning the proposal of "baby changing table" > anymore. What's happening? Should I start the voting process? Are all > words said?> > Answer "no" (with or without any reason) and I won't start the voting.> > > Cheers> > Sören alias Valor Naram> > >  Original Message > Subject: [Tagging] Feature Proposal - RFC - Baby changing table> From: Valor Naram> To: tagging@openstreetmap.org> CC:> > > *Definition:* A tag to mark the possibility to change the baby's nappy> *Proposal page:*> https://wiki.openstreetmap.org/wiki/Proposed_features/baby_changing_tables> > Please join the discussion and I will spend time to make changes.> > Cheerio> > Sören alias Valor Naram> > > ___> Tagging mailing list> Tagging@openstreetmap.org> https://lists.openstreetmap.org/listinfo/tagging> ___Tagging mailing listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tag for a plateau or tableland?

[Paul Johnson]

On Thu, Apr 18, 2019 at 5:13 PM Joseph Eisenberg 
wrote:

> Fri, Apr 19, 2019 at 7:.
>
>> I was wondering about leaving them all under peak?
>>
>> natural=peak
>> peak=hill/mountain/plateau/butte/mesa
>>
>> Would that work?
>>
>
> A peak is well defined as the local high point. A Mesa or butte will
> always have at least one peak, but the peak may be in one corner, which
> could be several kilometers from the center of a mesa, and a Mesa might
> have a dozen different peaks around it.
>
> Similarly, one named natural=ridge can have a dozen peaks, sometime with
> different names.
>
> Those Australian geological definitions are good, and match the American
> ones that I found. A Mesa and Butte are both bordered by an escarpment
> (cliff), while a “plateau” can also just be an elevated level area without
> cliffs.
>
> Since buttes are small they can usually be tagged just as a peak, but
> mesas need a tag for the center of the area.
>

That makes mapping things like Black Mesa

interesting... spanning the Oklahoma-New Mexico border, seems like an area
outline around the outside of the tabletop would be a good idea.  (Link
goes to OpenCycleMap, the contour lines don't quite pack together in a way
that properly shows how dramatic it looks on satellite).  I have no idea
what the peak point in New Mexico labeled Black Mesa represents (possibly
the highest spot on the mesa's tabletop, but I recognize the one in
Oklahoma as being probably more logically tagged as a tourism attraction or
monument since it's not so much a peak as it is a slightly high prominence
on the top of Black Mesa that happens to be the highest spot in the State
of Oklahoma, even if it's not the highest spot on the top of Black Mesa.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging