Re: [Tagging] Tagging Digest, Vol 108, Issue 162

[Joseph Eisenberg]

Practically, if the ways overlap, it may be hard to render the name labels
and interpret the data.

I’m imagining a routing app for boaters or paddlers. It could announce the
name of each new reach, bend and section, and also warn of hazards: “bridge
in 400 meters”, “Rock hazard”, “rapids ahead, grade 2”. For this case, it
would be harder to use river sections that overlap.

Also, if you wanted to download all the parts of the river into a
spreadsheet, it wouldn’t be easy to analyze the data if ways overlap.

I do like Yves’s suggested tags, for this reason
On Sat, Sep 29, 2018 at 5:19 PM Colin Smale  wrote:

> river_feature would be fine as well as it would imply that it doesn't need
> to be a linear feature, a node would also be OK (for small named bays etc?)
>
> Lets have a go at agreeing the basic principles of what we are trying to
> achieve.
> * there can be contiguous linear sections of a river which can have names
> * there can be small features with names, such as small bays which can
> better be represented by a node
> * they can be "straight" (for example "reaches") or "curved" (for example
> "bends")
> * they can (partially) overlap each other, and there may be gaps (there
> may not be a clear, sharp transition from one section to the next)
> * in the case of linear feature, they encompass the entire width of the
> river and are not just a 2D line
> * for "river", read (river OR stream OR drain OR...)
>
> This is pointing towards:
> * a way along the centre line of the river (colinear with the main_stream
> lines?) OR a node for smaller / non-linear features
> * waterway=river_feature
> * river_feature={reach,bend,bay,...}
> * name=*
>
>
> I would like this to be applicable to lakes as well (why not?) but it's
> difficult to see how a linear feature would apply to a lake. Any comments?
>
> There was a suggestion that we should re-use existing flow lines and not
> superimpose new ways. This would not allow for the fact that two linear
> features may overlap - the end of a "bend" may overlap with the first bit
> of a "reach" for example. The extent of these features may be well defined,
> but they may not be so sharp. My thought is that this freedom to allow
> overlaps is important. Any comments?
>
> On 2018-09-29 00:11, Graeme Fitzpatrick wrote:
>
>
> On Sat, 29 Sep 2018 at 06:32, Colin Smale  wrote:
>
>> The point of raising the "reach" business it to help abstracting the
>> proposed tagging model to make it more generic. If we consolidate all the
>> thoughts expressed so far, we can say that:
>> * there can be contiguous linear sections of a river which can have names
>> * they can be "straight" (for example "reaches") or "curved" (for example
>> "bends")
>> * they can (partially) overlap each other, and there may be gaps (there
>> may not be a clear, sharp transition from one section to the next)
>> * they encompass the entire width of the river and are not just a 2D line
>>
>
>
>> This is pointing towards:
>> * a way along the centre line of the river (colinear with the main_stream
>> lines?)
>> * waterway=river_section
>> * river_section={reach,bend,...}
>> * name=*
>>
>
> Liking your train of thought Colin.
>
> Just wondering, perhaps =river_feature?
>
> I'm not certain about "they encompass the entire width of the river" though?
> Would that then exclude things like *"The Deep Hole"* & *"17 Mile Rocks"*,
> which are both named spots that I can point out on a map?
>
> Thanks
>
> Graeme
>
> ___
> 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] Tagging Digest, Vol 108, Issue 162

[Yves]

For the rare case a 'section' should have two names, the smallest part can have 
it I guess.
Instead of section or reach, there's :part, like in building:part. 

Le 29 septembre 2018 11:24:29 GMT+02:00, Joseph Eisenberg 
 a écrit :
>Practically, if the ways overlap, it may be hard to render the name
>labels
>and interpret the data.
>
>I’m imagining a routing app for boaters or paddlers. It could announce
>the
>name of each new reach, bend and section, and also warn of hazards:
>“bridge
>in 400 meters”, “Rock hazard”, “rapids ahead, grade 2”. For this case,
>it
>would be harder to use river sections that overlap.
>
>Also, if you wanted to download all the parts of the river into a
>spreadsheet, it wouldn’t be easy to analyze the data if ways overlap.
>
>I do like Yves’s suggested tags, for this reason
>On Sat, Sep 29, 2018 at 5:19 PM Colin Smale 
>wrote:
>
>> river_feature would be fine as well as it would imply that it doesn't
>need
>> to be a linear feature, a node would also be OK (for small named bays
>etc?)
>>
>> Lets have a go at agreeing the basic principles of what we are trying
>to
>> achieve.
>> * there can be contiguous linear sections of a river which can have
>names
>> * there can be small features with names, such as small bays which
>can
>> better be represented by a node
>> * they can be "straight" (for example "reaches") or "curved" (for
>example
>> "bends")
>> * they can (partially) overlap each other, and there may be gaps
>(there
>> may not be a clear, sharp transition from one section to the next)
>> * in the case of linear feature, they encompass the entire width of
>the
>> river and are not just a 2D line
>> * for "river", read (river OR stream OR drain OR...)
>>
>> This is pointing towards:
>> * a way along the centre line of the river (colinear with the
>main_stream
>> lines?) OR a node for smaller / non-linear features
>> * waterway=river_feature
>> * river_feature={reach,bend,bay,...}
>> * name=*
>>
>>
>> I would like this to be applicable to lakes as well (why not?) but
>it's
>> difficult to see how a linear feature would apply to a lake. Any
>comments?
>>
>> There was a suggestion that we should re-use existing flow lines and
>not
>> superimpose new ways. This would not allow for the fact that two
>linear
>> features may overlap - the end of a "bend" may overlap with the first
>bit
>> of a "reach" for example. The extent of these features may be well
>defined,
>> but they may not be so sharp. My thought is that this freedom to
>allow
>> overlaps is important. Any comments?
>>
>> On 2018-09-29 00:11, Graeme Fitzpatrick wrote:
>>
>>
>> On Sat, 29 Sep 2018 at 06:32, Colin Smale 
>wrote:
>>
>>> The point of raising the "reach" business it to help abstracting the
>>> proposed tagging model to make it more generic. If we consolidate
>all the
>>> thoughts expressed so far, we can say that:
>>> * there can be contiguous linear sections of a river which can have
>names
>>> * they can be "straight" (for example "reaches") or "curved" (for
>example
>>> "bends")
>>> * they can (partially) overlap each other, and there may be gaps
>(there
>>> may not be a clear, sharp transition from one section to the next)
>>> * they encompass the entire width of the river and are not just a 2D
>line
>>>
>>
>>
>>> This is pointing towards:
>>> * a way along the centre line of the river (colinear with the
>main_stream
>>> lines?)
>>> * waterway=river_section
>>> * river_section={reach,bend,...}
>>> * name=*
>>>
>>
>> Liking your train of thought Colin.
>>
>> Just wondering, perhaps =river_feature?
>>
>> I'm not certain about "they encompass the entire width of the river"
>though?
>> Would that then exclude things like *"The Deep Hole"* & *"17 Mile
>Rocks"*,
>> which are both named spots that I can point out on a map?
>>
>> Thanks
>>
>> Graeme
>>
>> ___
>> 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] Tagging Digest, Vol 108, Issue 162

[Colin Smale]

I would prefer to stay close to real life if possible. We should
choose/adapt our tagging model to match reality, and not try to force
reality into unnatural boxes. If real life has the possibility of
overlaps, we should allow for that. Making the way for "river_feature"
colinear with any existing "centre line" is an artificial construct for
possible convenience. But if it starts limiting our ability to model the
world, then we should abandon that idea. We should not be feeling sorry
for the poor old database because it has to store a few extra nodes. The
name of a given river section is merely a convenience to a canoeist,
whereas warnings about rapids are slightly more important (I imagine,
anyway). I suppose there would be nothing wrong with having a river
section labelled with a name (as we are discussing here), and in
addition, information for the canoeist. How is this latter information
currently modelled in OSM? Is it possible that "rapids" or whatever do
not cover the whole width of the river? In that case they will need
their own polygon. Maybe we should not try to mix up "rapids" etc with
the naming of sections. 

On 2018-09-29 14:22, Yves wrote:

> For the rare case a 'section' should have two names, the smallest part can 
> have it I guess.
> Instead of section or reach, there's :part, like in building:part. 
> 
> Le 29 septembre 2018 11:24:29 GMT+02:00, Joseph Eisenberg 
>  a écrit : Practically, if the ways overlap, it 
> may be hard to render the name labels and interpret the data. 
> 
> I'm imagining a routing app for boaters or paddlers. It could announce the 
> name of each new reach, bend and section, and also warn of hazards: "bridge 
> in 400 meters", "Rock hazard", "rapids ahead, grade 2". For this case, it 
> would be harder to use river sections that overlap.
> 
> Also, if you wanted to download all the parts of the river into a 
> spreadsheet, it wouldn't be easy to analyze the data if ways overlap.
> 
> I do like Yves's suggested tags, for this reason
> 
> On Sat, Sep 29, 2018 at 5:19 PM Colin Smale  wrote: 
> 
> river_feature would be fine as well as it would imply that it doesn't need to 
> be a linear feature, a node would also be OK (for small named bays etc?)
> 
> Lets have a go at agreeing the basic principles of what we are trying to 
> achieve.  
> 
> * there can be contiguous linear sections of a river which can have names 
> * there can be small features with names, such as small bays which can better 
> be represented by a node 
> * they can be "straight" (for example "reaches") or "curved" (for example 
> "bends") 
> * they can (partially) overlap each other, and there may be gaps (there may 
> not be a clear, sharp transition from one section to the next) 
> * in the case of linear feature, they encompass the entire width of the river 
> and are not just a 2D line 
> * for "river", read (river OR stream OR drain OR...) 
> 
> This is pointing towards: 
> * a way along the centre line of the river (colinear with the main_stream 
> lines?) OR a node for smaller / non-linear features 
> * waterway=river_feature 
> * river_feature={reach,bend,bay,...} 
> 
> * name=* 
> 
> I would like this to be applicable to lakes as well (why not?) but it's 
> difficult to see how a linear feature would apply to a lake. Any comments? 
> 
> There was a suggestion that we should re-use existing flow lines and not 
> superimpose new ways. This would not allow for the fact that two linear 
> features may overlap - the end of a "bend" may overlap with the first bit of 
> a "reach" for example. The extent of these features may be well defined, but 
> they may not be so sharp. My thought is that this freedom to allow overlaps 
> is important. Any comments? 
> 
> On 2018-09-29 00:11, Graeme Fitzpatrick wrote: 
> 
> On Sat, 29 Sep 2018 at 06:32, Colin Smale  wrote: 
> 
> The point of raising the "reach" business it to help abstracting the proposed 
> tagging model to make it more generic. If we consolidate all the thoughts 
> expressed so far, we can say that:
> 
> * there can be contiguous linear sections of a river which can have names 
> * they can be "straight" (for example "reaches") or "curved" (for example 
> "bends") 
> * they can (partially) overlap each other, and there may be gaps (there may 
> not be a clear, sharp transition from one section to the next) 
> * they encompass the entire width of the river and are not just a 2D line 
> 
> This is pointing towards: 
> * a way along the centre line of the river (colinear with the main_stream 
> lines?) 
> * waterway=river_section 
> * river_section={reach,bend,...} 
> * name=* 
> 
> Liking your train of thought Colin. 
> 
> Just wondering, perhaps =river_feature? 
> 
> I'm not certain about "they encompass the entire width of the river" though? 
> Would that then exclude things like _"The Deep Hole"_ & _"17 Mile Rocks"_, 
> which are both named spots that I can point out on a map? 
> 
> Thanks 
> 
> Graeme  
> 

