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

[Shawn K. Quinn]

On 5/7/20 1:49 PM, Joseph Eisenberg wrote:
> 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?

taxi=* is already used as an access tag, so I think taxi:type=* should
be considered instead. Perhaps amenity=taxi can default to motorcar if
there is no taxi:type=* tag.

In theory we could even have taxi:type=tuktuk or similar if it's that
important to differentiate it from other types of motorized transport.

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

This might work but I'd rather not see a bunch of region-specific tags
that all mean the same thing. It's as if we had shop=vacuum in the US
and then shop=hoover in the UK (though that would run afoul of trademark
infringement, but you get where I'm coming from).

> 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?

Most ideas of this sort are implemented worldwide, just in different ways.

-- 
Shawn K. Quinn 
http://www.rantroulette.com
http://www.skqrecordquest.com

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

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

[Paul Allen]

On Sat, 9 May 2020 at 00:59, François Lacombe 
wrote:

We're not having an argument about making a difference or not between
> motorcycles or cars
>

What we're having is an argument about taxonomy.

Some people have mental models that distinguish between a taxi, an ojek and
a rickshaw, pther people see them as variants of a single concept.  They're
all
transport for hire but they have different capabilities.  If I look at a
map and see a taxi
stand, I expect some sort of four-wheel vehicle capable of carrying at
least 3
passengers and offering some degree of weather protection.  To me, an ojek
is not
a "taxi."  Even if I were visiting Indonesia where ojeks are common, if the
map
says "taxi" I think car, not motorbike.

This isn't just about optimizing the number of tags used, it's about
aligning with
how most people's mental models work.  And not just the mental models
of local mappers but also the mental models of tourists: locals don't refer
to maps as often as tourists do.

Some people see wheeled vehicles for hire as being different varieties of
taxi; some people see taxis, ojeks and rickshaws.

Some people see *Ailuropoda melanoleuca *an*d Ursus arctos* as different
members of the family Ursidae; others see then as giant pandas and brown
bears.  I'm a giant panda kind of guy.

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

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

[François Lacombe]

Hi Joseph,

Le sam. 9 mai 2020 à 01:28, Joseph Eisenberg  a
écrit :

> François,
>
> Have you personally hired a motorcycle before, or is the assumption that
> this is the same service based on theory rather than experience?
>

I've hired some before lockdown, independently as cars when alone.
I've paid someone to take me somewhere with a vehicle.

The proposal gave several reasons that using amenity=taxi was not a good
> idea, including these:
>
> "Motorcyles have different abilities.
>
> "In contrast to a family or group which needs a 4 to 6 seat taxicab,
> single travelers may strongly prefer to hire motorcycles when available,
> due to their lower cost and ability to fit through smaller spaces in
> congested cities and rural areas with narrow roads and paths.
>
> "Motorcar taxicabs with 4 wheels in 2 tracks cannot access highway=path
> features and narrow roads, but motorcycles may be permitted and feasible
> due to their narrow width and single track."
>
> So a different tag is proposed to avoid confusion and more precisely tag
> these features."
>

I agree on those points and they legit the use of vehicle=motorcycle vs
vehicle=car imho.
As said, we always hire a driver to get us where we want in his vehicle,
whatever the vehicle is (chosen according to punctual needs)


> A taxi can carry 4 or more passengers, with their luggage or shopping, and
> they are enclosed, heated and perhaps air conditioned, and protected from
> weather. When you are traveling with your elderly mother-in-law and her
> luggage in a rainstor, a taxicab stand and an "ojek" queue are quite
> different amenities.
>

We're not having an argument about making a difference or not between
motorcycles or cars
We're opposing on how making this difference.
Enumerating relevant differences between both won't lead us to valuable
tagging I'm afraid.

As shown in 2009 discussion amenity=taxi definition is not as clear as we
may think now.
This proposal would have been an occasion to make it explicit and separate
concepts (service, vehicle, activity, whatever) which is IMHO more valuable
in tagging than having less tags on a single feature.

"using amenity=taxi for other vehicles than car could lead to errors"
Then add proper vehicle=* value on it, problem solved.


> However, taxis  use much more gasoline and the vehicle is more expensive
> to buy and maintain, so the price is higher than a motorcycle. Since they
> are 1.5 meters wider, they cannot fit though spaces less than 2.5 meters
> wide, which is a big disadvantage in cities in Asia with narrow streets or
> high traffic. Often only a motorcycle can get through traffic jams and
> narrow streets. In rural areas, only motorcycles are used to access many
> mountain villages, where 4-wheel-drive motorcars would be hard-pressed to
> travel.
>
> Equating these features would be like using one tag to for moving truck
> rental ("U-Haul" in the USA), motorcycle rental, bike rental, and
> kick-scooter rental.
>

Truck rental, motorcycle rental, bike rental and flying saucer rental all
have "rental" in their name.
I would use two tags respectively for rental and for the vehicle.

All the best

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

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

[Joseph Eisenberg]

François,

Have you personally hired a motorcycle before, or is the assumption that
this is the same service based on theory rather than experience?

The proposal gave several reasons that using amenity=taxi was not a good
idea, including these:

"Motorcyles have different abilities.

"In contrast to a family or group which needs a 4 to 6 seat taxicab, single
travelers may strongly prefer to hire motorcycles when available, due to
their lower cost and ability to fit through smaller spaces in congested
cities and rural areas with narrow roads and paths.

"Motorcar taxicabs with 4 wheels in 2 tracks cannot access highway=path
features and narrow roads, but motorcycles may be permitted and feasible
due to their narrow width and single track."

So a different tag is proposed to avoid confusion and more precisely tag
these features."

A taxi can carry 4 or more passengers, with their luggage or shopping, and
they are enclosed, heated and perhaps air conditioned, and protected from
weather. When you are traveling with your elderly mother-in-law and her
luggage in a rainstor, a taxicab stand and an "ojek" queue are quite
different amenities.

However, taxis  use much more gasoline and the vehicle is more expensive to
buy and maintain, so the price is higher than a motorcycle. Since they are
1.5 meters wider, they cannot fit though spaces less than 2.5 meters wide,
which is a big disadvantage in cities in Asia with narrow streets or high
traffic. Often only a motorcycle can get through traffic jams and narrow
streets. In rural areas, only motorcycles are used to access many mountain
villages, where 4-wheel-drive motorcars would be hard-pressed to travel.

Equating these features would be like using one tag to for moving truck
rental ("U-Haul" in the USA), motorcycle rental, bike rental, and
kick-scooter rental.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[François Lacombe]

Hi

Le ven. 8 mai 2020 à 20:48, Phake Nick  a écrit :

> motorcycle are not the same type of service as regular taxi.
>

Then may I ask you why ?
I pay a driver to take me where I want to with his vehicle.


> The reaso  why you get the feeling of people saying "you don't understand"
> to you is because you couldn't tell others why your concern is legitimate,
> thus making it read like nonsense, even if they might make sense to you,
> thought I am still not sure about how the distinction of electric power or
> not is going to on the same level as different types of services.
>

There is a lack of understanding in both sides here because I don't get why
having two different amenity values is a benefit.

Back in 2009 a wiki contributor explained he's using amenity=taxi +
motorcycle=yes. Despite motorcycle=yes can be awkward as it is used as an
access tag, the idea to complete taxi service with explicit vehicle
definition is useful.
https://wiki.openstreetmap.org/wiki/Talk:Tag:amenity%3Dtaxi#Motorcycles.3F
As I assume motorcycle taxi service is the same as taxicab service (change
my mind upside), I find convenient to only define extra vehicule types
instead of the whole service we already have in amenity=taxi.

All the best

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

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

[Jarek Piórkowski]

On Fri, 8 May 2020 at 09:05, Phake Nick  wrote:
> On 2020-05-08 Fri 20:45, Jarek Piórkowski  wrote:
>> How much discussion do you think should be necessary before voting "I
>> oppose, because I think using sub-tags is better"? If someone thinks
>> that, they think that. A discussion would just print the arguments
>> back and forth.
>
> Given the proportion of opposing comment being raised, I would say "more than 
> what have been discussed", as barely anyone raised the point during the 
> discussion. The only two remotely relevant mentions about it during the 
> discussion process was 1. one user who think there should be a new parents 
> tag that cover both regular taxi and motorcycle taxi, and 2. another who 
> incorrectly assuned "motorcycle taxi" is a combination of two different 
> features just because the term come with a space. That clearly indicate 
> discussion was not sufficient and that the proposal should restart the 
> discussion process.

I'm assuming you mean the following messages in the February thread?
1. https://lists.openstreetmap.org/pipermail/tagging/2020-February/051244.html
2. https://lists.openstreetmap.org/pipermail/tagging/2020-February/051250.html

Do you expect others who agree with already-stated positions to write
in with a copy?

More widely, it is my impression that "refining with sub-tags vs
creating new tags" has been a culture conflict in OSM since long
before I became active. (I'm just waiting for the fireworks when
someone suggests public_transport=platform + motorcycle=yes)

These objections are not new. You might not agree with them, but their
existence should not surprise you. ¯\_(ツ)_/¯

--Jarek

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

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

[Jarek Piórkowski]

On Fri, 8 May 2020 at 18:30, Joseph Eisenberg
 wrote:
> > (especially those approved after, say, 2012)
>
> The proposal process became more difficult after March 2015, when the 
> standard for approval was changed from >50% to >74%:
>
> https://wiki.openstreetmap.org/w/index.php?title=Proposal_process=revision=1150734=1143140
>
> This has been helpful in preventing bad ideas from being approved without 
> consensus.
>
> But it has made it more likely that a proposal will not be approved, even 
> though the majority accepts it.

Ah yes, that sounds about right. I added the classifier because I
recall some early proposals, 2008 or 2009 or so, being pretty
barebone, and wanted to separate those from the current status.

--Jarek

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

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

[Joseph Eisenberg]

> (especially those approved after, say, 2012)

The proposal process became more difficult after March 2015, when the
standard for approval was changed from >50% to >74%:

https://wiki.openstreetmap.org/w/index.php?title=Proposal_process=revision=1150734=1143140

This has been helpful in preventing bad ideas from being approved without
consensus.

But it has made it more likely that a proposal will not be approved, even
though the majority accepts it.

--Joseph Eisenberg

On Fri, May 8, 2020 at 3:21 PM Jarek Piórkowski  wrote:
>
> On Fri, 8 May 2020 at 09:05, s8evq  wrote:
> > On Fri, 8 May 2020 08:43:27 -0400, Jarek Piórkowski 
wrote:
> > > How much discussion do you think should be necessary before voting "I
> > > oppose, because I think using sub-tags is better"? If someone thinks
> > > that, they think that. A discussion would just print the arguments
> > > back and forth.
> >
> > If these arguments were given beforehand, perhaps the proposal could
have changed, or opinions could have been changed?
>
> Honestly - I remember following the discussion on this mailing list
> for a while and my impression was that the arguments _were_ given.
> These arguments are not a surprise. Here's a version of this exact
> argument in February:
>
https://lists.openstreetmap.org/pipermail/tagging/2020-February/051250.html
>
> Subsequent discussion here is an example of what happened. Some
> people, _after having read the rationale offered_, think that a
> separate tag is not warranted. Some people think that it is. You won't
> win an argument by telling others they're wrong.
>
> > I hardly have any experience in proposals and the voting system. But
I've seen 3 proposal so far, where I know the author doesn't want to bring
it to vote, fearing the proposal would be rejected. The rationale behind
it: status Rejected is worse than having the proposal in the "Draft" state
forever.
> >
> > And then some people in this very thread suggest to just ignore a
rejection and start using it anyway. What's the use of the whole voting
system then? Why even bother writing a proposal in the first place? I'll
just do whatever.
>
> Yeah I understand. I myself rejected Joseph's suggestion to make a tag
> I used locally and documented on wiki into a "proposal", because I
> don't want the hassle.
>
> My interpretation is that "approved" is a _lot_ higher status than "in
> use", precisely because how harsh the proposal process is. That's just
> I see it being in OSM - you can have in-use tags, locally-accepted
> tags, and then the "approved" tags are really really accepted
> (especially those approved after, say, 2012).
>
> Failing a proposal isn't a bad thing. Tag what you like. (With some
> exceptions, like straight-up vandalism or trolltags)
>
> --Jarek
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Jarek Piórkowski]

