Re: [Tagging] courtyards

[Alex Rollin]

imho a courtyard is related to leisure.

why for: because a courtyard matters to people with leisure time and it is
a luxury of sorts.

why against: perhaps a courtyard is a sequestered area/way as it is often
tagger highway designated footpath as an area, an area that is a Very big
way for foot traffic, and so not leisure at all, just a big highway with
special rules.

I would like to hear more from others. I think courtyards are important,
and they are disappearing, so , if we map them, maybe they will lget more
attention, and their numbers will increase.  I have never tagged a
courtyard as a POI, perhaps because I didn't know how. I hope this
conversation can help lots of people. Thanks for bringing it up!

--
Alex

On Sat, Feb 7, 2015 at 6:47 AM, Lukas Sommer  wrote:

> I didn't know that courtyards have their own name ;-)
>
> In general, it seems a good idea to have a tag (apart from name=*) on
> the inner line of the multipolygon. But I would avoid the key place=*
> because this key is rather used for bigger features and seems to not
> fit well. Maybe there is another key *=courtyard that fits better?
>
> 2015-02-06 22:14 GMT, Friedrich Volkmann :
> > Courtyards use to be mapped as "inner" members of building
> multipolygons. We
> > can also use the multipolygon relation to assign a name to the bullding.
> If
> > we want to assign a name to the courtyard, we must assign it to the way.
> But
> > then we need some kind of physical tag in addition. Applications won't
> know
> > what do do with the name when there aren't any other tags.
> >
> > Some courtyards are tagged place=locality or highway=pedestrian or
> > leisure=park, but they all seem wrong. A place=locality wouldn't be that
> > strictly delimited, and a park or pedestrian area need not occupy the
> entire
> > courtyard.
> >
> > A courtyard really has nothing to do with leisure=*, and it is not a
> highway
> > either. It's just a hole in a building. What key can we use for this?
> >
> > What about place=courtyard (an area spared by a buildng), analogous to
> > place=island (an area spared by the ocean)?
> >
> > --
> > Friedrich K. Volkmann   http://www.volki.at/
> > Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
> >
>
>
> --
> Lukas Sommer
>
> ___
> 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] Lifecycle concepts, "REMOVED"

[Bryce Nesbitt]

On Mon, Feb 2, 2015 at 7:53 AM, Janko Mihelić  wrote:

> But what if hikers still refer to the spot? Like "Let's go to the burnt
> alpine hut, and then go left". That is a pretty important landmark, even if
> there is no sign of the hut any more. Maybe we can tag it as place=locality.
>

Clearly, that's a http://wiki.openstreetmap.org/wiki/Key:ruins
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tram tracks running in a road

[Jo]

That's how it was initially done in most places, before we started mapping
those tracks in more detail, which became possible thanks to improved
resolution of the aerial imagery (and in the case of Brussels, thanks to
UrbIS opening the data)

Jo

2015-02-07 4:02 GMT+01:00 James Mast :

> Here's how we have done this in the Pittsburgh, PA area where the 'light
> rail' line shares the pavement with the normal road lanes.  They normally
> only use this line during the rush hours unless they have to close the
> tunnel @ Station Square and divert the light rail traffic along this route.
>
> https://www.openstreetmap.org/#map=16/40.4260/-79.9990
> https://www.openstreetmap.org/way/294921081
>
> And here's a link to what it looks like on the ground level via Google
> StreetView since I don't have any pictures of it since I normally don't go
> on that road when I'm in that area of Pittsburgh unless the Liberty Tubes
> are closed and they are forcing traffic this way (which is very rare).
> http://goo.gl/maps/ittiG
>
> Anyways, this is our only example of 'active' tracks in the road here.
> However, there is still a segment of road on the North Side of Pittsburgh
> that still has the old streetcar tracks from when that line was
> decommissioned in the 1980's still embedded in it, and is a brick road to
> boot.  I don't think we have any other examples like that, but I haven't
> tried to do any research on all the old streetcar routes from before I was
> born here in Pittsburgh.
>
> -James
>
> ___
> 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] Tram tracks running in a road

[James Mast]

Here's how we have done this in the Pittsburgh, PA area where the 'light rail' 
line shares the pavement with the normal road lanes.  They normally only use 
this line during the rush hours unless they have 
to close the tunnel @ Station Square and divert the light rail traffic 
along this route.

https://www.openstreetmap.org/#map=16/40.4260/-79.9990
https://www.openstreetmap.org/way/294921081

And here's a link to what it looks like on the ground level via Google 
StreetView since I don't have any pictures of it since I normally don't go on 
that road when I'm in that area of Pittsburgh unless the Liberty Tubes are 
closed and they are forcing traffic this way (which is very rare).
http://goo.gl/maps/ittiG 

Anyways, this is our only example of 'active' tracks in the road here.  
However, there is still a segment of road on the North Side of Pittsburgh that 
still has the old streetcar tracks from when that line was decommissioned in 
the 1980's still embedded in it, and is a brick road to boot.  I don't think we 
have any other examples like that, but I haven't tried to do any research on 
all the old streetcar routes from before I was born here in Pittsburgh.

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

Re: [Tagging] Tram tracks running in a road

[Jo]

The reason to use separate ways for trams can be seen in the other tram
tracks I mapped:

http://www.openstreetmap.org/#map=18/50.83181/4.33280

You can clearly see that very often the rails don't follow the asphalt
where the cars drive. Cars can make 90 degree turns, the tram rails need to
follow smoother curves.

So it's only in situations where buses follow the tram bedding:

http://www.openstreetmap.org/#map=19/50.82432/4.33561

that one can have common ways for the tram and that service road.

* For normal streets we draw 2 ways for the tracks and 1 for the asphalt
road.
* For dual carriageways we draw 2 ways for the tracks and 2 for each side +
sometimes a service way between the tracks, when the buses use it too.

It's rather exceptional that the service road and the tram rails can use
the same OSM way.

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.


I'm sure André won't agree with me, but to implement the solution he
proposes, we'd have to restart OSM from scratch. And even though it may
simplify and solve some things, it would make other stuff a lot harder.

