Re: [Tagging] RFC ele:regional

[Greg Troxel]

Joseph Eisenberg  writes:

> Is there a reason to use this new tag ele:regional instead of ele:local=*
> which is already mentioned on the Key:ele page?

The notion of "ele:regional" is semantically wrong, because there is no
way to map a particular lcoation to a single vertical datum.

The notion of "local" has the same problem, and it is also a poor choice
of words in that in surveying, "local", refers to coordinate systems
established for particular projects or surveys that have no lasting
significance.

I have tended to say "regional datum", because in the US we share NAVD88
with Canada, and because I have the impression that in Europe multiple
countries share a vertical datum.


Basically, either you know what datum an elevation is in, in which case
you can 1) transform it to WGS84 height above geoid or 2) label it
correctly, or you don't know, in which case you should simply *admit
that you do not know*.


I would also ask: if this is reasonable for height, why isn't it also
reasonable for horizontal coordinates?

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

Re: [Tagging] RFC ele:regional

[Greg Troxel]

Mark Wagner  writes:

> What about regions where two or more reference systems are in common
> use?  If I copy an elevation from a USGS benchmark and put it in
> "ele:regional", how does an end-user know if it's a recent benchmark
> measured in NAVD 88 or an older benchmark measured in NVGD 29?

They don't, and this is why doing what you ask about is a bad idea.  (I
realize you are asking a mostly rhetorical question.)

The right thing to do is one of

  1) transform the elevation from whichever system it is in to WGS84
  height above geoid.  This is after all what we do with horizontal
  coordinates -- it is not acceptable in OSM to store coordinates in
  some random datum that is not WGS84, and then make up extra tags to
  pretend that's ok.

  2) Use ele:datum=unknown as a clue that the data is not that high
  quality.

  3) Look up the data sheet and mark it as ele:datum=NGVD29 or
  ele:datum=NAVD88 as it turns out.  Keep in mind that this 'on the
  ground' verifiability notion is taken to crazy extremes, and that
  looking up a height in a database is just as legit as reading it off
  the disc.  The physical discs are after all merely a distributed
  database.  If you are encoding "this disc says X", then you are
  reporting a fact you see with your eyes.  But once you report "the
  elevation of this disc is X (because it said so)", then you are making
  assumptions and *you have not actually verified* what you are putting
  into OSM.  In particular you have not verified it any more than
  looking it up in the NGS databse, and arguably you have verified it
  much less.

The next question is:

  If I just put a height that might be NGVD29 or NAVD88 into the db as
  ele, where it is interpreted as WGS84 heigh above geoid, what harm
  is done, and who suffers that harm?

and I would say "close to zero, and anybody who is upset is welcome to
look up the datasheets, transform precisely, and adjust the values in
the osm db, just like anybody who finds nodes that are not placed
correctly in horizontal coordinates is welcome to move them to better
places".


Not addressed at Mark, but I find the insistence that we have a real
problem to be hard to understand.


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

Re: [Tagging] RFC ele:regional

[Greg Troxel]

Simon Poole  writes:

> Am 04.05.2020 um 15:19 schrieb Kevin Kenny:
>> Elevation as height-above-ellipsoid, unless you're using it in the
>> intermediate results of a GPS calculation, is nonsensical.
>
> However if you read the argumentation on the Altitude page that was
> exactly the reasoning: store hae and therefore be able to calculate
> datum specific heights easily after the fact.

Yes, but this is a ridiculous stramwan.   HAE and height above wgs84
geoid are equally well defined, but one (height above geoid) is what is
used for height and also happens to be almost matching all civil height
systems.


The real point here is that people want to take data that has a number
but not a datum and enter it and feel good about themelves, instead of
realizing and admitting that they are doing something fundamentally
wrong.  I am perfectly ok with entering a height that has no datum, and
having some meta key that basically says that the height value is
inaccurate, and perhaps "ele:datum=unknown" is good for this, crisply
denoting that the height is without a solid basis.

But, I find it unreasonable that people want to legitimize this sort of
confusion, rather than mark it as confusion as a warning to others.

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

Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

[Warin]

On 8/5/20 8:41 am, Paul Norman via Tagging wrote:

On 2020-05-07 11:49 a.m., Joseph Eisenberg wrote:

So, what's the next step?


As a next step, I'd map motorcycle taxis as amenity=motorcycle_taxi. 
Vote with your mapping.



+1


If those opposed don't come up with something better then they will have 
to tolerate it.





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

Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

[Paul Norman via Tagging]

On 2020-05-07 11:49 a.m., Joseph Eisenberg wrote:

So, what's the next step?


As a next step, I'd map motorcycle taxis as amenity=motorcycle_taxi. 
Vote with your mapping.



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

Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

[Lukas-458]

"1) Propose using taxi=motorcar, =motorcycle, =boat, =airplane"

 

I believe at least with this key it would be a waste of time, yes, because taxi=yes is already an access tag and then we get into a chaos. If really wanted it would have to be something like "taxi:type", but this was just for noticing, because I was some of them who were opposed to expand amenity=taxi's definition.

 
--Lukas

Gesendet: Donnerstag, 07. Mai 2020 um 20:49 Uhr
Von: "Joseph Eisenberg" 
An: "Tag discussion, strategy and related tools" 
Betreff: [Tagging] Tag:amenity=motorcycle_taxi not approved


The voting period closed for amenity=motorcycle_taxi with 11 votes to approve and 8 votes in opposition, therefore it is not approved, since the 74% majority requirement was not met.

https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:amenity%3Dmotorcycle_taxi#Voting

Opposing voters preferred using amenity=taxi + motorcycle=yes or amenity=taxi + taxi=motorcycle
 

Surprisingly, at least 2 opposing voters would be willing to use amenity=taxi + taxi=submarine or taxi=airplane for a location where you could hire a submarine or airplane. 

 

However, several "yes" voters were strongly opposed to expanding the definition of amenity=taxi which currently is limited to taxicabs (generally assumed to be 4-wheel motor vehicles in contemporary British English).

 

So, what's the next step? 

 

1) Propose using taxi=motorcar, =motorcycle, =boat, =airplane, and get that idea officially rejected (it appears it would be certain to fail), or is that a waste of everyone's time?

 

2) Make a proposal to clarify the definition of amenity=taxi as only applying to motorcars, then try to propose the tag again?

 

3) Propose amenity=ojek and just hold the vote in the Indonesian community, like how the Japanese mapper community proposes locally-relevant definitions?

 

4) Give up on mapping things which are not found in western Europe, and recognize that this is in practice a project dominated by English/German/American culture, which will not accept new ideas which were not invented in the West?

 

-- Joseph Eisenberg

___ 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] Tag:amenity=motorcycle_taxi not approved

[Joseph Eisenberg]

The voting period closed for amenity=motorcycle_taxi with 11 votes to
approve and 8 votes in opposition, therefore it is not approved, since the
74% majority requirement was not met.

https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:amenity%3Dmotorcycle_taxi#Voting

Opposing voters preferred using amenity=taxi + motorcycle=yes or
amenity=taxi + taxi=motorcycle

Surprisingly, at least 2 opposing voters would be willing to use
amenity=taxi + taxi=submarine or taxi=airplane for a location where you
could hire a submarine or airplane.

However, several "yes" voters were strongly opposed to expanding the
definition of amenity=taxi which currently is limited to taxicabs
(generally assumed to be 4-wheel motor vehicles in contemporary British
English).

So, what's the next step?

1) Propose using taxi=motorcar, =motorcycle, =boat, =airplane, and get that
idea officially rejected (it appears it would be certain to fail), or is
that a waste of everyone's time?

2) Make a proposal to clarify the definition of amenity=taxi as only
applying to motorcars, then try to propose the tag again?

3) Propose amenity=ojek and just hold the vote in the Indonesian community,
like how the Japanese mapper community proposes locally-relevant
definitions?

4) Give up on mapping things which are not found in western Europe, and
recognize that this is in practice a project dominated by
English/German/American culture, which will not accept new ideas which were
not invented in the West?

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

Re: [Tagging] Is there any tagging scheme for carillons already?

[Joseph Eisenberg]

> Something like: man_made=bells + bells=carillon for the larger
instruments and man_made=bells + bells=chime for the smaller ones.

That makes sense. Also, "bells" is easier to translate into most languages.

-- Joseph Eisenberg

On Thu, May 7, 2020 at 9:57 AM Adam Franco  wrote:

