date:20180927

I'm working on adding islands and other features in the Tanana River in
Alaska. There are many named sloughs (side channels), islands and in some
areas curves or bends that have a name. In my example there is a large bend
in the river that has its own name, Harper Bend. I'm looking for a way to
tag that section so that the name is findable. It would be nice but not
imperative if that name would display on the OSM slippy map and
incidentally, on my GPSr.

If I break the river at both ends of the curve, I could add the name to the
section between the breaks but that doesn't seem right because the river's
name isn't changing. Another much more complicated solution would be to
break the riverbank into sections and add a name to the one that
encompasses the bend.

I don't know why I didn't ask here first but I raised this question on the
OSM Help forum and one answer was to use a node. But if one goes that way,
I reckon a new tag would be needed. So let's begin our discussion with
that. Given that it's important to me to describe our mapped objects as
completely as possible, I want a method to tag such a bend.

Suggestions? Opinions?
Best,
Dave
-- 
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] Tagging a named river bend

2018-09-27 Thread Warin


I'd use
place=locality
name=*

Fits, renders and searchable. Put it on a node.

On 27/09/18 19:58, Dave Swarthout wrote:


I'm working on adding islands and other features in the Tanana River 
in Alaska. There are many named sloughs (side channels), islands and 
in some areas curves or bends that have a name. In my example there is 
a large bend in the river that has its own name, Harper Bend. I'm 
looking for a way to tag that section so that the name is findable. It 
would be nice but not imperative if that name would display on the OSM 
slippy map and incidentally, on my GPSr.


If I break the river at both ends of the curve, I could add the name 
to the section between the breaks but that doesn't seem right because 
the river's name isn't changing. Another much more complicated 
solution would be to break the riverbank into sections and add a name 
to the one that encompasses the bend.


I don't know why I didn't ask here first but I raised this question on 
the OSM Help forum and one answer was to use a node. But if one goes 
that way, I reckon a new tag would be needed. So let's begin our 
discussion with that. Given that it's important to me to describe our 
mapped objects as completely as possible, I want a method to tag such 
a bend.


Suggestions? Opinions?

Best,
Dave
--
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



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

Re: [Tagging] Tagging a named river bend

I agree that a node is best, because it is  debatable where a river bend
starts and ends, but it is easy to put a node at the center.

To confirm, this name is for the section of river, not for the semi-circle
of land inside of the bend?

I agree that a separate tag is needed, as you said, because this is not the
name of a river. It’s analogous to a bay in a lake or sea.

Did you try searching taginfo? Has anyone been using waterway=bend or
natural=bend, or something similar?

-Joseph

On Thu, Sep 27, 2018 at 7:00 PM Dave Swarthout 
wrote:

> I'm working on adding islands and other features in the Tanana River in
> Alaska. There are many named sloughs (side channels), islands and in some
> areas curves or bends that have a name. In my example there is a large bend
> in the river that has its own name, Harper Bend. I'm looking for a way to
> tag that section so that the name is findable. It would be nice but not
> imperative if that name would display on the OSM slippy map and
> incidentally, on my GPSr.
>
> If I break the river at both ends of the curve, I could add the name to
> the section between the breaks but that doesn't seem right because the
> river's name isn't changing. Another much more complicated solution would
> be to break the riverbank into sections and add a name to the one that
> encompasses the bend.
>
> I don't know why I didn't ask here first but I raised this question on the
> OSM Help forum and one answer was to use a node. But if one goes that way,
> I reckon a new tag would be needed. So let's begin our discussion with
> that. Given that it's important to me to describe our mapped objects as
> completely as possible, I want a method to tag such a bend.
>
> Suggestions? Opinions?
> Best,
> Dave
>
> --
> 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging a named river bend

2018-09-27 Thread Peter Elderson

+1
If it's a well defined area, I would tag an area tagged place=* , name=*
If it's an island, I would tag place=island. If no regular place-value
fits, then place=locality.
If it's a normal thing, like when all bends in the river have a name, then
I would probably enter a new place-value, e.g. river_bend.

Op do 27 sep. 2018 om 12:12 schreef Warin <61sundow...@gmail.com>:

> I'd use
> place=locality
> name=*
>
> Fits, renders and searchable. Put it on a node.
>
> On 27/09/18 19:58, Dave Swarthout wrote:
>
> I'm working on adding islands and other features in the Tanana River in
> Alaska. There are many named sloughs (side channels), islands and in some
> areas curves or bends that have a name. In my example there is a large bend
> in the river that has its own name, Harper Bend. I'm looking for a way to
> tag that section so that the name is findable. It would be nice but not
> imperative if that name would display on the OSM slippy map and
> incidentally, on my GPSr.
>
> If I break the river at both ends of the curve, I could add the name to
> the section between the breaks but that doesn't seem right because the
> river's name isn't changing. Another much more complicated solution would
> be to break the riverbank into sections and add a name to the one that
> encompasses the bend.
>
> I don't know why I didn't ask here first but I raised this question on the
> OSM Help forum and one answer was to use a node. But if one goes that way,
> I reckon a new tag would be needed. So let's begin our discussion with
> that. Given that it's important to me to describe our mapped objects as
> completely as possible, I want a method to tag such a bend.
>
> Suggestions? Opinions?
> Best,
> Dave
> --
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Travel Blog at http://dswarthout.blogspot.com
>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Vr gr Peter Elderson
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Draft Proposal: Default Langauge Format

Some practical information from Belgium:

We have three official languages nl,fr,de
Flanders is nl (*)
Brussels is nl;fr
Wallonia is Fr (*)
Eupen-Malmedy is de

This means that town names, street names and bus stops can be expected
in the above mentioned languages. Same goes for government buildings.
This does not mean that the names of shops, restaurants have to be in
any of the above languages (just as the examples given by others for
Germany and Italy). More over, the names in Brussels will typically be
in either Dutch or French, depending on the mother tongue of the
owner. Schools and universities (e.g. VUB is a Dutch-speaking
university and ULB a french-speaking university in Brussels) are also
typically named in 1 language. As far as I can see, the current
proposals would mean that any POI (not referring to a government
building) in Brussels needs to be retagged to name:XX or add
default:language:XX. Is this a correct assumption ?

Although I am not overly familiar with the Eupen-Malmedy area, I think
that a lot of POI names in that area are in French.

Furthermore, the destination signs in Belgium can be a mixture of
Dutch/French/German, even for towns in France/Germany. Those signs are
often mapped with the destination-tag in OSM and announced by
navigation software. None of the proposed solutions here helps the
software to read those aloud.

So I see a massive amount of work + a lot of work to maintain this. I
really do hope that the benefits are huge. And to be honest, I do not
have a lot of problems with the current navigation software based on
OSM without all those extra tags.

(*) exceptions exist, there are towns with facilities, which means
citizens can demand to get official letters in another language

m.
On Thu, Sep 27, 2018 at 2:56 AM Joseph Eisenberg
 wrote:
>
> While it is a good idea to address the issues around name=* and name:=* 
> tags, this proposal is a necessary first step before we can do anything else.
> Frederik's perferred solution and Christoph's idea both require there to be a 
> default language format tag.
>
> I would recommend approving this proposal in some form first, then we can 
> have a separate discussion about the name tags. So I have removed a couple of 
> short comments from the proposal to avoid this confusion.
>
> Tags for official languages should also be a separate discussion (though I 
> also think this idea has merit).
>
> -Joseph
>
>
>
> On Thu, Sep 27, 2018 at 7:19 AM Christoph Hormann  wrote:
>>
>> On Wednesday 26 September 2018, Wolfgang Zenker wrote:
>> > > * allow mappers to accurately document information on names of
>> > > features in all situations that might exist world wide where there
>> > > are verifiable names with as little effort and in the least error
>> > > prone way as possible.
>> > > * allow data users to interpret this data without constraints due
>> > > to intransparent preprocessing performed by the mappers.
>> >
>> > I'm not sure that all the participants in this discussion and all the
>> > supporters of the draft proposal (and previous proposals) do really
>> > agree on the ultimate aim of that proposal.
>>
>> Yes, of course i should have mentioned that this is just my personal
>> opinion.  I did not mean to imply to speak for anyone else.
>>
>> > Hence my suggestion to
>> > explore the problem space first and find out what problem(s)
>> > different people try to solve with that proposal, then identify the
>> > constraints that reduce the possible solutions space and the "nice to
>> > have" properties that we'ld like to see in the solution.
>>
>> Yes, you can try to systematically develop a solution after defining
>> requirements and quantifying priorities.  But you need to keep in mind
>> that in OSM you have no centralized decision making process as you
>> usually have in engineering disciplines.  So you would already have
>> trouble finding agreement on what exactly the problem is.  And
>> experience tells that the solution space is typically much smaller than
>> the problem space when it comes to tagging in OSM.  Long story short:
>> Finding consensus on the solution is often much easier than on the
>> problem.
>>
>> Still you are right, systematically collecting all the problems related
>> to name data recording in OSM would be quite useful - even if just from
>> a single person's perspective.  But that is already quite a huge amount
>> of work.
>>
>> --
>> Christoph Hormann
>> http://www.imagico.de/
>>
>> ___
>> 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 a named river bend

2018-09-27 Thread Yves

Place=locality makes sense, I guess the name is also used for the area close to 
the bend by extension.
Locality on a node is always troublesome, and I wonder if anybody uses 
description=* to describe further the place, here this would be something like 
description=river bend. 