Jo

2015-02-07 0:31 GMT+01:00 Janko Mihelić :

> 2015-02-06 17:29 GMT+01:00 Luca Sigfrido Percich :
>
>>
>> We could also user a lanes modifier:
>> lanes=3
>> lanes:backward=2
>> tram:lanes:backward=yes|no
>> tram:forward=yes
>>
>>
> I think this is the best way to tag this. There's a great map paint style
> for seeing roads in towns in JOSM, and it helps a lot with tagging lanes.
> It's called Lanes and road attributes. Unfortunately, it doesn't show
> trams, but if we start tagging them, it will probably start rendering them.
> Right now, I use psv:lanes:forward=designated|no, because psv means all
> public service vehicles.
>
> http://wiki.openstreetmap.org/wiki/Key:lanes:psv
>
> And in my town those lanes are reserved for trams, buses and taxis.
>
> Janko Mihelić
>
> ___
> 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] courtyards

[Lukas Sommer]

I didn’t know that courtyards have their own name ;-)

In general, it seems a good idea to have a tag (apart from name=*) on
the inner line of the multipolygon. But I would avoid the key place=*
because this key is rather used for bigger features and seems to not
fit well. Maybe there is another key *=courtyard that fits better?

2015-02-06 22:14 GMT, Friedrich Volkmann :
> Courtyards use to be mapped as "inner" members of building multipolygons. We
> can also use the multipolygon relation to assign a name to the bullding. If
> we want to assign a name to the courtyard, we must assign it to the way. But
> then we need some kind of physical tag in addition. Applications won't know
> what do do with the name when there aren't any other tags.
>
> Some courtyards are tagged place=locality or highway=pedestrian or
> leisure=park, but they all seem wrong. A place=locality wouldn't be that
> strictly delimited, and a park or pedestrian area need not occupy the entire
> courtyard.
>
> A courtyard really has nothing to do with leisure=*, and it is not a highway
> either. It's just a hole in a building. What key can we use for this?
>
> What about place=courtyard (an area spared by a buildng), analogous to
> place=island (an area spared by the ocean)?
>
> --
> Friedrich K. Volkmann   http://www.volki.at/
> Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Lukas Sommer

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

Re: [Tagging] Tram tracks running in a road

[Janko Mihelić]

2015-02-06 17:29 GMT+01:00 Luca Sigfrido Percich :

>
> We could also user a lanes modifier:
> lanes=3
> lanes:backward=2
> tram:lanes:backward=yes|no
> tram:forward=yes
>
>
I think this is the best way to tag this. There's a great map paint style
for seeing roads in towns in JOSM, and it helps a lot with tagging lanes.
It's called Lanes and road attributes. Unfortunately, it doesn't show
trams, but if we start tagging them, it will probably start rendering them.
Right now, I use psv:lanes:forward=designated|no, because psv means all
public service vehicles.

http://wiki.openstreetmap.org/wiki/Key:lanes:psv

And in my town those lanes are reserved for trams, buses and taxis.

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

Re: [Tagging] Tram tracks running in a road

[André Pirard]

  
  
On 2015-02-06 21:11, Jo wrote :


  I think relation street applies to all the way
segments of the whole street with the same name (if in the same
municipality), but I didn't check to be honest.
  

Those kinds of relations are made to unsplit what wouldn't have been
split if what I presented as SEGMENT or OVERLAY and later revised as
PATCH tags were used.
One of the significant differences is that this tag is unique while
there are as many types of unsplitting relations as types of ways
that can be split.


  

  André.

  



  


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

Re: [Tagging] Wiki on amenity=waste_disposal Rewrite?

[David Bannon]

On Fri, 2015-02-06 at 19:31 +1100, Warin wrote:

 reasoned arg against (eg) amenity=waste_dog_excrement

Yes, Warin, you are probably right, while a more sensible syntax, it
will be resisted as too big a change.

An alternative might be to declare that (eg) waste=waste_dog_excrement
is on a par with amenity=, so waste= can be used without
amenity=waste_disposal. In other words, bumping waste= up to a higher
lever key.

While a big change in principle, its technically trivial, existing tags
in the database will still be valid, no changes needed, just in future,
taggers can leave out the redundant amenity=waste_disposal

The problem there is treating waste= as a high level tag. Considering
just how big an issue waste disposal is to humanity, I cannot help but
think its justified.

But won't be surprised if there are dissenters

David



> On 5/02/2015 12:04 PM, Dave Swarthout wrote:
> 
> > 
> > On Thu, Feb 5, 2015 at 7:10 AM, Warin <61sundow...@gmail.com> wrote:
> > You mean a one step? Like highway= x ?
> > 
> > To do that I'd think a new supper key   waste=   at the top
> > level! And maybe that is what it needs! If there are enough
> > different kinds then why not? 
> > waste=rubbish_bin
> > waste=skip_bin
> > waste=dump_point
> > waste=chemical_toilet
> > waste=dog_excrement
> > waste=sharps
> > waste=cigarettes
> > waste=excrement
> > 
> > What does it take to justify a top level tag? 
> > 
> > I think he means that if we use a top level amenity tag like
> > amenity=waste_disposal we are forced to make another whole set of
> > sub keys to describe the waste being disposed of. At least that's
> > where my criticism comes from. If however we can agree on a tag of
> > amenity=dump_point and define it as "a facility where one can dump
> > or discharge the waste tanks of an RV or recreational boat" it can
> > be understood and rendered by evaluating only that single tag.
> > 
> > Whether the waste being dumped is from a "chemical toilet" or from a
> > plastic bag on a "porta-potty" or "cassette"  then becomes
> > irrelevant. The facility will handle it.
> > 
> > 
> > This new top level tag might make the approval process easier too.
> > Standing alone as it would, it nicely separates garbage and trash,
> > or recyclables, from sewage and doesn't require any other
> > potentially lengthy approvals for new subkeys.
> > 
> The present sub tag already exists and is in use .. for oil,
> cigarettes, grey_water, drugs, dog_excrement, etc .. so they still
> have to be evaluated for a true render of the facility. If what is
> required is a one tag entry for each waste type then amenity= will be
> over loaded eg
> 
> amenity=waste_dog_excrement 
> amenity=waste_cigarettes
> amenity=waste_sharps
> 
> Note the inclusion of waste in the name .. so people don't think that
> they are places that sell the stuff! :) 
> 
> about 8 + around 28! if you include waste recycling... 
>  and I think it then needs to be a top level tag .. like shop=,
> tourism=. sport= etc. as there are too many of them .. and that would
> be opposed as it is a lot of work to change the present data and a lot
> of work to change the renders... at least another category of
> amenity ... presently
>   * 2.1 Sustenance
>   * 2.2 Education
>   * 2.3 Transportation
>   * 2.4 Financial
>   * 2.5 Healthcare
>   * 2.6 Entertainment, Arts & Culture
>   * 2.7 Others
> 
> Add  '2.8 Waste'?  I don't know.. just pointing out the possible
> future problems? 
> 
> 
> 
> 
> 
> ___
> 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 - RFC - Reception Desk