Re: [Tagging] Tagging a named river bend

[Martin Koppenhoefer]

sent from a phone

> On 28. Sep 2018, at 02:39, Dave Swarthout  wrote:
> 
> I keep coming back to Martin's place=river_bend. Adding a name=Harper Bend 
> along with that tag would solve the problem in a straightforward manner, 
> would not be confused with the specialized whitewater tagging schemes and 
> would be relatively easy to implement. A look at Taginfo tells me that the 
> "place"  key has been misused quite a bit but I think place=river_bend would 
> be a logical and easily understood new use of the key.


this works best if you want to focus on the fact it is a bend. If we want 
something more generic like “section” that could maybe even be applied to named 
sections of other linear features like city walls / walls, etc.

I would not discard the idea of using some kind of relation for this 
(type=route is not suitable, or is it?). It is the most flexible way to tag as 
it allows for overlapping entities and avoids duplication of ways. If 
overlapping is not required, an additional property like xxx_name does it 
(according to what is xxx, an additional place or waterway or other classifying 
tag would be helpful).


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

Re: [Tagging] mast / tower / communication_tower (again)

[SelfishSeahorse]

Hi

On Sat, 29 Sep 2018 at 00:29, Michael Booth  wrote:
>
> The Wiki definition is: "a huge tower for transmitting radio applications 
> It is often made from concrete and usually a far visible landmark." 
> https://wiki.openstreetmap.org/wiki/Tag:man%20made=communications%20tower
>
> Looking at examples of this tag in OSM I would guess that out of the <4,000 
> objects worldwide most of them do not conform to that definition. Many of 
> them are small mobile phone/cell site "masts", towers less than 100m, or very 
> tall guyed masts.

I fail to understand the difference between a
man_made=communications_tower and man_made=tower +
tower:type=communication. Aren't all towers far visible landmarks?
When is a tower huge? The wiki page also says that 'another indication
is, that a man_made=communications_tower has stairs and a lift inside,
whereas as man_made=tower, tower:type=communication has to be climbed
on the outside.' However this is contradictory with the definition of
man_made=tower: 'a tower is accessible and provides platforms, whereas
a mast only offers ladder steps to climb it.'

It might be better to discourage man_made=communications_tower and tag
them man_made=tower + tower:type=communication + height=*.

> I'd like to retag the structures near me to something more suitable - however 
> the wiki pages aren't very clear in distinguishing between the various 
> constructions and sizes for masts and towers.

I'm not an expert on this, but i think the distinction steps/lift
inside (= tower) vs latter outside (= mast) makes sense.

> Hopefully people can agree that the following should be tagged as 
> man_made=mast or tower + tower:type=communication + tower:construction + 
> height? Using TV transmitters in the UK as examples:
>
> * mast - guyed lattice, 306m: 
> https://en.wikipedia.org/wiki/Durris_transmitting_station
> * mast - guyed tube, 351m: 
> https://en.wikipedia.org/wiki/Belmont_transmitting_station
> * tower - lattice, 219m: 
> https://en.wikipedia.org/wiki/Crystal_Palace_transmitting_station
> * tower - freestanding, 330m: 
> https://en.wikipedia.org/wiki/Emley_Moor_transmitting_station

I would have tagged them the same.

> But how should these examples be tagged in OSM? All of them are 
> self-supporting structures, so in engineering terms they are not masts.
>
> 1. https://binged.it/2xILZO9
> 2. https://www.geograph.org.uk/photo/2361955
> 3. https://www.geograph.org.uk/photo/2337468
> 4. https://en.wikipedia.org/wiki/Charwelton_BT_Tower
> 5. https://www.geograph.org.uk/photo/2053885
> 6. https://binged.it/2xTxcQK
> 7. https://fr.wikipedia.org/wiki/Tour_hertzienne_de_Villeneuve-d%27Ascq
> 8. https://www.geograph.org.uk/photo/2162874

Why aren't 2, 3, 5, 6 and 8 masts and 4 and 7 towers? Because the
structure itself is an antenna?

By the way, i'm wondering if poles with mounted antennas like in the
following image can also be called masts or if man_made=pole
(undocumented, but 2 047 uses so far) would be better?

https://wiki.openstreetmap.org/wiki/File:Mobilfunkmasten_auf_Wohnhaus_Gotzingerplatz_Muenchen.JPG

Regards
Markus

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

Re: [Tagging] Tagging Digest, Vol 108, Issue 162

[Colin Smale]

river_feature would be fine as well as it would imply that it doesn't
need to be a linear feature, a node would also be OK (for small named
bays etc?)

Lets have a go at agreeing the basic principles of what we are trying to
achieve.  

* there can be contiguous linear sections of a river which can have
names 
* there can be small features with names, such as small bays which can
better be represented by a node 
* they can be "straight" (for example "reaches") or "curved" (for
example "bends") 
* they can (partially) overlap each other, and there may be gaps (there
may not be a clear, sharp transition from one section to the next) 
* in the case of linear feature, they encompass the entire width of the
river and are not just a 2D line 
* for "river", read (river OR stream OR drain OR...) 

This is pointing towards: 
* a way along the centre line of the river (colinear with the
main_stream lines?) OR a node for smaller / non-linear features 
* waterway=river_feature 
* river_feature={reach,bend,bay,...} 

* name=* 

I would like this to be applicable to lakes as well (why not?) but it's
difficult to see how a linear feature would apply to a lake. Any
comments? 

There was a suggestion that we should re-use existing flow lines and not
superimpose new ways. This would not allow for the fact that two linear
features may overlap - the end of a "bend" may overlap with the first
bit of a "reach" for example. The extent of these features may be well
defined, but they may not be so sharp. My thought is that this freedom
to allow overlaps is important. Any comments? 

On 2018-09-29 00:11, Graeme Fitzpatrick wrote:

> On Sat, 29 Sep 2018 at 06:32, Colin Smale  wrote: 
> 
>> The point of raising the "reach" business it to help abstracting the 
>> proposed tagging model to make it more generic. If we consolidate all the 
>> thoughts expressed so far, we can say that:
>> 
>> * there can be contiguous linear sections of a river which can have names 
>> * they can be "straight" (for example "reaches") or "curved" (for example 
>> "bends") 
>> * they can (partially) overlap each other, and there may be gaps (there may 
>> not be a clear, sharp transition from one section to the next) 
>> * they encompass the entire width of the river and are not just a 2D line
> 
>> This is pointing towards: 
>> * a way along the centre line of the river (colinear with the main_stream 
>> lines?) 
>> * waterway=river_section 
>> * river_section={reach,bend,...} 
>> * name=*
> 
> Liking your train of thought Colin. 
> 
> Just wondering, perhaps =river_feature? 
> 
> I'm not certain about "they encompass the entire width of the river" though? 
> Would that then exclude things like _"The Deep Hole"_ & _"17 Mile Rocks"_, 
> which are both named spots that I can point out on a map? 
> 
> Thanks 
> 
> Graeme  
> ___
> 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] How to tag prefab / movable buildings

[Martin Koppenhoefer]

sent from a phone

> On 27. Sep 2018, at 15:05, François Lacombe  wrote:
> 
> Should it be building:prefabricated or something else?


along the lines of my reply above, I would suggest structure:prefabricated=yes
facade:prefabricated=yes
etc.
of course there should be definitions what is intended by facade (according to 
the type of facade it can either be just that or can be load bearing).
or we decide prefabricated=yes indicates that both, structure and facade are 
prefabricated.

Tagging of construction types would either require sufficient publicly 
available documentation or your observation of the construction process, or a 
building that doesn’t hide it.

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

Re: [Tagging] waterway bend name WAS Re: Tagging Digest, Vol 108, Issue 168

[Warin]

On 29/09/18 18:09, Martin Koppenhoefer wrote:


sent from a phone


On 29. Sep 2018, at 00:53, Dave Swarthout  wrote:

waterway=river
name=Tanana River
waterway=section
section=bend
section:name=Harper Bend

I like what we've come up with so far. Any more suggestions?


this suggests 2 distinct (likely overlapping way) objects, right?

I would prefer a solution that works without duplicating the way, either by 
reusing it in a relation or by adding bend name properties directly on a part 
of the waterway (i.e. omit waterway=section tag and add all tags to the same 
way).


yves beat you to it by 1 hour 39 mins.
And he has a solution.


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

[Tagging] waterway bend name WAS Re: Tagging Digest, Vol 108, Issue 168

[Martin Koppenhoefer]

sent from a phone

> On 29. Sep 2018, at 00:53, Dave Swarthout  wrote:
> 
> waterway=river
> name=Tanana River
> waterway=section
> section=bend
> section:name=Harper Bend
> 
> I like what we've come up with so far. Any more suggestions?


