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

2020-05-09 Thread Phake Nick
在 2020年5月10日週日 07:08,François Lacombe  寫道:

>
> Le sam. 9 mai 2020 à 19:20, Phake Nick  a écrit :
>
>>
>> What you said doesn't make sense.
>> The existence of a space within the word doesn't inherently make them
>> separateable.
>> Like for the tag amenity=charging_station, do you think the space mean ot
>> make sense to change the tagging scheme into amenity=station +
>> station=charging ?
>>
>
> It depends on what your definition of station is.
>

As you said, it depends, you can't just break down everything this way just
because they're compounded word.

>
>
>>
>> Your interpretation on public transit service is incorrect.
>> When you board a plane from London to Paris, you didn't fly to Paris
>> because they told us they would fly to Paris. You're going to Paris because
>> you have expressed interest in going to Paris. Same with rideshareing or
>> other rented mobility services.
>>
>
> You're lucky enough to take on planes you define your own destination
> first.
> "Going to Paris" doesn't mean the same for a taxicab and for a plane.
> Even in ridesharing, destination is given by passengers and driver doesn't
> know it before meeting them (face to face or with an app, same actually).
> You don't define the destination reached by plane, by train or by bus.
> This is the difference I make.
>

You can book a flight ticket through travel agents, ticketing websites,
carrier hotline, or airport counter. You don't need luck to get a flight to
Paris.


>
>>
>>
>>> We agree on that particular point.
>>> Neverthess that doesn't make a second value of amentiy legit.
>>> OSM would only have one key grouping all possible values if it was
>>> relevant.
>>>
>>
>> I am not aware of such requirement on value ever existing in OSM.
>>
>
> This was actual irony.
>

I hope you realize the irony here is that you pulled some rule out of thin
air that didn't exists in OSM.


> Le sam. 9 mai 2020 à 20:45, Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> a écrit :
>
>>
>> Neverthess that doesn't make a second value of amentiy legit.
>>
>> Why?
>>
>
> Both have taxi service in common but the vehicle is different (and implies
> really different experiences indeed)
> amenity=* represents the taxi service and I find relevant to describe the
> different vehicle in another key.
>

As have already been explained they are different types of services


>
>> OSM would only have one key grouping all possible values if it was
>> relevant.
>>
>> Why?
>>
>
> If you accept to merge similarities and differences in values you don't
> need different keys.
> Who need operator key for instance?
> amenity=taxi_with_cars_operated_by_Acompany
> amenity=taxi_with_motorbikes_operated_by_anotherCompany
> Hey it's way different things, Acompany is really bad compared to
> anotherCompany.
>

That's a ridiculous comparison, that's like saying we shouldn't have
different tag for office building versus residential building because
people night expand it to make tags like microsoft_office_building.


> Finally, Paul, I find your point about taxonomy thinking interesting and
> will try to develop it a bit in future.
> Get me well, I don't intend to ban anyone from anything.
> Query tools are really important to consume data and my point wasn't to
> downgrade tagging readability in general (nor to encourage K9842=V2179).
> To me tourists and query tools users can only be the same persons at
> different time. I've never used overpass to locate myself in any train
> station, that's all.
>
> In proposal, arguing amenity=taxi/amenity=motorbike_taxi will better
> prevent errors than amenity=taxi + vehicle=* doesn't convince me : mappers
> are always able to confuse two services, whatever the tagging they use can
> be.
>
> That was my 2 cts, good night
>

So you're saying people would be confused by a motorcycle taxi and think
they're a 4-wheeled taxi, or they might look at a 4-wheeled taxi and think
it is a motorcycle taxi?

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


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

2020-05-09 Thread Jarek Piórkowski
On Sat, 9 May 2020 at 19:33, Paul Allen  wrote:
> On Sun, 10 May 2020 at 00:25, Martin Koppenhoefer  
> wrote:
>> imagine you are ordering a taxi for yourself and 2 colleagues to the airport 
>> and instead of a taxi (cab) they send you 3 taxi moto. Would that be equally 
>> ok, wouldn’t it matter, taxi is taxi?
>
> It would matter a hell of a lot if one or more of use were carrying an item of
> heavy luggage.