Le 27 septembre 2018 12:23:53 GMT+02:00, Peter Elderson  a 
écrit :
>+1
>If it's a well defined area, I would tag an area tagged place=* ,
>name=*
>If it's an island, I would tag place=island. If no regular place-value
>fits, then place=locality.
>If it's a normal thing, like when all bends in the river have a name,
>then
>I would probably enter a new place-value, e.g. river_bend.
>
>Op do 27 sep. 2018 om 12:12 schreef Warin <61sundow...@gmail.com>:
>
>> I'd use
>> place=locality
>> name=*
>>
>> Fits, renders and searchable. Put it on a node.
>>
>> On 27/09/18 19:58, Dave Swarthout wrote:
>>
>> I'm working on adding islands and other features in the Tanana River
>in
>> Alaska. There are many named sloughs (side channels), islands and in
>some
>> areas curves or bends that have a name. In my example there is a
>large bend
>> in the river that has its own name, Harper Bend. I'm looking for a
>way to
>> tag that section so that the name is findable. It would be nice but
>not
>> imperative if that name would display on the OSM slippy map and
>> incidentally, on my GPSr.
>>
>> If I break the river at both ends of the curve, I could add the name
>to
>> the section between the breaks but that doesn't seem right because
>the
>> river's name isn't changing. Another much more complicated solution
>would
>> be to break the riverbank into sections and add a name to the one
>that
>> encompasses the bend.
>>
>> I don't know why I didn't ask here first but I raised this question
>on the
>> OSM Help forum and one answer was to use a node. But if one goes that
>way,
>> I reckon a new tag would be needed. So let's begin our discussion
>with
>> that. Given that it's important to me to describe our mapped objects
>as
>> completely as possible, I want a method to tag such a bend.
>>
>> Suggestions? Opinions?
>> Best,
>> Dave
>> --
>> Dave Swarthout
>> Homer, Alaska
>> Chiang Mai, Thailand
>> Travel Blog at http://dswarthout.blogspot.com
>>
>>
>> ___
>> Tagging mailing
>listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
>-- 
>Vr gr Peter Elderson
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to tag a building constructed for a gastronomic purposes?

On Thu, Sep 27, 2018 at 9:21 AM Warin <61sundow...@gmail.com> wrote:
>
> On 27/09/18 00:48, Mateusz Konieczny wrote:
>
>
> building tag is supposed to contain how building is constructed. For example 
> hotel in
> a church is building=church (with hotel tagged as usual).
>
> Former hotel building used as a warehouse is building=hotel.
>
>
> That was the intention. But many mappers are mapping the function of the 
> building, not the appearance/architecture.
>
> e.g. building=parking, office, commercial, apartments, ... all functional 
> rather than architecture.
> The appearance of these vary widely so mappers tend to identify the use 
> rather than the appearance.
>

I was once told that it's not only the outside that counts, but also
the inside. It can be very difficult to distinguish an office
building, a hotel, an apartment building, a school or university
building by just looking at the outside.
I'm thinking here of a high block with a lots of window in a
row/column pattern on the long sides.

So if we have to take the inside (or whole structure) into account,
what is the building type when the outside and the inside tell
something different ? Apartments in a church, a fast-food restaurant
behind the facade of a rich merchant's house from 1600, etc. ? On the
outside it might be clearly a church, but once inside you might no
longer see it used to be a church. Is the building a church or an
apartment building ?

If the original purpose counts, will you always be able to determine
it without consulting the original building plans ?

regards

m.

p.s. I'm honestly only looking for answers. I'm fine with your
definition, I just don't know what to pick in some cases

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

Re: [Tagging] Draft Proposal: Default Langauge Format

Re: do “the current
proposals would mean that any POI (not referring to a government
building) in Brussels needs to be retagged to name:XX or add
default:language:XX (?)

There are no mandatory tags in OSM, nothing needs to be retagged. But there
would be the option to add
default:language=fr to a shop in Flanders which has a name in French. This
would help database users know that this shop name is in French rather than
Flemish. I believe this will be very useful, and I think mappers will enjoy
the chance to add the extra tags where necessary. Mapping is a bit
addictive, right?

My understanding of Brussels was that the streets have all been tagged with
3 name tags: name=*, name:fr=, and name:nl=. Right? So with knowledge that
the default languages for Brussels are nl and fr (recorded with a single
tag on the administrative boundary) a database user will know that they can
use both name:fr and name:nl in combination to render the Street names, and
also that both names are likely on signs.

This is important for a Flemish, Dutch or French-localized service, which
might want to show the name:nl or name:fr on all features, along with the
local name. Right now it you attempt to do this by showing name=* and
name:fr= at the same time (when they are not identical), you’ll get the
French name labeled twice on every street in Brussels! Not good

Joseph


On Thu, Sep 27, 2018 at 7:38 PM Marc Gemis  wrote:

> Some practical information from Belgium:
>
> We have three official languages nl,fr,de
> Flanders is nl (*)
> Brussels is nl;fr
> Wallonia is Fr (*)
> Eupen-Malmedy is de
>
> This means that town names, street names and bus stops can be expected
> in the above mentioned languages. Same goes for government buildings.
> This does not mean that the names of shops, restaurants have to be in
> any of the above languages (just as the examples given by others for
> Germany and Italy). More over, the names in Brussels will typically be
> in either Dutch or French, depending on the mother tongue of the
> owner. Schools and universities (e.g. VUB is a Dutch-speaking
> university and ULB a french-speaking university in Brussels) are also
> typically named in 1 language. As far as I can see, the current
> proposals would mean that any POI (not referring to a government
> building) in Brussels needs to be retagged to name:XX or add
> default:language:XX. Is this a correct assumption ?
>
> Although I am not overly familiar with the Eupen-Malmedy area, I think
> that a lot of POI names in that area are in French.
>
> Furthermore, the destination signs in Belgium can be a mixture of
> Dutch/French/German, even for towns in France/Germany. Those signs are
> often mapped with the destination-tag in OSM and announced by
> navigation software. None of the proposed solutions here helps the
> software to read those aloud.
>
> So I see a massive amount of work + a lot of work to maintain this. I
> really do hope that the benefits are huge. And to be honest, I do not
> have a lot of problems with the current navigation software based on
> OSM without all those extra tags.
>
> (*) exceptions exist, there are towns with facilities, which means
> citizens can demand to get official letters in another language
>
> m.
> On Thu, Sep 27, 2018 at 2:56 AM Joseph Eisenberg
>  wrote:
> >
> > While it is a good idea to address the issues around name=* and
> name:=* tags, this proposal is a necessary first step before we can do
> anything else.
> > Frederik's perferred solution and Christoph's idea both require there to
> be a default language format tag.
> >
> > I would recommend approving this proposal in some form first, then we
> can have a separate discussion about the name tags. So I have removed a
> couple of short comments from the proposal to avoid this confusion.
> >
> > Tags for official languages should also be a separate discussion (though
> I also think this idea has merit).
> >
> > -Joseph
> >
> >
> >
> > On Thu, Sep 27, 2018 at 7:19 AM Christoph Hormann 
> wrote:
> >>
> >> On Wednesday 26 September 2018, Wolfgang Zenker wrote:
> >> > > * allow mappers to accurately document information on names of
> >> > > features in all situations that might exist world wide where there
> >> > > are verifiable names with as little effort and in the least error
> >> > > prone way as possible.
> >> > > * allow data users to interpret this data without constraints due
> >> > > to intransparent preprocessing performed by the mappers.
> >> >
> >> > I'm not sure that all the participants in this discussion and all the
> >> > supporters of the draft proposal (and previous proposals) do really
> >> > agree on the ultimate aim of that proposal.
> >>
> >> Yes, of course i should have mentioned that this is just my personal
> >> opinion.  I did not mean to imply to speak for anyone else.
> >>
> >> > Hence my suggestion to
> >> > explore the problem space first and find out what problem(s)
> >> > different people try to solve with that proposal, then identi

Re: [Tagging] Draft Proposal: Default Langauge Format

I've thought some more about this.  And reflected upon some comments from a
previous discussion (this topic is one of the list's perennials) a few
months ago that, back then, I couldn't see the reasoning.  And yes, I
realize the proposal is about
what gets stored in the db, not what gets rendered, but in the course of
time it will affect rendering in some way because
it's in the db and so it will get used.

There are (at least) five conflicting requirements in terms of what gets
rendered in personalized maps (or even in
standard carto in future years when we have vector tiles, etc).

1) If I'm in a country with a language I don't speak, I want street names
and shop names rendered as displayed on the
signage ("paint the label").

2) If I'm looking at a map with a low zoom, for example trying to figure
out where Azerbaijan is in relation to
Turkmenistan, I want the country names rendered in my language.  A
transliteration into English of what the
inhabitants call that country would be unhelpful, and if it's in Cyrillic,
Arabic or any other non-Latin script that would
be even worse.

3) If I'm travelling across Europe by car, and am currently in France and
want to get to Munich, at the French side of
the border I want to know to look for Allemande, not Germany or Deutschland
on the signage.

4) As I get near the border, I want to check my route to Munich (because
that's what it is called in English, and that's the
only name that I know for it) but will also need to look for signs to
München.

5) All of the above have additional complications when dealing with
multi-lingual communities.

Some of the above are easy to deal with algorithmically: use my language
for things at low zooms.  Others require
significant thought in terms of "do what I want" algorithms.

Additional complication: some countries have, in recent years, altered
their transliteration schemes.  So now in
my country I see references to both Peking and Beijing, and to both Bombay
and Mumbai.  If those countries insist
on forcing what are effectively new names/pronunciations upon us then I
absolutely demand the French start using
"London" instead of "Londres." :)

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

Re: [Tagging] How to tag a building constructed for a gastronomic purposes?

On Thu, Sep 27, 2018 at 12:12 PM, Marc Gemis  wrote:

>
> So if we have to take the inside (or whole structure) into account,
> what is the building type when the outside and the inside tell
> something different ? Apartments in a church, a fast-food restaurant
> behind the facade of a rich merchant's house from 1600, etc. ? On the
> outside it might be clearly a church, but once inside you might no
> longer see it used to be a church. Is the building a church or an
> apartment building ?
>

A discussion along these lines comes to mind: "From the secondary school,
walk west along Arbuthnot Street for about
half a mile until you come to a church.  It's not really a church any more,
it was deconsecrated years ago and is now
a family home, but look for a church."  Would it be more useful to tag it
as building=church or building=house?

Similarly, ask a child to draw a church.  Or a house.  Or even a
supermarket.

That's why I have strong doubts about building=gastronomic (or whatever it
ends up being).  I know what a church looks
like.  Ditto for supermarket, industrial unit, warehouse and house.  I
cannot bring to mind a typical restaurant architecture.

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

Re: [Tagging] Draft Proposal: Default Langauge Format

We already have a map in of Belgium based on OSM without any
additional tag. A typical Flemish map does not show French names
high-level. So it it uses name:nl, if that's not there name. Since all
bi-langual object will be mapped with name, name:nl and name:fr, there
is no reason to use "name" if "name:nl"