this suggests 2 distinct (likely overlapping way) objects, right?

I would prefer a solution that works without duplicating the way, either by 
reusing it in a relation or by adding bend name properties directly on a part 
of the waterway (i.e. omit waterway=section tag and add all tags to the same 
way).

Cheers,
Martin


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

Re: [Tagging] Tagging Digest, Vol 108, Issue 162

[Dave Swarthout]

Yes, yes, of course. Quite right, Yves, and Martin.

>> waterway=river
>> name=Tanana River
>> waterway=section
>> section=bend
>> section:name=Harper Bend
>You can't use waterway=section + waterway=river on the same way, and you
>shouldn't map overlapping ways for obvious reasons.

I made that same argument myself earlier and then broke my own rule
immediately. LOL

Yves suggests this scenario:

waterway=river
name=Tanana River
waterway:section=bend
waterway:section_name=Harper Bend

Which I like, except for the way the last tag is written. I would prefer
waterway:section:name=Harper Bend

I don't like mixing the uses of "_" and ":"
The way these two delimiters have been used in OSM has always seemed
muddled to me.

Colin suggested we agree on the goals of this project and wrote:

* there can be contiguous linear sections of a river which can have names
* there can be small features with names, such as small bays which can
better be represented by a node
* they can be "straight" (for example "reaches") or "curved" (for example
"bends")
* they can (partially) overlap each other, and there may be gaps (there may
not be a clear, sharp transition from one section to the next)
* in the case of linear feature, they encompass the entire width of the
river and are not just a 2D line
* for "river", read (river OR stream OR drain OR...)

These indeed are the goals of this discussion as I see them. The last of
these is an attempt to make the tagging consistent for several varieties of
waterway which is why, IMO, we use the waterway key instead of river or
stream, etc.

So, what's next?






On Sat, Sep 29, 2018 at 3:19 PM Colin Smale  wrote:

> river_feature would be fine as well as it would imply that it doesn't need
> to be a linear feature, a node would also be OK (for small named bays etc?)
>
> Lets have a go at agreeing the basic principles of what we are trying to
> achieve.
> * there can be contiguous linear sections of a river which can have names
> * there can be small features with names, such as small bays which can
> better be represented by a node
> * they can be "straight" (for example "reaches") or "curved" (for example
> "bends")
> * they can (partially) overlap each other, and there may be gaps (there
> may not be a clear, sharp transition from one section to the next)
> * in the case of linear feature, they encompass the entire width of the
> river and are not just a 2D line
> * for "river", read (river OR stream OR drain OR...)
>
> This is pointing towards:
> * a way along the centre line of the river (colinear with the main_stream
> lines?) OR a node for smaller / non-linear features
> * waterway=river_feature
> * river_feature={reach,bend,bay,...}
> * name=*
>
>
> I would like this to be applicable to lakes as well (why not?) but it's
> difficult to see how a linear feature would apply to a lake. Any comments?
>
> There was a suggestion that we should re-use existing flow lines and not
> superimpose new ways. This would not allow for the fact that two linear
> features may overlap - the end of a "bend" may overlap with the first bit
> of a "reach" for example. The extent of these features may be well defined,
> but they may not be so sharp. My thought is that this freedom to allow
> overlaps is important. Any comments?
>
> On 2018-09-29 00:11, Graeme Fitzpatrick wrote:
>
>
> On Sat, 29 Sep 2018 at 06:32, Colin Smale  wrote:
>
>> The point of raising the "reach" business it to help abstracting the
>> proposed tagging model to make it more generic. If we consolidate all the
>> thoughts expressed so far, we can say that:
>> * there can be contiguous linear sections of a river which can have names
>> * they can be "straight" (for example "reaches") or "curved" (for example
>> "bends")
>> * they can (partially) overlap each other, and there may be gaps (there
>> may not be a clear, sharp transition from one section to the next)
>> * they encompass the entire width of the river and are not just a 2D line
>>
>
>
>> This is pointing towards:
>> * a way along the centre line of the river (colinear with the main_stream
>> lines?)
>> * waterway=river_section
>> * river_section={reach,bend,...}
>> * name=*
>>
>
> Liking your train of thought Colin.
>
> Just wondering, perhaps =river_feature?
>
> I'm not certain about "they encompass the entire width of the river" though?
> Would that then exclude things like *"The Deep Hole"* & *"17 Mile Rocks"*,
> which are both named spots that I can point out on a map?
>
> Thanks
>
> Graeme
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list

[Tagging] Feature Proposal - RFC - Refilling a purchased drink

[bkil]

I've sliced part of the drinking proposal to a new page. I've copied
the related comments.

So the question here is what would be the most efficient, most
intuitive way to tag places where you can refill your drink for free
(or for a discounted price?) after having purchased the first glass.

https://wiki.openstreetmap.org/wiki/Proposed_features/Refilling_a_purchased_drink

Some of the earlier related e-mails can be found under this thread:
https://lists.openstreetmap.org/pipermail/tagging/2018-September/039164.html


Let me reply to the last question inline here:

On Fri, Sep 21, 2018 at 12:28 AM Tom Pfeifer  wrote:
> (with cheaply produced unhealthy liquids anyway).
>

Well, the chosen drink could be as healthy as 100% fruit juice.
Although, if one is against the practice of refills, mapping these
could come in handy for those who want to campaign against it as well
to organize demonstrations.

> This is close to a restaurant review and
> not a geographical property.
>

The reason why we do not map more properties found in restaurant
reviews is that they fail the verifiability criterion due to
subjectivity or variability. This is why we do not map how "big" or
"delicious" the served meals or sandwiches are, how "spacious",
"crowded" or "clean" a place is, or how "organized", "friendly" or
"fast" table service is.

However, it is perfectly objective whether food is being served at all
(food=*), whether they serve ice cream, burgers or pizza (cuisine=*),
if air conditioning is installed or whether the purchased drinks are
eligible for refill. Verifying these is as simple as looking at the
website, menu or asking the staff and they will give a definite
answer. If you have recently moved to a town, or would like to try out
new places, it is very useful to be able to filter for places offering
carom billiards for example. Buffet lunch and refillable drinks are
feats that people also tend to look for as a novelty, thus it adds
value to be searchable. There exist websites on which you can search
for pubs offering given types of beers or serving breweries if you are
into this kind of thing.

There is nothing geographical about opening hours either, but users
see great value in it, and thus we map it. Compared to the
competition, OSM has the huge advantage of being extensible and being
usable offline. It adds value if we can navigate using a
self-contained database (think contact information). This does not
mean that OpenStreetMap should contain every single piece of
information in the world - we can link to Wikipedia/Wikidata for that.
However, if it sounds reasonable to visualize or search for a location
based on given criteria for a reasonable percentage of users, it
deserves to be mapped. Given such map extracts, business owners can
make decisions to open new venues or change practices at different
localities, tourists can use a reliable, unbiased guide to aid their
trip and stops, open minded locals or those skipping a train can
quickly get informed about new or interesting places to try.

And there's extensibility - the competition only maps for a subset of
highly profitable groups, like western automobile drivers with given
habits, while we can map for everyone. If there exists demand for a
given reasonable map use, we can cover it. Despite only appealing to a
niche, many are mapping using simple 3D tags, because they can.

Also, OSM is all about the community - if a given property has the
potential to increase community engagement, it should be especially
promoted in order to help grow the community itself. For example,
mapping those who welcome freeloaders is a win-win-win situation: the
amenities can see more traffic, passer-by can reduce their thirst and
mapping and actualizing of the amenities themselves can happen by yet
another group of volunteers.

> I am strongly against tagging the business practice how often a _paid_ glass 
> of
> beverage is being refilled
>

Could you please clarify what policy this would violate that makes you
disapprove?

> It does not need much language either, handing the bottle and
> and a friendly look are usually self-explanatory and sufficient.
> I would support tagging the free tap-water refilling campaign as it is 
> apparently a litter-avoiding
> idea and presumably ground-verifiable
>

The owncup=* campaign sounds like an idea to combat waste as well.
However, if a shop is part of both owncup & water-refill campaigns at
the same time, handing over your bottle may result in unwanted
consequences like getting beer in it!

So you vote for the possibility that no extra tag/description should
be added along `drinking_water=yes` (instead of =ask/on_demand) to
indicate that staff is handing out water on request and not a vending
machine/tap?

> (by some sticker or so at the door?).
>

It is definitely verifiable as all of these venues have staff that was
instructed by management to serve water to all, so asking any of them
should yield a unified answer. Some of the 

Re: [Tagging] How to tag prefab / movable buildings

[Graeme Fitzpatrick]

How about demountable buildings, which are "supposed" to be temporary (but
I know of some at schools that have been in place for +30 years now!)

eg https://www.lloydsauctions.com.au/insider/portable-buildings/

Thanks

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

Re: [Tagging] Traffic sign direction tagging..

[Graeme Fitzpatrick]

On Sun, 30 Sep 2018 at 08:58, Paul Johnson  wrote:

>
> I honestly don't understand why, ten years since it's introduction as
> OSM's third basic primitive, there's still this weirdly unnatural aversion
> to relations, even though they're quite a powerful primitive in our toolbox.
>

Maybe because people don't understand how to use them properly (I know I
don't?), so they're scared of them?

Some very simple, easily found, instructions / guidelines would be handy.

Thanks

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

Re: [Tagging] Traffic sign direction tagging..

[Graeme Fitzpatrick]

On Sat, 29 Sep 2018 at 02:58, Philip Barnes  wrote:

> OSMand also warns of traffic calming, toll barriers, level crossing,
> pedestrian crossings and enforcement cameras.
>

Phil

Do you have an example of a pedestrian crossing that OSMand warns you of,
as I don't see (or maybe just don't notice?) crossing warnings, so I'm
wondering if they may be tagged somehow differently?

Thanks

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

Re: [Tagging] Tagging Digest, Vol 108, Issue 162

[Dave Swarthout]