In that case you should probably order a taxi for 3 people and heavy
luggage. What if they sent a Matiz as a taxi?
https://www.flickr.com/photos/takeshicollection/4329846559

For that matter, many sedans won't fit 3 guests with 3
airplane-checked-luggage size suitcases.

There's always amenity=baggage_taxi ;)

--Jarek

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


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

2020-05-09 Thread Paul Allen
On Sun, 10 May 2020 at 00:25, Martin Koppenhoefer 
wrote:

>
> imagine you are ordering a taxi for yourself and 2 colleagues to the
> airport and instead of a taxi (cab) they send you 3 taxi moto. Would that
> be equally ok, wouldn’t it matter, taxi is taxi?
>

It would matter a hell of a lot if one or more of use were carrying an item
of
heavy luggage.  It would matter a hell of a lot if it was the monsoon
season.
It would matter a hell of a lot if we were wearing light, skimpy clothing
rather
than motorbike leathers and the driver was a bit of a nutter.

It might matter if they sent an "air taxi" at a ridiculous price.

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


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

2020-05-09 Thread Paul Allen
On Sun, 10 May 2020 at 00:08, François Lacombe 
wrote:


> Finally, Paul, I find your point about taxonomy thinking interesting and
> will try to develop it a bit in future.
>

I'm starting to wonder if the taxonomy adopted is influenced by the language
of the person doing the classifying.  If people speaking one language are
more likely to see 4-wheel and 2-wheel taxis as variants than people
speaking
a different language.  If true, I have absolutely no idea how this helps
the list
reach consensus about anything. :)

Query tools are really important to consume data and my point wasn't to
> downgrade tagging readability in general (nor to encourage K9842=V2179).
>

The taxonomy adopted by the person making the query will influence how
useful that person finds the results.

To me tourists and query tools users can only be the same persons at
> different time. I've never used overpass to locate myself in any train
> station, that's all.
>

I could see myself using it in a largem strange city to find the nearest
taxi rank to
where i am.  I could see the local government of that city embedding an
overpass
query in uMap to create a map showing all taxi ranks in the city.

>
> In proposal, arguing amenity=taxi/amenity=motorbike_taxi will better
> prevent errors than amenity=taxi + vehicle=* doesn't convince me : mappers
> are always able to confuse two services, whatever the tagging they use can
> be.
>

Thinking about it, there's another factor: if various cartos will render an
ojek
rank differently from a taxi rank.  If you use amenity=taxi + vehicle=* you
guarantee that any carto which renders amenity=taxi will render ojek ranks
incorrectly at first, and perhaps incorrectly for all time (if they decide
they're
going to ignore the vehicle tag).  If you use amenity=motorbike_taxi you
guarantee that all cartos will initially not render it at all, but that
eventually
some of them will (but you have no guarantee they won't then render it
identically to amenity=taxi).

I can't decide which of those two alternatives I prefer.

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


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

2020-05-09 Thread Martin Koppenhoefer


sent from a phone

> On 9. May 2020, at 22:50, Florimond Berthoux  
> wrote:
> 
> Yeah, that's the point...
> 
> Keep it simple.
> You know taxi key ? You know motorcycle key ? Yeah, you can contribute 
> without checking yet another wiki tag page.
> 
> By the way, this how a taxi moto looks like in Paris
> https://www.city-bird.com/wp-content/uploads/2018/08/DSC3972_R1_optimise_bas.jpg


imagine you are ordering a taxi for yourself and 2 colleagues to the airport 
and instead of a taxi (cab) they send you 3 taxi moto. Would that be equally 
ok, wouldn’t it matter, taxi is taxi?

Cheers Martin 


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


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

2020-05-09 Thread François Lacombe
Le sam. 9 mai 2020 à 19:20, Phake Nick  a écrit :

>
> What you said doesn't make sense.
> The existence of a space within the word doesn't inherently make them
> separateable.
> Like for the tag amenity=charging_station, do you think the space mean ot
> make sense to change the tagging scheme into amenity=station +
> station=charging ?
>

It depends on what your definition of station is.