Your assumption for streets is correct, also for administrative areas,
but not for POIs. And it might be hard for a mapper to find out what
the language is the name is for them (see mails from e.g. Frederik)
I tried to say that there are 2 types of objects,
administrative/government objects will have names in 2 or 3 languages
(federal government buildings in Brussels), and others that only have
1 name in a "random" language.

m.On Thu, Sep 27, 2018 at 1:18 PM Joseph Eisenberg
 wrote:
>
> Re: do “the current
> proposals would mean that any POI (not referring to a government
> building) in Brussels needs to be retagged to name:XX or add
> default:language:XX (?)
>
> There are no mandatory tags in OSM, nothing needs to be retagged. But there 
> would be the option to add
> default:language=fr to a shop in Flanders which has a name in French. This 
> would help database users know that this shop name is in French rather than 
> Flemish. I believe this will be very useful, and I think mappers will enjoy 
> the chance to add the extra tags where necessary. Mapping is a bit addictive, 
> right?
>
> My understanding of Brussels was that the streets have all been tagged with 3 
> name tags: name=*, name:fr=, and name:nl=. Right? So with knowledge that the 
> default languages for Brussels are nl and fr (recorded with a single tag on 
> the administrative boundary) a database user will know that they can use both 
> name:fr and name:nl in combination to render the Street names, and also that 
> both names are likely on signs.
>
> This is important for a Flemish, Dutch or French-localized service, which 
> might want to show the name:nl or name:fr on all features, along with the 
> local name. Right now it you attempt to do this by showing name=* and 
> name:fr= at the same time (when they are not identical), you’ll get the 
> French name labeled twice on every street in Brussels! Not good
>
> Joseph
>
>
> On Thu, Sep 27, 2018 at 7:38 PM Marc Gemis  wrote:
>>
>> Some practical information from Belgium:
>>
>> We have three official languages nl,fr,de
>> Flanders is nl (*)
>> Brussels is nl;fr
>> Wallonia is Fr (*)
>> Eupen-Malmedy is de
>>
>> This means that town names, street names and bus stops can be expected
>> in the above mentioned languages. Same goes for government buildings.
>> This does not mean that the names of shops, restaurants have to be in
>> any of the above languages (just as the examples given by others for
>> Germany and Italy). More over, the names in Brussels will typically be
>> in either Dutch or French, depending on the mother tongue of the
>> owner. Schools and universities (e.g. VUB is a Dutch-speaking
>> university and ULB a french-speaking university in Brussels) are also
>> typically named in 1 language. As far as I can see, the current
>> proposals would mean that any POI (not referring to a government
>> building) in Brussels needs to be retagged to name:XX or add
>> default:language:XX. Is this a correct assumption ?
>>
>> Although I am not overly familiar with the Eupen-Malmedy area, I think
>> that a lot of POI names in that area are in French.
>>
>> Furthermore, the destination signs in Belgium can be a mixture of
>> Dutch/French/German, even for towns in France/Germany. Those signs are
>> often mapped with the destination-tag in OSM and announced by
>> navigation software. None of the proposed solutions here helps the
>> software to read those aloud.
>>
>> So I see a massive amount of work + a lot of work to maintain this. I
>> really do hope that the benefits are huge. And to be honest, I do not
>> have a lot of problems with the current navigation software based on
>> OSM without all those extra tags.
>>
>> (*) exceptions exist, there are towns with facilities, which means
>> citizens can demand to get official letters in another language
>>
>> m.
>> On Thu, Sep 27, 2018 at 2:56 AM Joseph Eisenberg
>>  wrote:
>> >
>> > While it is a good idea to address the issues around name=* and 
>> > name:=* tags, this proposal is a necessary first step before we can do 
>> > anything else.
>> > Frederik's perferred solution and Christoph's idea both require there to 
>> > be a default language format tag.
>> >
>> > I would recommend approving this proposal in some form first, then we can 
>> > have a separate discussion about the name tags. So I have removed a couple 
>> > of short comments from the proposal to avoid this confusion.
>> >
>> > Tags for official languages should also be a separate discussion (though I 
>> > also think this idea has merit).
>> >
>> > -Joseph
>> >
>> >
>> >
>> > On Thu, Sep 27, 2018 at 7:19 AM Christoph Hormann  wrote:
>> >>
>> >> On Wednesday 26 September 20

Re: [Tagging] Tagging a named river bend

2018-09-27 Thread Colin Smale

I guess this can also apply to named straight bits as well? 

http://onthethames.net/reaches-river-thames/

On 2018-09-27 11:58, Dave Swarthout wrote:

> I'm working on adding islands and other features in the Tanana River in 
> Alaska. There are many named sloughs (side channels), islands and in some 
> areas curves or bends that have a name. In my example there is a large bend 
> in the river that has its own name, Harper Bend. I'm looking for a way to tag 
> that section so that the name is findable. It would be nice but not 
> imperative if that name would display on the OSM slippy map and incidentally, 
> on my GPSr. 
> 
> If I break the river at both ends of the curve, I could add the name to the 
> section between the breaks but that doesn't seem right because the river's 
> name isn't changing. Another much more complicated solution would be to break 
> the riverbank into sections and add a name to the one that encompasses the 
> bend. 
> 
> I don't know why I didn't ask here first but I raised this question on the 
> OSM Help forum and one answer was to use a node. But if one goes that way, I 
> reckon a new tag would be needed. So let's begin our discussion with that. 
> Given that it's important to me to describe our mapped objects as completely 
> as possible, I want a method to tag such a bend. 
> 
> Suggestions? Opinions? 
> Best, 
> Dave 
> -- 
> 
> 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___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Draft Proposal: Default Langauge Format

On Thu, Sep 27, 2018 at 1:21 PM Paul Allen  wrote:

> 3) If I'm travelling across Europe by car, and am currently in France and 
> want to get to Munich, at the French side of
> the border I want to know to look for Allemande, not Germany or Deutschland 
> on the signage.
>

I typically rely on the destination signs, which might be in
French/German or both. So I prefer that the satnav uses the text of
the destinations signs, regardless of the name for the town.
So depending on whether you use a satnav or not, the "language" might
be different.

> 4) As I get near the border, I want to check my route to Munich (because 
> that's what it is called in English, and that's the
> only name that I know for it) but will also need to look for signs to München.

All I agree that for "map lookups" one prefers to see the name in your
own language
>
> 5) All of the above have additional complications when dealing with 
> multi-lingual communities.

As a Flemish person, I rather have the name of the street pronounced
in Dutch in Brussels than in the 2 languages as is now the case. This
is probably one of the complications.

m.

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

Re: [Tagging] Draft Proposal: Default Langauge Format

On Thu, Sep 27, 2018 at 12:35 PM, Marc Gemis  wrote:

>
> > 5) All of the above have additional complications when dealing with
> multi-lingual communities.
>
> As a Flemish person, I rather have the name of the street pronounced
> in Dutch in Brussels than in the 2 languages as is now the case. This
> is probably one of the complications.
>

Also complicated by the fact that different multi-lingual communities
appear to handle things differently
on the ground.

Wales is officially bilingual Welsh/English.  Historically, much signage
was in English only, but as the Welsh
language movement gained strength bilingual signage has been phased in and,
in some recent cases, Welsh-only
signage has appeared.  It seems to depend largely upon how locals refer to
something.

Currently it is common to see bilingual signage.  Often confusingly
designed.  Road traffic signage, where each
destination appears on its own line, has the Welsh and English on separate
lines with no difference in vertical
spacing from the other destinations.  So you cannot easily tell if "St
Dogmaels" and "Llandudoch" are two
different destinations or two names for the same destination.   Street
names tend to be a little less confusing,
with (usually) each name on its own line, so "Heol Napier" with "Napier
Street" below it.

But shops often do it differently.  More words on a sign mean paying the
signwriter more money.  So they often take
advantage of the different word order in Welsh and English.  Instead of
"Davies Butcher" and "Cigydd Davies" you'll
see "Cigydd Davies Butcher" (often the "Davies" would be larger or bolder
or differentiated in some other way).  As an
English speaker who knows about this, I'd be happy if the map showed
"Davies Butcher" to me.  But tourists who
understand neither language well may not be aware that "Davies Butcher" on
the map is not a different thing from
"Cigydd Davies Butcher" on the sign.  For all they know, "Cigydd Davies
Butcher" is different to "Davies Butcher."  And,
let's face it, tourists need maps more than locals do.  Which is why I
think "paint the label" is the right thing to do at the
local level, even if I would prefer just the English name for the places I
already know well and my next-door neighbour
would prefer only the Welsh name.

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

Re: [Tagging] How to tag a building constructed for a gastronomic purposes?

On Thu, Sep 27, 2018 at 1:31 PM Paul Allen  wrote:
>
> On Thu, Sep 27, 2018 at 12:12 PM, Marc Gemis  wrote:
>>
>>
>> So if we have to take the inside (or whole structure) into account,
>> what is the building type when the outside and the inside tell
>> something different ? Apartments in a church, a fast-food restaurant
>> behind the facade of a rich merchant's house from 1600, etc. ? On the
>> outside it might be clearly a church, but once inside you might no
>> longer see it used to be a church. Is the building a church or an
>> apartment building ?
>
>
> A discussion along these lines comes to mind: "From the secondary school, 
> walk west along Arbuthnot Street for about
> half a mile until you come to a church.  It's not really a church any more, 
> it was deconsecrated years ago and is now
> a family home, but look for a church."  Would it be more useful to tag it as 
> building=church or building=house?
>
> Similarly, ask a child to draw a church.  Or a house.  Or even a supermarket.
>
> That's why I have strong doubts about building=gastronomic (or whatever it 
> ends up being).  I know what a church looks
> like.  Ditto for supermarket, industrial unit, warehouse and house.  I cannot 
> bring to mind a typical restaurant architecture.

if you have to take the interior into account it can be done sometimes:
- large seating area (even noticable when empty)
- a bar where the personnel prepares drinks
- large kitchen area
- a toilet area
- a reception area (possible with personnel) or wardrobe
- often better access for wheelchairs than a typical house
- for fast_food: a counter with large displays to list menus and prices

On the outside it can be a villa or a warehouse or a church...

m.

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

[Tagging] How to tag prefab / movable buildings

2018-09-27 Thread François Lacombe

Hi all,

I'm currently looking to know what would be the best way to tag prefab or
movable buildings.
Such buildings are used to host utilities or service equipments and
building=service is used.