On Fri, 8 May 2020 at 09:05, s8evq  wrote:
> On Fri, 8 May 2020 08:43:27 -0400, Jarek Piórkowski  
> wrote:
> > How much discussion do you think should be necessary before voting "I
> > oppose, because I think using sub-tags is better"? If someone thinks
> > that, they think that. A discussion would just print the arguments
> > back and forth.
>
> If these arguments were given beforehand, perhaps the proposal could have 
> changed, or opinions could have been changed?

Honestly - I remember following the discussion on this mailing list
for a while and my impression was that the arguments _were_ given.
These arguments are not a surprise. Here's a version of this exact
argument in February:
https://lists.openstreetmap.org/pipermail/tagging/2020-February/051250.html

Subsequent discussion here is an example of what happened. Some
people, _after having read the rationale offered_, think that a
separate tag is not warranted. Some people think that it is. You won't
win an argument by telling others they're wrong.

> I hardly have any experience in proposals and the voting system. But I've 
> seen 3 proposal so far, where I know the author doesn't want to bring it to 
> vote, fearing the proposal would be rejected. The rationale behind it: status 
> Rejected is worse than having the proposal in the "Draft" state forever.
>
> And then some people in this very thread suggest to just ignore a rejection 
> and start using it anyway. What's the use of the whole voting system then? 
> Why even bother writing a proposal in the first place? I'll just do whatever.

Yeah I understand. I myself rejected Joseph's suggestion to make a tag
I used locally and documented on wiki into a "proposal", because I
don't want the hassle.

My interpretation is that "approved" is a _lot_ higher status than "in
use", precisely because how harsh the proposal process is. That's just
I see it being in OSM - you can have in-use tags, locally-accepted
tags, and then the "approved" tags are really really accepted
(especially those approved after, say, 2012).

Failing a proposal isn't a bad thing. Tag what you like. (With some
exceptions, like straight-up vandalism or trolltags)

--Jarek

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

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

[Joseph Eisenberg]

The tag motorcycle=yes is already documented as defining legal access
restrictions for motorcycle riders, like access=yes or foot=yes
See https://wiki.openstreetmap.org/wiki/Tag:motorcycle%3Dyes

-- Joseph Eisenberg

On Fri, May 8, 2020 at 1:34 PM Florimond Berthoux <
florimond.berth...@gmail.com> wrote:
>
> Hi,
>
> 5) As a French I have to give you again the universal answer :
amenity=taxi + motorcycle=yes + whateveryourvehicle=yes|designated :)
>
> Tags is an intermediate language between human and machine, at the end
its just characters with definitions, but some are easier to use for
mapping and computing.
>
> (I read some disrespectful arguments in the following mails...)
>
> Regards
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Florimond Berthoux]

Hi,

5) As a French I have to give you again the universal answer : amenity=taxi
+ motorcycle=yes + whateveryourvehicle*=yes|*designated :)

Tags is an intermediate language between human and machine, at the end its
just characters with definitions, but some are easier to use for mapping
and computing.

(I read some disrespectful arguments in the following mails...)

Regards

Le jeu. 7 mai 2020 à 20:51, Joseph Eisenberg  a
écrit :

> 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
>


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

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

[Phake Nick]

That they exists doesn't mean they make a different. Taxi with low
pollution and taxi with electric power are same type of taxi as regular
taxi while motorcycle are not the same type of service as regular taxi.
That is like saying we shouldn't have a separate tag for bus versus cars
because there are many different types of cars, including electric car and
fuel efficient cars.:

The reaso  why you get the feeling of people saying "you don't understand"
to you is because you couldn't tell others why your concern is legitimate,
thus making it read like nonsense, even if they might make sense to you,
thought I am still not sure about how the distinction of electric power or
not is going to on the same level as different types of services.

在 2020年5月9日週六 01:19，Marc M.  寫道：

> apart from the joke with the foot_taxi, I used all the others, what to
> reply to someone who tells me it's not common and therefore gives the
> impression that only this usecase is important and therefore requires a
> top-level tag just for that ?
>
> that's why it gives the impression that you're saying "you didn't
> understand", without your answer explaining my argument : I'm talking
> about "the same *service*" and you reply with the number of *wheels*
>
> Le 08.05.20 à 18:17, Joseph Eisenberg a écrit :
> > For the record, I responded to Marc Marc’s comment on this list,
> > and there was not a response back:
> >
> > “ On 2/20/20, marc marc wrote:
> >> Le 20.02.20 à 12:45, Joseph Eisenberg a écrit :
> >>> Can't we have an easy to use top-level feature tag, instead of having
> >>> to add 3 tags like amenity=taxi + motorcar=no + motorcycle=yes to
> >>> define one very common, unique feature?
> >>
> >> did we need to have a top-level feature for every "unique" combination
> >> of the same service ?
> >> if yes, we need a lot of them
> >> amenity=foot_taxi
> >> amenity=moto_taxi
> >> amenity=sidecar_taxi
> >> amenity=taxi_low_local_pollution
> >> amenity=taxi_powered_by_renewable_energy etc.
> >> but all of these are part of the same type of service,
> >> regardless of the number of wheels and the driving force.
> >
> > Not all of these actually are in real-world use.
> >
> > The only 4 options in common use today are:
> >
> > 1) motorcar, 4 wheels, enclosed (amenity=taxi)
> > 2) motorcycle, 2 wheels, open (amenity=motorcycle_taxi)
> > 3) pedicabs / 3-wheel tricycles (amenity=pedicab?) - non-motorized
> > 4) autorickshaws, 3 wheels, enclosed (could be amenity=taxi or perhaps
> > amenity=autorickshaw - but these are not common where I live, though I
> > know they are common in Thailand, India and some other countries).
> >
> > There used to be human-pulled rickshaws, but these no longer exist.
> > They were take over by pedicabs / aka bicycle rickshaws, since those
> > are much more efficient.
> >
> > I will consider proposing the other 2 tags later, but motorcyle taxis
> > are by far the most common. I would bet there are more "ojek" stands
> > in Indonesia than taxi
> >  stands in all of Europe.”
> >
> >
> https://lists.openstreetmap.org/pipermail/tagging/2020-February/051233.html
> >
> > — Joseph Eisenberg
> >
> > On Fri, May 8, 2020 at 8:47 AM Marc M.  > > wrote:
> >
> > Hello,
> >
> > > If these arguments were given beforehand
> >
> > except memory problem, I exposed this opinion here during the RFC
> > (=consider that taxi is a service independent of the propulsion
> > of the engine which is a sub-tag), and I have the impression that
> > the answer was "you didn't understand".
> >
> > I would have liked to understand why I was wrong, but I have the
> > impression that this was not the goal of this rfc which is a mistake
> for
> > the quality (and it is not the first proposal that fails for lack of
> > quality either in the tag, either in the explanation of why this tag)
> >
> > Regards,
> > Marc
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org 
> > https://lists.openstreetmap.org/listinfo/tagging
> >
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
> >
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Mateusz Konieczny via Tagging]

May 8, 2020, 19:23 by marc_marc_...@hotmail.com:

> Le 08.05.20 à 19:06, Phake Nick a écrit :
>
>> Your argument was like saying we should use a amenity=stop tag for all
>> bus stop, taxi stop, helicopter stop, and cruise ship stop because they
>> are just "services
>>
>
> public_transport=* was invented for a service and relegate
> the mode of transport to a sub-tag.
>
Only for stop position, for bus/tram/railway stop ("platform")
simpletagging (highway=bus_stop etc) was supposed to be used
according to the approved version of a proposal.

PTv2 in the vote version is explicitly not deprecating any tags.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Voting procedures (Was: Re: Tag:amenity=motorcycle_taxi not approved)

[Mateusz Konieczny via Tagging]

May 8, 2020, 18:06 by kevin.b.ke...@gmail.com:

> On Fri, May 8, 2020 at 9:06 AM Phake Nick  wrote:
>
>> Given the proportion of opposing comment being raised, I would say "more 
>> than what have been discussed", as barely anyone raised the point during the 
>> discussion. The only two remotely relevant mentions about it during the 
>> discussion process was 1. one user who think there should be a new parents 
>> tag that cover both regular taxi and motorcycle taxi, and 2. another who 
>> incorrectly assuned "motorcycle taxi" is a combination of two different 
>> features just because the term come with a space. That clearly indicate 
>> discussion was not sufficient and that the proposal should restart the 
>> discussion process.
>>
>
>
> Our 'yes/no' voting on proposals leads to a pathological phenomenon
> that I've seen happen several times.
>
> Someone wants to map a particular feature, and floats an idea for a
> tag 'A' on the list.
>
> Several other people counter-propose incompatible tags 'B', 'C', 'D' -
> each with its own advantages and disadvantages.
>
> None of these tags garners a clear majority of commenters.
>
> Either the proponent abandons the idea, or else falls back on 'any
> tags you like', or actually bites the bullet and makes a formal
> proposal, calling the vote.
>
> In the last case, which is already uncommon, the vote fails, because,
> if for instance, 'B' becomes the final proposal, all of the supporters
> of 'A', 'C', 'D' vote against the proposal.
>
In my case I proceed with vote only in case of a clear support for a proposal.
(man_made=bridge, man_made=carpet_hanger)

https://wiki.openstreetmap.org/wiki/Proposed_features/man_made%3Dbridge
https://wiki.openstreetmap.org/wiki/Proposed_features/carpet_hanger

I made some proposals where discussion was very useful and helped to
improve page, but I decided to not risk a vote.

https://wiki.openstreetmap.org/wiki/Proposed_features/street_vendor%3Dyes
https://wiki.openstreetmap.org/wiki/Proposed_features/opening_hours:signed%3Dno

No vote at all and de facto tag is better outcome than a failed vote
if you want to tag something with an accepted tag.

Personally I am fine with this idea, I consider review, criticism and 
discussion as
the useful part of a proposal process. And I give little weight to whatever
tag was approved by vote or not.

(that is also why people wanting to deprecate highway=bus_stop or promote
landcover=* tag family will not make a proposal with vote, because it is
very likely that it would be rejected)

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

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

[Marc M.]

Le 08.05.20 à 19:06, Phake Nick a écrit :
> Your argument was like saying we should use a amenity=stop tag for all
> bus stop, taxi stop, helicopter stop, and cruise ship stop because they
> are just "services

public_transport=* was invented for a service and relegate
the mode of transport to a sub-tag.
this is probably not the best example given the difficulty
around PT schemas but it was approved

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

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

[Marc M.]

apart from the joke with the foot_taxi, I used all the others, what to
reply to someone who tells me it's not common and therefore gives the
impression that only this usecase is important and therefore requires a
top-level tag just for that ?

that's why it gives the impression that you're saying "you didn't
understand", without your answer explaining my argument : I'm talking
about "the same *service*" and you reply with the number of *wheels*

Le 08.05.20 à 18:17, Joseph Eisenberg a écrit :
> For the record, I responded to Marc Marc’s comment on this list, 
> and there was not a response back:
> 
> “ On 2/20/20, marc marc wrote:
>> Le 20.02.20 à 12:45, Joseph Eisenberg a écrit :
>>> Can't we have an easy to use top-level feature tag, instead of having
>>> to add 3 tags like amenity=taxi + motorcar=no + motorcycle=yes to
>>> define one very common, unique feature?
>>
>> did we need to have a top-level feature for every "unique" combination
>> of the same service ?
>> if yes, we need a lot of them
>> amenity=foot_taxi
>> amenity=moto_taxi
>> amenity=sidecar_taxi
>> amenity=taxi_low_local_pollution
>> amenity=taxi_powered_by_renewable_energy etc.
>> but all of these are part of the same type of service,
>> regardless of the number of wheels and the driving force.
> 
> Not all of these actually are in real-world use.
> 
> The only 4 options in common use today are:
> 
> 1) motorcar, 4 wheels, enclosed (amenity=taxi)
> 2) motorcycle, 2 wheels, open (amenity=motorcycle_taxi)
> 3) pedicabs / 3-wheel tricycles (amenity=pedicab?) - non-motorized
> 4) autorickshaws, 3 wheels, enclosed (could be amenity=taxi or perhaps
> amenity=autorickshaw - but these are not common where I live, though I
> know they are common in Thailand, India and some other countries).
> 
> There used to be human-pulled rickshaws, but these no longer exist.
> They were take over by pedicabs / aka bicycle rickshaws, since those
> are much more efficient.
> 
> I will consider proposing the other 2 tags later, but motorcyle taxis
> are by far the most common. I would bet there are more "ojek" stands
> in Indonesia than taxi
>  stands in all of Europe.”
> 
> https://lists.openstreetmap.org/pipermail/tagging/2020-February/051233.html
> 
> — Joseph Eisenberg
> 
> On Fri, May 8, 2020 at 8:47 AM Marc M.  > wrote:
> 
> Hello,
> 
> > If these arguments were given beforehand
> 
> except memory problem, I exposed this opinion here during the RFC
> (=consider that taxi is a service independent of the propulsion
> of the engine which is a sub-tag), and I have the impression that
> the answer was "you didn't understand".
> 
> I would have liked to understand why I was wrong, but I have the
> impression that this was not the goal of this rfc which is a mistake for
> the quality (and it is not the first proposal that fails for lack of
> quality either in the tag, either in the explanation of why this tag)
> 
> Regards,
> Marc
> 
> ___
> 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] RFC ele:regional

[Colin Smale]

On 2020-05-08 18:01, Greg Troxel wrote:

> I think we now know that the existing datums don't differ much from WGS84 
> except Belgium, and given the EVRF2007 datum, it seems clear that Belgium now 
> will have that and the old one, differing by 2m.
> Hence the thing we need to know, we don't, in this case.

Depends how you define "much". According to this info on Wikipedia
(sorry that it is in Dutch), the French also have their own datum, which
is TAW-1.82m, which works out to NAP-0.50m. 

https://nl.wikipedia.org/wiki/Tweede_Algemene_Waterpassing 

A little light reading for Greg: "The transformation of GPS into NAP
heights: Combining NAP, GPS and geoid heights to compute a height
reference surface for the Netherlands" 
https://repository.tudelft.nl/islandora/object/uuid%3Ae661fcdd-6fe8-46e9-b5ea-51dabbd89175___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Phake Nick]

在 2020年5月8日週五 23:47，Marc M.  寫道：

> Hello,
>
> > If these arguments were given beforehand
>
> except memory problem, I exposed this opinion here during the RFC
> (=consider that taxi is a service independent of the propulsion
> of the engine which is a sub-tag), and I have the impression that
> the answer was "you didn't understand".
>
> I would have liked to understand why I was wrong, but I have the
> impression that this was not the goal of this rfc which is a mistake for
> the quality (and it is not the first proposal that fails for lack of
> quality either in the tag, either in the explanation of why this tag)
>
> Regards,
> Marc
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


Because the difference between motorcycle taxi and 4-wheeled taxi is not
propulsion? Your argument was like saying we should use a amenity=stop tag
for all bus stop, taxi stop, helicopter stop, and cruise ship stop because
they are just "services with different propulsion engine" which obviously
wasn't their main differences.

