Re: [Tagging] How can I tag which lane has tram tracks?

[Jarek Piórkowski]

On Mon, 6 Jul 2020 at 20:15, Jarek Piórkowski  wrote:
> On Mon, 6 Jul 2020 at 15:56, Mateusz Konieczny via Tagging
>  wrote:
> > ...
> > tram:lanes:forward=designated|none
> > tram:lanes:backward=designated|none
> ...
> Looks like tram:lanes variations have around 1100 uses right now,
> embedded_rails variations around 5700 uses. I'm actually not sure if
> they mean something different?

I'm sorry, I realized I got the use count comparison wrong because I
included the non-lane-specific embedded_rails tags.

* embedded_rails:lanes plus embedded_rails:lanes:both_ways plus
embedded_rails:lanes:backward plus embedded_rails:lanes:forward is
used 610 times

* tram:lanes plus tram:lanes:forward plus tram:lanes:backward is used
1035 times - so more

I've not really seen tram:lanes tagging before, how is it used?

Looks like a substantial amount of the uses is tram:lanes:forward=yes
(364 uses) and tram:lanes:backward=yes (317) - mostly on two-lane
streets in Helsinki? tram:lanes:forward=designated|none would indeed
fit that schema.

--Jarek

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

Re: [Tagging] How can I tag which lane has tram tracks?

[Jarek Piórkowski]

On Mon, 6 Jul 2020 at 15:56, Mateusz Konieczny via Tagging
 wrote:
> I guess that something similar to
> https://wiki.openstreetmap.org/wiki/Lanes#Crossing_with_a_designated_lane_for_bicycles
> would fit.
>
> For example for road that has:
>
> - tram-free lane
> - lane with tram tracks
> - lane with tram tracks in an opposite direction
> - tram-free lane in an opposite direction
>
> could be tagged
>
> tram:lanes:forward=designated|none
> tram:lanes:backward=designated|none

I'm not sure - does this add something that embedded_rails:lanes=*
does not specify?

If you have the tram tracks already mapped as their own ways, I'd just
do embedded_rails:lanes=|tram|tram| on the street way.

Looks like tram:lanes variations have around 1100 uses right now,
embedded_rails variations around 5700 uses. I'm actually not sure if
they mean something different?