This is a prefab building :
https://wiki.openstreetmap.org/w/images/3/38/20140501_165031.jpg
This is not a prefab building :
https://wiki.openstreetmap.org/wiki/File:French_substation_tower.jpg
Despite they have the same function.

Is there an established tag for that?

All the best

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

Re: [Tagging] How to tag a building constructed for a gastronomic purposes?

On Thu, Sep 27, 2018 at 1:11 PM, Marc Gemis  wrote:

> On Thu, Sep 27, 2018 at 1:31 PM Paul Allen  wrote:
> >  I cannot bring to mind a typical restaurant architecture.
>
> if you have to take the interior into account it can be done sometimes:
> - large seating area (even noticable when empty)
> - a bar where the personnel prepares drinks
> - large kitchen area
> - a toilet area
> - a reception area (possible with personnel) or wardrobe
> - often better access for wheelchairs than a typical house
> - for fast_food: a counter with large displays to list menus and prices
>
> On the outside it can be a villa or a warehouse or a church...
>

Which, if you were describing it as a waypoint in a route to somebody,
would be "a church converted to a restaurant" or
"a restaurant in an old church."  What a shame we have no way of tagging
that, there is no mechanism for
saying "building=church + amenity=restaurant."  So let's invent
"building=gastronomic + amenity=restaurant +
building:looks_like=church"  because that's a much better way of doing it.
:)

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

Re: [Tagging] Draft Proposal: Default Langauge Format

2018-09-27 Thread Jo

>
> As a Flemish person, I rather have the name of the street pronounced
> in Dutch in Brussels than in the 2 languages as is now the case. This
> is probably one of the complications
> 


This is especially true because the pronunciation rules for both languages
differ significantly. I have OsmAND set to English and it manages to
pronounce both languages wrong... But the same would be true when setting
it to either nl or fr. It would be better to only use name:nl or name:fr
instead of name for Brussels. But that is something to solve in OsmAND.

When I'm looking at the map, I prefer to see both names though, as they are
now. So I totally agree with Paul Allen's message. It depends on the use
one wants to make of the data.

Ideally we know what language the name tag is in and even more ideally we
would have IPA transliterations for those cases added to the DB where
automated text to speech consistently gets it wrong. Of course that has its
own problems, as not everyone pronounces words or names the same way.

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

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

sent from a phone

> On 27. Sep 2018, at 14:10, François Lacombe wrote:
>
> Is there an established tag for that?

I am not aware of established tagging, but would like to add that there are all
kind of buildings that can be prefabricated, e.g. „famous“ German example:
https://upload.wikimedia.org/wikipedia/commons/thumb/8/84/1._WBS_70_Block_%281%29.JPG/1200px-1._WBS_70_Block_%281%29.JPG

And there are various levels of prefabrication, e.g. for a concrete structure
you could just have the lower parts of the ceiling in concrete delivered and
then add the formwork around it as well as the rest of the steel, and pour the
concrete to finish (i.e. ceiling is semi prefabricated and completed on site),
or similarly with walls (place a thin “sheet” of concrete at the sides instead
of formwork and fill it up).
You can also have complete walls and ceilings, and you can even have complete
rooms that get delivered and mounted at the site (even including installations
and finishes).
With some material it is common to have parts prefabricated, e.g. steel and
sometimes wood, not just concrete, and other parts like a facade in metal and
glass also consist usually of prefabricated parts (you’re not gonna cut glass
on site typically).

Using prefabricated parts is standard in today’s building practice, but not
sufficient to call a building prefabricated.

A simple property like prefabricated=yes does not catch it. We should define
what grade of prefabrication and which part (structure, ceilings, bath rooms,
etc) and most important, which material (concrete, steel, etc.).

cheers,
Martin

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

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

2018-09-27 Thread François Lacombe

Agreed there are several levels of prefabrication.
Material is completely solved with material=* and no need to specialize it
to prefabrication (concrete can be used on both prefabricated and not
buildings)

kind of prefabricated=yes would stand for complete prefabricated buildings
and other values may precise a particular part.
Should it be building:prefabricated or something else?

François

Le jeu. 27 sept. 2018 à 14:50, Martin Koppenhoefer 
a écrit :

>
>
> sent from a phone
>
> On 27. Sep 2018, at 14:10, François Lacombe 
> wrote:
>
> Is there an established tag for that?
>
>
>
> I am not aware of established tagging, but would like to add that there
> are all kind of buildings that can be prefabricated, e.g. „famous“ German
> example:
> https://upload.wikimedia.org/wikipedia/commons/thumb/8/84/1._WBS_70_Block_%281%29.JPG/1200px-1._WBS_70_Block_%281%29.JPG
>
>
> And there are various levels of prefabrication, e.g. for a concrete
> structure you could just have the lower parts of the ceiling in concrete
> delivered and then add the formwork around it as well as the rest of the
> steel, and pour the concrete to finish (i.e. ceiling is semi prefabricated
> and completed on site), or similarly with walls (place a thin “sheet” of
> concrete at the sides instead of formwork and fill it up).
> You can also have complete walls and ceilings, and you can even have
> complete rooms that get delivered and mounted at the site (even including
> installations and finishes).
> With some material it is common to have parts prefabricated, e.g. steel
> and sometimes wood, not just concrete, and other parts like a facade in
> metal and glass also consist usually of prefabricated parts (you’re not
> gonna cut glass on site typically).
>
> Using prefabricated parts is standard in today’s building practice, but
> not sufficient to call a building prefabricated.
>
> A simple property like prefabricated=yes does not catch it. We should
> define what grade of prefabrication and which part (structure, ceilings,
> bath rooms, etc) and most important, which material (concrete, steel, etc.).
>
> 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] Draft Proposal: Default Langauge Format

Re: destination signs for routing.

Paul brought up some good examples about routing and traveling.

I believe destination signs are already stored in OSM with the tag
“destination=xxx”, where “xxx” is whatever is actually written on the sign.
Certainly this should be used by routing services and apps. Eg “take exit
112 on the right, signs for xxx.”

This won’t be affected by this proposal.

But, hopefully this will make it easier for Marc to get a map that
preferential shows Flemish names as well as the  locally preferred names.

On Thu, Sep 27, 2018 at 8:37 PM Marc Gemis  wrote:

> On Thu, Sep 27, 2018 at 1:21 PM Paul Allen  wrote:
>
> > 3) If I'm travelling across Europe by car, and am currently in France
> and want to get to Munich, at the French side of
> > the border I want to know to look for Allemande, not Germany or
> Deutschland on the signage.
> >
>
> I typically rely on the destination signs, which might be in
> French/German or both. So I prefer that the satnav uses the text of
> the destinations signs, regardless of the name for the town.
> So depending on whether you use a satnav or not, the "language" might
> be different.
>
> > 4) As I get near the border, I want to check my route to Munich (because
> that's what it is called in English, and that's the
> > only name that I know for it) but will also need to look for signs to
> München.
>
> All I agree that for "map lookups" one prefers to see the name in your
> own language
> >
> > 5) All of the above have additional complications when dealing with
> multi-lingual communities.
>
> As a Flemish person, I rather have the name of the street pronounced
> in Dutch in Brussels than in the 2 languages as is now the case. This
> is probably one of the complications.
>
> m.
>
> ___
> 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

sent from a phone

> On 27. Sep 2018, at 12:10, Warin <61sundow...@gmail.com> wrote:
> 
> I'd use
> place=locality 
> name=*

I don’t oppose this, but I feel it would be time to introduce an additional tag 
for localities that states which kind of toponym it is (where it comes from or 
what is refers to), e.g 
locality=*

Current usage of this tag is practically restricted to 2 values, townland and 
subtownland
https://taginfo.openstreetmap.org/keys/locality#values

we could introduce values like river_part or waterway_section (I’d prefer the 
former because the word river already gives a slight indication about the 
importance as opposed to ‘waterway’ which includes ditches).

the wiki discourages locality on a way though: 
https://wiki.openstreetmap.org/wiki/Tag%3Aplace%3Dlocality

Not sure if this should be changed or we should introduce a new tag like 
place=river_part (or similar) or waterway=section etc.

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

Re: [Tagging] Draft Proposal: Default Langauge Format

I’m sorry I misunderstood your point about POIs (eg shops, amenities) in
Brussels, which as you say often have a name in only one language.

On this case, a map renderer or routing service that has adopted this new
tag should look first for name:nl=* and name:fr=*, and show whichever one
is found. If there is neither a name:fr or name:nl, then the label should
be based on name=*

It isn’t necessary to add the default language tag to any POIs in Brussels
as long as the name is in French, Flemish or both. Only places with foreign
names  (eg a Korean shop?) would need to be tagged directly.

I personally think it is a good idea to have a name:fr or a name:nl for
every POI in Brussels, but that’s not part of this proposal.

Joseph

On Thu, Sep 27, 2018 at 8:33 PM Marc Gemis  wrote:

> We already have a map in of Belgium based on OSM without any
> additional tag. A typical Flemish map does not show French names
> high-level. So it it uses name:nl, if that's not there name. Since all
> bi-langual object will be mapped with name, name:nl and name:fr, there
> is no reason to use "name" if "name:nl"
>
> Your assumption for streets is correct, also for administrative areas,
> but not for POIs. And it might be hard for a mapper to find out what
> the language is the name is for them (see mails from e.g. Frederik)
> I tried to say that there are 2 types of objects,
> administrative/government objects will have names in 2 or 3 languages
> (federal government buildings in Brussels), and others that only have
> 1 name in a "random" language.
>
> m.On Thu, Sep 27, 2018 at 1:18 PM Joseph Eisenberg
>  wrote:
> >
> > Re: do “the current
> > proposals would mean that any POI (not referring to a government
> > building) in Brussels needs to be retagged to name:XX or add
> > default:language:XX (?)
> >
> > There are no mandatory tags in OSM, nothing needs to be retagged. But
> there would be the option to add
> > default:language=fr to a shop in Flanders which has a name in French.
> This would help database users know that this shop name is in French rather
> than Flemish. I believe this will be very useful, and I think mappers will
> enjoy the chance to add the extra tags where necessary. Mapping is a bit
> addictive, right?
> >
> > My understanding of Brussels was that the streets have all been tagged
> with 3 name tags: name=*, name:fr=, and name:nl=. Right? So with knowledge
> that the default languages for Brussels are nl and fr (recorded with a
> single tag on the administrative boundary) a database user will know that
> they can use both name:fr and name:nl in combination to render the Street
> names, and also that both names are likely on signs.
> >
> > This is important for a Flemish, Dutch or French-localized service,
> which might want to show the name:nl or name:fr on all features, along with
> the local name. Right now it you attempt to do this by showing name=* and
> name:fr= at the same time (when they are not identical), you’ll get the
> French name labeled twice on every street in Brussels! Not good
> >
> > Joseph
> >
> >
> > On Thu, Sep 27, 2018 at 7:38 PM Marc Gemis  wrote:
> >>
> >> Some practical information from Belgium:
> >>
> >> We have three official languages nl,fr,de
> >> Flanders is nl (*)
> >> Brussels is nl;fr
> >> Wallonia is Fr (*)
> >> Eupen-Malmedy is de
> >>
> >> This means that town names, street names and bus stops can be expected
> >> in the above mentioned languages. Same goes for government buildings.
> >> This does not mean that the names of shops, restaurants have to be in
> >> any of the above languages (just as the examples given by others for
> >> Germany and Italy). More over, the names in Brussels will typically be
> >> in either Dutch or French, depending on the mother tongue of the
> >> owner. Schools and universities (e.g. VUB is a Dutch-speaking
> >> university and ULB a french-speaking university in Brussels) are also
> >> typically named in 1 language. As far as I can see, the current
> >> proposals would mean that any POI (not referring to a government
> >> building) in Brussels needs to be retagged to name:XX or add
> >> default:language:XX. Is this a correct assumption ?
> >>
> >> Although I am not overly familiar with the Eupen-Malmedy area, I think
> >> that a lot of POI names in that area are in French.
> >>
> >> Furthermore, the destination signs in Belgium can be a mixture of
> >> Dutch/French/German, even for towns in France/Germany. Those signs are
> >> often mapped with the destination-tag in OSM and announced by
> >> navigation software. None of the proposed solutions here helps the
> >> software to read those aloud.
> >>
> >> So I see a massive amount of work + a lot of work to maintain this. I
> >> really do hope that the benefits are huge. And to be honest, I do not
> >> have a lot of problems with the current navigation software based on
> >> OSM without all those extra tags.
> >>
> >> (*) exceptions exist, there are towns with facilities, which means
> >> ci

Re: [Tagging] Tagging a named river bend



sent from a phone

> On 27. Sep 2018, at 12:21, Joseph Eisenberg  
> wrote:
> 
> To confirm, this name is for the section of river, not for the semi-circle of 
> land inside of the bend?


practically I would expect the name to extend to this piece of land as well 
(often).


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

Re: [Tagging] How to tag a building constructed for a gastronomic purposes?

2018-09-27 Thread Mateusz Konieczny




27. Sep 2018 14:21 by pla16...@gmail.com :


> Which, if you were describing it as a waypoint in a route to somebody, would 
> be "a church converted to a restaurant" or> "a restaurant in an old church."  
> What a shame we have no way of tagging that, there is no mechanism for> 
> saying "building=church + amenity=restaurant."  So let's invent 
> "building=gastronomic + amenity=restaurant +> building:looks_like=church"  
> because that's a much better way of doing it. :)
>




There are building and building:use tags 





https://wiki.openstreetmap.org/wiki/Key:building:use 


https://wiki.openstreetmap.org/wiki/Buildings 


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

Re: [Tagging] How to tag a building constructed for a gastronomic purposes?

2018-09-27 Thread John Willis

> On Sep 27, 2018, at 4:20 PM, Warin <61sundow...@gmail.com> wrote:
> 
> That was the intention. But many mappers are mapping the function of the 
> building, not the appearance/architecture.

TLDR: it's difficult to understand the spirit of building=* as "constructed 
type" when almost all buildings one is mapping are used by their owner for 
their initially built purpose; this leads to a general misunderstanding of 
building=* usage. 

~

My house in San Diego was built in 1922, and is in the oldest 1% of structures. 
Most were built after 1960. 

In some areas, the structure is valuable, easily repurposable, and/or is not 
expected to be demolished - which would lead to the building=* tag to be 
different than the current use of the occupant. 

This descrepancy is what has led to some people (myself included) as the tag 
being for defining the general purpose the building  as it is currently used 
(building=retail, industrial, house, etc), which is not it's intended purpose. 

I understand the idea of the "constructed type" being defined through 
building=*, but that is very difficult to grasp when you tag mostly buildings 
made after WWII that are still used for the same purpose. 

Example: 

Japan is a very old place - but everything old is a temple or has rotted away  
- so many buildings: residential, commercial, and industrial are boom-times 
building (1960,1970s) - there is just so little repurposing of structures that 
I see.  Perhaps 1 in 5000 structures (where I am mapping) are repurposed, and 
the ones I know of are storehouse/warehouses from silk production -  there are 
just a handful. Most everything here gets demolished and the lot gravelled when 
the land is sold - people dont buy structures; they buy land. prewar wood and 
bamboo structures exist but are abandoned, boomyear house-shops have the shop 
portion shuttered, post war low-income housing was (& is still being) 
demolished to make apartment blocks that are now themselves being demolished 
for modern apartment complexes.  The only exception is a glut of 1990's 7-11s 
that were abandoned and repurosed into other shops - but almost 100% are still 
retail.  Old blocks of stores are demolished and convenience stores spring from 
the gravelled lots are like weeds here. I counted 7 new ones under construction 
in the past 10 days - they all are new construction replacing demolished older 
shops. 

I imagine tagging a bakery In a church building would entail using 
building=church - but for some mappers, it a very rare occurrence, leading to 
building=* to feel like  a usage identifier rather than for structure 
construction type, which I guess has led to mis-mapping and tag value 
pollution. 

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

Re: [Tagging] Draft Proposal: Default Langauge Format

2018-09-27 Thread Mateusz Konieczny

26. Sep 2018 21:27 by p...@trigpoint.me.uk :


> On Wed, 2018-09-26 at 19:54 +0200, Frederik Ramm wrote:
>> Hi,
>>
>> On 09/26/2018 05:53 PM, Christoph Hormann wrote:
>> > Names in a non-discernible language have so far not been
>> > discussed.  I 
>> > would need to see some examples for this to form an opinion on the 
>> > matter.  
>>
>> I am thinking of retail outlets like
>>
>> "Tesco"
> Not a word, but an acronym
>
> TE Stockwell Cohen
>
> Phil (trigpoint)




 Maybe etymology of this word is based on an acronym, but nowadays it is used 
as a

word.

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

Re: [Tagging] Tagging a named river bend

I would resist the use of the locality tag (also the other pro-node
arguments) even though it's an easy answer to my problem. It does not
communicate the quality of "riverness" at all. This bend may or may not
lend its name to a locality but it is primarily a feature of the river, not
the name of a settled place.

I like the suggestion of place=river_part because it works well with
existing waterway tags and would be searchable. I don't want to use the
waterway tag at all for this project; that "top-level" should be reserved
for the ways comprising a river, and is normally associated with the river
name. This is a separate but related part of a river. The scheme could even
be extended to include Colin's "reaches" or "holes" on the river Thames.

Hmmm

On Thu, Sep 27, 2018 at 8:25 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 27. Sep 2018, at 12:21, Joseph Eisenberg 
> wrote:
> >
> > To confirm, this name is for the section of river, not for the
> semi-circle of land inside of the bend?
>
>
> practically I would expect the name to extend to this piece of land as
> well (often).
>
>
> cheers,
> Martin

-- 
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] Draft Proposal: Default Langauge Format

sent from a phone

> On 27. Sep 2018, at 15:42, Mateusz Konieczny  wrote:
> 
> Maybe etymology of this word is based on an acronym, but nowadays
> 
> it is used as a word.
> 

As Christoph said in his first reply, these are brands, where it is typical to 
have abbreviations, acronyms or artificial words (think vw, bmw, gm, mg, aldi, 
haribo, tüv, rwe, basf, esso, bp, osram, agfa, ge, at&t, .).

I agree it mostly makes sense to classify it either as in the language from 
where it comes from/was first used or as not being in any language. There can 
also be exceptions though, e.g. “Alibaba” is not a chinese word, Mercedes is a 
Spanish name, etc.

Cheers,
Martin 

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

Re: [Tagging] Tagging a named river bend

sent from a phone

> On 27. Sep 2018, at 15:57, Dave Swarthout  wrote:
> 
> This bend may or may not lend its name to a locality but it is primarily a 
> feature of the river, not the name of a settled place.

locality is explicitly for toponyms that don’t refer to settlements or their 
parts. I agree that a node is not nice, because we might want to tag sections 
of a river that are quite long, and a node doesn’t express this.

Another idea would be to use additionally a subtag on the part, e.g. 
section_name=*

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

[Tagging] Tagging a named river bend

2018-09-27 Thread Michael Patrick

> It does not communicate the quality of "riverness" at all. This bend may
or may not lend its name to a locality but it is primarily a feature of the
river, not
the name of a settled place.

Generally, the term 'Reach' is most appropriate for subsections of flowing
water:
(From https://www.usgs.gov/faqs/what-a-reach )
What is a reach?

“Reach” can have *slightly different meanings*, depending on how it is used.

A reach is a section of a stream or river along which similar hydrologic
conditions exist, such as discharge, depth, area, and slope. It can also be
the length of a stream or river (with varying conditions) between two
stream gauges, or a length of river for which the characteristics are well
described by readings at a single stream gauge.

More generally, *a reach is just any length of a stream or river.* The term
is often used by hydrologists when they’re referring to a small section of
a river rather than its entire length from end to end.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to tag a building constructed for a gastronomic purposes?

sent from a phone

> On 27. Sep 2018, at 09:20, Warin <61sundow...@gmail.com> wrote:
> 
> e.g. building=parking, office, commercial, apartments, ... all functional 
> rather than architecture.

these are all building types. Buildings can be (and are) classified according 
to lots different criteria, intended usage/function is clearly a principal 
designing parameter, from my point of view there is nothing wrong with these 
values (commercial is so generic it doesn’t tell you much, at least you know it 
is not residential though).
cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to tag a building constructed for a gastronomic purposes?



sent from a phone

> On 27. Sep 2018, at 13:30, Paul Allen  wrote:
> 
> Would it be more useful to tag it as building=church or building=house?
> 
> Similarly, ask a child to draw a church.  Or a house.  Or even a supermarket.
> 
> That's why I have strong doubts about building=gastronomic (or whatever it 
> ends up being).  I know what a church looks
> like.  Ditto for supermarket, industrial unit, warehouse and house.  I cannot 
> bring to mind a typical restaurant architecture.


+1, exactly. Although a fast_food_restaurant building is something I would have 
an idea about. “gastronomy” doesn’t make sense.

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

Re: [Tagging] Tagging a named river bend

2018-09-27 Thread Steve Doerr


On 27/09/2018 15:17, Michael Patrick wrote:

*/a reach is just any length of a stream or river/*


*
*

It would seem odd to tag a bend as a reach, as the classic definition of 
a reach is 'A portion of a river, channel, or lake which lies between 
two bends or which can be seen in one view'.



--

Steve



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging a named river bend

2018-09-27 Thread Yves

Section_name, is there not something like this in the whitewater tagging scheme?
Yep: 
https://wiki.openstreetmap.org/w/index.php?title=Key:whitewater:section_name&action=edit&redlink=1

And yes, this tagging scheme extend to brown/blue/green river sections.
Yves 

Le 27 septembre 2018 16:14:47 GMT+02:00, Martin Koppenhoefer 
 a écrit :
>
>
>sent from a phone
>
>> On 27. Sep 2018, at 15:57, Dave Swarthout 
>wrote:
>> 
>> This bend may or may not lend its name to a locality but it is
>primarily a feature of the river, not the name of a settled place.
>
>
>locality is explicitly for toponyms that don’t refer to settlements or
>their parts. I agree that a node is not nice, because we might want to
>tag sections of a river that are quite long, and a node doesn’t express
>this.
>
>Another idea would be to use additionally a subtag on the part, e.g.
>section_name=*
>
>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] Draft Proposal: Default Langauge Format

2018-09-27 Thread Wolfgang Zenker

Hi,

* Joseph Eisenberg  [180927 13:10]:
> Re: do “the current
> proposals would mean that any POI (not referring to a government
> building) in Brussels needs to be retagged to name:XX or add
> default:language:XX (?)

> There are no mandatory tags in OSM, nothing needs to be retagged. But there
> would be the option to add
> default:language=fr to a shop in Flanders which has a name in French. This
> would help database users know that this shop name is in French rather than
> Flemish. I believe this will be very useful, and I think mappers will enjoy
> the chance to add the extra tags where necessary. Mapping is a bit
> addictive, right?
> [..]

this is one of the points where I have the impression that we are not
all talking about the same problem. For me a "default value" is a value
that is to be assumed if no specific value is available. So for me a
tag containing the word "default" would imply that it does NOT apply to
the object with that tag itself. If there is a default:language=XX tag
on an admin boundary, I would - by looking at the name of that key -
assume this is the language for things inside that admin boundary unless
these "things inside" specify a different language for themself. But I
would expext e.g. a POI within that area that uses a different language
to have a language=XX tag, not a default:language=XX tag.

Wolfgang

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

Re: [Tagging] Tagging a named river bend

2018-09-27 Thread Ture Pålsson


> 27 sep. 2018 kl. 13:03 skrev Yves :
> 
> Place=locality makes sense, I guess the name is also used for the area close 
> to the bend by extension.
> Locality on a node is always troublesome, and I wonder if anybody uses 
> description=* to describe further the place, here this would be something 
> like description=river bend. 


A simple place=locality gives no hint to a renderer that this is a water 
feature, and I can easily imagine a map style where one wants to do something 
special with those, like using blue text.

Look at this example from northern Sweden, where features in the river 
(Bredselet, Trångforsen and Vidselet) have lent their names, but in different 
grammatical form, the the nearby villages/hamlets of Bredsel, Trångfors and 
Vidsel.

(Follow there river and you'll see several other named rapids (-fors) and 
stretches of smooth water between them (-sel).


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

Re: [Tagging] Tagging a named river bend

2018-09-27 Thread Ture Pålsson

And again, with a link, this time! =)

https://kso.etjanster.lantmateriet.se/?e=749899&n=7312843&z=9&profile=default_background_noauth
 



> 27 sep. 2018 kl. 18:36 skrev Ture Pålsson :
> 
> 
>> 27 sep. 2018 kl. 13:03 skrev Yves :
>> 
>> Place=locality makes sense, I guess the name is also used for the area close 
>> to the bend by extension.
>> Locality on a node is always troublesome, and I wonder if anybody uses 
>> description=* to describe further the place, here this would be something 
>> like description=river bend. 
> 
> 
> A simple place=locality gives no hint to a renderer that this is a water 
> feature, and I can easily imagine a map style where one wants to do something 
> special with those, like using blue text.
> 
> Look at this example from northern Sweden, where features in the river 
> (Bredselet, Trångforsen and Vidselet) have lent their names, but in different 
> grammatical form, the the nearby villages/hamlets of Bredsel, Trångfors and 
> Vidsel.
> 
> (Follow there river and you'll see several other named rapids (-fors) and 
> stretches of smooth water between them (-sel).
> 

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

[Tagging] GPS Altitude Re: Topographic Prominence for Peaks

2018-09-27 Thread Bill Ricker

On Thu, Sep 27, 2018 at 3:20 AM Colin Smale  wrote:

> On 2018-09-27 07:17, Graeme Fitzpatrick wrote:
>
> & when you say survey with GPS, is that accurate enough for an altitude
> reading? With my Garmin GPS (which admittedly is 10 - 15 years old, but
> *wasn't* a cheap one!), I can calibrate it in the back yard at 6m ASL, go
> for a day trip & when I get home, it displays the exact same spot as
> anything between -5 & +30m ASL :-( When out driving, I've also seen the
> altitude display change by 100s of m's instantly, when the road is
> virtually flat.
>
>
>
> GPS is not very accurate in the vertical direction, due to ...
>

and the (unclassified) GPS algorithm is intentionally optimized against
altitude accuracy, to favor horizontal accuracy, since (a) friendly
aircraft have very accurate altimeters and unfriendly projectiles don't,
and (b) other users can generally assume they are in contact with the
surface, so Altitude is the least important output, can and should be least
accurate.

If one takes a long-term average solution  of GPS posits, especially with
pro WAAF input, the GPS altitude will be approximately right eventually
(and the L/L will be spot on); this is what modern surveyors' Total
Stations and GPS Stations do. (That's ok, as the incoming discount reentry
vehicle can't take a long term average to calculate its fusing height.)

Which is why Garmin units with a Barometer option (e.g. 78sc) allow
calibrating the altimeter altitude at either a known height or a known
sea-level barometer (same as aeroplane analog altimeters are recalibrated
for each airport, done before takeoff and upon making radio contact with
destination Approach Control).
This calibration is good for several hours and maybe a hundred miles or
two, but is not good for the adjacent air-mass, whether the front moves
over the house or the car moves down the interstate.

If you calibrate a Garmin GPS Altimeter to the known height of the peak
when standing on it, it should give vaguely accurate values if you hike to
a col within sight (provided the weather doesn't drastically change in the
meantime ... in which case you should have other priorities anyway), but
you'd still get a better value counting isocline contours on a topo map, or
using a Brunton Pocket Transit to shoot the angle of site [stet] and use
old school trig with the GPS horizontal baseline.

Air Pressure reported by a GPS with barometer in a moving car is prone to
wildly noisy fluctuation besides the slow change in altitude, as Graeme
noted.
Window open/closed, Air conditioning High/Low, truck swooshes past, into
the tunnel.
With the car parked and windows open a crack, it will be as protected and
stable as a Weather Service barometer in a protected instrument shed, but
not when driving.
(Unless the car is painted white, the temperature reading will not be as
accurate :-) )

A Garmin calibratable for altitude will give better Altitude numbers than a
pure GPS using only the satellites, but only if used within its
limitations.
Moving/sealed vehicle altitude readings are not a reliable mode!
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Draft Proposal: Default Langauge Format

You are absolutely correct that “language=xx” would be the simplest
tag. And it was proposed back in 2009 (though never progressed to a
vote): 
https://wiki.openstreetmap.org/wiki/Proposed_features/Language_of_this_element

But “language=*” is now being used for the language spoken or taught
at a school, eg language=Korean or language:en=main, so we can’t use
that tag without confusion. See:
https://taginfo.openstreetmap.org/keys/language#values
https://taginfo.openstreetmap.org/keys/language%3Aen#values

The best viable solution is to use the same tag on administration
boundaries and POIs, even though it is not perfect.

Do you think we should change the name of the tag to remove the word
default; eg language_format=* instead, for both boundaries and POIs?

Joseph

On Fri, Sep 28, 2018 at 1:06 AM Wolfgang Zenker
 wrote:
>
> Hi,
>
> * Joseph Eisenberg  [180927 13:10]:
> > Re: do “the current
> > proposals would mean that any POI (not referring to a government
> > building) in Brussels needs to be retagged to name:XX or add
> > default:language:XX (?)
>
> > There are no mandatory tags in OSM, nothing needs to be retagged. But there
> > would be the option to add
> > default:language=fr to a shop in Flanders which has a name in French. This
> > would help database users know that this shop name is in French rather than
> > Flemish. I believe this will be very useful, and I think mappers will enjoy
> > the chance to add the extra tags where necessary. Mapping is a bit
> > addictive, right?
> > [..]
>
> this is one of the points where I have the impression that we are not
> all talking about the same problem. For me a "default value" is a value
> that is to be assumed if no specific value is available. So for me a
> tag containing the word "default" would imply that it does NOT apply to
> the object with that tag itself. If there is a default:language=XX tag
> on an admin boundary, I would - by looking at the name of that key -
> assume this is the language for things inside that admin boundary unless
> these "things inside" specify a different language for themself. But I
> would expext e.g. a POI within that area that uses a different language
> to have a language=XX tag, not a default:language=XX tag.
>
> Wolfgang
>
> ___
> 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

At first, the use of "section" seemed useful to consider. The tag
"whitewater:section_name" has not been defined in the Wiki but might be
adapted to this issue. However, the word "whitewater" would be misleading
IMO because this is a flat river that whitewater enthusiasts would not seek
out. Also, like place=locality it doesn't give any indication that this is
a bend or curve in a river.

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.

See Taginfo: https://taginfo.openstreetmap.org/keys/place#values

On Thu, Sep 27, 2018 at 11:38 PM Ture Pålsson  wrote:

> And again, with a link, this time! =)
>
>
> https://kso.etjanster.lantmateriet.se/?e=749899&n=7312843&z=9&profile=default_background_noauth
>
>
> 27 sep. 2018 kl. 18:36 skrev Ture Pålsson :
>
>
> 27 sep. 2018 kl. 13:03 skrev Yves :
>
> Place=locality makes sense, I guess the name is also used for the area
> close to the bend by extension.
> Locality on a node is always troublesome, and I wonder if anybody uses
> description=* to describe further the place, here this would be something
> like description=river bend.
>
>
>
> A simple place=locality gives no hint to a renderer that this is a water
> feature, and I can easily imagine a map style where one wants to do
> something special with those, like using blue text.
>
> Look at this example from northern Sweden, where features in the river
> (Bredselet, Trångforsen and Vidselet) have lent their names, but in
> different grammatical form, the the nearby villages/hamlets of Bredsel,
> Trångfors and Vidsel.
>
> (Follow there river and you'll see several other named rapids (-fors) and
> stretches of smooth water between them (-sel).
>
>
> ___
> 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] Tagging a named river bend

"waterway=" is usually used for features that have to do with linear
water features; values include dam, weir, lock, etc.

Since the name of a bend would be most useful for boaters and kayakers
who are using a river as a waterway, I would recommend using
"waterway=bend".

This could then also be used for a bend in a canal, for example.

"place=*" doesn't say anything about if the feature is natural or a
settlement, and it isn't usually used for water features.

Another option would be natural=bend or natural=river_bend, because
natural=* is used for all sorts of geographic features in the natural
landscape, including water features like bays, straights, etc.

Joseph

On 9/28/18, Dave Swarthout  wrote:
> At first, the use of "section" seemed useful to consider. The tag
> "whitewater:section_name" has not been defined in the Wiki but might be
> adapted to this issue. However, the word "whitewater" would be misleading
> IMO because this is a flat river that whitewater enthusiasts would not seek
> out. Also, like place=locality it doesn't give any indication that this is
> a bend or curve in a river.
>
> 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.
>
> See Taginfo: https://taginfo.openstreetmap.org/keys/place#values
>
> On Thu, Sep 27, 2018 at 11:38 PM Ture Pålsson  wrote:
>
>> And again, with a link, this time! =)
>>
>>
>> https://kso.etjanster.lantmateriet.se/?e=749899&n=7312843&z=9&profile=default_background_noauth
>>
>>
>> 27 sep. 2018 kl. 18:36 skrev Ture Pålsson :
>>
>>
>> 27 sep. 2018 kl. 13:03 skrev Yves :
>>
>> Place=locality makes sense, I guess the name is also used for the area
>> close to the bend by extension.
>> Locality on a node is always troublesome, and I wonder if anybody uses
>> description=* to describe further the place, here this would be something
>> like description=river bend.
>>
>>
>>
>> A simple place=locality gives no hint to a renderer that this is a water
>> feature, and I can easily imagine a map style where one wants to do
>> something special with those, like using blue text.
>>
>> Look at this example from northern Sweden, where features in the river
>> (Bredselet, Trångforsen and Vidselet) have lent their names, but in
>> different grammatical form, the the nearby villages/hamlets of Bredsel,
>> Trångfors and Vidsel.
>>
>> (Follow there river and you'll see several other named rapids (-fors) and
>> stretches of smooth water between them (-sel).
>>
>>
>> ___
>> 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] Tagging a named river bend

@Joseph - I wanted to avoid using that particular top-level tag, waterway,
because there would be no simple way to add a name different from that of
the waterway=river itself. Unless we invent a new tag something like
name:bend=Harper Bend.

The key "natural" is so weighted with controversy already, I'd prefer not
to use that one either. But I'm not opposed if we can all agree on its use
here.

On Fri, Sep 28, 2018 at 7:54 AM Joseph Eisenberg 
wrote:

> "waterway=" is usually used for features that have to do with linear
> water features; values include dam, weir, lock, etc.
>
> Since the name of a bend would be most useful for boaters and kayakers
> who are using a river as a waterway, I would recommend using
> "waterway=bend".
>
> This could then also be used for a bend in a canal, for example.
>
> "place=*" doesn't say anything about if the feature is natural or a
> settlement, and it isn't usually used for water features.
>
> Another option would be natural=bend or natural=river_bend, because
> natural=* is used for all sorts of geographic features in the natural
> landscape, including water features like bays, straights, etc.
>
> Joseph
>
> On 9/28/18, Dave Swarthout  wrote:
> > At first, the use of "section" seemed useful to consider. The tag
> > "whitewater:section_name" has not been defined in the Wiki but might be
> > adapted to this issue. However, the word "whitewater" would be misleading
> > IMO because this is a flat river that whitewater enthusiasts would not
> seek
> > out. Also, like place=locality it doesn't give any indication that this
> is
> > a bend or curve in a river.
> >
> > 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.
> >
> > See Taginfo: https://taginfo.openstreetmap.org/keys/place#values
> >
> > On Thu, Sep 27, 2018 at 11:38 PM Ture Pålsson 
> wrote:
> >
> >> And again, with a link, this time! =)
> >>
> >>
> >>
> https://kso.etjanster.lantmateriet.se/?e=749899&n=7312843&z=9&profile=default_background_noauth
> >>
> >>
> >> 27 sep. 2018 kl. 18:36 skrev Ture Pålsson :
> >>
> >>
> >> 27 sep. 2018 kl. 13:03 skrev Yves :
> >>
> >> Place=locality makes sense, I guess the name is also used for the area
> >> close to the bend by extension.
> >> Locality on a node is always troublesome, and I wonder if anybody uses
> >> description=* to describe further the place, here this would be
> something
> >> like description=river bend.
> >>
> >>
> >>
> >> A simple place=locality gives no hint to a renderer that this is a water
> >> feature, and I can easily imagine a map style where one wants to do
> >> something special with those, like using blue text.
> >>
> >> Look at this example from northern Sweden, where features in the river
> >> (Bredselet, Trångforsen and Vidselet) have lent their names, but in
> >> different grammatical form, the the nearby villages/hamlets of Bredsel,
> >> Trångfors and Vidsel.
> >>
> >> (Follow there river and you'll see several other named rapids (-fors)
> and
> >> stretches of smooth water between them (-sel).
> >>
> >>
> >> ___
> >> 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
> >
>


-- 
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] Tagging a named river bend

Oh, I see. I was thinking about use on a node only, where this would not be
a problem. Place=* tags are usually used on nodes, perhaps on areas
(controverially) but not on ways.

This reminds me of the problem with naming mountain ranges and ridges.
Right now we can name part of an individual ridge or a peak, but for
“mountain_range” you can only draw a node, or if you draw a way it will
duplicate the ways used for ridges.

Waterways allow use of a relation to hold the name and characteristics of
the whole river or canal, and shorter ways for parts of the river, but
there isn’t a way to yet to tag a particular point or short part of a
river. It’s like we have mountain_range relations and ways but no
natural=ridge or =peak or saddle tags

On Fri, Sep 28, 2018 at 10:07 AM Dave Swarthout 
wrote:

> @Joseph - I wanted to avoid using that particular top-level tag, waterway,
> because there would be no simple way to add a name different from that of
> the waterway=river itself. Unless we invent a new tag something like
> name:bend=Harper Bend.
>
> The key "natural" is so weighted with controversy already, I'd prefer not
> to use that one either. But I'm not opposed if we can all agree on its use
> here.
>
> On Fri, Sep 28, 2018 at 7:54 AM Joseph Eisenberg <
> joseph.eisenb...@gmail.com> wrote:
>
>> "waterway=" is usually used for features that have to do with linear
>> water features; values include dam, weir, lock, etc.
>>
>> Since the name of a bend would be most useful for boaters and kayakers
>> who are using a river as a waterway, I would recommend using
>> "waterway=bend".
>>
>> This could then also be used for a bend in a canal, for example.
>>
>> "place=*" doesn't say anything about if the feature is natural or a
>> settlement, and it isn't usually used for water features.
>>
>> Another option would be natural=bend or natural=river_bend, because
>> natural=* is used for all sorts of geographic features in the natural
>> landscape, including water features like bays, straights, etc.
>>
>> Joseph
>>
>> On 9/28/18, Dave Swarthout  wrote:
>> > At first, the use of "section" seemed useful to consider. The tag
>> > "whitewater:section_name" has not been defined in the Wiki but might be
>> > adapted to this issue. However, the word "whitewater" would be
>> misleading
>> > IMO because this is a flat river that whitewater enthusiasts would not
>> seek
>> > out. Also, like place=locality it doesn't give any indication that this
>> is
>> > a bend or curve in a river.
>> >
>> > 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.
>> >
>> > See Taginfo: https://taginfo.openstreetmap.org/keys/place#values
>> >
>> > On Thu, Sep 27, 2018 at 11:38 PM Ture Pålsson 
>> wrote:
>> >
>> >> And again, with a link, this time! =)
>> >>
>> >>
>> >>
>> https://kso.etjanster.lantmateriet.se/?e=749899&n=7312843&z=9&profile=default_background_noauth
>> >>
>> >>
>> >> 27 sep. 2018 kl. 18:36 skrev Ture Pålsson :
>> >>
>> >>
>> >> 27 sep. 2018 kl. 13:03 skrev Yves :
>> >>
>> >> Place=locality makes sense, I guess the name is also used for the area
>> >> close to the bend by extension.
>> >> Locality on a node is always troublesome, and I wonder if anybody uses
>> >> description=* to describe further the place, here this would be
>> something
>> >> like description=river bend.
>> >>
>> >>
>> >>
>> >> A simple place=locality gives no hint to a renderer that this is a
>> water
>> >> feature, and I can easily imagine a map style where one wants to do
>> >> something special with those, like using blue text.
>> >>
>> >> Look at this example from northern Sweden, where features in the river
>> >> (Bredselet, Trångforsen and Vidselet) have lent their names, but in
>> >> different grammatical form, the the nearby villages/hamlets of Bredsel,
>> >> Trångfors and Vidsel.
>> >>
>> >> (Follow there river and you'll see several other named rapids (-fors)
>> and
>> >> stretches of smooth water between them (-sel).
>> >>
>> >>
>> >> ___
>> >> 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
>> >
>>
>
>
> --
> 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
>
___
Tag

[Tagging] Traffic sign direction tagging..

2018-09-27 Thread Bryan Housel

Hey Tagging List!

While reviewing a pull request to add Traffic Sign presets to iD, I came across 
a tagging issue with how traffic sign directions are tagged.
The details are here https://github.com/openstreetmap/iD/pull/5333 
 and relevant guidance on the 
OSM wiki is quoted below:   

> Traffic sign as a separate node
> https://wiki.openstreetmap.org/wiki/Key:traffic_sign#As_a_separate_node 
> 
> Create a separate node beside the road at the position of the actual sign... 
> You can use the `direction=*` tag to describe the facing orientation of the 
> sign by using an angle or cardinal direction.

^ This is ok!  iD supports `direction=*` and will even render a view cone at 
higher zooms so mappers can see which direction it points.

> Traffic sign along a way
> https://wiki.openstreetmap.org/wiki/Key:traffic_sign#As_part_of_a_way 
> 
> Create a new node within the relevant way next to the sign... You can use 
> `traffic_sign:forward=*` to specify that this sign affects vehicles moving in 
> the same direction as the OSM way. The opposite direction can be tagged with 
> `traffic_sign:backward=*`. Formerly the `direction=*` key has also been used 
> to describe the affected direction. But its common meaning has changed to 
> Relative to Geographic North.

^ This is the problem.  The wiki says we are supposed to do something like 
`traffic_sign:forward=US:R1`, and we can't really do that. A preset needs to be 
based on a "toplevel" tag like `traffic_sign=*` not `traffic_sign:forward=*` or 
`traffic_sign:backward=*` (remember seamark? many of their tags have this issue 
too, where they put a value in the key part, and so we can’t turn it into a 
preset).

So instead what we’ve decided to do is:  Support a tag `traffic_sign:direction` 
which works exactly the same as the existing and well supported 
`traffic_signals:direction`

See https://wiki.openstreetmap.org/wiki/Key:traffic_signals:direction 

iD already has support for  `traffic_signals:direction=forward/backward`

To keep things simple, we'll do the same thing for traffic signs:
`traffic_sign:direction=forward/backward`

Thanks,
Bryan

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

Re: [Tagging] Tagging a named river bend

2018-09-27 Thread Yves

I think it would be hard to restrict natural=* to a node, but then, which way? 
Not a good idea IMHO.
Yves ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Topographic Prominence for Peaks

Fortunately, when you are finding the prominence of a peak, it matters
that the peak and saddle elevations are measured from the same
baseline. But thanks for the reminder abou the EGN96 standard. I
believe this is also what is used on USGS Topo maps and Opentopomap,
which are the sources I usually check?

I've added some examples to the proposal page and added a description
of how the key saddle of a peak can be found by looking at a topo map
with contours. The saddle is right next to the lowest contour line
that fully encircles the peak, but doesn't encircle any higher point.

Here's a good example:
https://www.opentopomap.org/#marker=17/19.82363/-155.47869
This point is the saddle between Mauna Kea, the high point of Hawaii,
and a small sub-peak named Pu'u Poliahu. It can be seen even better on
the USGS topo map layer in JOSM, or on the USGS website, though then
you get to convert feet to meters. As you see, and elevation cutoff
leads to quite different results compared to prominence when comparing
Mauna Kea and Pu'u Poliahu: similar elevation, very different
prominence.

It would be beneficial to check the elevation of the saddle points
with GPS and an altimeter, because they are often not as precisely
defined as the elevation of the summits, but it is possible to get a
measurement within 10 meters of the true elevation, based on
topographic maps in North America. It is probably true of elevations
of smaller peaks, which have not been surveyed by hand.

I also added an example of the problem with only using elevation:

"The main summit of Mount Everest
(https://www.openstreetmap.org/node/5369192667#map=14/27.9850/86.9259)
and the South Peak (aka the South Summit
https://www.openstreetmap.org/node/1326607409#map=14/27.98492/86.92531)
are very close in elevation and in location. Maps that show all peaks,
or all peaks over a certain elevation, do not have a clear way to
distinguish between the main summit of Everest - the tallest and most
prominent mountain on Earth, and South Peak, a minor sub-peak with a
prominence of only 11 meters. That is, a climber descending from the
main summit need only walk 11 meters up from the col to reach South
Peak."

I also added additional warnings against copying this data from
wikipedia and other sources which are incompatible with the OSM
license. I suspect that many of wikipedia and wikidata prominence
values were inappropriately copied from websites like peakbagger.com,
hence the need for a clean data source in Openstreetmap.

Updated proposal:
https://wiki.openstreetmap.org/wiki/Proposed_features/key:prominence

Joseph

On 9/27/18, Colin Smale  wrote:
> On 2018-09-27 07:17, Graeme Fitzpatrick wrote:
>
>> & when you say survey with GPS, is that accurate enough for an altitude
>> reading? With my Garmin GPS (which admittedly is 10 - 15 years old, but
>> _wasn't_ a cheap one!), I can calibrate it in the back yard at 6m ASL, go
>> for a day trip & when I get home, it displays the exact same spot as
>> anything between -5 & +30m ASL :-( When out driving, I've also seen the
>> altitude display change by 100s of m's instantly, when the road is
>> virtually flat.
>
> ...bearing in mind that ele=* is supposed to be expressed in WGS84 /
> EGN96 not relative to a local sea level datum, so if your GPS already
> applies a "correction" to show you heights relative to sea level, you
> have to back those corrections out, or put the datum in the OSM
> tagging
>
> GPS is not very accurate in the vertical direction, due to the altitude
> of the satellites and the geometry involved. In the horizontal
> directions, you are surrounded on all sides by satellites which can give
> a fairly accurate fix. In the vertical plane the angles to the
> satellites are limited to the half sphere you can "see" without going
> through the earth.

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

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

2018-09-27 Thread Michael Patrick

> It would seem odd to tag a bend as a reach, as the classic definition of
a reach is 'A portion of a river, channel, or lake which lies between two
bends or which can be seen in one view'.

Which is why the first sentence the USGS definition is: “Reach” can
have *slightly
different meanings*, depending on how it is used.

Since USGS is the custodian of the Geographic Names Information System
 (GNIS) and also the hydrology models,
they probably have a better overview of where and how it's applied ranging
from common / historical names to strict scientific terminology.

One that came to my mind which has no straightness component at all was the
Hanford Reach on the Columbia River: *" The Hanford Reach
 is a free-flowing section of
the Columbia River, around 51 miles (82 km) long, in eastern Washington
state. It is named after a large northward bend in the river's otherwise
southbound course."*

I.e. that single bend is the 'reach' :-) The Mississippi River Reaches

are hundreds of miles long and include many straight log sections, bends
etc.

I also have an U.S. Navy COLREGS book "Collision Prevention" on my table
here where their use is exactly according to the definition you mention
based on 'visibility'. And close to other nautical meanings like a sailing
'reach', being the longest clear path achievable without obstruction under
given conditions.

One source gives the 1520s as the earliest use, referring to stretches of
water.There weren't to many straight stretches of water back then, even the
canals in Venice and Amsterdam were pretty organic. :-)

It seams it can be applied in any ad hoc way to any water between two
locations, even nested and overlapping manners, at any scale. Precise
ambiguity, good for OSM. :-)

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

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

The discussion about the definition of "reach" is interesting but IMO it's
slightly off topic.  Perhaps, because of those differences in its
interpretation, we would be best served by not using the term at all.

On Fri, Sep 28, 2018 at 12:06 PM Michael Patrick 
wrote:

>
> > It would seem odd to tag a bend as a reach, as the classic definition of
> a reach is 'A portion of a river, channel, or lake which lies between two
> bends or which can be seen in one view'.
>
> Which is why the first sentence the USGS definition is: “Reach” can have 
> *slightly
> different meanings*, depending on how it is used.
>
> Since USGS is the custodian of the Geographic Names Information System
>  (GNIS) and also the hydrology
> models, they probably have a better overview of where and how it's applied
> ranging from common / historical names to strict scientific terminology.
>
> One that came to my mind which has no straightness component at all was
> the Hanford Reach on the Columbia River: *" The Hanford Reach
>  is a free-flowing section of
> the Columbia River, around 51 miles (82 km) long, in eastern Washington
> state. It is named after a large northward bend in the river's otherwise
> southbound course."*
>
> I.e. that single bend is the 'reach' :-) The Mississippi River Reaches
> 
> are hundreds of miles long and include many straight log sections, bends
> etc.
>
> I also have an U.S. Navy COLREGS book "Collision Prevention" on my table
> here where their use is exactly according to the definition you mention
> based on 'visibility'. And close to other nautical meanings like a
> sailing 'reach', being the longest clear path achievable without
> obstruction under given conditions.
>
> One source gives the 1520s as the earliest use, referring to stretches of
> water.There weren't to many straight stretches of water back then, even the
> canals in Venice and Amsterdam were pretty organic. :-)
>
> It seams it can be applied in any ad hoc way to any water between two
> locations, even nested and overlapping manners, at any scale. Precise
> ambiguity, good for OSM. :-)
>
> Michael Patrick
> Geographer
> .
>
>
>
>
> ___
> 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] Topographic Prominence for Peaks

2018-09-27 Thread Graeme Fitzpatrick

On Fri, 28 Sep 2018 at 15:02, Joseph Eisenberg 
wrote:

> and added a description of how the key saddle of a peak can be found by
> looking at a topo map
> with contours.
>
> I also added additional warnings against copying this data from
> wikipedia and other sources which are incompatible with the OSM
> license. I suspect that many of wikipedia and wikidata prominence
> values were inappropriately copied from websites like peakbagger.com,
> hence the need for a clean data source in Openstreetmap.
>

Not wanting to be a pain here Joseph :-), but do we have (or need?) the OK
to use said topo maps?

I know the ex-Army topo maps that I use (for navigation, not mapping!) are
all copyright Australian Dept of Natural Resources (circa 1967!)

Thanks

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

Re: [Tagging] Topographic Prominence for Peaks