[David Bannon]

On Fri, 2015-02-06 at 11:16 +, Dan S wrote:

> However it occurs to me that it would be useful to have some way of
> indicating _what_ it is the reception for.

In a lot of cases, we'd probably see a larger area mapped as something,
be it caravan park, mine, whatever. Then a single node within that space
would represent the reception_desk. Clearly the larger area would not be
tagged =reception desk would it ?

The usefulness here it to identify where, in the larger area, the
reception desk is.

Hmm

David



>  For example, if it was part
> of a "site" relation*, then a role like role=reception would connect
> it to the larger entity in a meaningful way. That might be a suggested
> tagging option...
> 
> Best
> Dan
> 
> 
> * http://wiki.openstreetmap.org/wiki/Relations/Proposed/Site
> 
> 
> 
> 2015-02-06 2:03 GMT+00:00 Warin <61sundow...@gmail.com>:
> > Hi,
> >
> > Request for comment on new tag 'amenity=reception_desk'
> >
> > https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dreception_desk
> >
> > This comes out of the tag ON HT E tourism=camp_site WIKI PAGE which has a
> > sub key of camp_site=reception.
> >
> > As 'Receptions' are numerous outside of camp sites I think it is best to
> > have them available for use under other things - like hotels. So the new
> > tag.
> >
> > 'reception_desk' .. should separate it from other types of receivers .. like
> > radio receivers.
> >
> > Amenity is the best fit so amenity=reception_desk.
> >
> > what do you think?
> >
> >
> >
> >
> >
> > ___
> > 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 - RFC - Reception Desk

[John F. Eldredge]

On February 6, 2015 4:10:23 PM CST, David Bannon  
wrote:
> On Fri, 2015-02-06 at 13:58 +0100, Janko Mihelić wrote:
> > Why not tourism=reception_desk? We have tourism=hotel,
> > tourism=camp_site, tourism=information, it's only logical to use the
> > same key.
> > 
> I think the idea of =reception_desk could be applied much more widely
> than just tourism. Commercial sites, mining sites, the list would be
> quite long. So, I'd vote for amenity=
> 
> David
> > 
> > 
> 
> > 
> > 
> > 
> > 
> > 
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
> 
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

Agreed. The amenity tag is better, as otherwise we would need a separate tag 
for each industry.

-- 
John F. Eldredge -- j...@jfeldredge.com
"Darkness cannot drive out darkness: only light can do that. Hate cannot drive 
out hate: only love can do that." -- Martin Luther King, Jr.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] courtyards

[Friedrich Volkmann]

Courtyards use to be mapped as "inner" members of building multipolygons. We
can also use the multipolygon relation to assign a name to the bullding. If
we want to assign a name to the courtyard, we must assign it to the way. But
then we need some kind of physical tag in addition. Applications won't know
what do do with the name when there aren't any other tags.

Some courtyards are tagged place=locality or highway=pedestrian or
leisure=park, but they all seem wrong. A place=locality wouldn't be that
strictly delimited, and a park or pedestrian area need not occupy the entire
courtyard.

A courtyard really has nothing to do with leisure=*, and it is not a highway
either. It's just a hole in a building. What key can we use for this?

What about place=courtyard (an area spared by a buildng), analogous to
place=island (an area spared by the ocean)?

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Feature Proposal - RFC - Reception Desk

[David Bannon]

On Fri, 2015-02-06 at 13:58 +0100, Janko Mihelić wrote:
> Why not tourism=reception_desk? We have tourism=hotel,
> tourism=camp_site, tourism=information, it's only logical to use the
> same key.
> 
I think the idea of =reception_desk could be applied much more widely
than just tourism. Commercial sites, mining sites, the list would be
quite long. So, I'd vote for amenity=

David
> 
> 

> 
> 
> 
> 
> 
> ___
> 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] Whole planet flooded at main map?

[Tom Pfeifer]

Nelson A. de Oliveira wrote on 2015-02-06 21:52:

On Fri, Feb 6, 2015 at 6:50 PM, Martin Vonwald  wrote:

Is it just me or is currently the whole planet flooded on the main map? At
least at zoom level 1-6. Starting with 7 countries reappear.


It's flooded, yes.
(but tagging isn't the proper place to ask this :-))


This is usually caused by the Diluge, some uncorked coastline, or
a rendering issue. Being discussed everywhere ;-)

https://github.com/gravitystorm/openstreetmap-carto/issues/1294


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

Re: [Tagging] Feature Proposal - RFC - Reception Desk

[John Willis]

Reception is used for tourists, but also is common for any large office complex 
or even a industrial plant. 

People visiting the plant (for work related activities) would go to reception, 
check in, and get a visitors badge. 

I think there is a difference between a person on vacation and a product rep 
having an appointment at a car parts plant, but both have reception. 

Since the object is part of another object - a hotel, office, etc - it is an 
amenity of the building, whose purpose is tourism. 

But people visiting a factory complex and looking for visitor check-in aren't 
really tourists, are they? 

I think amenity is the right key.

Javbw

> On Feb 6, 2015, at 9:58 PM, Janko Mihelić  wrote:
> 
> Why not tourism=reception_desk? We have tourism=hotel, tourism=camp_site, 
> tourism=information, it's only logical to use the same key.
> 
> 
> Janko Mihelić
> 
> 
> 
> ___
> 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] Whole planet flooded at main map?

[Nelson A. de Oliveira]

On Fri, Feb 6, 2015 at 6:50 PM, Martin Vonwald  wrote:
> Is it just me or is currently the whole planet flooded on the main map? At
> least at zoom level 1-6. Starting with 7 countries reappear.

It's flooded, yes.
(but tagging isn't the proper place to ask this :-))

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

[Tagging] Whole planet flooded at main map?

[Martin Vonwald]

Hi!

Is it just me or is currently the whole planet flooded on the main map? At
least at zoom level 1-6. Starting with 7 countries reappear.

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

Re: [Tagging] Tram tracks running in a road

[Jo]

I think relation street applies to all the way segments of the whole street
with the same name (if in the same municipality), but I didn't check to be
honest.

2015-02-06 19:44 GMT+01:00 Luca Sigfrido Percich :

> Many thanks Jo!
>
> Volker also suggests that I should see how things are mapped in other
> major cities, and so I'll do.
>
> So you confirm that there isn't an established way of expressing the
> tram-in-road relationship?
>
> The use of the street relation has been suggested by a fellow member of
> the italian discussion group. It's not clear from the wiki, however, if
> this relation can be used for associating railways to highways for a single
> road segment (from crossroads to crossroads) or is meant for associating
> everything which belongs to a single street (so all the railways and
> highways which belong to the same street).
>
> I'll investigate further.
>
> Many thanks!
>
> Sig
>
>
> 2015-02-06 19:26 GMT+01:00 Jo :
>
>> Ciao Luca,
>>
>> For an example of a road with many variations in how the tram tracks are
>> embedded, you can have a look at this stretch I mapped a few months ago:
>>
>> http://www.openstreetmap.org/#map=16/50.8601/4.3117
>>
>> To indicate how they belong together, maybe a street or associatedStreet
>> relation makes sense?
>>
>> Jo
>>
>> 2015-02-06 17:29 GMT+01:00 Luca Sigfrido Percich 
>> :
>>
>>> Hi all,
>>>
>>> first time I write to the list (after lurking for a while), so I
>>> introduce myself. I am from Milano - Italy, I work for the municipality's
>>> agency for environment and mobility, and we'we been working for the last
>>> months to integrate our road graph with OSM.
>>>
>>> Currently in Milano all tram tracks are mapped separately, so they are
>>> all oneway and no way has both highway=* and railway=tram tags (apart from
>>> some cases we're correcting).
>>>
>>> Now, we would like to store the information wether a certain railway
>>> track runs in a road sharing the same space with motor vehicles.
>>>
>>> I am referring to situations similar to this one:
>>>
>>> http://wiki.openstreetmap.org/wiki/File:Tram_Amadeo.jpg
>>>
>>> Which is here on the map:
>>>
>>> https://www.openstreetmap.org/#map=19/45.470987/9.236118
>>>
>>> I searched the wiki for a tagging or relation scheme, but found none.
>>>
>>> I was thinking about a simple tagging scheme: tram=yes|forward|backward
>>> for the highway, and road=yes for the railway.
>>>
>>> From the previous example (the picture points at the opposite direction
>>> of the highway on which it was taken:
>>>
>>> For the center way (road):
>>>
>>> tram=yes (it's on both directions)
>>>
>>> and on the two railways:
>>> road=yes (the track lies on a road used by motor vehicles)
>>>
>>> We could also user a lanes modifier:
>>> lanes=3
>>> lanes:backward=2
>>> tram:lanes:backward=yes|no
>>> tram:forward=yes
>>>
>>> The tram tag should not be used for tracks which run separated from the
>>> road (they are tagged with railway=tram).
>>>
>>> The tram tag should go along with access tags, as we have lanes reserved
>>> for trams and buses/taxis:
>>>
>>> http://wiki.openstreetmap.org/wiki/File:Tram_xxii_marzo.jpg
>>>
>>> So the center way (carriageway reserved to psv with two tram tracks in
>>> shared space) would get tagged as:
>>> access=no
>>> bus=yes
>>> taxi=yes
>>> tram=yes
>>>
>>> We could also think about a relation, type=tram_on_road, it could be
>>> useful for sorting things out in complex multi-carriageway situations like
>>> this one:
>>>
>>> https://www.openstreetmap.org/#map=19/45.49833/9.19607
>>>
>>> but would also be more difficult for users to mantain and for clients to
>>> consume.
>>>
>>> Any suggestions / impressions?
>>>
>>> Thanks!
>>>
>>> Sig
>>>
>>> ___
>>> 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] Tram tracks running in a road

[Luca Sigfrido Percich]

Many thanks Jo!

Volker also suggests that I should see how things are mapped in other major
cities, and so I'll do.

So you confirm that there isn't an established way of expressing the
tram-in-road relationship?

The use of the street relation has been suggested by a fellow member of the
italian discussion group. It's not clear from the wiki, however, if this
relation can be used for associating railways to highways for a single road
segment (from crossroads to crossroads) or is meant for associating
everything which belongs to a single street (so all the railways and
highways which belong to the same street).

I'll investigate further.

Many thanks!

Sig


2015-02-06 19:26 GMT+01:00 Jo :

> Ciao Luca,
>
> For an example of a road with many variations in how the tram tracks are
> embedded, you can have a look at this stretch I mapped a few months ago:
>
> http://www.openstreetmap.org/#map=16/50.8601/4.3117
>
> To indicate how they belong together, maybe a street or associatedStreet
> relation makes sense?
>
> Jo
>
> 2015-02-06 17:29 GMT+01:00 Luca Sigfrido Percich :
>
>> Hi all,
>>
>> first time I write to the list (after lurking for a while), so I
>> introduce myself. I am from Milano - Italy, I work for the municipality's
>> agency for environment and mobility, and we'we been working for the last
>> months to integrate our road graph with OSM.
>>
>> Currently in Milano all tram tracks are mapped separately, so they are
>> all oneway and no way has both highway=* and railway=tram tags (apart from
>> some cases we're correcting).
>>
>> Now, we would like to store the information wether a certain railway
>> track runs in a road sharing the same space with motor vehicles.
>>
>> I am referring to situations similar to this one:
>>
>> http://wiki.openstreetmap.org/wiki/File:Tram_Amadeo.jpg
>>
>> Which is here on the map:
>>
>> https://www.openstreetmap.org/#map=19/45.470987/9.236118
>>
>> I searched the wiki for a tagging or relation scheme, but found none.
>>
>> I was thinking about a simple tagging scheme: tram=yes|forward|backward
>> for the highway, and road=yes for the railway.
>>
>> From the previous example (the picture points at the opposite direction
>> of the highway on which it was taken:
>>
>> For the center way (road):
>>
>> tram=yes (it's on both directions)
>>
>> and on the two railways:
>> road=yes (the track lies on a road used by motor vehicles)
>>
>> We could also user a lanes modifier:
>> lanes=3
>> lanes:backward=2
>> tram:lanes:backward=yes|no
>> tram:forward=yes
>>
>> The tram tag should not be used for tracks which run separated from the
>> road (they are tagged with railway=tram).
>>
>> The tram tag should go along with access tags, as we have lanes reserved
>> for trams and buses/taxis:
>>
>> http://wiki.openstreetmap.org/wiki/File:Tram_xxii_marzo.jpg
>>
>> So the center way (carriageway reserved to psv with two tram tracks in
>> shared space) would get tagged as:
>> access=no
>> bus=yes
>> taxi=yes
>> tram=yes
>>
>> We could also think about a relation, type=tram_on_road, it could be
>> useful for sorting things out in complex multi-carriageway situations like
>> this one:
>>
>> https://www.openstreetmap.org/#map=19/45.49833/9.19607
>>
>> but would also be more difficult for users to mantain and for clients to
>> consume.
>>
>> Any suggestions / impressions?
>>
>> Thanks!
>>
>> Sig
>>
>> ___
>> 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] Tram tracks running in a road

[Jo]

Ciao Luca,

For an example of a road with many variations in how the tram tracks are
embedded, you can have a look at this stretch I mapped a few months ago:

http://www.openstreetmap.org/#map=16/50.8601/4.3117

To indicate how they belong together, maybe a street or associatedStreet
relation makes sense?

Jo

2015-02-06 17:29 GMT+01:00 Luca Sigfrido Percich :

> Hi all,
>
> first time I write to the list (after lurking for a while), so I introduce
> myself. I am from Milano - Italy, I work for the municipality's agency for
> environment and mobility, and we'we been working for the last months to
> integrate our road graph with OSM.
>
> Currently in Milano all tram tracks are mapped separately, so they are all
> oneway and no way has both highway=* and railway=tram tags (apart from some
> cases we're correcting).
>
> Now, we would like to store the information wether a certain railway track
> runs in a road sharing the same space with motor vehicles.
>
> I am referring to situations similar to this one:
>
> http://wiki.openstreetmap.org/wiki/File:Tram_Amadeo.jpg
>
> Which is here on the map:
>
> https://www.openstreetmap.org/#map=19/45.470987/9.236118
>
> I searched the wiki for a tagging or relation scheme, but found none.
>
> I was thinking about a simple tagging scheme: tram=yes|forward|backward
> for the highway, and road=yes for the railway.
>
> From the previous example (the picture points at the opposite direction of
> the highway on which it was taken:
>
> For the center way (road):
>
> tram=yes (it's on both directions)
>
> and on the two railways:
> road=yes (the track lies on a road used by motor vehicles)
>
> We could also user a lanes modifier:
> lanes=3
> lanes:backward=2
> tram:lanes:backward=yes|no
> tram:forward=yes
>
> The tram tag should not be used for tracks which run separated from the
> road (they are tagged with railway=tram).
>
> The tram tag should go along with access tags, as we have lanes reserved
> for trams and buses/taxis:
>
> http://wiki.openstreetmap.org/wiki/File:Tram_xxii_marzo.jpg
>
> So the center way (carriageway reserved to psv with two tram tracks in
> shared space) would get tagged as:
> access=no
> bus=yes
> taxi=yes
> tram=yes
>
> We could also think about a relation, type=tram_on_road, it could be
> useful for sorting things out in complex multi-carriageway situations like
> this one:
>
> https://www.openstreetmap.org/#map=19/45.49833/9.19607
>
> but would also be more difficult for users to mantain and for clients to
> consume.
>
> Any suggestions / impressions?
>
> Thanks!
>
> Sig
>
> ___
> 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] Tram tracks running in a road

[Volker Schmidt]

Ciao,

hai guardato come l'hanno fatto altre città che hanno tram su strada? Mi
vengono in mente:
Strasbourg, Muenchen, Karlsruhe, San Francisco, Basel,  ...

Cari saluti

Volker
Padova, Italy

On 6 February 2015 at 17:29, Luca Sigfrido Percich 
wrote:

> Hi all,
>
> first time I write to the list (after lurking for a while), so I introduce
> myself. I am from Milano - Italy, I work for the municipality's agency for
> environment and mobility, and we'we been working for the last months to
> integrate our road graph with OSM.
>
> Currently in Milano all tram tracks are mapped separately, so they are all
> oneway and no way has both highway=* and railway=tram tags (apart from some
> cases we're correcting).
>
> Now, we would like to store the information wether a certain railway track
> runs in a road sharing the same space with motor vehicles.
>
> I am referring to situations similar to this one:
>
> http://wiki.openstreetmap.org/wiki/File:Tram_Amadeo.jpg
>
> Which is here on the map:
>
> https://www.openstreetmap.org/#map=19/45.470987/9.236118
>
> I searched the wiki for a tagging or relation scheme, but found none.
>
> I was thinking about a simple tagging scheme: tram=yes|forward|backward
> for the highway, and road=yes for the railway.
>
> From the previous example (the picture points at the opposite direction of
> the highway on which it was taken:
>
> For the center way (road):
>
> tram=yes (it's on both directions)
>
> and on the two railways:
> road=yes (the track lies on a road used by motor vehicles)
>
> We could also user a lanes modifier:
> lanes=3
> lanes:backward=2
> tram:lanes:backward=yes|no
> tram:forward=yes
>
> The tram tag should not be used for tracks which run separated from the
> road (they are tagged with railway=tram).
>
> The tram tag should go along with access tags, as we have lanes reserved
> for trams and buses/taxis:
>
> http://wiki.openstreetmap.org/wiki/File:Tram_xxii_marzo.jpg
>
> So the center way (carriageway reserved to psv with two tram tracks in
> shared space) would get tagged as:
> access=no
> bus=yes
> taxi=yes
> tram=yes
>
> We could also think about a relation, type=tram_on_road, it could be
> useful for sorting things out in complex multi-carriageway situations like
> this one:
>
> https://www.openstreetmap.org/#map=19/45.49833/9.19607
>
> but would also be more difficult for users to mantain and for clients to
> consume.
>
> Any suggestions / impressions?
>
> Thanks!
>
> Sig
>
> ___
> 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] Tram tracks running in a road

[Luca Sigfrido Percich]

Hi all,

first time I write to the list (after lurking for a while), so I introduce
myself. I am from Milano - Italy, I work for the municipality's agency for
environment and mobility, and we'we been working for the last months to
integrate our road graph with OSM.

Currently in Milano all tram tracks are mapped separately, so they are all
oneway and no way has both highway=* and railway=tram tags (apart from some
cases we're correcting).

Now, we would like to store the information wether a certain railway track
runs in a road sharing the same space with motor vehicles.

I am referring to situations similar to this one:

http://wiki.openstreetmap.org/wiki/File:Tram_Amadeo.jpg

Which is here on the map:

https://www.openstreetmap.org/#map=19/45.470987/9.236118

I searched the wiki for a tagging or relation scheme, but found none.

I was thinking about a simple tagging scheme: tram=yes|forward|backward for
the highway, and road=yes for the railway.

>From the previous example (the picture points at the opposite direction of
the highway on which it was taken:

For the center way (road):

tram=yes (it's on both directions)

and on the two railways:
road=yes (the track lies on a road used by motor vehicles)

We could also user a lanes modifier:
lanes=3
lanes:backward=2
tram:lanes:backward=yes|no
tram:forward=yes

The tram tag should not be used for tracks which run separated from the
road (they are tagged with railway=tram).

The tram tag should go along with access tags, as we have lanes reserved
for trams and buses/taxis:

http://wiki.openstreetmap.org/wiki/File:Tram_xxii_marzo.jpg

So the center way (carriageway reserved to psv with two tram tracks in
shared space) would get tagged as:
access=no
bus=yes
taxi=yes
tram=yes

We could also think about a relation, type=tram_on_road, it could be useful
for sorting things out in complex multi-carriageway situations like this
one:

https://www.openstreetmap.org/#map=19/45.49833/9.19607

but would also be more difficult for users to mantain and for clients to
consume.

Any suggestions / impressions?

Thanks!

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

Re: [Tagging] Feature Proposal - RFC - Reception Desk

[John F. Eldredge]

On February 6, 2015 9:37:20 AM CST, Tobias Knerr  wrote:
> On 06.02.2015 12:16, Dan S wrote:
> > However it occurs to me that it would be useful to have some way of
> > indicating _what_ it is the reception for. For example, if it was
> part
> > of a "site" relation*, then a role like role=reception would connect
> > it to the larger entity in a meaningful way. That might be a
> suggested
> > tagging option...
> 
> I believe this is not necessary as long as the reception is contained
> in
> only one outline of a relevant feature (hotel, motel etc.), which will
> cover almost all cases. Of course, for the special cases you could use
> a
> relation, but that should be limited to those cases.
> 
> What I consider a bit odd, by the way, is the amenity key. Receptions
> are usually not amenities by themselves, but instead part of an
> amenity.
> Perhaps a new key for this kind of sub-feature would be in order?
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

One circumstance where the relation would be useful would be if you were 
mapping an office building, and wanted to map both the reception desk for the 
entire building, and also reception desks for individual office suites within 
that building. This is a common circumstance when a building contains offices 
for several different companies.

-- 
John F. Eldredge -- j...@jfeldredge.com
"Darkness cannot drive out darkness: only light can do that. Hate cannot drive 
out hate: only love can do that." -- Martin Luther King, Jr.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Reception Desk

[Tobias Knerr]

On 06.02.2015 12:16, Dan S wrote:
> However it occurs to me that it would be useful to have some way of
> indicating _what_ it is the reception for. For example, if it was part
> of a "site" relation*, then a role like role=reception would connect
> it to the larger entity in a meaningful way. That might be a suggested
> tagging option...

I believe this is not necessary as long as the reception is contained in
only one outline of a relevant feature (hotel, motel etc.), which will
cover almost all cases. Of course, for the special cases you could use a
relation, but that should be limited to those cases.

What I consider a bit odd, by the way, is the amenity key. Receptions
are usually not amenities by themselves, but instead part of an amenity.
Perhaps a new key for this kind of sub-feature would be in order?


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

Re: [Tagging] Access restrictions for shoulder lanes?

[fly]

Am 06.02.2015 um 14:00 schrieb Bryce Nesbitt:
> In the USA occasional sections of even Interstate highways are open to
> bicycles,
> where no equivalent route exists. There's some argument to tag these as
> bike paths to avoid the tag soup of lanes,
> and ensure the (unusual) situation is perfectly clear.

Why is bicycle=yes and motorroad=no not enough ?

Please no separate ways, as you loose the information that you are using
a motorway and might looking forward to find a nice bicycle path.

cu fly


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

Re: [Tagging] Access restrictions for shoulder lanes?

[Bryce Nesbitt]

In the USA occasional sections of even Interstate highways are open to
bicycles,
where no equivalent route exists. There's some argument to tag these as
bike paths to avoid the tag soup of lanes,
and ensure the (unusual) situation is perfectly clear.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Reception Desk

[Janko Mihelić]

Why not tourism=reception_desk? We have tourism=hotel, tourism=camp_site,
tourism=information, it's only logical to use the same key.


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

Re: [Tagging] Feature Proposal - RFC - Reception Desk

[johnw]

> On Feb 6, 2015, at 2:18 PM, Paul Johnson  wrote:
> 
> This seems to have a bit of overlap with information to a large extent.  Most 
> have tourism information for the area they're located and vicinity and can 
> provide a lot of the same stuff as a general tourism information office 
> would.  They just also rent space to park an RV (or even an RV or cabin), or 
> throw up a tent.
> 
> 

-1

information is a place to get information, usually tourist information. 

Where to actually go to register for your space / hotel room / name badge / 
visitor check-in / visitor-checkout is a very different concept than an info 
kiosk or tourist info desk. 

Most large train stations have information booths. but its different than the 
ticketing window. 

Most hotels have a large reception desk. the information booth outside for 
tourists passing by is a information point. 

a reception desk at a hotel also has the ability to order food, but we would 
not confuse that with a restaurant. 

considering the phase “reception” is so widely used int he hospitality 
industry, and it can also be used for check-in at a motel, camp, or other 
corporate facility that handles visitors along with the working staff (like a 
big company office or complex where one building or space is designated 
reception for the visitors. 

It seems like a good idea to have the amenity. ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Reception Desk

[Dan S]

Hi,

No big objections from me, sounds useful.

However it occurs to me that it would be useful to have some way of
indicating _what_ it is the reception for. For example, if it was part
of a "site" relation*, then a role like role=reception would connect
it to the larger entity in a meaningful way. That might be a suggested
tagging option...

Best
Dan


* http://wiki.openstreetmap.org/wiki/Relations/Proposed/Site



2015-02-06 2:03 GMT+00:00 Warin <61sundow...@gmail.com>:
> Hi,
>
> Request for comment on new tag 'amenity=reception_desk'
>
> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dreception_desk
>
> This comes out of the tag ON HT E tourism=camp_site WIKI PAGE which has a
> sub key of camp_site=reception.
>
> As 'Receptions' are numerous outside of camp sites I think it is best to
> have them available for use under other things - like hotels. So the new
> tag.
>
> 'reception_desk' .. should separate it from other types of receivers .. like
> radio receivers.
>
> Amenity is the best fit so amenity=reception_desk.
>
> what do you think?
>
>
>
>
>
> ___
> 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 - RFC - Reception Desk

[Kotya Karapetyan]

I think this proposal is very relevant for some larger hotel and
resorts. I've been myself a few times in a situation when I had to
search for the reception over a large area. It can be a trouble if you
simultaneously have to get rid of your car in a parking restricted
area. Same for multi-entrance campuses where only one door can be used
by guests (has a reception).

On Fri, Feb 6, 2015 at 6:18 AM, Paul Johnson  wrote:
> This seems to have a bit of overlap with information to a large extent.
> Most have tourism information for the area they're located and vicinity and
> can provide a lot of the same stuff as a general tourism information office
> would.  They just also rent space to park an RV (or even an RV or cabin), or
> throw up a tent.
>
> On Feb 5, 2015 8:07 PM, "Warin" <61sundow...@gmail.com> wrote:
>>
>> Hi,
>>
>> Request for comment on new tag 'amenity=reception_desk'
>>
>> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dreception_desk
>>
>> This comes out of the tag ON HT E tourism=camp_site WIKI PAGE which has a
>> sub key of camp_site=reception.
>>
>> As 'Receptions' are numerous outside of camp sites I think it is best to
>> have them available for use under other things - like hotels. So the new
>> tag.
>>
>> 'reception_desk' .. should separate it from other types of receivers ..
>> like radio receivers.
>>
>> Amenity is the best fit so amenity=reception_desk.
>>
>> what do you think?
>>
>>
>>
>>
>>
>> ___
>> 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 - RFC - temperature

[Kotya Karapetyan]

1) +1 to drop Kelvins.

2) heated/cooled is a nice idea, but I wouldn't like seeing too many
top level tags.

temperature=heated
temperature=cooled
would be my preferred way to go.

I don't like :hvac too much either, because then what do I do if I
have AC + fireplace + central heating and use all of them for heating?
I would rather, if needed, use
temperature=heated
temperature:heated=fireplace|HVAC

3) +1 for having "mild" added. It is not the same as "ambient" and is useful.

Cheers,
Kotya

On Thu, Feb 5, 2015 at 9:14 PM, Warin <61sundow...@gmail.com> wrote:
> On 5/02/2015 1:02 AM, fly wrote:
>
> Am 04.02.2015 um 10:56 schrieb Kotya Karapetyan:
>
> Hi,
>
> +1 for the proposal as such.
>
> I have suggestions for some parts of the proposal though.
>
> 1) I would discourage specification of the temperature without the
> scale indication. I have never lived in the US but I see from the Web
> that Americans like specifying temperature in degrees Fahrenheit
> without mentioning it (the same way as we in Europe use centigrade
> without underlying it). Taking into account the international nature
> of the OSM community, I foresee a significant risk that the map will
> get populated with invalid values. Warin is right about SI units, but
> SI is not even strictly followed in the technical and scientific
> community, not to mention the general public. Obviously, Americans in
> general ignore it by using inches, miles and degrees Fahrenheit :) I
> am afraid many people will not have heard about SI guidelines and will
> not have read the wiki page in significant detail.
>
> Therefore, for the sake of clarity, I suggest always specifying "F" or
> "C" with the temperature value.
>
> +1
> Units for temperature are really wired and obviously Kelvin which I
> would suspect to be the default is not really used in real live as
> Celsius has the better scale for real life usage.
>
>
> I'm inclined to drop the Kelvin. Unlikely to be used, anyone using the
> Kelvin can easily convert it to degrees Celsius.
>
> 2) I suggest clarifying the verbal specification of the temperature.
> - Replace "chilled" with "cool" (by analogy with "warm") and also
> because "chilled" actually assumes that I know that the object was
> purportedly cooled down, which adds yet another uncertainty and is
> usually not very relevant;
> - remove the definition of "substantially colder" etc., because it
> doesn't add any clarity. I agree that it is important to distinguish
> between safe and unsafe situations, so let's just do that:
>
>
> I put that in to cover the 'chilled water' that some might have or come
> across. Maybe more of a hot climate thing? I think the users may include it
> anyway so I covered it in the documentation.
>
> freezing
> cold — may be unsafe to handle
> cool
> warm
> hot — may be unsafe to handle
> boiling
> adjustable — the object temperature can be changed by consumer/user
> variable — the object temperature can vary on its own
> ambient — the object always remains at ambient temperature (note that
> this may include the object being "cold" and "warm", including being
> unsafe to handle, depending on the ambient temperature; think about
> water in Siberia rivers in January)
>
> Only two values I could live with are cold and hot. Generally these
> values are too ambiguous and an estimated value is much better.
>
>
> I think I said this .. but here it is again with some more thoughts?
>
> The proposal only tags 3 conditions;
> adjustable - box outline around the originally rendered symbol - red at the
> top fading to blue at the bottom
> hot - box outline around the originally rendered symbol - red
> cold -box outline around the originally rendered symbol - blue
>
> For the numerical data rendered as above for hot if over 55 C and blue if
> under 0 C ??
>
> 3) For the numeric specification, I suggest adding:
> - "above"/"below" options
> - "approximate" value
> - range of temperatures (using above/below)
>
> E.g.
> temperature:circa = 80 C
> temperature:above[:circa] = 300 C
> temperature:below[:circa] = 1000 C
>
> I would add this in the value like:
>
> temperature = < 10 C
> temperature = > 300 C
>
>
> Nice idea. But;
> How many object in OSM need that kind of information? If the usage is low
> then it probably wont be rendered.
> How many data entry people will know the max/mins for an OSM object?
> And how would it be rendered?
>
> Possibly a better tag for this would be temperature_maximum= and
> temperature_minimum=
>
> ___
> 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 - RFC - temperature

[John Willis]

If we're going to have a temperature key - there should be some qualitative 
values in human understandable ranges. Yes, they are subjective. 

Cool/ cold / frozen / danger-cold
Warm / hot / boiling / danger-hot

Mild (human range comfortable, both hot and cold) 

This allows tagging for objects / pipes / buildings with unexpected 
temperatures.  there are refrigerators (cold) sub-zero freezers (danger-cold) 
and exposed steam pipes (Danger-hot) which have very different temperatures 
from their ambient environment - and knowing the exact temp of the freezer, or 
the range it operates in is not so useful, but knowing that it is someplace 
where if you stayed there, it could kill you is very useful. 

There could also be a sublet value to define class of method, if the object 
itself isn't the source of the temperature (aka a steam pipe is inherently hot, 
but a room is made hot by a device or method)

temperature=mild
temperature:hvac=controlled (heated&cooled) 

temperature=warm
temperature:hvac=heated

temperature=warm
temperature:fire=heated

temperature=danger-cold
temperature:hvac=cooled

temperature=-20 (c)
temperature:hvac=cooled

(freezer warehouse where the value is constant and known)

Filing all the different man made heating options (radiator, electric heater, 
oil boiler) it all gets filed under HVAC (heating ventilation air 
conditioning), as method might be very hard to determine how something is kept 
warm, but it could be filed in the hvac subkey. 

Temperature:hvac=kerosene_heater

Temperature:fire=wood_fireplace

Just my ideas, not sure how well they fit - but having some kinds of 
qualitative values is important, as the range is more useful than the exact 
number most of the time. 

Javbw


> On Feb 6, 2015, at 9: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.
> ___
> 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] Wiki on amenity=waste_disposal Rewrite?

[Warin]

On 5/02/2015 12:04 PM, Dave Swarthout wrote:


On Thu, Feb 5, 2015 at 7:10 AM, Warin <61sundow...@gmail.com 
> wrote:


You mean a one step? Like highway= x ?

To do that I'd think a new supper key   waste=   at the top level!
And maybe that is what it needs! If there are enough different
kinds then why not?
waste=rubbish_bin
waste=skip_bin
waste=dump_point
waste=chemical_toilet
waste=dog_excrement
waste=sharps
waste=cigarettes
waste=excrement

What does it take to justify a top level tag? 



I think he means that if we use a top level amenity tag like 
amenity=waste_disposal we are forced to make another whole set of sub 
keys to describe the waste being disposed of. At least that's where my 
criticism comes from. If however we can agree on a tag of 
amenity=dump_point and define it as "a facility where one can dump or 
discharge the waste tanks of an RV or recreational boat" it can be 
understood and rendered by evaluating only that single tag.


Whether the waste being dumped is from a "chemical toilet" or from a 
plastic bag on a "porta-potty" or "cassette"  then becomes irrelevant. 
The facility will handle it.


This new top level tag might make the approval process easier too. 
Standing alone as it would, it nicely separates garbage and trash, or 
recyclables, from sewage and doesn't require any other potentially 
lengthy approvals for new subkeys.
The present sub tag already exists and is in use .. for oil, cigarettes, 
grey_water, drugs, dog_excrement, etc .. so they still have to be 
evaluated for a true render of the facility. If what is required is a 
one tag entry for each waste type then amenity= will be over loaded eg


amenity=waste_dog_excrement
amenity=waste_cigarettes
amenity=waste_sharps

Note the inclusion of waste in the name .. so people don't think that 
they are places that sell the stuff! :)


about 8 + around 28! if you include waste recycling...
 and I think it then needs to be a top level tag .. like shop=, 
tourism=. sport= etc. as there are too many of them .. and that would be 
opposed as it is a lot of work to change the present data and a lot of 
work to change the renders... at least another category of amenity ... 
presently


 * 2.1 Sustenance
   
 * 2.2 Education 
 * 2.3 Transportation
   
 * 2.4 Financial 
 * 2.5 Healthcare
   
 * 2.6 Entertainment, Arts & Culture
   

 * 2.7 Others 

Add  '2.8 Waste'?  I don't know.. just pointing out the possible future 
problems?





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