Actually I guess they might since there's some abandoned tracks here
(e.g. https://osm.org/way/553562816 + https://osm.org/way/553562815 )
where embedded rails still exist but trams don't have a legal access
(or physical access), so strictly speaking the street way would be
embedded_rails:lanes=|tram|tram + tram:lanes:forward=|no|no... but I'm
not sure if that's what you meant?

--Jarek

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

Re: [Tagging] How to map terrace buildings with names

[Paul Allen]

On Mon, 6 Jul 2020 at 21:42, Joseph Eisenberg 
wrote:

> According to the wiki page about building=terrace, it is usually best
> practice to map each house as a separate area (closed way) object.
>
> "A more detailed and recommended alternative is to map each dwelling
> separately using building
> =house
> , but keeping
> at least two nodes in common for adjoining houses."
>
> https://wiki.openstreetmap.org/wiki/Tag:building%3Dterrace
>
> If you map each house individually, it is not necessary to map the whole
> outline of the row of houses.
>

Based purely upon my own idiosyncratic interpretation, I came to the
conclusion that I would use building=terrace for a row of terraced houses
where I did not have the time to ascertain the numbers on a survey or
was working from aerial imagery.  I view it as a placeholder.  There are
some house there but I don't know where the individual boundaries are
and I can only give you a range of addresses, if that.

Then, after having replaced a terrace mapped by somebody else with
individual houses, I came to the conclusion that I wouldn't bother mapping
things as terraces - too much effort for too little gain if I intended to
replace them at a future date.

I see no point in wrapping individually-mapped houses in a terrace.  If
they're conjoined then it's already obvious that they're part of a terrace.

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

Re: [Tagging] How to map terrace buildings with names

[Skyler Hawthorne]

> I'm also, in a more general sense, raising a question about the
> established conventions and whether it makes sense to be tagging the
> individual units as "buildings", when they are not really buildings
> in and of themselves, but sections of one larger building that
> contains several other units.
> 

To expand on this a bit, for example, if we are tagging a shopping
center that has one large building which contains several individual
shops, you tag the whole building with building=retail and amenity=* or
shop=*, not building=shop or something like that. It's just curious
that for terraces, the convention is to tag each individual unit as a
building in its own right.

--
Skyler


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

Re: [Tagging] How to map terrace buildings with names

[Skyler Hawthorne]

On Mon, 2020-07-06 at 13:40 -0700, Joseph Eisenberg wrote:
> According to the wiki page about building=terrace, it is usually best
> practice to map each house as a separate area (closed way) object. 
> 
> "A more detailed and recommended alternative is to map each dwelling
> separately using building=house, but keeping at least two nodes in
> common for adjoining houses."
> 
> https://wiki.openstreetmap.org/wiki/Tag:building%3Dterrace
> 
> 
> If you map each house individually, it is not necessary to map the
> whole outline of the row of houses.
> 
> – Joseph Eisenberg

Thanks for your reply. It may not be "necessary", but it is what I
desire (in order to name each building), and I'm asking if there's a
tagging scheme to do this that makes sense.

I'm also, in a more general sense, raising a question about the
established conventions and whether it makes sense to be tagging the
individual units as "buildings", when they are not really buildings in
and of themselves, but sections of one larger building that contains
several other units.
-- 
Skyler
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to tag a light that is always green for certain directions?

[Matthew Woehlke]

On 06/07/2020 15.28, Shawn K. Quinn wrote:

On 7/6/20 12:59, Matthew Woehlke wrote:

https://www.openstreetmap.org/node/7688734125 is a traffic light that is
always green for straight traffic (left turns get a cycle). Is there a
way to tag this?

(I recall seeing a way to tag a signal as always green, but a) IIRC it
didn't distinguish always green *only* for certain directions, and
anyway b) I can't find it again, even using the wiki search or Google.)


traffic_signals=continuous_green for the approach that has a continuous
green. The left turn traffic should have a standard traffic signal node.


I can't see how that can work. The intersection has a "single" light 
(single cluster of signals, anyway; one signal per lane as is often the 
case), and is a fairly typical three-lane highway (three lanes 
westbound, that is). The lanes are not separated in any way aside from 
lane markings. Unless I am *completely* misunderstanding you (always 
possible), the only way what you're proposing would work is if the left 
turn lane was modeled as a separate way from where the turn lane starts, 
which is a) a pain to model, and b) just not done AFAICT (and very 
likely not recommended either!).


See 
https://www.google.com/maps/@42.8624981,-73.7768253,3a,75y,276.06h,92.31t/data=!3m6!1e1!3m4!1swTw_2p-hAbi7yl-tRuPloQ!2e0!7i16384!8i8192.


Moreover, I'm reasonably confident I've seen *actual* single signals 
that were always green for one direction (e.g. a four-lamp signal with 
red/yellow/green 'up' arrows and an always-on green right arrow).


Maybe we need something like traffic_signals:through=continuous_green? I 
suppose we could also do traffic_signals:lanes, but that seems fraught 
with parsing pitfalls, and wouldn't work anyway for e.g. a signal on a 
single lane that always has a green right arrow but a regular cycle for 
other traffic.


--
Matthew

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

Re: [Tagging] How to map terrace buildings with names

[Joseph Eisenberg]

According to the wiki page about building=terrace, it is usually best
practice to map each house as a separate area (closed way) object.

"A more detailed and recommended alternative is to map each dwelling
separately using building 
=house , but
keeping at least two nodes in common for adjoining houses."

https://wiki.openstreetmap.org/wiki/Tag:building%3Dterrace

If you map each house individually, it is not necessary to map the whole
outline of the row of houses.

– Joseph Eisenberg

On Mon, Jul 6, 2020 at 1:21 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 6. Jul 2020, at 20:45, Skyler Hawthorne  wrote:
> >
> > Are there any alternative schemes? Is there a tag to indicate that a
> closed way represents a "dwelling" or "housing unit", but not a standalone
> building in and of itself? Or, what if I tagged the whole building with
> building=terrace, and then the ways inside just have address tags?
>
>
> there is the key “building:part” which might eventually fit for the single
> units (I never mapped a terraced house and am not familiar with how they
> are usually mapped).
>
> Cheers Martin
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to map terrace buildings with names

[Martin Koppenhoefer]

sent from a phone

> On 6. Jul 2020, at 20:45, Skyler Hawthorne  wrote:
> 
> Are there any alternative schemes? Is there a tag to indicate that a closed 
> way represents a "dwelling" or "housing unit", but not a standalone building 
> in and of itself? Or, what if I tagged the whole building with 
> building=terrace, and then the ways inside just have address tags?


there is the key “building:part” which might eventually fit for the single 
units (I never mapped a terraced house and am not familiar with how they are 
usually mapped).

Cheers Martin 


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

Re: [Tagging] How to map terrace buildings with names

[Andy Mabbett]

On Mon, 6 Jul 2020 at 19:43, Skyler Hawthorne  wrote:

> 1. Draw a way around the whole building and tag it with building=terrace,
> and then add entrance nodes with addresses, or
> 2. Draw the outline of the terrace builiding, but then make ways inside the
> building to create detailed borders of the individual properties inside the
> terrace  building, and map each of those ways with building=house with the
> address.

if you're using JOSM, the "Terracer" plug-in:

   https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Terracer

will do your second option for you, in one process, and very well.

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

[Tagging] How can I tag which lane has tram tracks?

[Mateusz Konieczny via Tagging]

I guess that something similar to
https://wiki.openstreetmap.org/wiki/Lanes#Crossing_with_a_designated_lane_for_bicycles
would fit.

For example for road that has:

- tram-free lane
- lane with tram tracks
- lane with tram tracks in an opposite direction
- tram-free lane in an opposite direction

could be tagged

tram:lanes:forward=designated|none
tram:lanes:backward=designated|none
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to tag a light that is always green for certain directions?

[Shawn K. Quinn]

On 7/6/20 12:59, Matthew Woehlke wrote:
> https://www.openstreetmap.org/node/7688734125 is a traffic light that is
> always green for straight traffic (left turns get a cycle). Is there a
> way to tag this?
> 
> (I recall seeing a way to tag a signal as always green, but a) IIRC it
> didn't distinguish always green *only* for certain directions, and
> anyway b) I can't find it again, even using the wiki search or Google.)

traffic_signals=continuous_green for the approach that has a continuous
green. The left turn traffic should have a standard traffic signal node.

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

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

[Tagging] How to map terrace buildings with names

[Skyler Hawthorne]

Hello. I am mapping a housing development that has a few terrace
buildings that each have several town homes that share walls. From what
I've gathered from the wiki, you can either:

1. Draw a way around the whole building and tag it with
building=terrace, and then add entrance nodes with addresses, or
2. Draw the outline of the terrace builiding, but then make ways inside
the building to create detailed borders of the individual properties
inside the terrace  building, and map each of those ways with
building=house with the address.

I like having the borders of each home, so I want to do the second
option, but the other issue I'm thinking about is each building is
numbered, so I  would like to name the whole building, but how would I
tag this? Having a way on the outline of the building with only a name
tag seems wrong, but it also seems wrong to tag it with
building=terrace if the individual units are tagged with
building=house; it would seem like having buildings inside buildings,
which Osmose actually complains about.

Are there any alternative schemes? Is there a tag to indicate that a
closed way represents a "dwelling" or "housing unit", but not a
standalone building in and of itself? Or, what if I tagged the whole
building with building=terrace, and then the ways inside just have
address tags?

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

[Tagging] How to tag a light that is always green for certain directions?

[Matthew Woehlke]

https://www.openstreetmap.org/node/7688734125 is a traffic light that is 
always green for straight traffic (left turns get a cycle). Is there a 
way to tag this?


(I recall seeing a way to tag a signal as always green, but a) IIRC it 
didn't distinguish always green *only* for certain directions, and 
anyway b) I can't find it again, even using the wiki search or Google.)


--
Matthew

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

Re: [Tagging] How to tag correct number of lanes for freeway on/off ramps?