If you don't understand why they're different, you can ask, but you didn't
and just said "They are the same therefore " which obviously didn't
make sense.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Snusmumriken]

On Fri, 2020-05-08 at 09:17 -0700, Joseph Eisenberg wrote:
> There used to be human-pulled rickshaws, but these no longer exist.
> They were take over by pedicabs / aka bicycle rickshaws, since those
> are much more efficient.

Not so. I've seen human-pulled rickshaws in Japan. And they probably
have an other name there. And yes it was a very touristic area, so you
could probably only get a ride inside the large park/compound area. But
they were waiting for rides at certain spots.


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

Re: [Tagging] Voting procedures

[Colin Smale]

The subject of a vote should not be amendable. All the discussions,
debates, consideration of alternatives etc should be BEFORE the proposal
is put to the vote. If a vote fails, THEN the proposal might be amended
and submitted again - but this has to be subject to some time
constraints such as not less than 1 month after the previous vote to
stop people making a quick tweak and resubmitting it immediately. 

When is a proposal "ready for a vote," other than on a timer? How do you
measure or sense if the vote is likely to pass, i.e. a reasonable
consensus has been achieved? A quick check amongst a good sample of the
commenters perhaps? Are they happy that their concerns have now been
addressed? What about having a proposal reviewed for readiness, before a
vote can be announced? 

Which brings us back to the psyche of a "good tagging schema". What's
the difference between a tagging scheme, and a BETTER tagging scheme?
For example allowing flexibility to add details in the future, and
getting the balance right between world-wide standards and regional
variations. Other aspects like alignment with established standards,
both current OSM practise and internationally accepted norms, should
also be on the list. 

Too many comments, right down to the wire, are along the lines of "I
would do it this way..." or "in my country it works like this...". There
will be a period of this kind of exchange of course, but it should
followed by a convergence phase that has a concrete proposal on the
table, that may still undergo minor tweaks but no great changes of
direction. 

On 2020-05-08 18:06, Kevin Kenny wrote:

> On Fri, May 8, 2020 at 9:06 AM Phake Nick  wrote: 
> 
>> Given the proportion of opposing comment being raised, I would say "more 
>> than what have been discussed", as barely anyone raised the point during the 
>> discussion. The only two remotely relevant mentions about it during the 
>> discussion process was 1. one user who think there should be a new parents 
>> tag that cover both regular taxi and motorcycle taxi, and 2. another who 
>> incorrectly assuned "motorcycle taxi" is a combination of two different 
>> features just because the term come with a space. That clearly indicate 
>> discussion was not sufficient and that the proposal should restart the 
>> discussion process.
> 
> Our 'yes/no' voting on proposals leads to a pathological phenomenon
> that I've seen happen several times.
> 
> Someone wants to map a particular feature, and floats an idea for a
> tag 'A' on the list.
> 
> Several other people counter-propose incompatible tags 'B', 'C', 'D' -
> each with its own advantages and disadvantages.
> 
> None of these tags garners a clear majority of commenters.
> 
> Either the proponent abandons the idea, or else falls back on 'any
> tags you like', or actually bites the bullet and makes a formal
> proposal, calling the vote.
> 
> In the last case, which is already uncommon, the vote fails, because,
> if for instance, 'B' becomes the final proposal, all of the supporters
> of 'A', 'C', 'D' vote against the proposal.
> 
> Any of the other schemes would also have been rejected.
> 
> Do we need to refine the system to something like: supermajority that
> the feature should be mapped, and preference voting for how to map it?
> 
> I will concede that I've never called for a vote on any proposal,
> because after testing the waters on this list, I've taken the cowardly
> option of falling back to 'any tags you like'. Even though there
> appears to be a consensus (recall that consensus is not unanimity!)
> that things like 'access=permit' or 'protection_class=*' are small
> steps in the right direction, there was clearly enough controversy
> over the details that it became obvious to me that a vote on either
> proposal would fail.
> 
> In many cases the failures truly are ones of metaphysical
> understanding. For a taxi service, is the vehicle (car, motorcycle,
> pedicab, rickshaw) the essence, and 'for hire' a mere accident, or is
> 'passenger service for hire' the essence, and the choice of vehicle
> the accident? In typical tagging discussions like this one, I often
> see several other attributes being proposed as essential, and the
> attempt to fit the entire world into a taxonomic tree fails because
> nobody can agree which attributes are generic and which are specific.
> That inevitably comes of using Platonic tagging to approximate an
> Aristotelian understanding of the objects being tagged. Tagging will
> always be approximate. The map is not the territory.
> 
> I have little sympathy for those who cannot be troubled to comment on
> a proposal in progress and then pop up with new objections after the
> vote is called. I consider that to be obstructionist behaviour. While
> it does not necessarily negate the technical value of the objection,
> it is annoying in the extreme. It can also serve as a presumptive (not
> determinative!) measure of the technical merit; people with a deep
> technical 

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

[Joseph Eisenberg]

For the record, I responded to Marc Marc’s comment on this list, and there
was not a response back:

“ On 2/20/20, marc marc wrote:
> Le 20.02.20 à 12:45, Joseph Eisenberg a écrit :
>> Can't we have an easy to use top-level feature tag, instead of having
>> to add 3 tags like amenity=taxi + motorcar=no + motorcycle=yes to
>> define one very common, unique feature?
>
> did we need to have a top-level feature for every "unique" combination
> of the same service ?
> if yes, we need a lot of them
> amenity=foot_taxi
> amenity=moto_taxi
> amenity=sidecar_taxi
> amenity=taxi_low_local_pollution
> amenity=taxi_powered_by_renewable_energy etc.
> but all of these are part of the same type of service,
> regardless of the number of wheels and the driving force.

Not all of these actually are in real-world use.

The only 4 options in common use today are:

1) motorcar, 4 wheels, enclosed (amenity=taxi)
2) motorcycle, 2 wheels, open (amenity=motorcycle_taxi)
3) pedicabs / 3-wheel tricycles (amenity=pedicab?) - non-motorized
4) autorickshaws, 3 wheels, enclosed (could be amenity=taxi or perhaps
amenity=autorickshaw - but these are not common where I live, though I
know they are common in Thailand, India and some other countries).

There used to be human-pulled rickshaws, but these no longer exist.
They were take over by pedicabs / aka bicycle rickshaws, since those
are much more efficient.

I will consider proposing the other 2 tags later, but motorcyle taxis
are by far the most common. I would bet there are more "ojek" stands
in Indonesia than taxi
 stands in all of Europe.”

https://lists.openstreetmap.org/pipermail/tagging/2020-February/051233.html

— Joseph Eisenberg

On Fri, May 8, 2020 at 8:47 AM Marc M.  wrote:

> Hello,
>
> > If these arguments were given beforehand
>
> except memory problem, I exposed this opinion here during the RFC
> (=consider that taxi is a service independent of the propulsion
> of the engine which is a sub-tag), and I have the impression that
> the answer was "you didn't understand".
>
> I would have liked to understand why I was wrong, but I have the
> impression that this was not the goal of this rfc which is a mistake for
> the quality (and it is not the first proposal that fails for lack of
> quality either in the tag, either in the explanation of why this tag)
>
> Regards,
> Marc
>
> ___
> 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] Voting procedures (Was: Re: Tag:amenity=motorcycle_taxi not approved)

[Kevin Kenny]

On Fri, May 8, 2020 at 9:06 AM Phake Nick  wrote:
> Given the proportion of opposing comment being raised, I would say "more than 
> what have been discussed", as barely anyone raised the point during the 
> discussion. The only two remotely relevant mentions about it during the 
> discussion process was 1. one user who think there should be a new parents 
> tag that cover both regular taxi and motorcycle taxi, and 2. another who 
> incorrectly assuned "motorcycle taxi" is a combination of two different 
> features just because the term come with a space. That clearly indicate 
> discussion was not sufficient and that the proposal should restart the 
> discussion process.


Our 'yes/no' voting on proposals leads to a pathological phenomenon
that I've seen happen several times.

Someone wants to map a particular feature, and floats an idea for a
tag 'A' on the list.

Several other people counter-propose incompatible tags 'B', 'C', 'D' -
each with its own advantages and disadvantages.

None of these tags garners a clear majority of commenters.

Either the proponent abandons the idea, or else falls back on 'any
tags you like', or actually bites the bullet and makes a formal
proposal, calling the vote.

In the last case, which is already uncommon, the vote fails, because,
if for instance, 'B' becomes the final proposal, all of the supporters
of 'A', 'C', 'D' vote against the proposal.

Any of the other schemes would also have been rejected.

Do we need to refine the system to something like: supermajority that
the feature should be mapped, and preference voting for how to map it?

I will concede that I've never called for a vote on any proposal,
because after testing the waters on this list, I've taken the cowardly
option of falling back to 'any tags you like'. Even though there
appears to be a consensus (recall that consensus is not unanimity!)
that things like 'access=permit' or 'protection_class=*' are small
steps in the right direction, there was clearly enough controversy
over the details that it became obvious to me that a vote on either
proposal would fail.

In many cases the failures truly are ones of metaphysical
understanding. For a taxi service, is the vehicle (car, motorcycle,
pedicab, rickshaw) the essence, and 'for hire' a mere accident, or is
'passenger service for hire' the essence, and the choice of vehicle
the accident? In typical tagging discussions like this one, I often
see several other attributes being proposed as essential, and the
attempt to fit the entire world into a taxonomic tree fails because
nobody can agree which attributes are generic and which are specific.
That inevitably comes of using Platonic tagging to approximate an
Aristotelian understanding of the objects being tagged. Tagging will
always be approximate. The map is not the territory.

I have little sympathy for those who cannot be troubled to comment on
a proposal in progress and then pop up with new objections after the
vote is called. I consider that to be obstructionist behaviour. While
it does not necessarily negate the technical value of the objection,
it is annoying in the extreme. It can also serve as a presumptive (not
determinative!) measure of the technical merit; people with a deep
technical understanding of the issue tend to involve themselves in the
process in a timely manner.
-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] RFC ele:regional

[Greg Troxel]

On 2020-05-08 11:33, Martin Koppenhoefer wrote:

It could be useful when mapping something like a building. You could 
establish a certain elevation as local zero (e.g. the elevation of the 
ground floor) and have all other levels based on this. It is something 
that could also not be needed because of an editor who abstracts this 
(no need to store relative information if some frontend could do it), 
but I would not hinder people from experimenting with it.


I can see wanting to do this, but I think it should not use the ele= 
tag, and this really feels like it needs to be "height above ground 
floor" or something.   It really needs a scheme that is well thought 
out.   I too think it's fine if people do this, as long as they don't 
use the ele= tag, which means something else.




 > ele:regional is about admitting that you don't know

But, it asserts that the value is in some particular datum, and that you
can tell which one from knowing the area.   All of this is untrue.

maybe a particular datum can not be given, but you can be quite sure (as 
sure as you are willing to accept from a tag which pretends it is) it is 
one of those common in the area (which also will not differ a lot, 
probably).


I think we now know that the existing datums don't differ much from 
WGS84 except Belgium, and given the EVRF2007 datum, it seems clear that 
Belgium now will have that and the old one, differing by 2m.

Hence the thing we need to know, we don't, in this case.

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

Re: [Tagging] RFC ele:regional

[Greg Troxel]

Martin Koppenhoefer  writes:

> I was not aware there weren't any meaningful differences (when comparing
> some official height references to the German DHHN92 those in wikipedia.de
> with delta information all are within 1m besides Belgium DNG/TAW, which is
> -2.3).

Thanks for looking into this.  It is interesting about Belgium's datum
being so far off, but I'm sure there's some long-ago historical reason
and various datums along the way matched some earlier datum.   Perhaps
relating a nautical datum (tends to be mean low water) with a land datum
(tends to be mean sea level).

> Maybe all we should do is clarify that we are NOT expecting
> ellipsoid heights in ele tags (leaving open the possibility to add
> ele:datum tags)?

I would very much like to clarify that, and it feels like we have
consensus on that point.  I can edit the wiki page to make it clearer,
since we have had a big discussion and there is no one advocating for
ellipsoidal height in OSM.

I am ok with some text about the possible future use of ele:datum to
refer to some other datum, although I think it's preferable for people
to transform, just as it is for horizontal.

> WGS84 uses a 2 dimensional ellipsoidal coordinate system?

WGS84 at its core is a 3-dimensional cartesian system, written XYZ, with
the origin at the center of mass of the earth.  There is a transform to
latitude, longitude, and ellipsoidal height (which is just math and not
a source of errors).   All modern datums are like this.  Note that WGS84
is essentially the same thing as ITRF2014, the current international
datum from the geodesy (since of measuring the earth) community, perhaps
differing by a few mm, perhaps not.

> Wouldn't "natural" height information be based on this ellipsoid? I'm all
> fine with stating we should use geoid heights, but it doesn't necessarily
> seem to be implicit.

It does need to be made clear, as there is ample reason to think there
has been confusion about it in OSM.


ellipsoidal heights are not natural!

To understand this, one has to look to the history of surveying.  Until
the satellite era, horizontal datums and vertical datums were basically
separate.  Horizontal was done by maesured baselines and triangulation.

Vertical was done by 'leveling' which is basically a telescope with a
bubble level, so you transfer horizontally from one place to another,
and then read the difference on a rod, which is basically a giant
measuring stick.  As you move from a tide gauge across a continent, you
keep track of the accumulated differences (and loops, and then you do
least squares).

Implicit in leveling is that two places at the same height are at the
same gravitational potential, and that when you say "height is x m" you
mean that if you measured vertically (along the plumb line) it was x
until you got to where the ocean would flow to if there were a tunnel.
So height as surveyors used it, and the national/regional datums taht
this height is referenced too, have always been about gravity, and the 0
reference level has more or less been at some notion of sea level.
Typical is the mean reading of a tide gauge over 19 years (a sun/moon
cycle).

NAVD88 is referenced to a single tide gauge at Father's Point in
Rimouski, Quebec.  NGVD29 set a number of tide gauges around the
continent at 0 (and this caused distortions).

Satellite techniques just measure position and distance, and not
gravity.  Thus they in their raw form give you ellipsoidal height.  But,
this is not useful for water engineering, because lower elllipsoidal
height is not downhill.  So WGS84 defines a "geoid model" that gives the
height of an equal-gravity surface that more or less corresponds to mean
sea level, compared to the ellipsoid, and except for 1) some buggy
android programs and 2) survey-grade GPS equipment, all GPS (GNSS,
GLONASS, Galileo, BeiDou, etc.) receivers give altitudes in height above
the geoid, because aligning (at the meter level) with the previous
national height datums is important, and having water flow to lower
elevations is important.  And because nobody except national-level
surveyors has ever cared about ellipsoidal heights.

Ellipsoidal heights are basically used only as internal steps in
surveying, and nobody in the surveying world would ever think to put
them on a sign, or say to the public "the ellipsoidal height of Mount
Washington is X".  (A datasheet for surveyors would say that, but it
would also give the NAVD88 height.  A poll of 1000 surveyors asking
"should we put ellipsoidal height or NAVD88 on the sign" would result in
all 1000 of them looking at you like you were crazy and saying "NAVD88,
of course".)

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

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

[Marc M.]

Hello,

> If these arguments were given beforehand

except memory problem, I exposed this opinion here during the RFC
(=consider that taxi is a service independent of the propulsion
of the engine which is a sub-tag), and I have the impression that
the answer was "you didn't understand".

I would have liked to understand why I was wrong, but I have the
impression that this was not the goal of this rfc which is a mistake for
the quality (and it is not the first proposal that fails for lack of
quality either in the tag, either in the explanation of why this tag)

Regards,
Marc

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

Re: [Tagging] RFC ele:regional

[Martin Koppenhoefer]

Am Fr., 8. Mai 2020 um 17:16 Uhr schrieb Martin Koppenhoefer <
dieterdre...@gmail.com>:

> I was not aware there weren't any meaningful differences (when comparing
> some official height references to the German DHHN92 those in wikipedia.de
> with delta information all are within 1m besides Belgium DNG/TAW, which is
> -2.3). Maybe all we should do is clarify that we are NOT expecting
> ellipsoid heights in ele tags (leaving open the possibility to add
> ele:datum tags)? WGS84 uses a 2 dimensional ellipsoidal coordinate system?
> Wouldn't "natural" height information be based on this ellipsoid? I'm all
> fine with stating we should use geoid heights, but it doesn't necessarily
> seem to be implicit.
>


forgot the link:
https://de.wikipedia.org/wiki/H%C3%B6he_%C3%BCber_dem_Meeresspiegel#Amtliche_H%C3%B6hensysteme_ausgew%C3%A4hlter_L%C3%A4nder
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Martin Koppenhoefer]

Am Fr., 8. Mai 2020 um 14:35 Uhr schrieb Colin Smale :

> As I mentioned before, the national datums of the Netherlands and Belgium
> differ by over 2m, which for everything connected to water is very
> significant. Waterways often form the border, with bridges that cross the
> border. You cannot use a map/chart (at last for tidal waters) if you don't
> know what datum it uses.
>


it seems Belgium is an "outlier" because they use the low water level as
reference.


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

Re: [Tagging] RFC ele:regional

[Martin Koppenhoefer]

Am Fr., 8. Mai 2020 um 14:26 Uhr schrieb Greg Troxel :

> Martin Koppenhoefer  writes:
>
> > Am Fr., 8. Mai 2020 um 03:26 Uhr schrieb Greg Troxel :
> > the "definition" for "ele:local" (in German language on the English talk
> > page of the tag) seems to be about this: a local datum based on a local
> > reference (i.e. not the same as ele:regional). I am not in any way
> involved
> > in ele:local, just wanted to point it out.
>

> That does sound like what I mean by local.   I would say that heights in
> such local systems should not be entered into OSM, and I would find
> their use in anything tourist-facing to be very strange.
>


It could be useful when mapping something like a building. You could
establish a certain elevation as local zero (e.g. the elevation of the
ground floor) and have all other levels based on this. It is something that
could also not be needed because of an editor who abstracts this (no need
to store relative information if some frontend could do it), but I would
not hinder people from experimenting with it.


> > ele:regional is about admitting that you don't know
>
> But, it asserts that the value is in some particular datum, and that you
> can tell which one from knowing the area.   All of this is untrue.



maybe a particular datum can not be given, but you can be quite sure (as
sure as you are willing to accept from a tag which pretends it is) it is
one of those common in the area (which also will not differ a lot,
probably).


> As I said before, if you want to put something like
>
> information=board
> inscription="Mount Washington // Elevation 6288 Feet"
>
> that's totally fine.
>


yes, but I want the elevation to be in a semantic tag, not in
description/note/name/inscription


[not want]  any notion that HAE is reasonable in OSM
>


I am fine with this. HAE is not what casual mappers would expect (to have
the sea signficantly different than 0). But I have come to the impression
that some people would prefer HAE because it can be seen more logical when
speaking about WGS84.

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

Re: [Tagging] RFC ele:regional

[Martin Koppenhoefer]

Am Fr., 8. Mai 2020 um 14:09 Uhr schrieb Greg Troxel :

> Martin Koppenhoefer  writes:
>
> > Am Fr., 8. Mai 2020 um 03:22 Uhr schrieb Greg Troxel :
> >
> >>   3) Look up the data sheet and mark it as ele:datum=NGVD29 or
> >>   ele:datum=NAVD88 as it turns out.
> >
> > IIRR, in another mail, you wrote that the difference between these 2 is
> > less than a meter, can you confirm this, or did I understand you or
> > remember wrong?
>
> Yes,it typically is.
>
> So let me ask you again, since you keep declining to answer this:
>
>   Please give an example of an elevation of a real thing that is
>   meaningfully different in one of these "regional datums" (established
>   by a country's survey agency) compared to WGS84 height above geoid.
>   Identify the regional datum, and identify two values linked with a
>   rigorous transformation (such as national survey agencies publish).
>
>
> Thus far, you have not established that there is an actual problem that
> needs to be solved.
>


I was not aware there weren't any meaningful differences (when comparing
some official height references to the German DHHN92 those in wikipedia.de
with delta information all are within 1m besides Belgium DNG/TAW, which is
-2.3). Maybe all we should do is clarify that we are NOT expecting
ellipsoid heights in ele tags (leaving open the possibility to add
ele:datum tags)? WGS84 uses a 2 dimensional ellipsoidal coordinate system?
Wouldn't "natural" height information be based on this ellipsoid? I'm all
fine with stating we should use geoid heights, but it doesn't necessarily
seem to be implicit.

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

Re: [Tagging] RFC ele:regional

[Kevin Kenny]

My thoughts - trying to be brief, I started writing a much longer
message, but it got disorganized fast:

1. ele=* should always be orthometric.

2. Datum may be supplied with ele:datum=*, defaulting to
'ele:datum=unknown'. Within the regions of the Earth where a datum is
valid, all the datums in common use agree to within a couple of metres
of each other. (Obviously, you wouldn't want to try to extrapolate
NAVD88 onto a different continent!) Accuracy at that level is good
enough for virtually all land and aeronautical applications. How many
elevations in OSM have been determined with precise division of
levels, or with a four-hour integration time on a survey-grade GNSS
station?

3. A key like ele:tidal=* should be considered for nautical uses,
because water depths and bridge heights in tidal regions are measured
relative to tidal elevations.

4. Tidal datum may be supplied with ele:tidal:datum=*. The values for
this key may the local tidal measurements of MLLW, MLW, LMSL, DTL,
MTL, MHW, LWD, MHHW. Default in North America should likely be
'ele:tidal:datum=mllw' because that's how bathymetry is tabulated here
- referenced to local Mean Lower Low Water. Other locales will likely
have other conventions.

Rationale for separate keys: Orthometric and tidal elevations may be
some metres apart, and there would likely be considerable confusion if
the two were to use the same key. (Consider the case of the Bay of
Fundy, where the tidal range is 16 m. Geoid height and MLLW will be
eight metres apart - try to compare 'ele:*' values!

Bridge heights and water depths are not elevations, but elevation
differences, and need further discussion. (How best to call out water
depths on inland waterways, or bridge heights above them?) The Wiki
doesn't appear yet to have a lot about bathymetry.

5. Height-above-ellipsoid COULD be tabulated as ele:ellipsoidal=*
(with datum required), I suppose - but I agree with Greg Troxel that
ellipsoidal elevation has no place in OSM. It's an intermediate
calculation, which we wouldn't be discussing on the 'tagging' list at
all if it were not for the fact that the Android location API
unfortunately exposes it. It's very often tens of metres off from the
actual surface of the sea. It cannot be displayed as anything that an
ordinary user would recognize as an 'elevation' without further
computation; data consumers ought not to be required to resort to such
computations merely to produce a map for popular use, as opposed to a
navigational chart. Since API's like the one to 'vdatum' generally
allow conversion between two arbitrarily chosen reference frames, it's
no more work for the programmer of a data consumer that needs precise
data to convert from the supplied datim than from the ellipsoid.

Those wishing to determine whether a building site is above 19-year
highest high water should really consult a competent engineer, and not
OSM. (Disclaimer: I am an engineer. In a different specialty entirely.
Choice of building site in a tidal region is entirely outside my
professional competence, and it would be unethical and illegal for me
to consult on such a project.)

Those piloting a vessel had better have charts from a competent
authority. For commercial vessels, there are legal chart carriage
requirements that OSM will likely never satisfy.

"Leadsman!" "And a quarter five, over a clay bottom!"

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

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

[Andy Townsend]

On 08/05/2020 14:04, s8evq wrote:
And then some people in this very thread suggest to just ignore a 
rejection and start using it anyway. What's the use of the whole 
voting system then? 


Frankly, not much.


Why even bother writing a proposal in the first place? I'll just do 
whatever.


"I'll just do whatever" is why OSM succeeded and other approaches 
failed.  "I'll just do whatever" allows people to just add stuff to 
their neighbourhood _right now_, which they can't if they have to 
consult a committee beforehand.*


That said, it _does_ make sense to discuss what is the best way of 
tagging a particular real-world object - and it also helps if the people 
discussing it have actually seen one of those in the real world (as was 
previously suggested, I doubt some of the "no-voters" have).


In this case clearly not all the people in favour of adding a subtag to 
"amenity=taxi" could be persuaded that it was a bad idea, but since they 
are never likely to encounter such a feature in their everyday lives 
their data is not likely to matter.  OSM should be built be people who 
are familiar with the objects that they are mapping, not people guessing 
from afar.


Best Regards,

Andy

* OSM vs (say) wikimapia isn't the only example of this - wikipedia / 
nupedia is another more famous one.  Elsewhere way back in the 1980s and 
1990s the company I was working for was telling people that a 
statistical approach to fault diagnosis was a better approach to trying 
to diagnose and fix electronic stuff than an "Expert Systems" approach - 
essentially having someone coming in and trying to design some rules 
based on a few hours "sitting with Nellie".  The statistical approach 
won out, allowing you to read this message easily in your inbox, with 
the Bayesian spamfilter having moved all the undesirable stuff into 
"junk"**.


** but not in electronics, unfortunately, as no-one repairs that any 
more - it's (currently ) cheaper to buy more stuff from 
$low_wage_economy elsewhere.




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

Re: [Tagging] RFC ele:regional

[Greg Troxel]

Colin Smale  writes:

> As I mentioned before, the national datums of the Netherlands and
> Belgium differ by over 2m, which for everything connected to water is
> very significant. Waterways often form the border, with bridges that
> cross the border. You cannot use a map/chart (at last for tidal waters)
> if you don't know what datum it uses. 

Thanks.  2m is perhaps significant, and I'm surprised it's that much.  I
would suggest that if people care about that 2m, then they need to
transform to a common height reference.

I would expect that Europe is working on a new satellite-native regional
height system, similar to the new 2020 in Australia and the 2022 one in
North  America, that will basically align heights.

> In OSM we often leave out "obvious" annotations, giving rise to a kind
> of "default" (such as maxspeed in km/h). But there is always a way of
> making it explicit, for those who feel the need. In this case we may
> agree to define "ele" as relative to the "local datum" or WGS84 or
> whatever, but we must always provide a system for making that explicit,
> and (preferably) a means to derive the intended basis for values that
> are not explicitly qualified.

So what do you think about what I've been saying:

  ele is assumed to be in, and should be represented in, WGS84 height
  above geoid (as the international norm, aligned with OSM's horizontal
  datum)

  ele:datum=unknown represents that the mapper doesn't know what datum
  the number they put in ele is expressed in

  ele:datum=EPSG:5703 (as an example for NAVD88), when the mapper really
  does know the datum, and doesn't want to transform to WGS84


I assume you are referring to:

  https://epsg.io/5709

  https://epsg.io/5710

and it seems that the European more modern height datum has already
happened:

  https://epsg.io/5730 (superceded)
  https://epsg.io/5621 (European Vertical Reference Frame 2007)

This looks useful:

  http://euref.eu/documentation/Tutorial2015/t-04-01-Liebsch.pdf

And this all makes me think that an elevation without a datum cannot be
reliably used at the better than 2m level.

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

[Tagging] Feature Proposal - RFC - electric_bicycle and speed_pedelec

[Jan Michel]

Dear all,
some time ago I started the proposal to define tags for several light 
electric vehicles. It turned out to be difficult to come up with names 
for keys that unambiguously describes all these vehicles.


During discussion the idea came up to separate the proposal in two 
parts. This first proposal covers the two keys electric_bicycle and 
speed_pedelec for the two types of bicycles with electric motors that 
are recognized by law in several European countries.


The full proposal can be found here:
https://wiki.openstreetmap.org/wiki/Proposed_features/ElectricBicycles

I would like to ask you for further comments and aim for putting this 
proposal up for voting in two weeks from now.


Jan


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

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

[s8evq]

On Fri, 8 May 2020 08:43:27 -0400, Jarek Piórkowski  wrote:
> On Fri, 8 May 2020 at 02:27, s8evq  wrote:
> >
> > Of the 8 opposing votes, only 1 has made the effort to comment beforehand 
> > on the talk page. The 7 others just came in and voted no, without any 
> > discussion beforehand. That doesn't seem correct. It should not be possible 
> > to be suddenly faced with this fait accompli.
> 
> Hm, I'm not seeing that requirement on
> https://wiki.openstreetmap.org/wiki/Proposal_process#Voting
> 
> In fact all the opposing votes made comments as to why they oppose it.
> You may disagree with their reasons but that doesn't make them
> invalid.

Sure. You're totally right.
 
> How much discussion do you think should be necessary before voting "I
> oppose, because I think using sub-tags is better"? If someone thinks
> that, they think that. A discussion would just print the arguments
> back and forth.

If these arguments were given beforehand, perhaps the proposal could have 
changed, or opinions could have been changed?

I hardly have any experience in proposals and the voting system. But I've seen 
3 proposal so far, where I know the author doesn't want to bring it to vote, 
fearing the proposal would be rejected. The rationale behind it: status 
Rejected is worse than having the proposal in the "Draft" state forever.

And then some people in this very thread suggest to just ignore a rejection and 
start using it anyway. What's the use of the whole voting system then? Why even 
bother writing a proposal in the first place? I'll just do whatever.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Phake Nick]

On 2020-05-08 Fri 20:45, Jarek Piórkowski  wrote:

>
> How much discussion do you think should be necessary before voting "I
> oppose, because I think using sub-tags is better"? If someone thinks
> that, they think that. A discussion would just print the arguments
> back and forth.
>

Given the proportion of opposing comment being raised, I would say "more
than what have been discussed", as barely anyone raised the point during
the discussion. The only two remotely relevant mentions about it during the
discussion process was 1. one user who think there should be a new parents
tag that cover both regular taxi and motorcycle taxi, and 2. another who
incorrectly assuned "motorcycle taxi" is a combination of two different
features just because the term come with a space. That clearly indicate
discussion was not sufficient and that the proposal should restart the
discussion process.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Jarek Piórkowski]