>
> Your interpretation on public transit service is incorrect.
> When you board a plane from London to Paris, you didn't fly to Paris
> because they told us they would fly to Paris. You're going to Paris because
> you have expressed interest in going to Paris. Same with rideshareing or
> other rented mobility services.
>

You're lucky enough to take on planes you define your own destination first.
"Going to Paris" doesn't mean the same for a taxicab and for a plane.
Even in ridesharing, destination is given by passengers and driver doesn't
know it before meeting them (face to face or with an app, same actually).
You don't define the destination reached by plane, by train or by bus. This
is the difference I make.


>
>
>> We agree on that particular point.
>> Neverthess that doesn't make a second value of amentiy legit.
>> OSM would only have one key grouping all possible values if it was
>> relevant.
>>
>
> I am not aware of such requirement on value ever existing in OSM.
>

This was actual irony.

Le sam. 9 mai 2020 à 20:45, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> a écrit :

>
> Neverthess that doesn't make a second value of amentiy legit.
>
> Why?
>

Both have taxi service in common but the vehicle is different (and implies
really different experiences indeed)
amenity=* represents the taxi service and I find relevant to describe the
different vehicle in another key.


> OSM would only have one key grouping all possible values if it was
> relevant.
>
> Why?
>

If you accept to merge similarities and differences in values you don't
need different keys.
Who need operator key for instance?
amenity=taxi_with_cars_operated_by_Acompany
amenity=taxi_with_motorbikes_operated_by_anotherCompany
Hey it's way different things, Acompany is really bad compared to
anotherCompany.

Finally, Paul, I find your point about taxonomy thinking interesting and
will try to develop it a bit in future.
Get me well, I don't intend to ban anyone from anything.
Query tools are really important to consume data and my point wasn't to
downgrade tagging readability in general (nor to encourage K9842=V2179).
To me tourists and query tools users can only be the same persons at
different time. I've never used overpass to locate myself in any train
station, that's all.

In proposal, arguing amenity=taxi/amenity=motorbike_taxi will better
prevent errors than amenity=taxi + vehicle=* doesn't convince me : mappers
are always able to confuse two services, whatever the tagging they use can
be.

That was my 2 cts, good night

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


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

2020-05-09 Thread Phake Nick
Key chaining is the more complex form of representation, especially when
there are no obvious relationship between different types of objects being
represented.

在 2020年5月10日週日 04:50,Florimond Berthoux  寫道:

> Yeah, that's the point...
>
> Keep it simple.
> You know taxi key ? You know motorcycle key ? Yeah, you can contribute
> without checking yet another wiki tag page.
>
> By the way, this how a taxi moto looks like in Paris
>
> https://www.city-bird.com/wp-content/uploads/2018/08/DSC3972_R1_optimise_bas.jpg
>
> Le ven. 8 mai 2020 à 23:32, Joseph Eisenberg 
> a écrit :
>
>> 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
>>
>
>
> --
> Florimond Berthoux
> ___
> 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

2020-05-09 Thread Florimond Berthoux
Yeah, that's the point...

Keep it simple.
You know taxi key ? You know motorcycle key ? Yeah, you can contribute
without checking yet another wiki tag page.

By the way, this how a taxi moto looks like in Paris
https://www.city-bird.com/wp-content/uploads/2018/08/DSC3972_R1_optimise_bas.jpg

Le ven. 8 mai 2020 à 23:32, Joseph Eisenberg  a
écrit :

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


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


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

2020-05-09 Thread Mateusz Konieczny via Tagging



May 9, 2020, 14:33 by fl.infosrese...@gmail.com:

> Le sam. 9 mai 2020 à 02:29, Paul Allen <> pla16...@gmail.com> > a écrit :
>  
>
>> Motorcycle taxi is different from 4-wheeled taxi because they provide a 
>> different experience with different speed, charge different fare, have 
>> different level of convenience, can access different area, and various other 
>> factors.
>>
>
> We agree on that particular point.
> Neverthess that doesn't make a second value of amentiy legit.
>
Why?

> OSM would only have one key grouping all possible values if it was relevant.
>
Why?

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


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

2020-05-09 Thread Phake Nick
在 2020年5月9日週六 20:35,François Lacombe  寫道:

> Hi Paul,
>
> Le sam. 9 mai 2020 à 02:29, Paul Allen  a écrit :
>
>>
>> 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.
>>
>
> Tourists aren't supposed to refer to tags to know which kind of taxi
> service they can use.
> Renders, tools, apps are here to ease this for them. Are you aware of
> Google Maps data model when browsing it?
> Even local mappers can use tools focused on a specific topic which makes
> tagging less important to master to contribute.
>

> Nevertheless, we're are discussing about things like amenity=taxi +
> vehicle=* which doesn't sound that complex.
> Even common language using two words "motorcycle" and "taxi" could mean we
> have something to do with several keys.
>

What you said doesn't make sense.
The existence of a space within the word doesn't inherently make them
separateable.
Like for the tag amenity=charging_station, do you think the space mean ot
make sense to change the tagging scheme into amenity=station +
station=charging ?



> Le sam. 9 mai 2020 à 06:38, Shawn K. Quinn  a
> écrit :
>
>> 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.
>>
>
> Beware of :type disadvantages.
> Things like vehicle=* sounds better (or another word referring to vehicle
> used).
>
> Default to motorcar can lead to mistakes for consumers.
> It's more valuable to consider vehicle unknown if absent (and encourage
> mappers to explicitly define it)
>

And that make the tag valueless as that cannot actually indicate what exact
type of place the tag was indicating.


> Le sam. 9 mai 2020 à 08:01, Phake Nick  a écrit :
>
>>
>> "I pay a driver to take me where I want to with his vehicle" is something
>> that would also be true for any other public transit vehicles.
>>
>
> I respectably disagree regarding public transit: you're not asking them to
> take you where YOU want but if they actually go where THEY told us they
> will.
> Every word counts here.
>

Your interpretation on public transit service is incorrect.
When you board a plane from London to Paris, you didn't fly to Paris
because they told us they would fly to Paris. You're going to Paris because
you have expressed interest in going to Paris. Same with rideshareing or
other rented mobility services.


>
>> Motorcycle taxi is different from 4-wheeled taxi because they provide a
>> different experience with different speed, charge different fare, have
>> different level of convenience, can access different area, and various
>> other factors.
>>
>
> We agree on that particular point.
> Neverthess that doesn't make a second value of amentiy legit.
> OSM would only have one key grouping all possible values if it was
> relevant.
>

I am not aware of such requirement on value ever existing in OSM.


>
>
>> In addition to them being different kind of services, for the purpose of
>> openstreetmap tagging, it's better to remember that a motorcycle taxi stand
>> would look quite different from a taxi stand, use the streetspace
>> differently, and thus mixing them together would also hurt any downstream
>> data user who might wish to understand the situation of 4-wheeled taxi
>> penetration in certain geographical area due to conflating the data with
>> others that aren't of the same type. They're often regulated by different
>> laws and face different operational restrictions also.
>>
>
> That could eventually be a point if all those differences were known
> precisely and described.
> There are many many kind of public transit stations but we're still
> calling them stations and platforms.
>

That would be a big departure from the way how these features are currently
tagged within OSM.

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


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

2020-05-09 Thread Paul Allen
On Sat, 9 May 2020 at 13:35, François Lacombe 
wrote:

>
> Tourists aren't supposed to refer to tags to know which kind of taxi
> service they can use.
>

But the query tool is there.  Or are you proposing banning tourists from
using it?
That would be possible - login required to use the query tool.  Or login
required to
use the map.  But the map is only primarily there for mappers, other uses
are
encouraged.

And before the choir sings a chorus of "standard carto is for mappers, not
users"
and "different renderers may do things differently" they're right.
Different renderers
may also expose all the gory details of raw tags without prettying them up.

Renders, tools, apps are here to ease this for them. Are you aware of
> Google Maps data model when browsing it?
>

I'm aware of some of its limitations.  Otherwise I wouldn't be here. :)

Even local mappers can use tools focused on a specific topic which makes
> tagging less important to master to contribute.
>

A lot of things can be hidden by renderers and editor presets.  But the
query tool
is still there.  As is overpass turbo.  And there are a lot of things I
need to add as
raw tags because the editor I use most has decided that things I add
frequently
to certain types of POI aren't things that anybody wants to add.  It makes
life
easier for newbies who may not be interested in nuances but it makes life
harder
for experienced mappers who do.  It is even harder when I have to keep
looking
things up in the documentation because the tagging isn't very meaningful.

Unless there are good reasons not to for specific cases, we should strive to
make the semantics of tags meaningful.  It would be possible to have tags
like K9842=V2179 provided ALL renderer query tools, editors, overpass
turboi,
etc. did the appropriate translations.  It would be a real pain when you
needed
to add a raw tag, but it would be feasible.  But we'd never get all tools to
do the translations, so making things meaningful is necessary.  We just
can't agree on what is meaningful because we're have different mental
models.

>
> Nevertheless, we're are discussing about things like amenity=taxi +
> vehicle=* which doesn't sound that complex.
>

Nope, it doesn't sound that complex.  Yet the discussion goes on and on,
because
some people dislike amenity=taxi + vehicle=* and prefer amenity=*.

Even common language using two words "motorcycle" and "taxi" could mean we
> have something to do with several keys.
>

It could mean that if everyone had the same mental model you do.  We're not
all
strict taxonomists.  Or even strict taxi-ists.  As somebody else pointed
out, if
vehicles with a driver for hire are all taxis, then why do we have buses?
Very
few people class taxi and bus identically.  And even fewer put chartered
aircraft in the same class.  Many see ojeks and taxis the same way they see
buses and taxis - different things, not variants of the same thing.

In everyday life, most people don't think in a taxonomic way.  They see
instances, not classes.  Push them to categorize things and they will
agree that a chair is a type of seat, and a seat is a type of furniture, but
most of them see a chair and think "chair."  And if you do persuade
somebody to think taxonomically, the hierarchy he or she uses may or
may not be the same one you do: that chair is made of wood, as is that
table - they're both wooden. not they're both furniture.

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


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

2020-05-09 Thread François Lacombe
Hi Paul,

Le sam. 9 mai 2020 à 02:29, Paul Allen  a écrit :

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

Tourists aren't supposed to refer to tags to know which kind of taxi
service they can use.
Renders, tools, apps are here to ease this for them. Are you aware of
Google Maps data model when browsing it?
Even local mappers can use tools focused on a specific topic which makes
tagging less important to master to contribute.

Nevertheless, we're are discussing about things like amenity=taxi +
vehicle=* which doesn't sound that complex.
Even common language using two words "motorcycle" and "taxi" could mean we
have something to do with several keys.

Le sam. 9 mai 2020 à 06:38, Shawn K. Quinn  a écrit :

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

Beware of :type disadvantages.
Things like vehicle=* sounds better (or another word referring to vehicle
used).

Default to motorcar can lead to mistakes for consumers.
It's more valuable to consider vehicle unknown if absent (and encourage
mappers to explicitly define it)

Le sam. 9 mai 2020 à 08:01, Phake Nick  a écrit :

>
> "I pay a driver to take me where I want to with his vehicle" is something
> that would also be true for any other public transit vehicles.
>

I respectably disagree regarding public transit: you're not asking them to
take you where YOU want but if they actually go where THEY told us they
will.
Every word counts here.


> Motorcycle taxi is different from 4-wheeled taxi because they provide a
> different experience with different speed, charge different fare, have
> different level of convenience, can access different area, and various
> other factors.
>

We agree on that particular point.
Neverthess that doesn't make a second value of amentiy legit.
OSM would only have one key grouping all possible values if it was relevant.



> In addition to them being different kind of services, for the purpose of
> openstreetmap tagging, it's better to remember that a motorcycle taxi stand
> would look quite different from a taxi stand, use the streetspace
> differently, and thus mixing them together would also hurt any downstream
> data user who might wish to understand the situation of 4-wheeled taxi
> penetration in certain geographical area due to conflating the data with
> others that aren't of the same type. They're often regulated by different
> laws and face different operational restrictions also.
>

That could eventually be a point if all those differences were known
precisely and described.
There are many many kind of public transit stations but we're still calling
them stations and platforms.

All the best

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


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

2020-05-09 Thread Lukas-458
Hi,

in a discussion during voting on my proposal of traffic_signals=crossing_only (https://wiki.openstreetmap.org/wiki/Proposed_features/traffic_signals%3Dcrossing_only)

there was mentioned that the existing values of traffic_signals=* partial rather describe the configuration of a traffic signal (blinker, continuous_green, blink_mode) than describing their responsibilty. But I think that's not the case for all ones, because "emergency", "bus/tram_priority" and "ramp_meter" are responsibilities, to me.

 

But how to tag a traffic signal which is blinking every time (blink_mode) but only activated/chaging to red for the cars when a pedestrian wants to cross (traffic_signals=crossing_only) then? Two tags get in conflict here, but I think both have a legitimation to get tagged. The same cann appear for a "bus_priority" signal, for example.

My question is, whether we need a new key for differentiation between "how is a traffic light configured" and "for what is a traffic light responsible".

 

Something like "traffic_signals:default_light"? Then the "resposibility" of a traffic light can go on traffic_signals=*, and traffic_signals:default_light could describe if the signal has a light before getting activated, so values could be "staying_green","staying_yellow","blinking_yellow", something like this.

 

I would like to hear/read what you think.

--Lukas


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



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




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


Re: [Tagging] RFC ele:regional

2020-05-09 Thread Simon Poole
I was just making a statement of fact, not arguing one way or the other.
The original reason for using HAE in the ele tag was exactly what Kevin
claimed what would be the only sensible use of the HAE value. That it
probably was a bad idea because it didn't take the realities of mapping
in to account (as far as these could even be known at the time) doesn't
affect the original intent.

The really only open question is: do we consider ele so burnt that it
should just go away and we use a different tag (for example
ele:regional, though I would be against that specific key) for "height
indicated on things without knowing exactly which datum is being used"
or do we use ele for that.

Simon

Am 08.05.2020 um 03:11 schrieb Greg Troxel:
> Simon Poole  writes:
>
>> Am 04.05.2020 um 15:19 schrieb Kevin Kenny:
>>> Elevation as height-above-ellipsoid, unless you're using it in the
>>> intermediate results of a GPS calculation, is nonsensical.
>> However if you read the argumentation on the Altitude page that was
>> exactly the reasoning: store hae and therefore be able to calculate
>> datum specific heights easily after the fact.
> Yes, but this is a ridiculous stramwan.   HAE and height above wgs84
> geoid are equally well defined, but one (height above geoid) is what is
> used for height and also happens to be almost matching all civil height
> systems.
>
>
> The real point here is that people want to take data that has a number
> but not a datum and enter it and feel good about themelves, instead of
> realizing and admitting that they are doing something fundamentally
> wrong.  I am perfectly ok with entering a height that has no datum, and
> having some meta key that basically says that the height value is
> inaccurate, and perhaps "ele:datum=unknown" is good for this, crisply
> denoting that the height is without a solid basis.
>
> But, I find it unreasonable that people want to legitimize this sort of
> confusion, rather than mark it as confusion as a warning to others.



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2020-05-09 Thread Phake Nick
在 2020年5月9日週六 07:07,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.
>


"I pay a driver to take me where I want to with his vehicle" is something
that would also be true for any other public transit vehicles.
Motorcycle taxi is different from 4-wheeled taxi because they provide a
different experience with different speed, charge different fare, have
different level of convenience, can access different area, and various
other factors.


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

That's why I suggest clarifying the proposal and restart the discussion
process so that RFC can be centered around such idea. Or we are actually
doing it now.

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

In addition to them being different kind of services, for the purpose of
openstreetmap tagging, it's better to remember that a motorcycle taxi stand
would look quite different from a taxi stand, use the streetspace
differently, and thus mixing them together would also hurt any downstream
data user who might wish to understand the situation of 4-wheeled taxi
penetration in certain geographical area due to conflating the data with
others that aren't of the same type. They're often regulated by different
laws and face different operational restrictions also.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging