Re: [Tagging] Feature Proposal - RFC - temperature

[Warin]

On 6/02/2015 11:22 AM, Bryce Nesbitt wrote:
There are cases where an approximate temperature is more useful than a 
single scalar number.
For example a drinking fountain may be "chilled", but not operating at 
a single fixed temperature.
Similarly there's a big difference in a tropical climate between a 
building with A/C and one without.
And a mountain hut with a fireplace, compared to one without.  Neither 
can be expressed well as a temperature=.


In many cases what matters is the ability to warm or cool from 
ambient.  A/C give you the ability to
make a room cooler than ambient, but not hotter.  A fireplace the 
opposite.  Thus perhaps instead:


heated=yes
cooled=no

Could apply to pools, spas, hotel rooms, water taps.


A hotel room that has air conditioning may be both heated or cooled 
depending on the desired temperature and the ambient temperature (and 
the air conditioner). It usually supplies a measure of fresh air too. I 
think that this should be considered as part of the building .. and a 
sub tag developed for that?


A heated pool would be warm, cooled would be cool? Same with spars and 
taps..


If adjustable, e.g. as most showers are, then the tag 
'temperature=adjustable' is part of this proposal...





I have done a number of changes ...

A) Removed the Kelvin as a unit for data entry.

B) The water tap  labelled 'cold' issue. For tagging I think this should 
be labelled 'ambient'. I have added a note about it, and added words 
that cold means colder that ambient .. similar words have been added for 
the other subjective terms. Should examples of the relevant subjective 
values be added to aid there use?


C) Removed the safety references. Boiling water of 0.5 gram would do 
little harm to the palm of the hand, a 1kg bit of metal at 75 C would 
cause burns... so the safety is not all about temperature.


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

[Tagging] Nominatim mysteries

[André Pirard]

Hi,

Can anyone make sense out of this?
About:  http://wiki.openstreetmap.org/wiki/Nominatim/Special_Phrases/FR
Two columns prepended to the table, second: Y=works, N=does not.
All OSM queries are appended with the place name "Dolembreux".
Seeing that #1 works, I add the alternate #2 and it doesn't.
Then I check "recycling Dolembreux" and it doesn't work.
But "recycling point Dolembreux" does work.
(OK, I see that phrase in the EN page, but...)
Now if I add #5, it does work but #3 and #4 don't.
Plus, all the prepositions in entries marked with "?" seem unnecessary.
The queries with or without them seem to return the same results;
And yet, the specification page
 defines them.

Am I missing something?

André.



1
Y
Point de recyclage  amenity recycling   -
N
2
N
Bulle à verre   amenity recycling   -
N
3
N
Bulle   amenity recycling point -   N
4
N
Bulle verre amenity recycling point -   N
5
Y
Bulle à verre   amenity recycling point -   N
6
Y
Point de recyclage  amenity recycling   -   N
7
Y
Points de recyclage amenity recycling   -   Y

?
Point de recyclage àamenity recycling   in  N

?
Points de recyclage à   amenity recycling   in  Y

?
Point de recyclage en   amenity recycling   in  N

?
Points de recyclage en  amenity recycling   in  Y

?
Point de recyclage dans amenity recycling   in  
N

?
Points de recyclage dansamenity recycling   in  
Y

?
Point de recyclage près amenity recycling   near
N

?
Points de recyclage prèsamenity recycling   near
Y

?
Point de recyclage près de  amenity recycling   near
N

?
Points de recyclage près de amenity recycling   near
Y

?
Point de recyclage proche   amenity recycling   near
N

?
Points de recyclage proche  amenity recycling   near
Y

?
Point de recyclage proche deamenity recycling   near
N

?
Points de recyclage proches de  amenity recycling   near
Y


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

Re: [Tagging] Feature Proposal - Voting - traffic_signals (Lukas Schaus)

[fly]

Still do not see any need for a relation once we have micromapped enough
and this should be the prior quest.

What I totally miss are options for operating_time. I won't be able to
tag the phase as many other did already mention but I can tell you the
times when traffic_signals are usually operating.

Guess people might already use opening_hours but I rather prefer
operating_time.

Am 10.02.2015 um 14:33 schrieb Lukas Schaus:
> fly lowflight66 at googlemail.com,  Mon Feb 9 15:47:00 UTC 2015
>> You did not comment on my question about micromapping a junction and
>> adding a highway=traffic_signal at the pedestrian crossing or the stop
>> line for each direction separately. Have a look at the examples below
>> [1],[2].
>>
>> For complete direction separated junctions like [3] we probable will not
>> even need any relation.
>>
>> Please, consider this tagging style and show me how this will work
>> together with your proposal.
>>
>> Altogether, I am not sure if this relation is needed at all but for sure
>> not at the current base.
>>
>> Still would prefer simple tags on the nodes if possible.
>>
>> cu fly
>>
>> [1] https://www.openstreetmap.org/#map=19/48.10739/7.85080
>> [2] https://www.openstreetmap.org/#map=18/48.06123/7.81258
>> [3] https://www.openstreetmap.org/#map=19/47.98530/7.82814
> I am sorry i did not see your question,
> If the traffic signals are mapped at the stop line or the pedestrian
> crossing this scheme works still perfectly. the From way is the way the
> signal is at and the direction can be specified by forward or backward.
> Simple Tags on the nodes only work with this scheme mentioned by you.
> With intersections where the signal is mapped at the crossing of 2 roads
> it is not working. Why would there no relation needed in 3?
> 
> AYTOUN RALPH ralph.aytoun at ntlworld.com, Tue Feb 10 11:09:16 UTC 2015
>> My feelingsis this not something for a separate study by someone
>> rather
>> than a feature on OSM? Keeping this kind of information updated will
>> be an
>> impossibilitymany cities are becoming "computerised" and the signals
>> adjusted according to the traffic conditions along that road. At best the
>> timings could be either static or variable.
> 
> That is why we kept the mapping of the phases simple and not accurate.
> These values shall give an idea on how long a total cycle of the
> traffic_signal is and an average of green time or the proportion between
> red and green time. These two information are very helpful for simulations.
> Please note that the phases tag is only one part of the proposal. at
> least as important is the ability to define to-ways for the signal.
> Knowing this other traffic_signals on the way can be ignored since they
> are not of concern for the turning vehicle. Also the defined connection
> of a turn_lane to its destination is a major benefit from this scheme

So we need at least tags for these situations like button operated and
psv-priority and so on.

cu fly


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

Re: [Tagging] Tagging Digest, Vol 65, Issue 47

[Lukas Sommer]

> i don't see the potential for confusion since this is a relation.
> Maybe you can elaborate why this could be a problem since
> i am not aware.

Without reading the documentation, I would expect to
type=traffic_signals to be something very similar to
highway=traffic_signals. But type=traffic_signals is not about traffic
signals, it’s more but about a way through a traffic signal system.

> The name does maybe not match to 100% the purpose
> but the relation is more than just about the phases.

Maybe another – longer and more descriptive – tag would be better.

Changing this during voting is only possible when you have the
agreement of all these who votes with “yes” so far. As in the meantime
more people have voted, that get’s complicate …

Best regards

Lukas Sommer

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

Re: [Tagging] Feature Proposal - Voting - traffic_signals (Lukas Schaus)

[Tobias Knerr]

On 09.02.2015 15:31, Lukas Schaus wrote:
> My proposal concerning the modelling of traffic signals is now open for
> voting.

Oh dear. I had hoped to discuss the mapping of physical traffic signal
locations with you before the vote. I was not aware that you had planned
to vote after just 1 week of discussion for the new proposal version.

Tobias

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

Re: [Tagging] Feature Proposal - Voting - traffic_signals (Lukas Schaus)

[Lukas Schaus]

fly lowflight66 at googlemail.com,  Mon Feb 9 15:47:00 UTC 2015

You did not comment on my question about micromapping a junction and
adding a highway=traffic_signal at the pedestrian crossing or the stop
line for each direction separately. Have a look at the examples below
[1],[2].

For complete direction separated junctions like [3] we probable will not
even need any relation.

Please, consider this tagging style and show me how this will work
together with your proposal.

Altogether, I am not sure if this relation is needed at all but for sure
not at the current base.

Still would prefer simple tags on the nodes if possible.

cu fly

[1] https://www.openstreetmap.org/#map=19/48.10739/7.85080
[2] https://www.openstreetmap.org/#map=18/48.06123/7.81258
[3] https://www.openstreetmap.org/#map=19/47.98530/7.82814

I am sorry i did not see your question,
If the traffic signals are mapped at the stop line or the pedestrian  
crossing this scheme works still perfectly. the From way is the way  
the signal is at and the direction can be specified by forward or  
backward. Simple Tags on the nodes only work with this scheme  
mentioned by you. With intersections where the signal is mapped at the  
crossing of 2 roads it is not working. Why would there no relation  
needed in 3?


AYTOUN RALPH ralph.aytoun at ntlworld.com, Tue Feb 10 11:09:16 UTC 2015

My feelingsis this not something for a separate study by someone rather
than a feature on OSM? Keeping this kind of information updated will be an
impossibilitymany cities are becoming "computerised" and the signals
adjusted according to the traffic conditions along that road. At best the
timings could be either static or variable.


That is why we kept the mapping of the phases simple and not accurate.  
These values shall give an idea on how long a total cycle of the  
traffic_signal is and an average of green time or the proportion  
between red and green time. These two information are very helpful for  
simulations.
Please note that the phases tag is only one part of the proposal. at  
least as important is the ability to define to-ways for the signal.  
Knowing this other traffic_signals on the way can be ignored since  
they are not of concern for the turning vehicle. Also the defined  
connection of a turn_lane to its destination is a major benefit from  
this scheme



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

Re: [Tagging] Feature Proposal - Voting - traffic_signals (Lukas Schaus)

[Philip Barnes]

On Tue, 2015-02-10 at 11:09 +, AYTOUN RALPH wrote:
> My feelingsis this not something for a separate study by someone
> rather than a feature on OSM? Keeping this kind of information updated
> will be an impossibilitymany cities are becoming "computerised"
> and the signals adjusted according to the traffic conditions along
> that road. At best the timings could be either static or variable.
> 
I think most cities traffic lights became computer controlled in the
1970s, they have certainly been remotely operated by an operator using
CCTV since then.

Even back in the 1960s there were pressure tubes to detect traffic and
adjust sequences, during the 70s they were replaced by wireloops in the
road.

Even with the simplest set of traffic lights, the timing will depend on
the amount of traffic and whether a pedestrian has pressed the button
hence adding the pedestrian phase.

I think this is far to complicated to be included in OSM and any data
will rapidly become stale.   

Phil (trigpoint)


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

Re: [Tagging] Feature Proposal - Voting - traffic_signals (Lukas Schaus)

[AYTOUN RALPH]

My feelingsis this not something for a separate study by someone rather
than a feature on OSM? Keeping this kind of information updated will be an
impossibilitymany cities are becoming "computerised" and the signals
adjusted according to the traffic conditions along that road. At best the
timings could be either static or variable.

On 10 February 2015 at 11:00, Janko Mihelić  wrote:

> 2015-02-10 11:29 GMT+01:00 Philip Barnes :
>
>>
>> This does seem very complicated, I cannot see much take up by mappers on
>> the ground.
>>
>> Traffic signal timing varies by time of day, day of week, and traffic
>> density. Many traffic signals can be remotely controlled to clear
>> problems.
>>
>> It is really not a simple case of green is x seconds, but will vary
>> throughout the day.
>>
>
> I'm sure mappers are not going to update this very much, but it could be
> automated. An app could have a camera and could scan periods of lights, put
> them in a database, analyze times of days, and after enough data put it in
> osm.
>
>
> ___
> 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] Feature Proposal - Voting - traffic_signals (Lukas Schaus)

[Janko Mihelić]

2015-02-10 11:29 GMT+01:00 Philip Barnes :

>
> This does seem very complicated, I cannot see much take up by mappers on
> the ground.
>
> Traffic signal timing varies by time of day, day of week, and traffic
> density. Many traffic signals can be remotely controlled to clear
> problems.
>
> It is really not a simple case of green is x seconds, but will vary
> throughout the day.
>

I'm sure mappers are not going to update this very much, but it could be
automated. An app could have a camera and could scan periods of lights, put
them in a database, analyze times of days, and after enough data put it in
osm.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging Digest, Vol 65, Issue 47

[Lukas Schaus]

Hi,
i am sorry i must have missed your comment where you mentioned it  
before. I am not this experienced in OSM, but i don't see the  
potential for confusion since this is a relation. Maybe you can  
elaborate why this could be a problem since i am not aware. The name  
does maybe not match to 100% the purpose but the relation is more than  
just about the phases. Another major benefit is, to get information of  
the scope of the intersection and all possible connections between the  
incoming and outgoing edges in complex intersections as well as the  
relation between lanes and traffic signals.


Since I don't have a name that fits better, suggestions are welcome.  
BTW: How would I proceed if i wanted to change the name during vote?



Date: Mon, 9 Feb 2015 20:38:32 +
From: Lukas Sommer 
To: "Tag discussion, strategy and related tools"

Subject: Re: [Tagging] Feature Proposal - Voting - traffic_signals
(Lukas  Schaus)
Message-ID:

Content-Type: text/plain; charset=UTF-8

I know that I’m a little late with this comment – I missed this while
reading the proposal. Sorry.

Maybe that’s something that can be changed in the prososal – if
current voters agree?

2015-02-09 17:29 GMT, Lukas Sommer :

I would strongly recommend to not use type=traffic_signals because we






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

Re: [Tagging] Feature Proposal - RFC - key:rubbish=

[Warin]

On 9/02/2015 1:59 PM, David Bannon wrote:

On Mon, 2015-02-09 at 09:15 +1100, Warin wrote:

A proposal for a new high level tag of .. Rubbish :-)

Sigh ... .

I find it amusing..



Thirdly, dare I say this, will someone argue rubbish= indicates that
there is rubbish there, on that spot ?  preferable to say
rubbish_disposal or something similar.


There you have a very good point. And waste_disposal fits well too
Ok .. humm disposal ... could imply no recycling ... what about
waste_collection ?

That may not have been used in OSM before .. so no conflict... nice. 
What do you think? ... change rubbish to waste_collection?




I do believe we need a high level key for rubbish, trash, waste whatever

Hmm, rubbish_receptacle perhaps ? And definitely not
rubbish_receptacle_desk !!


:-)That is the spirit.


(sorry)

David





https://wiki.openstreetmap.org/wiki/Proposed_features_key%3Drubbish

At present there as a number of 'waste' values under the amenity key.
Some people say the amenity key is being over used. There are people
thinking of adding more waste values to the amenity key. So there is a
case for a high level new key for waste facilities. The number of
possible values of this is key I estimate at 27. Don't fixate on the
values of this key - the ones shown are examples only .. and would need
there own separate proposals.

Unfortunately the key waste= is already in use, so to avoid conflicts
and mistakes a new name should be used - thus 'rubbish'.


Is there a better way? So far the choices look to be;

A) More values under the key amenity such as amenity=waste_dump_station?
B) More values under amenity=waste_disposal in the key waste=?
OR
C) New top level key rubbish= with new values under that?

Any other options?
And what one do you prefer? May be a why would be good.

Personally .. I don't know. I think a new top level tag would be good in
that it does separte it out from hte others and provides a clear path
for new rubbish tags. But I also acknowledge the problems/work that this
would introduce. On htewhole I'd go with the neew top level tag, I like
a good structure, but any other good ideas or arguments can easily sway
my present view.

-
I'd like to leave the comments open for 3 weeks .. unless there is a
vast amount of comments made and changes/additions to the different
choices that could be made.
So possible closure on 2 march?

___
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] Feature Proposal - Voting - traffic_signals (Lukas Schaus)

[Philip Barnes]

On Mon, 2015-02-09 at 20:38 +, Lukas Sommer wrote:
> I know that I’m a little late with this comment – I missed this while
> reading the proposal. Sorry.
> 
> Maybe that’s something that can be changed in the prososal – if
> current voters agree?
> 
> 2015-02-09 17:29 GMT, Lukas Sommer :
> > I would strongly recommend to not use type=traffic_signals because we
> 

This does seem very complicated, I cannot see much take up by mappers on
the ground.

Traffic signal timing varies by time of day, day of week, and traffic
density. Many traffic signals can be remotely controlled to clear
problems. 

It is really not a simple case of green is x seconds, but will vary
throughout the day.

Phil (trigpoint)


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

Re: [Tagging] Tram tracks running in a road

[Warin]

On 9/02/2015 10:50 PM, Martin Koppenhoefer wrote:


2015-02-07 1:12 GMT+01:00 Jo >:


Keep in mind it's only a model to represent reality. A model which
uses lines for what in reality are areas, so whatever we do, it
will never be a perfect fit.



+1, why not draw area:highway=* for the road areas to model that the 
trams run on the road and not separately?


Few thing would be true lines i.e. zero width. Things like boundaries 
would be true lines (country/state/administrative). Most cliff lines 
will have some 'widt' as they won't be perfectly vertical. Roads and 
train line have a definite width, and that width can be represented by 
the lanes= or track gauge entries. It is not unusual to have a sinle 
drawing line represent something eles in reality e.g. single line 
electrical drawing have a single line represent a number of wires, this 
easies the drawing and makes the resulting 'map' easier to read. I see 
little advantage to making highways areas for the work input involved 
myself.


Upto the mapper on the spot. But remen]ber that the data input may not 
get to the output - the render may not use it.





cheers,
Martin


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


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