> These large bell-instruments their own terminology with a Carillon being
> defined as having 24+ bells:* "A carillon-like instrument with fewer than
> 23 bells is called a chime
> ." *(ref
> Wikipedia/Carillon ) with the
> exception of *"Instruments built before 1940 and composed of between 15
> and 22 bells may be designated as 'historical carillons.'"* (ref
> Wikipedia/Carillon )
>
> It seems that tagging these instruments under a overarching category might
> be good. Something like: man_made=bells + bells=carillon for the larger
> instruments and man_made=bells + bells=chime for the smaller ones. Those
> "historical carillons" could get either one or their own value for bells=.
> This would avoid the potential confusion of calling something with 14 bells
> a "carillon" which would be inaccurate.
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Is there any tagging scheme for carillons already?

[Adam Franco]

These large bell-instruments their own terminology with a Carillon being
defined as having 24+ bells:* "A carillon-like instrument with fewer than
23 bells is called a chime
." *(ref
Wikipedia/Carillon ) with the
exception of *"Instruments built before 1940 and composed of between 15 and
22 bells may be designated as 'historical carillons.'"* (ref
Wikipedia/Carillon )

It seems that tagging these instruments under a overarching category might
be good. Something like: man_made=bells + bells=carillon for the larger
instruments and man_made=bells + bells=chime for the smaller ones. Those
"historical carillons" could get either one or their own value for bells=.
This would avoid the potential confusion of calling something with 14 bells
a "carillon" which would be inaccurate.

On Thu, May 7, 2020 at 11:22 AM Joseph Eisenberg 
wrote:

> +1 to using man_made=carillon or =bells.
>
> Don’t use attraction because that is for carousels and roller coasters and
> similar things in amusement parks, mostly.
>
> —Joseph Eisenberg
>
> On Thu, May 7, 2020 at 8:18 AM Martin Koppenhoefer 
> wrote:
>
>>
>>
>> sent from a phone
>>
>> > On 7. May 2020, at 16:26, lukas-...@web.de wrote:
>> >
>> > But maybe I will start a proposal with attraction=carillon for tagging
>> carillons which are operated as an attraction, but then the definition of
>> that has to be very clear, I think.
>>
>>
>> I am all for tagging carillons, if you like with all the details like
>> material, number of bells, melodies that are commonly played and at which
>> times, etc., but please do not use the “attraction” key. tourism=attraction
>> is a questionable tag (how would it be verified/what is an objective
>> criterion on distinguish between something being or not yet, an
>> attraction?), and it does generally more harm than help to describe the
>> world (because it renders a name and many people are not encouraged to push
>> it further and actually describe what the thing is).
>>
>> Just leave it open whether a carillon is an attraction or not, and map:
>> “here’s a carillon”. Suitable keys I would examine could be amenity or
>> man_made, there could also be a property like carillon=yes/no to indicate
>> there’s a carillon at a place (e.g. a tower).
>> If you are interested in tagging additional detail it seems better to
>> create a distinct object than adding a property to something else.
>>
>> Cheers Martin
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Is there any tagging scheme for carillons already?

[Joseph Eisenberg]

+1 to using man_made=carillon or =bells.

Don’t use attraction because that is for carousels and roller coasters and
similar things in amusement parks, mostly.

—Joseph Eisenberg

On Thu, May 7, 2020 at 8:18 AM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 7. May 2020, at 16:26, lukas-...@web.de wrote:
> >
> > But maybe I will start a proposal with attraction=carillon for tagging
> carillons which are operated as an attraction, but then the definition of
> that has to be very clear, I think.
>
>
> I am all for tagging carillons, if you like with all the details like
> material, number of bells, melodies that are commonly played and at which
> times, etc., but please do not use the “attraction” key. tourism=attraction
> is a questionable tag (how would it be verified/what is an objective
> criterion on distinguish between something being or not yet, an
> attraction?), and it does generally more harm than help to describe the
> world (because it renders a name and many people are not encouraged to push
> it further and actually describe what the thing is).
>
> Just leave it open whether a carillon is an attraction or not, and map:
> “here’s a carillon”. Suitable keys I would examine could be amenity or
> man_made, there could also be a property like carillon=yes/no to indicate
> there’s a carillon at a place (e.g. a tower).
> If you are interested in tagging additional detail it seems better to
> create a distinct object than adding a property to something else.
>
> 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] Is there any tagging scheme for carillons already?

[Martin Koppenhoefer]

sent from a phone

> On 7. May 2020, at 16:26, lukas-...@web.de wrote:
> 
> But maybe I will start a proposal with attraction=carillon for tagging 
> carillons which are operated as an attraction, but then the definition of 
> that has to be very clear, I think.