On Fri, 8 May 2020 at 02:27, s8evq  wrote:
>
> Of the 8 opposing votes, only 1 has made the effort to comment beforehand on 
> the talk page. The 7 others just came in and voted no, without any discussion 
> beforehand. That doesn't seem correct. It should not be possible to be 
> suddenly faced with this fait accompli.

Hm, I'm not seeing that requirement on
https://wiki.openstreetmap.org/wiki/Proposal_process#Voting

In fact all the opposing votes made comments as to why they oppose it.
You may disagree with their reasons but that doesn't make them
invalid.

How much discussion do you think should be necessary before voting "I
oppose, because I think using sub-tags is better"? If someone thinks
that, they think that. A discussion would just print the arguments
back and forth.

--Jarek

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

Re: [Tagging] RFC ele:regional

[Colin Smale]

On 2020-05-08 14:09, Greg Troxel wrote:

> Martin Koppenhoefer  writes:
> 
> Am Fr., 8. Mai 2020 um 03:22 Uhr schrieb Greg Troxel :
> 
> 3) Look up the data sheet and mark it as ele:datum=NGVD29 or
> ele:datum=NAVD88 as it turns out. 
> IIRR, in another mail, you wrote that the difference between these 2 is
> less than a meter, can you confirm this, or did I understand you or
> remember wrong?

Yes,it typically is.

So let me ask you again, since you keep declining to answer this:

  Please give an example of an elevation of a real thing that is
  meaningfully different in one of these "regional datums" (established
  by a country's survey agency) compared to WGS84 height above geoid.
  Identify the regional datum, and identify two values linked with a
  rigorous transformation (such as national survey agencies publish). 

As I mentioned before, the national datums of the Netherlands and
Belgium differ by over 2m, which for everything connected to water is
very significant. Waterways often form the border, with bridges that
cross the border. You cannot use a map/chart (at last for tidal waters)
if you don't know what datum it uses. 

In OSM we often leave out "obvious" annotations, giving rise to a kind
of "default" (such as maxspeed in km/h). But there is always a way of
making it explicit, for those who feel the need. In this case we may
agree to define "ele" as relative to the "local datum" or WGS84 or
whatever, but we must always provide a system for making that explicit,
and (preferably) a means to derive the intended basis for values that
are not explicitly qualified.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Greg Troxel]

Martin Koppenhoefer  writes:

> Am Fr., 8. Mai 2020 um 03:26 Uhr schrieb Greg Troxel :
>
>> 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.
>
> the "definition" for "ele:local" (in German language on the English talk
> page of the tag) seems to be about this: a local datum based on a local
> reference (i.e. not the same as ele:regional). I am not in any way involved
> in ele:local, just wanted to point it out.

That does sound like what I mean by local.   I would say that heights in
such local systems should not be entered into OSM, and I would find
their use in anything tourist-facing to be very strange.

>> 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*.

> ele:regional is about admitting that you don't know

But, it asserts that the value is in some particular datum, and that you
can tell which one from knowing the area.   All of this is untrue.   In
contrast "ele:datum=unknown" is a crisp statement that you don't know
the datum, no more and no less.

As for guessing about regional, data consumers can guess too, but
encoding a guess in a vague way seems really unhelpful.

>> I would also ask: if this is reasonable for height, why isn't it also
>> reasonable for horizontal coordinates?
>
> because we typically have much more horizontal positional information with
> which we can compare. Errors in horizontal position are more evident
> because the relation to the surrounding (alignment, reference, angles,
> axis, proportions, etc.) won't fit. Up to a certain degree (e.g. when other
> information around is missing, and when accurate positional information is
> missing) we also do have and tolerate very approximate horizontal spatial
> information.

I'm talking about things like NAD83 vs WGS84, which is basically a 1m
difference around me.   We either transform or accept the fuzz, but it
would be crazy to label points as being in NAD83.  That's really my point.

> Greg, you wrote we should convert locally signed regional datum elevation
> information to the WGS84:geoid reference. In other context, we do not do
> unit conversions, for example we do not convert speed limits in mph to kph,
> nor do we convert weight information or maxheight information.

This isn't really about units.  Datum is about point of reference, and
the "don't convert" argument applies equally well to horizontal datums.

As I said before, if you want to put something like

information=board
inscription="Mount Washington // Elevation 6288 Feet"

that's totally fine.

> I could imagine doing a "reasonable" conversion (precision the same as
> expected from the original value) if there would be support from the
> tools (e.g.  mobile editors, iD or Josm), but otherwise I would not
> expect the vast majority of mappers doing this conversion at all in
> case of a value read off a sign, and even if they did I would expect
> this conversion step to be error prone (e.g. the mapper won't know
> which is the original datum).

I agree that casual mappers doing conversions is likely too much.

However, I don't see the harm in just entering a signed elevation in
ele= and not worrying about it, or also adding ele:datum=unknown to
represent that the data is not known to have been handled accurately.

My primary objection is not about having a tag to say the datum is
unknown.  What I really don't like is:

  the notion that it is a desired state to have elevations in other than
  the standard OSM datum, and that all data consumers should have to deal
  with this

  any notion that HAE is reasonable in OSM

  marking something as "regional" as if that is clear, when the reality
  is "unknown".  (If I come across a sign in the US with elevation, even
  I, as an elevation nerd, have no idea if it's NGVD29 or NAVD88, or if
  it's just plain bogus, with the number being copied from someone else
  who didn't really know either.)


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

Re: [Tagging] RFC ele:regional

[Greg Troxel]

Martin Koppenhoefer  writes:

> Am Fr., 8. Mai 2020 um 03:22 Uhr schrieb Greg Troxel :
>
>>   3) Look up the data sheet and mark it as ele:datum=NGVD29 or
>>   ele:datum=NAVD88 as it turns out.
>
> IIRR, in another mail, you wrote that the difference between these 2 is
> less than a meter, can you confirm this, or did I understand you or
> remember wrong?

Yes,it typically is.

So let me ask you again, since you keep declining to answer this:

  Please give an example of an elevation of a real thing that is
  meaningfully different in one of these "regional datums" (established
  by a country's survey agency) compared to WGS84 height above geoid.
  Identify the regional datum, and identify two values linked with a
  rigorous transformation (such as national survey agencies publish).


Thus far, you have not established that there is an actual problem that
needs to be solved.

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

Re: [Tagging] RFC ele:regional

[Greg Troxel]

Peter Elderson  writes:

> Why not use a datum:value pair?
>
> ele=[datum:]value
>
> datum: is optional. If you don't know, just leave it out. Data users can
> assume locally signed or known.

Becuase, as I have said many times and no one seems to be listening, in
OSM we have said that we use WGS84, and thus all elevations must be in
WGS84 (height above geoid), the same way that all horizontal coordinates
must also be in WGS84.

The very notion of putting in elevations in other datums is very
irregular, and it's a path to madness where data in OSM is in varying
reference systems and the data consumer then has to deal and transform.
It seems really obvious that the data should be in the standard OSM
datum and therefore correct.

This entire situation is really blowing up a situation of people who
want to simultaneously not be rigorous, by entering elevations that they
don't have any basis for trusting or knowing the datum, and to be sort
of appearing to be rigorous by labeling them in a way that isn't sound.

I think it's completely fair to have an extra tag that indicates the
elevation value is low quality, so that those mappers that know this and
those data consumers that know this can express and understand this.
But it's also very important for the simple case to remain simple.

Adding datum: into elevation means that every data consumer has to adapt
to the new rule, while ele:datum= does not - those that ignore it
are not harmed.


Other than your proposal making it difficult for data consumers, it
seems equivalent to ele:datum=.

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

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

[Warin]

On 7/5/20 1:54 am, Philip Barnes wrote:

On Wed, 2020-05-06 at 14:03 +0200, Martin Koppenhoefer wrote:



sent from a phone


On 6. May 2020, at 13:14, lukas-...@web.de wrote:

In the wiki I found bell_tower=* (but without a carillon-specific 
value) and I think a carillon does not have to be a bell_tower at 
all, so these are two different things.



I am aware of this instance:
https://www.openstreetmap.org/way/37410673


Also Loughborough Carillon https://www.openstreetmap.org/way/156539835

To which I have added a few missing tags and bell_tower=carillon, it 
doesn't seem far off the mark considering other uses in 
https://taginfo.openstreetmap.org/keys/bell_tower#values




https://www.openstreetmap.org/way/8016458  Canberra Australia.

Tagged:

building=yes
height=50
man_made=tower
name=National Carillon
start_date=1970
tourism=attraction
tower:construction=concrete
tower:type=bell_tower
wikidata=Q494865

Added tags:

website=https://www.nca.gov.au/national-carillon

bell_tower=carillon


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

Re: [Tagging] RFC ele:regional

[Martin Koppenhoefer]

Am Fr., 8. Mai 2020 um 03:22 Uhr schrieb Greg Troxel :

>   3) Look up the data sheet and mark it as ele:datum=NGVD29 or
>   ele:datum=NAVD88 as it turns out.
>


IIRR, in another mail, you wrote that the difference between these 2 is
less than a meter, can you confirm this, or did I understand you or
remember wrong?

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

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

[Marc M.]

Le 07.05.20 à 20:49, Joseph Eisenberg a écrit :
> Opposing voters preferred using amenity=taxi + motorcycle=yes

> So, what's the next step? 

propose that :) (maybe with motorcycle=only variant if needed)
it allow to have "zone when you request to be transported by individual
transport" with several transport mode depending the local usage.

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

Re: [Tagging] RFC ele:regional

[Martin Koppenhoefer]

Am Fr., 8. Mai 2020 um 03:26 Uhr schrieb Greg Troxel :

> 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.
>


the "definition" for "ele:local" (in German language on the English talk
page of the tag) seems to be about this: a local datum based on a local
reference (i.e. not the same as ele:regional). I am not in any way involved
in ele:local, just wanted to point it out.




> 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*.
>


ele:regional is about admitting that you don't know



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



because we typically have much more horizontal positional information with
which we can compare. Errors in horizontal position are more evident
because the relation to the surrounding (alignment, reference, angles,
axis, proportions, etc.) won't fit. Up to a certain degree (e.g. when other
information around is missing, and when accurate positional information is
missing) we also do have and tolerate very approximate horizontal spatial
information.


Greg, you wrote we should convert locally signed regional datum elevation
information to the WGS84:geoid reference. In other context, we do not do
unit conversions, for example we do not convert speed limits in mph to kph,
nor do we convert weight information or maxheight information. I could
imagine doing a "reasonable" conversion (precision the same as expected
from the original value) if there would be support from the tools (e.g.
mobile editors, iD or Josm), but otherwise I would not expect the vast
majority of mappers doing this conversion at all in case of a value read
off a sign, and even if they did I would expect this conversion step to be
error prone (e.g. the mapper won't know which is the original datum).

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

Re: [Tagging] Feature Proposal - Voting - traffic_signals=crossing_only

[Lukas-458]

Hi,

at the moment, there are not so many people who looked at my proposal for traffic_signals=crossing_only :

https://wiki.openstreetmap.org/wiki/Proposed_features/traffic_signals%3Dcrossing_only

 

I would look forward to some more people comment or vote on my proposal which has the aim to distingiush those highway=traffic_signals on "straight road" which control only a crossing from other types of traffic signals.

 

Current tagging (highway=crossing/crossing=traffic_signals, sometimes + button_operated=yes), does not allow to distinguish them clearly.

It carries potentially information because the traffic lights I mentioned have other circuits and are often activated on-demand only.

 

If questions comment either here or maybe rather on the discussion page.

 

--Lukas


Gesendet: Freitag, 01. Mai 2020 um 14:05 Uhr
Von: lukas-...@web.de
An: tagging@openstreetmap.org
Betreff: [Tagging] Feature Proposal - Voting - traffic_signals=crossing_only




Hello to everyone,

Voting has opened for the proposal of traffic_signals=crossing_only – see the proposal page here: https://wiki.openstreetmap.org/wiki/Proposed_features/traffic_signals%3Dcrossing_only

 

(please note the old name was traffic_signals=crossing_on_demand, but I changed that because the focus is not on the „on demand“, but on the „traffic lights for only a crossing“).

 

It has been discussed about on the mailing list at 2020-04-13 and a few days after.

 

The proposal's purpose:

traffic_signals=crossing_only marks those highway=traffic_signals which do only control a crossing

 

Why?

It's interesting for routers concerning penalty times (much lower on those points than for a junction) and at the moment, there is no real way to mark that:

 

highway=traffic_signals + crossing=traffic_signals is used together on the same node, but NOT only in those cases where there is a „crossing-only“ traffic light. It's also used on junctions. We discussed that it would be difficult to change that, because highway=traffic_signals + crossing=traffic_signals is an accepted tagging and can be used together also when the exact locations of the crossings - at a junction - are not known and in some other cases.

 

highway=traffic_signals + crossing=traffic_signals + button_operated=yes can be used, but with looking just at button_operated=yes, this does not mean that there is only a crossing and not a traffic junction. Crossings at junctions can have buttons for pedestrians, too, example: https://www.openstreetmap.org/node/3070180267

So the solution would be to add another under-category for highway=traffic_signals, as traffic_signals=* does it already.

--Lukas


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




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

Re: [Tagging] RFC ele:regional

[Peter Elderson]

Why not use a datum:value pair?

ele=[datum:]value

datum: is optional. If you don't know, just leave it out. Data users can
assume locally signed or known.

Thus, the spontaneous mapper and the elevation experts are served. Mapper
communities can establish regional preferences. Quality checking can be
applied.

As usual with measures, unit may follow the value, where m is default.

Best, Peter Elderson


Op vr 8 mei 2020 om 10:04 schreef Marc Gemis :

> >   2) Use ele:datum=unknown as a clue that the data is not that high
> >   quality.
>
> or make that the default, so that when there is no ele:datum data
> consumers have to consider it as unknown .
> Any ordinary mapper, including myself, just wants to put the number
> they see on a sign into the database. Why do they need to add
> ele:datum=unknown?
> Let people that do know the datum (a much smaller group I assume) add
> ele:datum explicitly.
>
> regards
>
> 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] RFC ele:regional

[Marc Gemis]

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

or make that the default, so that when there is no ele:datum data
consumers have to consider it as unknown .
Any ordinary mapper, including myself, just wants to put the number
they see on a sign into the database. Why do they need to add
ele:datum=unknown?
Let people that do know the datum (a much smaller group I assume) add
ele:datum explicitly.

regards

m.

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

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

[Martin Koppenhoefer]

sent from a phone

> On 8. May 2020, at 00:43, Paul Norman via Tagging  
> wrote:
> 
> As a next step, I'd map motorcycle taxis as amenity=motorcycle_taxi. Vote 
> with your mapping.


+1, most people who voted no supposedly never saw a motorcycle taxi in their 
life...

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

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

[Phake Nick]

Since the wiki say,

> Rejected features may be resubmitted, modified, and moved back to the RFC
process.

, and given most reason appeared on the voting page, I would say the
correct action right now is to improve the reasons listed in the paragraph
on why alternative tagging are not available, and then enter discussion
phase again to see if such similar opinion still surface, and then head
into the voting phase again.

在 2020年5月8日週五 02:51，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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[s8evq]

Of the 8 opposing votes, only 1 has made the effort to comment beforehand on 
the talk page. The 7 others just came in and voted no, without any discussion 
beforehand. That doesn't seem correct. It should not be possible to be suddenly 
faced with this fait accompli. 

On Thu, 7 May 2020 11:49:43 -0700, Joseph Eisenberg 
 wrote:

> 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