Unfortunately, this topic has gotten split into two threads making it
difficult to follow. In trying to summarize, let's not be overly concerned
with rendering issues or whether this scheme can be fully modeled on OSM.
We can deal with rapids, hazards, etc., using existing tagging or develop
new tagging schemes later. That goes for discussions about using relations
to model "overlaps". I'm trying to tag a river feature, a named bend in the
waterway. Can we decide about the scenario we're currently working with?

This example uses the colon ":" as a separator for different parts of the
keys rather than mixing it with the underscore character "_".

> waterway=river
> name=Tanana River
> waterway:section=bend
> waterway:section:name=Harper Bend

Pros and cons (subject to the limitations I mentioned)?

On Sun, Sep 30, 2018 at 8:13 AM Joseph Eisenberg 
wrote:

> I believe rapids always will cover the width of a river, just like a
> waterfall. Rapids form where the channel of a river heads downhill at a
> steeper grade, and water wants to follow The exception would be a river
> that has split in two at a flat spot up above the rapids (eg the Niagra
> river splits around an island before the Canadian and American falls) but
> in that case there should be 2 ways, one as main_stream and one as
> side_stream. There will still be a rapid or waterfall on each part of the
> river where it crosses the area of different geology, though the location
> might be different in this case.
>
> On Sat, Sep 29, 2018 at 10:39 PM Colin Smale 
> wrote:
>
>> I would prefer to stay close to real life if possible. We should
>> choose/adapt our tagging model to match reality, and not try to force
>> reality into unnatural boxes. If real life has the possibility of overlaps,
>> we should allow for that. Making the way for "river_feature" colinear with
>> any existing "centre line" is an artificial construct for possible
>> convenience. But if it starts limiting our ability to model the world, then
>> we should abandon that idea. We should not be feeling sorry for the poor
>> old database because it has to store a few extra nodes. The name of a given
>> river section is merely a convenience to a canoeist, whereas warnings about
>> rapids are slightly more important (I imagine, anyway). I suppose there
>> would be nothing wrong with having a river section labelled with a name (as
>> we are discussing here), and in addition, information for the canoeist. How
>> is this latter information currently modelled in OSM? Is it possible that
>> "rapids" or whatever do not cover the whole width of the river? In that
>> case they will need their own polygon. Maybe we should not try to mix up
>> "rapids" etc with the naming of sections.
>>
>>
>> On 2018-09-29 14:22, Yves wrote:
>>
>> For the rare case a 'section' should have two names, the smallest part
>> can have it I guess.
>> Instead of section or reach, there's :part, like in building:part.
>>
>> Le 29 septembre 2018 11:24:29 GMT+02:00, Joseph Eisenberg <
>> joseph.eisenb...@gmail.com> a écrit :
>>>
>>> Practically, if the ways overlap, it may be hard to render the name
>>> labels and interpret the data.
>>>
>>> I'm imagining a routing app for boaters or paddlers. It could announce
>>> the name of each new reach, bend and section, and also warn of hazards:
>>> "bridge in 400 meters", "Rock hazard", "rapids ahead, grade 2". For this
>>> case, it would be harder to use river sections that overlap.
>>>
>>> Also, if you wanted to download all the parts of the river into a
>>> spreadsheet, it wouldn't be easy to analyze the data if ways overlap.
>>>
>>> I do like Yves's suggested tags, for this reason
>>> On Sat, Sep 29, 2018 at 5:19 PM Colin Smale 
>>> wrote:
>>>
 river_feature would be fine as well as it would imply that it doesn't
 need to be a linear feature, a node would also be OK (for small named bays
 etc?)

 Lets have a go at agreeing the basic principles of what we are trying
 to achieve.
 * there can be contiguous linear sections of a river which can have
 names
 * there can be small features with names, such as small bays which can
 better be represented by a node
 * they can be "straight" (for example "reaches") or "curved" (for
 example "bends")
 * they can (partially) overlap each other, and there may be gaps (there
 may not be a clear, sharp transition from one section to the next)
 * in the case of linear feature, they encompass the entire width of the
 river and are not just a 2D line
 * for "river", read (river OR stream OR drain OR...)

 This is pointing towards:
 * a way along the centre line of the river (colinear with the
 main_stream lines?) OR a node for smaller / non-linear features
 * waterway=river_feature
 * river_feature={reach,bend,bay,...}
 * name=*


 I would like this to be applicable to lakes as well (why not?) but it's
 difficult to see how a linear 

Re: [Tagging] Tagging a named river bend

[Dave Swarthout]

 Unfortunately, this topic has gotten split into two threads making it
difficult to follow. In trying to summarize, let's not be overly concerned
with rendering issues or whether this scheme can be fully modeled on OSM.
We can deal with rapids, hazards, etc., using existing tagging or develop
new tagging schemes later. That goes for discussions about using relations
to model "overlaps". I'm trying to tag a river feature, a named bend in the
waterway. Can we decide about the scenario we're currently working with?

This example uses the colon ":" as a separator for different parts of the
keys rather than mixing it with the underscore character "_".

> waterway=river
> name=Tanana River
> waterway:section=bend
> waterway:section:name=Harper Bend

Pros and cons (subject to the limitations I mentioned)?

On Sun, Sep 30, 2018 at 6:09 AM Joseph Eisenberg 
wrote:

> Re: "I would not discard the idea of using some kind of relation for this
> (type=route is not suitable, or is it?). It is the most flexible way to tag
> as it allows for overlapping entities and avoids duplication of ways."
>
> In theory, it would be great to be able to build up a long river from many
> nested relations, but it doesn't seem to work now.
>
> Imagine a long river that passes through different language regions, and
> therefore has a different name near the headwaters, in the middle, and near
> the sea. Each short bend, reach, or rapid (in a whitewater river) would be
> a way, perhaps 1/2 to 2km long. Then each named section of the river would
> be made up of several of these ways. And the three long parts of the
> waterway with a different name*(eg name:de= then name:fr= then name:nl=,
> from mountains to sea) would be a relation made up of the shorter relations.
>
> Unfortunately, because "super"-relations are not handled well in the
> editors or any applications, this would be hard to maintain and hard for
> database users. I actually tried doing this for a river in New Guinea that
> changes names between mountains and lowlands, by making a "super"-relation
> that continued a couple of sub-relations, but JOSM complains and it doesn't
> seem to render.
>
> If we ever manage to add "area" as a database primitive, we should
> consider adding "multipolygon" as an area made up of constituent polygons
> and ways, and "linestring" or something, as a longer way made up of shorter
> ways, if such a thing is possible.
>
> (When I used to be able to edit roads on Google Maps, the API seemed to be
> able to recognize that a short segment of a street was part of the longer
> street, and suggested editing the whole longer way (or relation?) when I
> would select the short segment. )
>
> -Joseph
>
> On Sat, Sep 29, 2018 at 10:55 PM Martin Koppenhoefer <
> dieterdre...@gmail.com> wrote:
>
>>
>>
>> sent from a phone
>>
>> > On 28. Sep 2018, at 02:39, Dave Swarthout 
>> wrote:
>> >
>> > I keep coming back to Martin's place=river_bend. Adding a name=Harper
>> Bend along with that tag would solve the problem in a straightforward
>> manner, would not be confused with the specialized whitewater tagging
>> schemes and would be relatively easy to implement. A look at Taginfo tells
>> me that the "place"  key has been misused quite a bit but I think
>> place=river_bend would be a logical and easily understood new use of the
>> key.
>>
>>
>> this works best if you want to focus on the fact it is a bend. If we want
>> something more generic like “section” that could maybe even be applied to
>> named sections of other linear features like city walls / walls, etc.
>>
>> I would not discard the idea of using some kind of relation for this
>> (type=route is not suitable, or is it?). It is the most flexible way to tag
>> as it allows for overlapping entities and avoids duplication of ways. If
>> overlapping is not required, an additional property like xxx_name does it
>> (according to what is xxx, an additional place or waterway or other
>> classifying tag would be helpful).
>>
>>
>> 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
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Default Language Format; language:default or default:language?

[Joseph Eisenberg]

Any opinions on the order of the tag?

Just a couple of people have said that default:language would be preferred
to language:default.

It will take some time to update the proposal page, so I would like a few
more opinions

Joseph

On Thu, Sep 27, 2018 at 10:16 AM Joseph Eisenberg <
joseph.eisenb...@gmail.com> wrote:

> Should we change the tag from language:default to default:language?
>
> I've found out that language:* has already been used in the format
> language:de, language:fr, language:en, etc, for the languages taught at a
> school. See
> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dlanguage_school. And
> language=* has been used, though rarely.
>
> There is also a page for default_language, which was made without going
> through the proposal process. And there is a new proposal to specify all
> "defaults" in the fomat default:subkey, though I have also seen this the
> other way around, eg key:default, suggested for maxspeed.
>
> I am not wedded to the current tag "language:default=". Please
> respond here (or on the talk page) if you prefer default:language= or
> default_language=, or if you prefer the current order.
>
> Proposal:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Default_Language_Format
>
> Talk page:
> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Default_Language_Format
>
> Thank you,
> Joseph
>
> On Mon, Sep 24, 2018 at 9:36 PM Joseph Eisenberg <
> joseph.eisenb...@gmail.com> wrote:
>
>> Please see the Proposal page for the new tag, "language:default=> code>"
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Default_Language_Format
>>
>> Description:
>> "Specify the default language format used for names, and recommend use
>> of language-specific name tags.
>>
>> "By making it easier to use language-specific name:code=* tags to be
>> used instead of the default name=* tag, this proposal will encourage
>> the use of name tags that include the language code for all features.
>> This will improve the quality and utility of the database. It will be
>> possible to display non-Western languages in their correct orientation
>> and script, properly display multilingual names, and to research the
>> most commonly used language formats in a particular area.
>>
>> "The key language:default=* with a 2 or 3 letter ISO language code
>> should be tagged on administrative boundary relations, such as
>> countries, provinces and aboriginal communities. This is the language
>> used for the majority of named features within a particular region, as
>> indicated on public signs and in common use by the local community. If
>> the language can be written in more than one script, a qualifier can
>> be added to specify the script format. More than one language code can
>> be listed, separated with a semicolon, if the local community uses
>> more than one language on signs or by consensus.
>>
>> "The language tag should be applied to the largest boundary relation
>> that accurately represents the language used for default names. When a
>> smaller administrative boundary has a different default language
>> format, this boundary should receive a language tag as well. This
>> would include boundaries of provinces or aboriginal lands where a
>> different language is used.
>>
>> "The language tag may also be applied to individual features when the
>> name is in a different language than the default for the region, or
>> when the feature crosses a border."
>>
>> Please read the whole page, which has quite a number of examples and a
>> detailed rationale for the proposal, then please comment here or on
>> the discussion page:
>>
>> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Default_Language_Format
>>
>> Thank you for all of your comments, criticisms and suggestions
>> -Joseph
>>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Traffic sign direction tagging..

[Paul Johnson]

On Fri, Sep 28, 2018 at 11:09 AM Bryan Housel  wrote:

> I actually mentioned the issue in Milano.
>
> Essentially `traffic_sign`, `traffic_sign:forward` and
> `traffic_sign:backward` need to be treated as "object" tags as things are
> now.
>
> Let’s just do `traffic_sign=*` and consider the others an unfortunate
> mistake that can go away.
>

I'm still against using forward/backward on nodes, it really feels like a
hacky way to avoid using a relation (up there with using ref=* on ways to
describe routes), which would disambiguate things without being so brittle
just because a way reversed, and handle more complex situations like "right
turn permitted without stopping" sign below a "stop" sign, or allow a data
consumer to be able to display a diagram indicating which ways a stop
applies to (handy if you encounter, say, a six way intersection with a four
way stop).

I honestly don't understand why, ten years since it's introduction as OSM's
third basic primitive, there's still this weirdly unnatural aversion to
relations, even though they're quite a powerful primitive in our toolbox.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging a named river bend

[Joseph Eisenberg]

Re: "I would not discard the idea of using some kind of relation for this
(type=route is not suitable, or is it?). It is the most flexible way to tag
as it allows for overlapping entities and avoids duplication of ways."

In theory, it would be great to be able to build up a long river from many
nested relations, but it doesn't seem to work now.

Imagine a long river that passes through different language regions, and
therefore has a different name near the headwaters, in the middle, and near
the sea. Each short bend, reach, or rapid (in a whitewater river) would be
a way, perhaps 1/2 to 2km long. Then each named section of the river would
be made up of several of these ways. And the three long parts of the
waterway with a different name*(eg name:de= then name:fr= then name:nl=,
from mountains to sea) would be a relation made up of the shorter relations.

Unfortunately, because "super"-relations are not handled well in the
editors or any applications, this would be hard to maintain and hard for
database users. I actually tried doing this for a river in New Guinea that
changes names between mountains and lowlands, by making a "super"-relation
that continued a couple of sub-relations, but JOSM complains and it doesn't
seem to render.

If we ever manage to add "area" as a database primitive, we should consider
adding "multipolygon" as an area made up of constituent polygons and ways,
and "linestring" or something, as a longer way made up of shorter ways, if
such a thing is possible.

(When I used to be able to edit roads on Google Maps, the API seemed to be
able to recognize that a short segment of a street was part of the longer
street, and suggested editing the whole longer way (or relation?) when I
would select the short segment. )

-Joseph

On Sat, Sep 29, 2018 at 10:55 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 28. Sep 2018, at 02:39, Dave Swarthout 
> wrote:
> >
> > I keep coming back to Martin's place=river_bend. Adding a name=Harper
> Bend along with that tag would solve the problem in a straightforward
> manner, would not be confused with the specialized whitewater tagging
> schemes and would be relatively easy to implement. A look at Taginfo tells
> me that the "place"  key has been misused quite a bit but I think
> place=river_bend would be a logical and easily understood new use of the
> key.
>
>
> this works best if you want to focus on the fact it is a bend. If we want
> something more generic like “section” that could maybe even be applied to
> named sections of other linear features like city walls / walls, etc.
>
> I would not discard the idea of using some kind of relation for this
> (type=route is not suitable, or is it?). It is the most flexible way to tag
> as it allows for overlapping entities and avoids duplication of ways. If
> overlapping is not required, an additional property like xxx_name does it
> (according to what is xxx, an additional place or waterway or other
> classifying tag would be helpful).
>
>
> 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] mast / tower / communication_tower (again)

[Graeme Fitzpatrick]

On Sun, 30 Sep 2018 at 00:54, SelfishSeahorse 
wrote:

>
> On Sat, 29 Sep 2018 at 00:29, Michael Booth  wrote:
>
> I fail to understand the difference between a
> man_made=communications_tower and man_made=tower +
> tower:type=communication. Aren't all towers far visible landmarks?
> When is a tower huge? The wiki page also says that 'another indication
> is, that a man_made=communications_tower has stairs and a lift inside,
> whereas as man_made=tower, tower:type=communication has to be climbed
> on the outside.' However this is contradictory with the definition of
> man_made=tower: 'a tower is accessible and provides platforms, whereas
> a mast only offers ladder steps to climb it.'
>
> It might be better to discourage man_made=communications_tower and tag
> them man_made=tower + tower:type=communication + height=*.
>
> > I'd like to retag the structures near me to something more suitable -
> however the wiki pages aren't very clear in distinguishing between the
> various constructions and sizes for masts and towers.
>
> I'm not an expert on this, but i think the distinction steps/lift
> inside (= tower) vs latter outside (= mast) makes sense.
>

Agree with you both that the definitions are contradictory :-(
https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dmast says that

"In structural engineering, *mast* is a vertical structure, supported by
external guys and anchors.

This is the only existing definite feature that could be used to
differentiate masts and towers."

but then shows an photo example of a "mast" with no guys.


> 1. https://binged.it/2xILZO9
> > 2. https://www.geograph.org.uk/photo/2361955
> > 3. https://www.geograph.org.uk/photo/2337468
> > 4. https://en.wikipedia.org/wiki/Charwelton_BT_Tower
> > 5. https://www.geograph.org.uk/photo/2053885
> > 6. https://binged.it/2xTxcQK
> > 7. https://fr.wikipedia.org/wiki/Tour_hertzienne_de_Villeneuve-d%27Ascq
> > 8. https://www.geograph.org.uk/photo/2162874
>
> Why aren't 2, 3, 5, 6 and 8 masts and 4 and 7 towers? Because the
> structure itself is an antenna?
>

Going by that definition, none of them are masts are they're not guyed? But
this:
https://www.google.com/maps/@-27.3092365,153.0188494,3a,26.8y,208.74h,113.98t/data=!3m7!1e1!3m5!1s5_tHVpvyp4DL3A_9vMPZYw!2e0!6s%2F%2Fgeo0.ggpht.com%2Fcbk%3Fpanoid%3D5_tHVpvyp4DL3A_9vMPZYw%26output%3Dthumbnail%26cb_client%3Dmaps_sv.tactile.gps%26thumb%3D2%26w%3D203%26h%3D100%26yaw%3D306.1943%26pitch%3D0%26thumbfov%3D100!7i13312!8i6656
*is* a mast.


> By the way, i'm wondering if poles with mounted antennas like in the
> following image can also be called masts or if man_made=pole
> (undocumented, but 2 047 uses so far) would be better?
>

Possibly so, but by your own question "When is a tower huge?", when does a
pole become a mast / tower? :-)

Thanks

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

Re: [Tagging] Tagging Digest, Vol 108, Issue 162

[Joseph Eisenberg]

I believe rapids always will cover the width of a river, just like a
waterfall. Rapids form where the channel of a river heads downhill at a
steeper grade, and water wants to follow The exception would be a river
that has split in two at a flat spot up above the rapids (eg the Niagra
river splits around an island before the Canadian and American falls) but
in that case there should be 2 ways, one as main_stream and one as
side_stream. There will still be a rapid or waterfall on each part of the
river where it crosses the area of different geology, though the location
might be different in this case.

On Sat, Sep 29, 2018 at 10:39 PM Colin Smale  wrote:

> I would prefer to stay close to real life if possible. We should
> choose/adapt our tagging model to match reality, and not try to force
> reality into unnatural boxes. If real life has the possibility of overlaps,
> we should allow for that. Making the way for "river_feature" colinear with
> any existing "centre line" is an artificial construct for possible
> convenience. But if it starts limiting our ability to model the world, then
> we should abandon that idea. We should not be feeling sorry for the poor
> old database because it has to store a few extra nodes. The name of a given
> river section is merely a convenience to a canoeist, whereas warnings about
> rapids are slightly more important (I imagine, anyway). I suppose there
> would be nothing wrong with having a river section labelled with a name (as
> we are discussing here), and in addition, information for the canoeist. How
> is this latter information currently modelled in OSM? Is it possible that
> "rapids" or whatever do not cover the whole width of the river? In that
> case they will need their own polygon. Maybe we should not try to mix up
> "rapids" etc with the naming of sections.
>
>
> On 2018-09-29 14:22, Yves wrote:
>
> For the rare case a 'section' should have two names, the smallest part can
> have it I guess.
> Instead of section or reach, there's :part, like in building:part.
>
> Le 29 septembre 2018 11:24:29 GMT+02:00, Joseph Eisenberg <
> joseph.eisenb...@gmail.com> a écrit :
>>
>> Practically, if the ways overlap, it may be hard to render the name
>> labels and interpret the data.
>>
>> I'm imagining a routing app for boaters or paddlers. It could announce
>> the name of each new reach, bend and section, and also warn of hazards:
>> "bridge in 400 meters", "Rock hazard", "rapids ahead, grade 2". For this
>> case, it would be harder to use river sections that overlap.
>>
>> Also, if you wanted to download all the parts of the river into a
>> spreadsheet, it wouldn't be easy to analyze the data if ways overlap.
>>
>> I do like Yves's suggested tags, for this reason
>> On Sat, Sep 29, 2018 at 5:19 PM Colin Smale 
>> wrote:
>>
>>> river_feature would be fine as well as it would imply that it doesn't
>>> need to be a linear feature, a node would also be OK (for small named bays
>>> etc?)
>>>
>>> Lets have a go at agreeing the basic principles of what we are trying to
>>> achieve.
>>> * there can be contiguous linear sections of a river which can have names
>>> * there can be small features with names, such as small bays which can
>>> better be represented by a node
>>> * they can be "straight" (for example "reaches") or "curved" (for
>>> example "bends")
>>> * they can (partially) overlap each other, and there may be gaps (there
>>> may not be a clear, sharp transition from one section to the next)
>>> * in the case of linear feature, they encompass the entire width of the
>>> river and are not just a 2D line
>>> * for "river", read (river OR stream OR drain OR...)
>>>
>>> This is pointing towards:
>>> * a way along the centre line of the river (colinear with the
>>> main_stream lines?) OR a node for smaller / non-linear features
>>> * waterway=river_feature
>>> * river_feature={reach,bend,bay,...}
>>> * name=*
>>>
>>>
>>> I would like this to be applicable to lakes as well (why not?) but it's
>>> difficult to see how a linear feature would apply to a lake. Any comments?
>>>
>>> There was a suggestion that we should re-use existing flow lines and not
>>> superimpose new ways. This would not allow for the fact that two linear
>>> features may overlap - the end of a "bend" may overlap with the first bit
>>> of a "reach" for example. The extent of these features may be well defined,
>>> but they may not be so sharp. My thought is that this freedom to allow
>>> overlaps is important. Any comments?
>>>
>>> On 2018-09-29 00:11, Graeme Fitzpatrick wrote:
>>>
>>>
>>> On Sat, 29 Sep 2018 at 06:32, Colin Smale  wrote:
>>>
 The point of raising the "reach" business it to help abstracting the
 proposed tagging model to make it more generic. If we consolidate all the
 thoughts expressed so far, we can say that:
 * there can be contiguous linear sections of a river which can have
 names
 * they can be "straight" (for example "reaches") or "curved" (for
 example 

Re: [Tagging] My "weirdly unnatural aversion to relations"

[Bryan Housel]

> On Sep 29, 2018, at 6:56 PM, Paul Johnson  wrote:
> 
> I honestly don't understand why, ten years since it's introduction as OSM's 
> third basic primitive, there's still this weirdly unnatural aversion to 
> relations, even though they're quite a powerful primitive in our toolbox.

From my own perspective as the main developer on the main editor for OSM, the 
reason I don’t like relations very much is because:
- every type of node basically works the same.
- every type of linear way basically works the same.
- every type of polygonal area basically works the same 
- every type of relation is an edge case that requires special code in order 
not to break.  

Relations are also problematic because they are unbounded.  Want to make a 
boundary relation with a million child ways?  This is allowed.  Want to ensure 
that all those ways are connected?  It may take minutes to download them all.  

They’re almost even a security threat.  I’m willing to bet a black hat could 
design and upload a relation that would destroy OSM.. Or at least, crash every 
piece of software in the stack that we rely on:  mapnik, osmium, and any editor 
that tries to touch it.  

Anyway, I’m not totally against them, but every one of them is different and I 
can't spend weeks or months supporting every kind of relation or public 
transport schema people dream up unless it’s super critical for building a 
useful map (like turn restrictions).  They are really best for features that 
can not be mapped any other way.

Thanks, Bryan

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

Re: [Tagging] My "weirdly unnatural aversion to relations"

[Joseph Eisenberg]

Would it be helpful if there were several simpler database primitives for
several of the simplest types of relations?

I know people have already talked for years about adding a true area object
(which now we imitate with closed ways)

Could we also have a linear feature made up of ways only? This would
include the current route and waterway relations. Would something like this
be helpful, especially if there were a  limit to how many ways could be
included?

Could multipolygons be specifically defined, perhaps as a type of area?

I do think it is strange that any random collection of nodes and ways can
form a relation. And the ability to make relations out of other relations
is also confusing.

But it would be quite helpful to be able to make relations from smaller
relations, in the simpler cases of a Lake with an island inside
(multipolygon in a multipolygon), or a long highway made of shorter routes,
or a long river made of shorter waterway relations.

-Joseph

On Sun, Sep 30, 2018 at 12:01 PM Bryan Housel  wrote:

> On Sep 29, 2018, at 6:56 PM, Paul Johnson  wrote:
>
> I honestly don't understand why, ten years since it's introduction as
> OSM's third basic primitive, there's still this weirdly unnatural aversion
> to relations, even though they're quite a powerful primitive in our toolbox.
>
>
> From my own perspective as the main developer on the main editor for OSM,
> the reason I don’t like relations very much is because:
> - every type of node basically works the same.
> - every type of linear way basically works the same.
> - every type of polygonal area basically works the same
> *- every type of relation is an edge case that requires special code in
> order not to break.  *
>
> Relations are also problematic because they are unbounded.  Want to make a
> boundary relation with a million child ways?  This is allowed.  Want to
> ensure that all those ways are connected?  It may take minutes to download
> them all.
>
> They’re almost even a security threat.  I’m willing to bet a black hat
> could design and upload a relation that would destroy OSM.. Or at least,
> crash every piece of software in the stack that we rely on:  mapnik,
> osmium, and any editor that tries to touch it.
>
> Anyway, I’m not totally against them, but every one of them is different
> and I can't spend weeks or months supporting every kind of relation or
> public transport schema people dream up unless it’s super critical for
> building a useful map (like turn restrictions).  They are really best for
> features that can not be mapped any other way.
>
> Thanks, Bryan
>
> ___
> 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] Tagging a named river bend

[Dave Swarthout]

 Correct. I will split the river way at either end of the bend and apply
the section tags to that piece only. The river continues to have its own
name tag while the bend has only the tags needed to identify it as a
section with special characteristics, and also a name

On Sun, Sep 30, 2018 at 10:33 AM Joseph Eisenberg <
joseph.eisenb...@gmail.com> wrote:

> I think this is a good solution for your situation; tagging bends and
> reaches. It should work for other types of waterways too.
>
> I assume in this example you will be splitting the way (waterway=river) at
> the beginning and end of the bend? So there are no overlapping or duplicate
> ways.
> On Sun, Sep 30, 2018 at 11:28 AM Dave Swarthout 
> wrote:
>
>> Unfortunately, this topic has gotten split into two threads making it
>> difficult to follow. In trying to summarize, let's not be overly concerned
>> with rendering issues or whether this scheme can be fully modeled on OSM.
>> We can deal with rapids, hazards, etc., using existing tagging or develop
>> new tagging schemes later. That goes for discussions about using relations
>> to model "overlaps". I'm trying to tag a river feature, a named bend in the
>> waterway. Can we decide about the scenario we're currently working with?
>>
>> This example uses the colon ":" as a separator for different parts of the
>> keys rather than mixing it with the underscore character "_".
>>
>> > waterway=river
>> > name=Tanana River
>> > waterway:section=bend
>> > waterway:section:name=Harper Bend
>>
>> Pros and cons (subject to the limitations I mentioned)?
>>
>> On Sun, Sep 30, 2018 at 6:09 AM Joseph Eisenberg <
>> joseph.eisenb...@gmail.com> wrote:
>>
>>> Re: "I would not discard the idea of using some kind of relation for
>>> this (type=route is not suitable, or is it?). It is the most flexible way
>>> to tag as it allows for overlapping entities and avoids duplication of
>>> ways."
>>>
>>> In theory, it would be great to be able to build up a long river from
>>> many nested relations, but it doesn't seem to work now.
>>>
>>> Imagine a long river that passes through different language regions, and
>>> therefore has a different name near the headwaters, in the middle, and near
>>> the sea. Each short bend, reach, or rapid (in a whitewater river) would be
>>> a way, perhaps 1/2 to 2km long. Then each named section of the river would
>>> be made up of several of these ways. And the three long parts of the
>>> waterway with a different name*(eg name:de= then name:fr= then name:nl=,
>>> from mountains to sea) would be a relation made up of the shorter relations.
>>>
>>> Unfortunately, because "super"-relations are not handled well in the
>>> editors or any applications, this would be hard to maintain and hard for
>>> database users. I actually tried doing this for a river in New Guinea that
>>> changes names between mountains and lowlands, by making a "super"-relation
>>> that continued a couple of sub-relations, but JOSM complains and it doesn't
>>> seem to render.
>>>
>>> If we ever manage to add "area" as a database primitive, we should
>>> consider adding "multipolygon" as an area made up of constituent polygons
>>> and ways, and "linestring" or something, as a longer way made up of shorter
>>> ways, if such a thing is possible.
>>>
>>> (When I used to be able to edit roads on Google Maps, the API seemed to
>>> be able to recognize that a short segment of a street was part of the
>>> longer street, and suggested editing the whole longer way (or relation?)
>>> when I would select the short segment. )
>>>
>>> -Joseph
>>>
>>> On Sat, Sep 29, 2018 at 10:55 PM Martin Koppenhoefer <
>>> dieterdre...@gmail.com> wrote:
>>>


 sent from a phone

 > On 28. Sep 2018, at 02:39, Dave Swarthout 
 wrote:
 >
 > I keep coming back to Martin's place=river_bend. Adding a name=Harper
 Bend along with that tag would solve the problem in a straightforward
 manner, would not be confused with the specialized whitewater tagging
 schemes and would be relatively easy to implement. A look at Taginfo tells
 me that the "place"  key has been misused quite a bit but I think
 place=river_bend would be a logical and easily understood new use of the
 key.


 this works best if you want to focus on the fact it is a bend. If we
 want something more generic like “section” that could maybe even be applied
 to named sections of other linear features like city walls / walls, etc.

 I would not discard the idea of using some kind of relation for this
 (type=route is not suitable, or is it?). It is the most flexible way to tag
 as it allows for overlapping entities and avoids duplication of ways. If
 overlapping is not required, an additional property like xxx_name does it
 (according to what is xxx, an additional place or waterway or other
 classifying tag would be helpful).


 Cheers,
 Martin
 

Re: [Tagging] Traffic sign direction tagging..

[Kevin Kenny]

On Sat, Sep 29, 2018 at 6:58 PM Paul Johnson  wrote:
> I'm still against using forward/backward on nodes, it really feels like a 
> hacky way to avoid using a relation (up there with using ref=* on ways to 
> describe routes), which would disambiguate things without being so brittle 
> just because a way reversed, and handle more complex situations like "right 
> turn permitted without stopping" sign below a "stop" sign, or allow a data 
> consumer to be able to display a diagram indicating which ways a stop applies 
> to (handy if you encounter, say, a six way intersection with a four way stop).
>
> I honestly don't understand why, ten years since it's introduction as OSM's 
> third basic primitive, there's still this weirdly unnatural aversion to 
> relations, even though they're quite a powerful primitive in our toolbox.

I agree with you that we need to design relations for the complex
cases such as what you describe, but I've no problem with the 'hacky'
approach as well - on the principle of 'make simple things easy and
complex things possible'. JOSM (and from what I understand, iD, but I
rarely use it) handles directional nodes on ways fairly competently,
detecting that the mapper is reversing a way that has such nodes
attached and asking what to do about them.

As far as the aversion to relations goes, I think a big part of it is
simply that the downstream support just isn't there.  The tools do
multipolygons fairly well, but that is the only relation that is
really handled well. A bit part of that is that once OSM data has been
through a stock osm2pgsql, there are no relations any more.
Multipolygons become first class objects, and all other relations are
handled at best by devolving their tags upon their components.

(The rest of this message is off the topic of stop signs.)

You raise the issue of ref=* on ways, and why we still use it. That's
a clear case where we use it because the downstream systems can't do
route relations.  I've been trying to help with this - at least to the
extent of trying to revive Phil! Gold's route relation processing. My
version is at https://github.com/kennykb/osm-shields, and you can see
one rendering with shaped shields based on relations at
https://kbk.is-a-geek.net/catskills/test4.html?la=42.7440=-72.4830=11.
That link is chosen to illustrate an area that intermixes 'tag on way'
with 'tag on relation'. Unfortunately, my time is limited, so the
project has stagnated for a few weeks.  I've not given up, though; the
next task will have to be to generate a pull request to adapt
osm2pgsql optionally to preserve relations, with two new tables to
track them.

Alas, I don't have much hope that the pull request will be accepted.
I've asked the upstream developers several times if they could
possibly review the proposed functionality (I've at least a draft at a
formal proposal -
https://github.com/kennykb/osm-shields/wiki/Proposal:-add-route-tables-to-osm2pgsql)
so that I can know whether I'm entirely wasting my time. I've heard
nothng but silence.

This silence is understandable. The developers are very, very busy,
with much more urgent issues to address. I've not yet advanced the
idea far enough to merit their attention. But at some point, I will
have to conclude that further advances will simply cost me too much in
time and money to be worth risking, because a likely outcome is that
when I do get someone's attention, the whole idea will be dismissed
out of hand.

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

Re: [Tagging] Tagging a named river bend

[Joseph Eisenberg]

I think this is a good solution for your situation; tagging bends and
reaches. It should work for other types of waterways too.

I assume in this example you will be splitting the way (waterway=river) at
the beginning and end of the bend? So there are no overlapping or duplicate
ways.
On Sun, Sep 30, 2018 at 11:28 AM Dave Swarthout 
wrote:

> Unfortunately, this topic has gotten split into two threads making it
> difficult to follow. In trying to summarize, let's not be overly concerned
> with rendering issues or whether this scheme can be fully modeled on OSM.
> We can deal with rapids, hazards, etc., using existing tagging or develop
> new tagging schemes later. That goes for discussions about using relations
> to model "overlaps". I'm trying to tag a river feature, a named bend in the
> waterway. Can we decide about the scenario we're currently working with?
>
> This example uses the colon ":" as a separator for different parts of the
> keys rather than mixing it with the underscore character "_".
>
> > waterway=river
> > name=Tanana River
> > waterway:section=bend
> > waterway:section:name=Harper Bend
>
> Pros and cons (subject to the limitations I mentioned)?
>
> On Sun, Sep 30, 2018 at 6:09 AM Joseph Eisenberg <
> joseph.eisenb...@gmail.com> wrote:
>
>> Re: "I would not discard the idea of using some kind of relation for this
>> (type=route is not suitable, or is it?). It is the most flexible way to tag
>> as it allows for overlapping entities and avoids duplication of ways."
>>
>> In theory, it would be great to be able to build up a long river from
>> many nested relations, but it doesn't seem to work now.
>>
>> Imagine a long river that passes through different language regions, and
>> therefore has a different name near the headwaters, in the middle, and near
>> the sea. Each short bend, reach, or rapid (in a whitewater river) would be
>> a way, perhaps 1/2 to 2km long. Then each named section of the river would
>> be made up of several of these ways. And the three long parts of the
>> waterway with a different name*(eg name:de= then name:fr= then name:nl=,
>> from mountains to sea) would be a relation made up of the shorter relations.
>>
>> Unfortunately, because "super"-relations are not handled well in the
>> editors or any applications, this would be hard to maintain and hard for
>> database users. I actually tried doing this for a river in New Guinea that
>> changes names between mountains and lowlands, by making a "super"-relation
>> that continued a couple of sub-relations, but JOSM complains and it doesn't
>> seem to render.
>>
>> If we ever manage to add "area" as a database primitive, we should
>> consider adding "multipolygon" as an area made up of constituent polygons
>> and ways, and "linestring" or something, as a longer way made up of shorter
>> ways, if such a thing is possible.
>>
>> (When I used to be able to edit roads on Google Maps, the API seemed to
>> be able to recognize that a short segment of a street was part of the
>> longer street, and suggested editing the whole longer way (or relation?)
>> when I would select the short segment. )
>>
>> -Joseph
>>
>> On Sat, Sep 29, 2018 at 10:55 PM Martin Koppenhoefer <
>> dieterdre...@gmail.com> wrote:
>>
>>>
>>>
>>> sent from a phone
>>>
>>> > On 28. Sep 2018, at 02:39, Dave Swarthout 
>>> wrote:
>>> >
>>> > I keep coming back to Martin's place=river_bend. Adding a name=Harper
>>> Bend along with that tag would solve the problem in a straightforward
>>> manner, would not be confused with the specialized whitewater tagging
>>> schemes and would be relatively easy to implement. A look at Taginfo tells
>>> me that the "place"  key has been misused quite a bit but I think
>>> place=river_bend would be a logical and easily understood new use of the
>>> key.
>>>
>>>
>>> this works best if you want to focus on the fact it is a bend. If we
>>> want something more generic like “section” that could maybe even be applied
>>> to named sections of other linear features like city walls / walls, etc.
>>>
>>> I would not discard the idea of using some kind of relation for this
>>> (type=route is not suitable, or is it?). It is the most flexible way to tag
>>> as it allows for overlapping entities and avoids duplication of ways. If
>>> overlapping is not required, an additional property like xxx_name does it
>>> (according to what is xxx, an additional place or waterway or other
>>> classifying tag would be helpful).
>>>
>>>
>>> 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
>>
>
>
> --
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Travel Blog at http://dswarthout.blogspot.com
> ___
> Tagging mailing list

Re: [Tagging] Traffic sign direction tagging..

[Paul Johnson]

On Fri, Sep 28, 2018 at 11:58 AM Philip Barnes  wrote:

>
>
> On 28 September 2018 17:31:18 BST, Kevin Kenny 
> wrote:
> >On Fri, Sep 28, 2018, 5:34 AM Marc Gemis  wrote:
> >
> >> I still highway=give_way and highway=stop with
> >> direction=forward/backward (which is used by OsmAnd AFAIK).
> >
> >
> >Me, too - I went around my neighbourhood last year adding them. OSMand
> >does
> >indeed recognize them.
> >
> >Describing what a driver might see when approaching a turn would be an
> >effective use of traffic_sign, but 'node near the way' is pretty
> >useless
> >for routing. For maximal detail you'd need both, but if you're only
> >going
> >to add one, the highway=stop is far more useful.
> +1
> although also mapping the signs is useful for debugging.
>
> OSMand also warns of traffic calming, toll barriers, level crossing,
> pedestrian crossings and enforcement cameras.
>

Also stopped warning of rumble strips, which is annoying since they're
almost impossible to spot in advance in Oklahoma, as most of them are
unpainted and, depending on the vehicle really try to wrest control of the
steering away from motorists or introduce harmonic oscillation (aka speed
wobbles) in two wheeled vehicles in the worst case, and really give you a
good jumpscare at best.

I honestly miss getting "Attention: Rumble strip" out of Osmand.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging Digest, Vol 108, Issue 162

[Graeme Fitzpatrick]

On Sat, 29 Sep 2018 at 18:19, Colin Smale  wrote:

> I would like this to be applicable to lakes as well (why not?) but it's
> difficult to see how a linear feature would apply to a lake. Any comments?
>
How about permanent "lanes" (moored rows of buoys) for rowing races /
practice - not sure how you'd name it though?

On Sat, 29 Sep 2018 at 23:39, Colin Smale  wrote:

> How is this latter information currently modelled in OSM? Is it possible
> that "rapids" or whatever do not cover the whole width of the river? In
> that case they will need their own polygon. Maybe we should not try to mix
> up "rapids" etc with the naming of sections.
>
Here are several examples that I noticed while working on one of our local
Creeks recently - which is certainly *not* white water! :-)

https://www.openstreetmap.org/node/5434480021#map=19/-28.09408/153.46106

https://www.openstreetmap.org/node/5434480020

https://www.openstreetmap.org/node/5434480022

https://www.openstreetmap.org/node/5434480023

Unfortunately, none of these render on the standard map - they're only
visible in edit mode (at least in iD?)

Thanks

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

Re: [Tagging] My "weirdly unnatural aversion to relations"

[Dave Swarthout]

I'm surprised to learn that a major developer has reservations and concerns
about OSM relations. I don't like them much either. Small ones like simple
riverbanks and lakes containing islands are okay but when they get large,
they're difficult to understand and nearly impossible to debug. There are
myriad tools to "assist" the debugging process but which tool is best to
use and when? And how does the tool itself work? I've got a "polygon is not
closed" error that I must've inadvertently caused on a big riverbank
relation in Alaska. When I go into the relation editor and ask it to "jump
to the error", it highlights an entire, many miles long riverbank. This is
not helpful at all. For the moment I'm stuck. I have much I want to
accomplish in my Mapping Alaska (as I call it) project. Debugging an
obscure error in a large relation slows me down horribly.

I'll be following this thread to see if I can learn more about how to deal
with them.

Dave



On Sun, Sep 30, 2018 at 10:28 AM Joseph Eisenberg <
joseph.eisenb...@gmail.com> wrote:

> Would it be helpful if there were several simpler database primitives for
> several of the simplest types of relations?
>
> I know people have already talked for years about adding a true area
> object (which now we imitate with closed ways)
>
> Could we also have a linear feature made up of ways only? This would
> include the current route and waterway relations. Would something like this
> be helpful, especially if there were a  limit to how many ways could be
> included?
>
> Could multipolygons be specifically defined, perhaps as a type of area?
>
> I do think it is strange that any random collection of nodes and ways can
> form a relation. And the ability to make relations out of other relations
> is also confusing.
>
> But it would be quite helpful to be able to make relations from smaller
> relations, in the simpler cases of a Lake with an island inside
> (multipolygon in a multipolygon), or a long highway made of shorter routes,
> or a long river made of shorter waterway relations.
>
> -Joseph
>
> On Sun, Sep 30, 2018 at 12:01 PM Bryan Housel  wrote:
>
>> On Sep 29, 2018, at 6:56 PM, Paul Johnson  wrote:
>>
>> I honestly don't understand why, ten years since it's introduction as
>> OSM's third basic primitive, there's still this weirdly unnatural aversion
>> to relations, even though they're quite a powerful primitive in our toolbox.
>>
>>
>> From my own perspective as the main developer on the main editor for OSM,
>> the reason I don’t like relations very much is because:
>> - every type of node basically works the same.
>> - every type of linear way basically works the same.
>> - every type of polygonal area basically works the same
>> *- every type of relation is an edge case that requires special code in
>> order not to break.  *
>>
>> Relations are also problematic because they are unbounded.  Want to make
>> a boundary relation with a million child ways?  This is allowed.  Want to
>> ensure that all those ways are connected?  It may take minutes to download
>> them all.
>>
>> They’re almost even a security threat.  I’m willing to bet a black hat
>> could design and upload a relation that would destroy OSM.. Or at least,
>> crash every piece of software in the stack that we rely on:  mapnik,
>> osmium, and any editor that tries to touch it.
>>
>> Anyway, I’m not totally against them, but every one of them is different
>> and I can't spend weeks or months supporting every kind of relation or
>> public transport schema people dream up unless it’s super critical for
>> building a useful map (like turn restrictions).  They are really best for
>> features that can not be mapped any other way.
>>
>> Thanks, Bryan
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Default Language Format; language:default or default:language?

[Yuri Astrakhan]

I still think that if this feature is there to document the language of the
name tag, we should reuse the default_language [1] -- it is already set on
more than 200 large regions, covering most of the world. What's the point
of duplicating it?  If there is a region where name could be in 2 or more
languages, we may want to introduce a new tag to specifically address that
in those regions only, e.g. multiple_default_languages_of_the_region tag
that lists all possible values that the name MAY be in. (the tag name might
need some work :)).

That said, I fail to understand how it will help data processing. If a
region could be in FR and DE, you still don't know the language of the
specific feature's name.  How will the proposal help?  I might have misread
it though.

[1]  https://wiki.openstreetmap.org/wiki/Key:default_language

On Sat, Sep 29, 2018 at 11:48 PM Joseph Eisenberg <
joseph.eisenb...@gmail.com> wrote:

> Any opinions on the order of the tag?
>
> Just a couple of people have said that default:language would be preferred
> to language:default.
>
> It will take some time to update the proposal page, so I would like a few
> more opinions
>
> Joseph
>
> On Thu, Sep 27, 2018 at 10:16 AM Joseph Eisenberg <
> joseph.eisenb...@gmail.com> wrote:
>
>> Should we change the tag from language:default to default:language?
>>
>> I've found out that language:* has already been used in the format
>> language:de, language:fr, language:en, etc, for the languages taught at a
>> school. See
>> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dlanguage_school. And
>> language=* has been used, though rarely.
>>
>> There is also a page for default_language, which was made without going
>> through the proposal process. And there is a new proposal to specify all
>> "defaults" in the fomat default:subkey, though I have also seen this the
>> other way around, eg key:default, suggested for maxspeed.
>>
>> I am not wedded to the current tag "language:default=". Please
>> respond here (or on the talk page) if you prefer default:language= or
>> default_language=, or if you prefer the current order.
>>
>> Proposal:
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Default_Language_Format
>>
>> Talk page:
>> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Default_Language_Format
>>
>> Thank you,
>> Joseph
>>
>> On Mon, Sep 24, 2018 at 9:36 PM Joseph Eisenberg <
>> joseph.eisenb...@gmail.com> wrote:
>>
>>> Please see the Proposal page for the new tag,
>>> "language:default="
>>>
>>> https://wiki.openstreetmap.org/wiki/Proposed_features/Default_Language_Format
>>>
>>> Description:
>>> "Specify the default language format used for names, and recommend use
>>> of language-specific name tags.
>>>
>>> "By making it easier to use language-specific name:code=* tags to be
>>> used instead of the default name=* tag, this proposal will encourage
>>> the use of name tags that include the language code for all features.
>>> This will improve the quality and utility of the database. It will be
>>> possible to display non-Western languages in their correct orientation
>>> and script, properly display multilingual names, and to research the
>>> most commonly used language formats in a particular area.
>>>
>>> "The key language:default=* with a 2 or 3 letter ISO language code
>>> should be tagged on administrative boundary relations, such as
>>> countries, provinces and aboriginal communities. This is the language
>>> used for the majority of named features within a particular region, as
>>> indicated on public signs and in common use by the local community. If
>>> the language can be written in more than one script, a qualifier can
>>> be added to specify the script format. More than one language code can
>>> be listed, separated with a semicolon, if the local community uses
>>> more than one language on signs or by consensus.
>>>
>>> "The language tag should be applied to the largest boundary relation
>>> that accurately represents the language used for default names. When a
>>> smaller administrative boundary has a different default language
>>> format, this boundary should receive a language tag as well. This
>>> would include boundaries of provinces or aboriginal lands where a
>>> different language is used.
>>>
>>> "The language tag may also be applied to individual features when the
>>> name is in a different language than the default for the region, or
>>> when the feature crosses a border."
>>>
>>> Please read the whole page, which has quite a number of examples and a
>>> detailed rationale for the proposal, then please comment here or on
>>> the discussion page:
>>>
>>> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Default_Language_Format
>>>
>>> Thank you for all of your comments, criticisms and suggestions
>>> -Joseph
>>>
>> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

Re: [Tagging] Feature Proposal - RFC - Free drinking water by private entities

[bkil]

I've separated the proposal for non-inclusive drink refilling from the
drinking water cases. Anticipating a discussion, I'm replying to part
of Tom's most recent insights in the new RFC here (unfortunately, I've
copied some extra parts there too that is relevant here instead):

https://lists.openstreetmap.org/pipermail/tagging/2018-September/039520.html



> It does not need much language either, handing the bottle and
> and a friendly look are usually self-explanatory and sufficient.
> I would support tagging the free tap-water refilling campaign as it is 
> apparently a litter-avoiding
> idea and presumably ground-verifiable
>

The owncup=* campaign sounds like an idea to combat waste as well.
However, if a shop is part of both owncup & water-refill campaigns at
the same time, handing over your bottle may result in unwanted
consequences like getting beer in it!

So you vote for the possibility that no extra tag/description should
be added along `drinking_water=yes` (instead of =ask/on_demand) to
indicate that staff is handing out water on request and not a vending
machine/tap?

> (by some sticker or so at the door?).
>

It is definitely verifiable as all of these venues have staff that was
instructed by management to serve water to all, so asking any of them
should yield a unified answer. Some of the dozens of campaigns listed
have printable stickers, but note that they should all be different.

The best visibility for both venues and people should be via OSM
itself. However, if we do not highlight these via specific tags, this
visibility may be impaired. Renderers could be enhanced to highlight
various tag combinations, like drinking_water on bars, restaurants,
etc., though that is not ideal. Verification could also be made more
difficult, because if I see drinking_water=yes on a pub, I need to
first start looking for a vending machine/fountain/tap, if not found,
ask for an accessible vending machine/fountain/tap from staff, if they
don't know anything about those, then I ask whether they could
manually refill my container. This sounds a bit more awkward than
ideal.

> As a side note, I am surprised it needs such a campaign. I was never refused 
> a filling of my water
> bottle, in various countries. Not in a pub while hiking, nor in an airport 
> cafe (behind security
> where carrying water is not allowed).
> tom
>

Although nobody would deny you a glass of water on a hot summer day if
you were dangerously dehydrated, not every restaurant would like to
degrade their atmosphere to a pass-through house by lines of
freeloaders if they are situated at a busy location. Those who
volunteer to join such a campaign anticipate this traffic and educate
their staff to welcome all passer-by as a matter of business.

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

Re: [Tagging] Tagging Digest, Vol 108, Issue 162

[yves]

Although the whitewater proposal is here for a long time, and it being 
the only documented way to tag kayaking/canoe practise on whitewater, it 
is seldom used.
Probably there is simply not enough people interested in those sports 
and Openstreetmap at the same time. Maybe in a few years there will be 
enough people interested so that a RFC + vote would make any sense, for 
now I think it's best to let it alone as a documentation.






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

Re: [Tagging] Tagging Digest, Vol 108, Issue 162

[yves]

Le 29. 09. 18 à 00:53, Dave Swarthout a écrit

waterway=river
name=Tanana River
waterway=section
section=bend
section:name=Harper Bend
You can't use waterway=section + waterway=river on the same way, and you 
shouldn't map overlapping ways for obvious reasons.


But you can split a waterway=river in how many smaller way you want to 
add a subtag.

To take the whitewater proposal method, this could be :

waterway=river
name=Tanana River
waterway:section=bend
waterway:section_name=Harper Bend

or

waterway=river
name=Tanana River
river:section=bend
river:section_name=Harper Bend

but the former allow for canal, ditches and else.
Yves

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