[Matthew Woehlke]

On 03/07/2020 17.53, Paul Johnson wrote:

On Fri, Jul 3, 2020 at 3:19 PM Matthew Woehlke wrote:

Consider https://www.openstreetmap.org/#map=17/42.85888/-73.77169. As I
write this, I-87 is annotated as having 3 lanes south of the on/off
ramps (south of 146). However, the off ramp starts all the way back at
the Sitterly Road overpass, and the on ramp doesn't fully merge until
just before the emergency vehicle turn-around only slightly north of
said overpass. Accordingly, there are actually four lanes for these
stretches.

What is the correct way to model this?


It's hard for me to explain so try the example in
https://www.openstreetmap.org/changeset/87518597#map=14/42.8442/-73.7720 on
for size?


Thanks! In particular, TIL about the `placement` tag. Actually, the 
proposal page for that is rather helpful.


A couple notes, though: you missed a transition, and IIUC, the `turns` 
should instead be `|||slight_right`, since there is no explicit 
'straight only' marking. (Strictly speaking, there is no *explicit* 
marking for 'slight right' either, but it's implied by the fact that 
you're in a turn lane. I wonder if we should have a way to tag that 
separately? Anyway, I would hope that having the lane so tagged — I also 
tagged the on ramps |||merge_left — will encourage tools to not 
gratuitously route into those lanes only to need to leave them 
immediately, i.e. a better and more correct version of merge prohibition.)


Anyway, I hopefully cleaned up most of the stuff for the on/off ramps 
here. (Hmm, I skipped the north-most on ramp though, maybe I'll do that 
one later.)


It seems I need to take a look at JOSM, I've been wanting something that 
actually renders lanes... BTW, my "ultimate" goal, potentially, is to 
have fully and correctly modeled lane placement and connectivity. I'm 
working on traffic simulation with SUMO and basically need to be able to 
do perfect imports from OSM without having to clean up the network 
afterward. Plus, it can't hurt routing engines for this stuff to be correct.


--
Matthew

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

Re: [Tagging] R: Are we mapping ground on OSM?

[Martin Koppenhoefer]

Am Mo., 6. Juli 2020 um 08:22 Uhr schrieb Michael Montani <
michael.mont...@un.org>:

> It seems to me that up to now there is a duality of tagging in OSM for
> landcover: basically there are some tags that refer to 'what's on the
> imagery' (eg. natural=sand, natural=rock ...) and others which focus on the
> geological meaning of the feature (natural=shingle, natural=scree ...).
>


yes, admittedly, this has become quite inconsistent and blurred, because
some people see natural as "mother nature", not altered /made by humans,
describing a material (mud, sand), while other features are more in the
sense of (geological) _features_ (beach, spring, cave, wetland, ...)



> By the way it seems to me very strange that there is nothing there for a
> straightforward feature as ground: compacted soil with very few or no
> vegetation, which can be of mineral or organic nature.
>


IMHO the distinction between mostly of mineralic or of organic nature would
be quite important (how much water can be stored or is it draining).
Compacted organic soil might not store water initially, but when it becomes
wet it will become less compacted. Bedrock to me seems to be a kind of
ground (you seem to think otherwise). The term "ground" does not imply
"compacted" for me.



> Open global coverage dataset can definetely help to map landcover and many
> ones are out there. The discussion is not about seasonality of lakes but
> generally on ground.
>


global coverage datasets tend to be so generalized and large scale that
they often do not fit well with the human scale that we survey on the
ground.



> To me, a tag proposal *natural=ground*, *ground:type=organic/mineral* with
> the further possibility to specify soil type seems reasonable.
>


I guess I would make this "landcover" and "bare_ground" or something like
this (although as was mentioned, this may vary seasonally. Generally,
mapping seasonal variations is a challenge we are not set up well to deal
with).

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

[Tagging] R: Are we mapping ground on OSM?

[Michael Montani]

> there is natural=bare_rock for some cases, generally I would go with 
> landcover tags. Knowing the composition of the material would be interesting 
> to understand what to expect when it is wet.

natural=bare_rock 
is about bedrock, not related at all with ground. 
landcover=* 
would fit for this purpose, but it is a proposal as well and the wikipage has 
been updated since long time. Furthermore I believe landcover=* would be a 
duplication of already existing tags (eg. natural=wood and landcover=trees).

> We have established and usually quite consistently used tags for a number of 
> fairly specific natural or semi-natural non-vegetated surfaces - 
> natural=bare_rock, natural=scree, natural=shingle, natural=sand and 
> natural=mud and more specifically in coastal environments natural=beach, 
> natural=shoal, natural=reef and natural=wetland + wetland=tidalflat.  It 
> would therefore be rather counterproductive to introduce a new umbrella tag 
> engrossing those like natural=bare_ground.

It seems to me that up to now there is a duality of tagging in OSM for 
landcover: basically there are some tags that refer to 'what's on the imagery' 
(eg. natural=sand, natural=rock ...) and others which focus on the geological 
meaning of the feature (natural=shingle, natural=scree ...). By the way it 
seems to me very strange that there is nothing there for a straightforward 
feature as ground: compacted soil with very few or no vegetation, which can be 
of mineral or organic nature. This, as I told you, would be super useful for 
off-road navigation (to know if your car/motorbike/tank will get stuck into the 
mud).

I agree by the way that dried lakes are mostly mapped with natural=wetland + 
intermittent=yes, which makes sense and again refers to the role that natural 
feature is playing in the environment. But a tag on ground will possibly cover 
all the other cases, as I find it's a huge gap in landcover tagging.

>The local, regional, or global Copernicus time series datasets are 
>specifically meant to overcome this. 
>https://land.copernicus.eu/global/products/
"The Water Bodies product detects the areas covered by inland water along the 
year providing the maximum and the minimum extent of the water surface as well 
as the seasonal dynamics. The area of water bodies is identified as an 
Essential Climate Variable (ECV) by the Global Climate Observing System (GCOS)."
The global ones are built of higher resolution datasets with variable 
accessibility. Like the JRC’s Global Surface Water (MWE-GSW) Dataset at  
https://global-surface-water.appspot.com/map ... "...location and temporal 
distribution of water surfaces at the global scale over the past 3.6 decades, 
and provides statistics on their extent and change ..."

Open global coverage dataset can definetely help to map landcover and many ones 
are out there. The discussion is not about seasonality of lakes but generally 
on ground.

To me, a tag proposal natural=ground, ground:type=organic/mineral with the 
further possibility to specify soil type seems reasonable.

Thanks,

--
Michael Montani
GIS Consultant, Client Solutions Delivery Section
Service for Geospatial Information and Telecommunications Technologies
United Nations Global Service Centre
United Nations Department of Operational Support

Brindisi | Phone: +39 0831 056985 | Mobile: +39 3297193455 | Intermission: 158 
6985
E-mail: michael.mont...@un.org | 
www.ungsc.org

[cid:aecd50ec-b315-4265-bf62-424fec50adeb]

Da: Michael Patrick 
Inviato: domenica 5 luglio 2020 22:01
A: tagging@openstreetmap.org 
Oggetto: Re: [Tagging] Are we mapping ground on OSM?


> Generally mapping bare ground beyond the specific established tags mentioned 
> earlier is often hard without local knowledge.  Imagery taken during dry 
> season will often read like bare ground while there is often fairly extensive 
> plant growth (like natural=grassland) that dries up and looks 
> indistinguishable from bare ground even on high resolution imagery.

The local, regional, or global Copernicus time series datasets are specifically 
meant to overcome this. https://land.copernicus.eu/global/products/

"The Water Bodies product detects the areas covered by inland water along the 
year providing the maximum and the minimum extent of the water surface as well 
as the seasonal dynamics. The area of water bodies is identified as an 
Essential Climate Variable (ECV) by the Global Climate Observing System (GCOS)."

The global ones are built of higher resolution datasets with variable 
accessibility. Like the JRC’s Global Surface Water (MWE-GSW) Dataset at  
https://global-surface-water.appspot.com/map ... "...location and temporal 
distribution of water surfaces at the global scale over the past 3.6 decades, 
and provides statistics on