I am all for tagging carillons, if you like with all the details like material, 
number of bells, melodies that are commonly played and at which times, etc., 
but please do not use the “attraction” key. tourism=attraction is a 
questionable tag (how would it be verified/what is an objective criterion on 
distinguish between something being or not yet, an attraction?), and it does 
generally more harm than help to describe the world (because it renders a name 
and many people are not encouraged to push it further and actually describe 
what the thing is). 

Just leave it open whether a carillon is an attraction or not, and map: “here’s 
a carillon”. Suitable keys I would examine could be amenity or man_made, there 
could also be a property like carillon=yes/no to indicate there’s a carillon at 
a place (e.g. a tower). 
If you are interested in tagging additional detail it seems better to create a 
distinct object than adding a property to something else.

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

Re: [Tagging] Is there any tagging scheme for carillons already?

[Lukas-458]

Hmm, okay. I think a carillon is so widespread especially, but not only for bell_towers, that something like carillon=yes wouldn't be useful.

 

But maybe I will start a proposal with attraction=carillon for tagging carillons which are operated as an attraction, but then the definition of that has to be very clear, I think.

 

But I think we need a tag for tagging just bells, too. There exists amenity=bell 198x but I think a bell is not really an "amenity", is it? man_made=bells could be used just for the bell itself, because tower:type=bell_tower ist just about the tower, not about the bell. And if people want to tag those they can decide for themselves, no really matter whether the bells is/are seeable for public or not. There are also some bells which are outside of towers, anyway.

 

I think I would go on with a proposal for that.

 
--Lukas

Gesendet: Donnerstag, 07. Mai 2020 um 07:11 Uhr
Von: "Marc Gemis" 
An: "Tag discussion, strategy and related tools" 
Betreff: Re: [Tagging] Is there any tagging scheme for carillons already?

On Wed, May 6, 2020 at 7:54 PM Paul Allen  wrote:

> I'm not sure we need to tag the carillon. The ones in churches I've
> encountered or read about aren't operated as attractions.

Not important for tagging, but perhaps worth mentioning.

Normally, in summer there are concerts in 3 Flemish towns on
carillons, called beiaardconcerten [1]
I wonder whether that classifies as "operated as attractions"
It seems that in some towns you can visit them as well [2].

regards

m.

[1] https://nl.wikipedia.org/wiki/Beiaardconcert
[2] https://bib.kuleuven.be/over-ons/Index/beiaardbezoek

___
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] Doorzone bicycle lanes

[Andrew Harvey]

On Thu, 7 May 2020 at 02:05, Florimond Berthoux <
florimond.berth...@gmail.com> wrote:

> Hazard tag seems to be used when there is a sign, so I'm not confident to
> use it for doorzone.
>
> There is two choices :
> 1. describe the layout of the street lanes + cyclelanes + : parking lane +
> sidewalk
> then add the widt of the cycle lane.
> Data consumer can deduce if the lane is dangerous or not
> + objective
> + complete without feature tagged twice
> - harder to compute doorzone state
> - harder to tag (a cyclist willing to tag doorzone has to tag parking
> lanes and width)
>
> example :
> cycleway=lane
> cycleway:width=1m
> parking:lane=parallel
>
> => doorzone
>
> (I could add more tags, for buffer, but I keep simple as possible.)
>
> 2. just tag doorzone feature
> (opposite arguments +/-)
>
> example :
> cycleway=lane
> cycleway:left:doorzone=yes
>
> Before writing this email I was not pro 1., but it's only 2 tags against
> 1, problem is that you must measure the lane and that is little difficult
> (our eyes are bad at that).
> At the end if the two way of tagging is documented for doorzone I'm ok
> with both.
>

I agree there are the two approaches, both can co-exist. I think (1) alone
is a tad too fragile especially since if the cyclelane is a doorzone or not
depends on the buffer and layout, I think it's safer to have a tag like (2)
to specifically say the cyclelane is a doorzone.



On Thu, 7 May 2020 at 15:33, Marc Gemis  wrote:

> but in the end, someone will probably have to add
> parking:lane=parallel as well, not? The second style of mapping
> nothing says nothing about the parking lane. Or does
> cycleway:left:doorzone=yes implies parking:lane:left=parallel?
>

Yes the parking:lane tag should also be added together with the doorzone
tag, I guess you could say it's implied, but it would be a pain for both
data consumers and mappers to rely on this kind of implication, better to
always tag it.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging