Re: [Tagging] Feature Proposal - RFC - (Ground)

[Kevin Kenny]

On Fri, Jul 10, 2020 at 1:34 PM Matthew Woehlke
 wrote:
> > The car park in town, is that barren?
> If it's well maintained, hopefully it is. If it's crumbling, it might
> not be! My previous residence had a paved driveway that, strictly
> speaking, was not barren.

In a wet climate like the one I inhabit, truly barren surfaces are
rare.  Just a few days ago, I spotted these beauties growing in a
crack in the pavement _on a bridge_.  No real soil anywhere about!
They were rooted in whatever wind-blown material had accumulated
between the asphalt of the cycleway and the parapet of the bridge:
https://www.flickr.com/photos/ke9tv/50076407291 There are even a few
stray blades of grass taking root in the concrete.



-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Distinguishing closed office spaces and client service locations?

[Jarek Piórkowski]

On Fri, 10 Jul 2020 at 18:35, Graeme Fitzpatrick  wrote:
>> (I would probably use access=permissive for e.g. a mall parking lot,
>> where it's not strictly public, but where you wouldn't be expected to be
>> visiting a particular building or organization such that it's much less
>> clear whether or not you are a "customer".)
>
> I've usually left them as =public, but =permissive does seem a better option 
> - thanks!

Just a note that access=public is not a valid value according to some
strict OSM schemas. In particular, you will see carto rendering these
greyed out just as it does access=private or access=customers
(particularly visible on parking lot symbols). access=yes is the
prescribed value for "public access".

--Jarek

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

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

[Graeme Fitzpatrick]

On Sat, 11 Jul 2020 at 00:33, Matthew Woehlke 
wrote:

>
> - Semi-detached house: A set of row houses with exactly two connected
> units. (IMO this is a somewhat stupid distinction likely created by
> realtors for marketing purposes.)
>

& for us, that's a duplex eg
https://www.google.com.au/maps/@-27.9226702,153.3158076,3a,75y,185.34h,74.35t/data=!3m6!1e1!3m4!1skHhWw7oQyFFzrahW34YqgA!2e0!7i13312!8i6656?hl=en,
but there are also triplexes, which are 3 units together in a single
building.

On Sat, 11 Jul 2020 at 04:18, Martin Koppenhoefer 
wrote:

>  it is not so relevant for the international mailing list, because these
> things tend to work differently in different countries.
>

Which proves the impossibility of trying to get one term to cover all
possible aspects interchangeably worldwide :-(

Thanks

Graeme

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

Re: [Tagging] Distinguishing closed office spaces and client service locations?

[Shawn K. Quinn]

On 7/10/20 09:04, Matthew Woehlke wrote:
> (I would probably use access=permissive for e.g. a mall parking lot,
> where it's not strictly public, but where you wouldn't be expected to be
> visiting a particular building or organization such that it's much less
> clear whether or not you are a "customer".)

You would still most likely be expected to be a customer of some store
within the mall, whether you're just popping into the food court to get
a Big Mac from McDonald's for lunch or you're getting a new flat screen
TV from Macy's (or for that matter, just browsing in Macy's).

At least in the US, even though malls are nominally public spaces they
are still private property and many of them around here (Houston area)
specifically state certain non-shopping activities that will get you
bounced from the property (usually things like protesting or
unauthorized peddling).

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

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

Re: [Tagging] Feature Proposal - RFC - (Ground)

[Graeme Fitzpatrick]

On Fri, 10 Jul 2020 at 19:19, Michael Montani 
wrote:

>
> Tag: natural = bare_ground (but many other options are open to discussion).
> Description: "An area covered by soil, without any vegetation"
>

I agree that we need some way to tag areas like those in Somalia that you
posted, but I have some concerns about the definition " without *any*
vegetation"

Even those photos show that there is some vegetation there, even though
it's sparse.

At what level of plant growth, does it stop being "bare ground"? One
"plant" (tree / shrub / patch of grass etc) per sq km / 100 / 10 / 1 sq m?

Maybe, instead of saying it's bare ground, we need some way of describing
the level of ground cover eg vegetation=sparse or similar?

& while you say that it is a long-term thing, if you get decent rain, it
can change virtually (& sometimes literally!) overnight:

https://www.abc.net.au/news/2020-02-07/dams-start-to-fill-after-summer-rains-in-southern-queensland/11940556

Thanks

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

Re: [Tagging] Distinguishing closed office spaces and client service locations?

[Graeme Fitzpatrick]

On Sat, 11 Jul 2020 at 00:53, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
> I was thinking about space that explicitly welcomes walk-ins and exists
> solely to
> handle them (office of an energy company - handling issues such as
> resolving
> billing mistakes, handling overdue payments, attaching property to a
> power/gas
> network, changing gas/electricity provider, changing billing rules etc).
>

You then get the problem that customers are allowed to come in to the front
counter / service / reception area, but the rest of the office / building
is strictly staff only, so it would then need to be something like
office=company + access=private, together with a separate node
amenity=customer_service + access=customers on that counter area - messy :-(

Which one gets all the details like name, phone number, website etc - the
private back office, or the public reception area?

Thanks

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

Re: [Tagging] Distinguishing closed office spaces and client service locations?

[Graeme Fitzpatrick]

On Sat, 11 Jul 2020 at 00:05, Matthew Woehlke 
wrote:

>
> I think this makes sense also. To a previous point, I take
> access=customers to mean someone intending to visit the associated
> location, whether that's a store, a church, a doctor's office, ...
>
> BTW, I've used access=customers for parking lots that aren't
> *explicitly* marked 'customers only', but where I would expect the
> proprietors would nevertheless be annoyed by people just using their
> lots that aren't going to the associated store (or church, or ...) at
> all. Should I not do that? Is there a clear rule for when to use
> access=customers vs. access=permissive?
>

That's certainly the way I always do it, thinking exactly the same as you
do - it's not there for the general public to use, just visitors to that
shop / building.

(I would probably use access=permissive for e.g. a mall parking lot,
> where it's not strictly public, but where you wouldn't be expected to be
> visiting a particular building or organization such that it's much less
> clear whether or not you are a "customer".)
>

I've usually left them as =public, but =permissive does seem a better
option - thanks!

Thanks

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

Re: [Tagging] Feature Proposal - RFC - junction=intersection

[Tod Fitch]

> On Jul 10, 2020, at 9:26 AM, Matthew Woehlke  wrote:
> 
> On 10/07/2020 11.24, Peter Elderson wrote:
>> Well, if you do a couple of intersections it's no big deal, but if every
>> intersection would need this and it breaks relations, no matter whose fault
>> it is, it is a problem. Then it's not just modeling, but forced repair
>> work.

In the old days the wiki said you could put a highway=stop or highway=give_way 
node on a way and the data consumer would determine the nearest intersection 
and just do the right thing. I mapped several thousand, yes thousand, stop 
signs that way. Later it was decided that each of those nodes should also have 
a direction=forward or direction=backward tag as well. Years later, I am still 
updating those highway=stop nodes as the various QA tools nag that I am 
responsible for miss tagging them. So I am pretty sensitive to changing tagging 
norms on intersections.

That change in tagging was also annoying because at the time the direction tag 
was defined and used for showing the bearing, in degrees, something (cave 
opening, adit, etc.) was facing. So we ended up with two separate semantics for 
the direction tag depending on the type of node. And an inconsistency between 
how stop and yield sign directions were specified (“direction=*”) and how 
traffic light directions were specified (“traffic_signals:direction=*”).

> 
> Sure, but my point was that I don't think my proposal changes anything here, 
> since someone (myself, for example) might already split ways at intersections 
> for other reasons.
> 
>> May be worth it, but I would like to know that at proposal time, not
>> by discovering all routes and turn restrictions are broken.
> 
> That's fair. I'm not actually sure offhand what happens when you split a way 
> at or near an intersection, although I would hope that editors can update the 
> relations correctly. This is probably more of an issue with intersections 
> where turn lanes are separately modeled, and I wonder how many of those 
> aren't already split as they would need to be.
> 
> That said, I think it makes sense to add a note asking editors to be mindful 
> of such things. I'll add some wordage to the proposal.


With respect to what happens when a way is split near an intersection, I have 
been using the “tag all incoming ways” [1] method for mapping intersections. On 
two way roads leading into an intersection current tagging asks for a 
direction=* tag on stop and yield signs and for a traffic_signals:direction=* 
tag on traffic signals. I have seen a few intersections where the limit line 
(where you would place the stop sign or traffic light node) exactly on top of a 
the transition to a bridge. This leads me to wonder what the semantics of 
“direction=forward | backward” or “traffic_signals:direction=forward | 
backward” are if the node is at the change of ways, especially if the ways have 
different directions. I haven’t seen this defined.

But I think it is a situation that could be come more common if all ways are 
split where they enter an intersection so some thought should be given to that.

Cheers!
Tod

[1] 
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtraffic_signals#Tag_all_incoming_ways




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

Re: [Tagging] Feature Proposal - RFC - junction=intersection

[Martin Koppenhoefer]

sent from a phone

> On 10. Jul 2020, at 21:52, Matthew Woehlke  wrote:
> 
> I have to strongly disagree. Consider an intersection of dual carriageways 
> (so, four intersection nodes) where signals are tagged on the intersection 
> nodes.


that’s the problem, they should not be tagged on the intersection nodes in this 
case. If you tag them shortly before the intersection there is no issue with 
the traffic lights.

That’s what I meant to say. It’s possible to get it right with both methods.

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

Re: [Tagging] Feature Proposal - RFC - junction=intersection

[Jarek Piórkowski]

On Fri, 10 Jul 2020 at 15:53, Matthew Woehlke  wrote:
> On 10/07/2020 15.01, Martin Koppenhoefer wrote:
> >> On 10. Jul 2020, at 16:17, Matthew Woehlke  
> >> wrote:
> >> My use case isn't the only one that has issues with this sort of
> >> thing; routers can "see" more traffic lights than actually exist
> >> and can (so I hear, anyway) give directions that are potentially
> >> confusing.
> >
> > this is a different issue though, it depends how the traffic lights
> > are mapped (the way the junction is represented does have influence
> > how the traffic lights are mapped, but neither way leads necessarily
> > to a wrong number of traffic lights).
>
> I have to strongly disagree. Consider an intersection of dual
> carriageways (so, four intersection nodes) where signals are tagged on
> the intersection nodes. Please explain how a tool is supposed to
> determine whether a vehicle passing "straight through" the intersection
> will encounter one or two signals.
>
> Now take that same intersection and plop it into a dense urban area
> where there really *are* four separate intersections and explain how the
> same tool is supposed to know when that's the case.

Yeah that's a problem. But since OSM would have to be changed to add
junction=intersection tags anyway, isn't it better to use the
established method of tagging with one traffic signal per direction at
the stop line, as suggested in the wiki
https://wiki.openstreetmap.org/wiki/Tag:highway=traffic_signals#Tag_all_incoming_ways
?

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

Re: [Tagging] Feature Proposal - RFC - junction=intersection

[Matthew Woehlke]

On 10/07/2020 15.01, Martin Koppenhoefer wrote:

On 10. Jul 2020, at 16:17, Matthew Woehlke  wrote:

My use case isn't the only one that has issues with this sort of
thing; routers can "see" more traffic lights than actually exist
and can (so I hear, anyway) give directions that are potentially
confusing.


this is a different issue though, it depends how the traffic lights
are mapped (the way the junction is represented does have influence
how the traffic lights are mapped, but neither way leads necessarily
to a wrong number of traffic lights).


I have to strongly disagree. Consider an intersection of dual 
carriageways (so, four intersection nodes) where signals are tagged on 
the intersection nodes. Please explain how a tool is supposed to 
determine whether a vehicle passing "straight through" the intersection 
will encounter one or two signals.


Now take that same intersection and plop it into a dense urban area 
where there really *are* four separate intersections and explain how the 
same tool is supposed to know when that's the case.


--
Matthew

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

Re: [Tagging] Feature Proposal - RFC - junction=intersection

[Martin Koppenhoefer]

sent from a phone

> On 10. Jul 2020, at 16:17, Matthew Woehlke  wrote:
> 
> My use case isn't the only one that has issues with this sort of thing; 
> routers can "see" more traffic lights than actually exist and can (so I hear, 
> anyway) give directions that are potentially confusing.


this is a different issue though, it depends how the traffic lights are mapped 
(the way the junction is represented does have influence how the traffic lights 
are mapped, but neither way leads necessarily to a wrong number of traffic 
lights).


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

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

[Martin Koppenhoefer]

IMHO this discussion is going offtopic as we generally do not map ownership. If 
you want to dig deep into american legislation specifics only, it is not so 
relevant for the international mailing list, because these things tend to work 
differently in different countries.


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

Re: [Tagging] Feature Proposal - RFC - junction=intersection

[Matthew Woehlke]

For illustrative purposes, I went ahead and tagged 
https://www.openstreetmap.org/way/175473372. (I chose this intersection 
because the way was already split, so the only edit needed was to add 
the tag.)


On 10/07/2020 10.15, Matthew Woehlke wrote:
As some of you may recall, I'm working on a project to do traffic 
simulation with the help of OSM data and SUMO¹.


One of the issues that SUMO has is that the typical method of modeling 
intersections (which I don't propose to change, mostly) results in SUMO 
thinking there are multiple intersections where there should only be 
one. For example, intersections of two dual carriageways produces four 
intersections and makes the turns much sharper than in reality.


My use case isn't the only one that has issues with this sort of thing; 
routers can "see" more traffic lights than actually exist and can (so I 
hear, anyway) give directions that are potentially confusing. 
Intersection modeling is a long-standing issue that has had multiple 
previous proposals.


The major two prior proposals of which I'm aware are to map the 
'footprint' of the intersection as an area, or to create relations to 
map the intersection. Both are difficult, both to model, and for tools 
to parse. The area proposal has potential rendering issues.


I am proposing² a *much* simpler alternative, which is to simply tag the 
portions of a road that are "part of" an intersection (i.e. the 'm', 
'n', 'p', 'q' segments of 
https://wiki.openstreetmap.org/wiki/File:Doublejunction.svg) with 
junction=intersection. This is straight-forward to model, and I believe 
solves most of the issues for a majority of affected intersections. 
(Exceptions likely exist, but 'perfect' is the enemy of 'good', and 
right now we're at 'bad'.)


Comments would be appreciated!

Also, should I start just doing this for the areas I'm trying to use for 
my project, or is it better to wait for some degree of consensus?


(¹ https://www.eclipse.org/sumo/)

(² https://wiki.openstreetmap.org/wiki/Proposed_features/junction%3Dintersection) 


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

Re: [Tagging] Feature Proposal - RFC - (Ground)

[Matthew Woehlke]

On 10/07/2020 11.25, Paul Allen wrote:

On Fri, 10 Jul 2020 at 15:41, Matthew Woehlke wrote:

On 10/07/2020 09.32, Paul Allen wrote:

On Fri, 10 Jul 2020 at 14:10, Mateusz Konieczny wrote:

barren is horrible as it can be easily interpreted as including also
paved surfaces,


Ummm, not really.  Not in British English.  I'd never describe paved
surfaces as barren.  Technically, I suppose they are, but they don't
fit my mental category of barren.


As someone who desperately wishes his gravel driveway *was* barren, I'm
afraid I'm inclined to agree with Mateusz Konieczny :-).


How about the roof of your house?  Unless there's moss growing on it,
is it barren?  The road your house is on, is that barren?


My earthen roof might be barren, yes :-). (Okay, *I* don't have such a 
roof, but some people do!)



The car park in town, is that barren?
If it's well maintained, hopefully it is. If it's crumbling, it might 
not be! My previous residence had a paved driveway that, strictly 
speaking, was not barren.


It's true that such surfaces are often *implied* to be barren, and we 
may not think of typically labeling them as such, but strictly speaking, 
"barrenness" is a property that they *can*, and *don't necessarily* possess.


I think the real reason we don't typically think of roads as "barren" is 
because we think of them as existing at a different level, if that makes 
any sense. We don't think of a field with a large rock in it as "an area 
of bare rock surrounded by meadow", we think of it as "meadow, with a 
[large] rock in it". Roads and rivers are similar. By contrast, I 
*could* easily see describing a sufficient expanse of paved ground as 
"barren".


--
Matthew

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

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

[Joseph Eisenberg]

Re: “a unit that is *sold* is not an "apartment" in America."

While in most of the United States this is the common meaning of
"apartment", in New York City (and nearby cities in the northeast) it is
common to refer to buying an "apartment" in a Co-op building or a
condominium building.

In some buildings, especially older ones, the land and building is owned by
a cooperative (Co-Op), while in others there is a condominium legally, but
both of these are considered types of apartments which can be owned.

"apartments for sale in NYC are either condos or co-ops" -
https://www.investopedia.com/articles/personal-finance/090115/living-new-york-city-coops-vs-condos.asp

– Joseph Eisenberg

On Fri, Jul 10, 2020 at 7:33 AM Matthew Woehlke 
wrote:

> On 09/07/2020 21.51, Warin wrote:
> > On 9/7/20 12:44 am, Martin Koppenhoefer wrote:
> >> both is possible, each one can own a precise list of apartments, or
> >> both can own 50% of all apartments.
> >
> > Here apartments are usually sold separately, each as a title dead.
> > Other than 100% ownership it would be highly unusual for a  50%
> > ownership other than by the entire thing being owned by a firm and an
> > individual/firm owning 50% of the 100% owning firm.
>
> FWIW, and while we're at the point of arguing definitions and not how we
> should do things in OSM, a unit that is *sold* is not an "apartment" in
> America.
>
> - Apartment: The larger property, including habitable units, is owned by
> some entity. Units are leased.
>
> - Condominium: The larger property / building exterior is owned by some
> entity. Units are deeded and sold. (Unit owners may in turn lease the
> units they own.) Unit owners typically must pay dues to an association
> which maintains the exterior and grounds. Unit owners are not legally
> responsible for the building exterior or grounds
>
> - Townhouse: Units are deeded and sold. (Unit owners may in turn lease
> the units they own.) Unit owners typically must pay dues to an
> association which maintains the exterior and grounds. However, unit
> owners also own a land parcel which contains their unit and associated
> grounds, and have some degree of legally responsibility for their
> portion of the building and grounds.
>
> - Row house: The parcel grounds and all structures thereon are owned by
> an individual or entity (which may lease the residence or portions
> thereof). Said owners are fully responsible for all building exteriors
> and grounds on their lot. However, the structures may share walls with
> other structures on adjacent parcels.
>
> - Semi-detached house: A set of row houses with exactly two connected
> units. (IMO this is a somewhat stupid distinction likely created by
> realtors for marketing purposes.)
>
> - Detached house: The parcel grounds and all structures thereon are
> owned by an individual or entity (which may lease the residence or
> portions thereof).
>
> Note that the line between a detached house, flats, and apartments can
> get pretty blurry, especially when you start running into things like
> buildings that were constructed as single-family dwellings and have been
> converted into apartments. However, if we ignore the case of converted
> single-family homes, I think we can be non-ambiguous.
>
> Those are the specific, *legal* categories of which I know. We can argue
> about what to call those categories (different locations may assign the
> names differently), but IMHO those are the categories that (at a
> minimum; it's entirely possible there are others I'm not familiar with)
> make sense to model/tag.
>
> --
> Matthew
>
> ___
> 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 - junction=intersection

[Matthew Woehlke]

On 10/07/2020 12.57, Tod Fitch wrote:

In the old days the wiki said you could put a highway=stop or
highway=give_way node on a way and the data consumer would determine
the nearest intersection and just do the right thing. I mapped
several thousand, yes thousand, stop signs that way. Later it was
decided that each of those nodes should also have a direction=forward
or direction=backward tag as well. Years later, I am still updating
those highway=stop nodes as the various QA tools nag that I am
responsible for miss tagging them. So I am pretty sensitive to
changing tagging norms on intersections.


That's... interestingly ironic. The problem is you *cannot* correctly 
tag a direction on such entities where assigned to the intersection 
nodes of a dual carriageway. My proposal would not only fix that, it 
would obviate the need for specifying a direction.


Going back to relations, is it even *possible* to correctly tag a 
relation on a way that isn't split at the 'via' node? (How does the 
relation otherwise know to which side of the way it applies?) If the way 
already *must* be split at the 'via' node, I don't think splitting it 
downstream will break the relation unless the editor is dumb as rocks. 
(That is, I think the editor can reliably repair the relation 
automatically.)



With respect to what happens when a way is split near an
intersection, I have been using the “tag all incoming ways” [1]
method for mapping intersections.


Heh... I missed (or had forgotten about) that. Yes, that's what I'm 
doing, also. It solves the signals/signage issue (and likewise makes it 
sometimes unnecessary to add directionality), but not other issues with 
tools not recognizing intersections as single logical entities.



I have seen a few intersections where the limit line (where you would
place the stop sign or traffic light node) exactly on top of a the
transition to a bridge. This leads me to wonder what the semantics of
“direction=forward | backward” or “traffic_signals:direction=forward
| backward” are if the node is at the change of ways, especially if
the ways have different directions.


Broken, I would expect, if the meeting ways don't have the same 
direction :-). (Fortunately, it should be easy for tools to flag this...)


If they're in the _same_ direction, it would apply to the way that is 
"entering" (or "exiting") the node, i.e. it's well defined.


But I think it is a situation that could be come more common if all 
ways are split where they enter an intersection so some thought

should be given to that.


I think I've already done that? One of the proposed semantics is that 
"signals do not apply to a way which is tagged junction=intersection". 
That is, it is well defined to which edge a signal/signage/etc. applies 
*without* needing to specify a direction. (This is implicit, because 
AFAIK signals/signs never apply *inside* of intersections, but to the 
*boundaries* of intersections. Once you're *in* an intersection, the 
intent is that you *get out ASAP*.)


--
Matthew

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

Re: [Tagging] Feature Proposal - RFC - junction=intersection

[Matthew Woehlke]

On 10/07/2020 12.22, Clifford Snow wrote:

Interesting suggestion. The sumo github page doesn't appear to have any
open issues that involve OSM and intersections that I could find. (I only
looked at intersection issue titles) Has this been reported to the sumo
developers? Sumo documentation does suggest fixing OSM issues but other
than that it seems to indicate that OSM data is suitable for use with their
software.


I haven't reported anything yet, but (obviously?) it is my intention if 
this gains any traction to improve SUMO to automatically merge 
intersections based on this tag. That said, if you watch their 
*tutorial* (it's over an hour long), there is at least one example where 
the presenter shows an instance of this issue, so it *is* known to the 
community. I'm not sure if anyone else has had the idea to specifically 
annotate these in OSM in order to be able to better fix up such 
intersections automatically.


For my specific use case, it's moderately important to be able to 
convert OSM data into SUMO networks in a fully automated and 
deterministic manner.


Another issue, that isn't really OSM's fault, is that SUMO likes to add 
intersections wherever a way is split, even though only two edges come 
together. I don't think OSM needs to change anything there, however, 
except perhaps that it might be desirable to mark nodes where a U-turn 
is specifically legal.



You mention that the duplicate traffic signals are a problem but I don't
understand from your proposal how traffic signals should be tagged in your
proposal. Could you update your proposal to include how they are to be
tagged as part of the intersection.


That's because the proposal isn't proposing to change how signals are 
tagged. Rather, the objective is to make it so that "the existing way" 
("each [intersection] node is tagged as a traffic signal") Just Works™ 
with tools: "signals do not apply to a way which is tagged 
junction=intersection".


*Independently*, I am leaning toward suggesting to tag signals at the 
'stop here' line rather than on the intersection nodes (which also 
solves the signals aspect of the problem in a different manner), but IMO 
that is orthogonal. See e.g. 
https://www.openstreetmap.org/node/7695739446. (Also, if this proposal 
is approved, that change may or may not be necessary or desirable. I 
think the 'stop here' lines should be tagged in *some* manner, but with 
junction=intersection, it may be that a new way to tag 'stop here' lines 
is desired and leaving the signals on the intersection nodes is 
preferred. At that point, we're getting into arguing about tagging where 
the signal *applies* vs. where the actual signal lamp is physically 
located.)


--
Matthew

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

Re: [Tagging] Feature Proposal - RFC - junction=intersection

[Matthew Woehlke]

On 10/07/2020 11.24, Peter Elderson wrote:

Well, if you do a couple of intersections it's no big deal, but if every
intersection would need this and it breaks relations, no matter whose fault
it is, it is a problem. Then it's not just modeling, but forced repair
work.


Sure, but my point was that I don't think my proposal changes anything 
here, since someone (myself, for example) might already split ways at 
intersections for other reasons.



May be worth it, but I would like to know that at proposal time, not
by discovering all routes and turn restrictions are broken.


That's fair. I'm not actually sure offhand what happens when you split a 
way at or near an intersection, although I would hope that editors can 
update the relations correctly. This is probably more of an issue with 
intersections where turn lanes are separately modeled, and I wonder how 
many of those aren't already split as they would need to be.


That said, I think it makes sense to add a note asking editors to be 
mindful of such things. I'll add some wordage to the proposal.


--
Matthew

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

Re: [Tagging] Feature Proposal - RFC - junction=intersection

[Clifford Snow]

Matthew,
Interesting suggestion. The sumo github page doesn't appear to have any
open issues that involve OSM and intersections that I could find. (I only
looked at intersection issue titles) Has this been reported to the sumo
developers? Sumo documentation does suggest fixing OSM issues but other
than that it seems to indicate that OSM data is suitable for use with their
software.

You mention that the duplicate traffic signals are a problem but I don't
understand from your proposal how traffic signals should be tagged in your
proposal. Could you update your proposal to include how they are to be
tagged as part of the intersection.

Best,
Clifford


On Fri, Jul 10, 2020 at 7:15 AM Matthew Woehlke 
wrote:

> As some of you may recall, I'm working on a project to do traffic
> simulation with the help of OSM data and SUMO¹.
>
> One of the issues that SUMO has is that the typical method of modeling
> intersections (which I don't propose to change, mostly) results in SUMO
> thinking there are multiple intersections where there should only be
> one. For example, intersections of two dual carriageways produces four
> intersections and makes the turns much sharper than in reality.
>
> My use case isn't the only one that has issues with this sort of thing;
> routers can "see" more traffic lights than actually exist and can (so I
> hear, anyway) give directions that are potentially confusing.
> Intersection modeling is a long-standing issue that has had multiple
> previous proposals.
>
> The major two prior proposals of which I'm aware are to map the
> 'footprint' of the intersection as an area, or to create relations to
> map the intersection. Both are difficult, both to model, and for tools
> to parse. The area proposal has potential rendering issues.
>
> I am proposing² a *much* simpler alternative, which is to simply tag the
> portions of a road that are "part of" an intersection (i.e. the 'm',
> 'n', 'p', 'q' segments of
> https://wiki.openstreetmap.org/wiki/File:Doublejunction.svg) with
> junction=intersection. This is straight-forward to model, and I believe
> solves most of the issues for a majority of affected intersections.
> (Exceptions likely exist, but 'perfect' is the enemy of 'good', and
> right now we're at 'bad'.)
>
> Comments would be appreciated!
>
> Also, should I start just doing this for the areas I'm trying to use for
> my project, or is it better to wait for some degree of consensus?
>
> (¹ https://www.eclipse.org/sumo/)
>
> (²
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/junction%3Dintersection
> )
>
> --
> Matthew
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
@osm_washington
www.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Ground)

[Paul Allen]

On Fri, 10 Jul 2020 at 15:41, Matthew Woehlke 
wrote:

> On 10/07/2020 09.32, Paul Allen wrote:
> > On Fri, 10 Jul 2020 at 14:10, Mateusz Konieczny wrote:
> >> barren is horrible as it can be easily interpreted as including also
> paved
> >> surfaces,
> >
> > Ummm, not really.  Not in British English.  I'd never describe paved
> > surfaces as barren.  Technically, I suppose they are, but they don't
> > fit my mental category of barren.
>
> As someone who desperately wishes his gravel driveway *was* barren, I'm
> afraid I'm inclined to agree with Mateusz Konieczny :-).
>

How about the roof of your house?  Unless there's moss growing on it,
is it barren?  The road your house is on, is that barren?  The car park
in town, is that barren?  Maybe it's just my idiosyncratic view of the
world again, but "barren" implies to me that there is a reasonable
expectation that plants might grow there.

BTW, my tiny back garden has so-called ornamental gravel (my
landlord is to blame for that).  I call it "weed compost."

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

Re: [Tagging] Feature Proposal - RFC - junction=intersection

[Peter Elderson]

Well, if you do a couple of intersections it's no big deal, but if every
intersection would need this and it breaks relations, no matter whose fault
it is, it is a problem. Then it's not just modeling, but forced repair
work. May be worth it, but I would like to know that at proposal time, not
by discovering all routes and turn restrictions are broken.

Just a consideration, if it doesn't break anything it's fine.

Best, Peter Elderson


Op vr 10 jul. 2020 om 16:50 schreef Matthew Woehlke <
mwoehlke.fl...@gmail.com>:

> On 10/07/2020 10.36, Peter Elderson wrote:
> > Question: does it break anything? I am thinking about existing relations
> of
> > various kinds.
>
> If splitting ways breaks relations, well, a) that's an editor problem,
> and b) I've already been breaking those left and right from splitting
> ways to improve accuracy of lane information.
>
> I don't see how it would break the *ability* to model anything, however.
> Given the above, I don't see how it could be meaningfully *harmful*.
>
> --
> Matthew
>
> ___
> 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] Distinguishing closed office spaces and client service locations?

[Mateusz Konieczny via Tagging]

Jul 10, 2020, 15:57 by mwoehlke.fl...@gmail.com:

> On 09/07/2020 17.34, Mateusz Konieczny via Tagging wrote:
>
>> Jul 9, 2020, 20:38 by pla16...@gmail.com:
>>
>>> Maybe not ideal, but if you're looking for an immediate solution then
>>> access=customers and access=private?
>>>
>> I like it, but it is a bit tricky as I can walk into many offices without 
>> being
>> a customer (though typically it is done as someone wants or
>> considers being one).
>>
>
> I wonder if we shouldn't discourage this "use case". In my experience, while 
> you are correct that corporate offices *do* sometimes get "walk-in clients", 
> I think most tend to discourage that sort of thing. Usually an office that 
> doesn't have resources dedicated to dealing with walk-ins will prefer to set 
> up appointments for a potential customer to visit.
>
>> Maybe something along amenity=customer_service?
>>
>
> If a space does actively encourage walk-ins, that might work. Although...
>
I was thinking about space that explicitly welcomes walk-ins and exists solely 
to
handle them (office of an energy company - handling issues such as resolving
billing mistakes, handling overdue payments, attaching property to a power/gas
network, changing gas/electricity provider, changing billing rules etc).

Currently tagged as office=company - I was looking for something that would 
distinguish
it from an internal office space and for example indicate that opening_hours and
wheelchair tags are an useful addition.

>> Though access=private seems perfectly fine to mark office as internal
>> to a company (or covering restricted set of clients).
>>
>
> ...I would think that, yes, access=private should probably be used. I would 
> expect that even access=private implies it's okay to go there if you're 
> invited. (Also, if you're invited, you probably don't need to be asking OSM 
> if it's okay to visit.)
>
> As Paul notes, I would also assume that access=private includes service 
> workers with a legitimate reason to access the premises; affiliated vendors, 
> postal workers, maintenance persons, etc.
>
+1

> p.s. access=designated is *not* a thing; so saith the wiki.
>
access=designated is meaningless (what is designated? Everything?)

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

Re: [Tagging] Feature Proposal - RFC - junction=intersection

[Matthew Woehlke]

On 10/07/2020 10.36, Peter Elderson wrote:

Question: does it break anything? I am thinking about existing relations of
various kinds.


If splitting ways breaks relations, well, a) that's an editor problem, 
and b) I've already been breaking those left and right from splitting 
ways to improve accuracy of lane information.


I don't see how it would break the *ability* to model anything, however. 
Given the above, I don't see how it could be meaningfully *harmful*.


--
Matthew

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

Re: [Tagging] Feature Proposal - RFC - (Ground)

[Matthew Woehlke]

On 10/07/2020 09.32, Paul Allen wrote:

On Fri, 10 Jul 2020 at 14:10, Mateusz Konieczny wrote:

barren is horrible as it can be easily interpreted as including also paved
surfaces,


Ummm, not really.  Not in British English.  I'd never describe paved 
surfaces as barren.  Technically, I suppose they are, but they don't

fit my mental category of barren.


As someone who desperately wishes his gravel driveway *was* barren, I'm 
afraid I'm inclined to agree with Mateusz Konieczny :-).


--
Matthew

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

Re: [Tagging] Feature Proposal - RFC - junction=intersection

[Peter Elderson]

Question: does it break anything? I am thinking about existing relations of
various kinds.

Best, Peter Elderson


Op vr 10 jul. 2020 om 16:17 schreef Matthew Woehlke <
mwoehlke.fl...@gmail.com>:

> As some of you may recall, I'm working on a project to do traffic
> simulation with the help of OSM data and SUMO¹.
>
> One of the issues that SUMO has is that the typical method of modeling
> intersections (which I don't propose to change, mostly) results in SUMO
> thinking there are multiple intersections where there should only be
> one. For example, intersections of two dual carriageways produces four
> intersections and makes the turns much sharper than in reality.
>
> My use case isn't the only one that has issues with this sort of thing;
> routers can "see" more traffic lights than actually exist and can (so I
> hear, anyway) give directions that are potentially confusing.
> Intersection modeling is a long-standing issue that has had multiple
> previous proposals.
>
> The major two prior proposals of which I'm aware are to map the
> 'footprint' of the intersection as an area, or to create relations to
> map the intersection. Both are difficult, both to model, and for tools
> to parse. The area proposal has potential rendering issues.
>
> I am proposing² a *much* simpler alternative, which is to simply tag the
> portions of a road that are "part of" an intersection (i.e. the 'm',
> 'n', 'p', 'q' segments of
> https://wiki.openstreetmap.org/wiki/File:Doublejunction.svg) with
> junction=intersection. This is straight-forward to model, and I believe
> solves most of the issues for a majority of affected intersections.
> (Exceptions likely exist, but 'perfect' is the enemy of 'good', and
> right now we're at 'bad'.)
>
> Comments would be appreciated!
>
> Also, should I start just doing this for the areas I'm trying to use for
> my project, or is it better to wait for some degree of consensus?
>
> (¹ https://www.eclipse.org/sumo/)
>
> (²
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/junction%3Dintersection
> )
>
> --
> Matthew
>
> ___
> 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

[Matthew Woehlke]

On 09/07/2020 21.51, Warin wrote:

On 9/7/20 12:44 am, Martin Koppenhoefer wrote:
both is possible, each one can own a precise list of apartments, or 
both can own 50% of all apartments.


Here apartments are usually sold separately, each as a title dead.
Other than 100% ownership it would be highly unusual for a  50% 
ownership other than by the entire thing being owned by a firm and an 
individual/firm owning 50% of the 100% owning firm.


FWIW, and while we're at the point of arguing definitions and not how we 
should do things in OSM, a unit that is *sold* is not an "apartment" in 
America.


- Apartment: The larger property, including habitable units, is owned by 
some entity. Units are leased.


- Condominium: The larger property / building exterior is owned by some 
entity. Units are deeded and sold. (Unit owners may in turn lease the 
units they own.) Unit owners typically must pay dues to an association 
which maintains the exterior and grounds. Unit owners are not legally 
responsible for the building exterior or grounds


- Townhouse: Units are deeded and sold. (Unit owners may in turn lease 
the units they own.) Unit owners typically must pay dues to an 
association which maintains the exterior and grounds. However, unit 
owners also own a land parcel which contains their unit and associated 
grounds, and have some degree of legally responsibility for their 
portion of the building and grounds.


- Row house: The parcel grounds and all structures thereon are owned by 
an individual or entity (which may lease the residence or portions 
thereof). Said owners are fully responsible for all building exteriors 
and grounds on their lot. However, the structures may share walls with 
other structures on adjacent parcels.


- Semi-detached house: A set of row houses with exactly two connected 
units. (IMO this is a somewhat stupid distinction likely created by 
realtors for marketing purposes.)


- Detached house: The parcel grounds and all structures thereon are 
owned by an individual or entity (which may lease the residence or 
portions thereof).


Note that the line between a detached house, flats, and apartments can 
get pretty blurry, especially when you start running into things like 
buildings that were constructed as single-family dwellings and have been 
converted into apartments. However, if we ignore the case of converted 
single-family homes, I think we can be non-ambiguous.


Those are the specific, *legal* categories of which I know. We can argue 
about what to call those categories (different locations may assign the 
names differently), but IMHO those are the categories that (at a 
minimum; it's entirely possible there are others I'm not familiar with) 
make sense to model/tag.


--
Matthew

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

[Tagging] Feature Proposal - RFC - junction=intersection

[Matthew Woehlke]

As some of you may recall, I'm working on a project to do traffic 
simulation with the help of OSM data and SUMO¹.


One of the issues that SUMO has is that the typical method of modeling 
intersections (which I don't propose to change, mostly) results in SUMO 
thinking there are multiple intersections where there should only be 
one. For example, intersections of two dual carriageways produces four 
intersections and makes the turns much sharper than in reality.


My use case isn't the only one that has issues with this sort of thing; 
routers can "see" more traffic lights than actually exist and can (so I 
hear, anyway) give directions that are potentially confusing. 
Intersection modeling is a long-standing issue that has had multiple 
previous proposals.


The major two prior proposals of which I'm aware are to map the 
'footprint' of the intersection as an area, or to create relations to 
map the intersection. Both are difficult, both to model, and for tools 
to parse. The area proposal has potential rendering issues.


I am proposing² a *much* simpler alternative, which is to simply tag the 
portions of a road that are "part of" an intersection (i.e. the 'm', 
'n', 'p', 'q' segments of 
https://wiki.openstreetmap.org/wiki/File:Doublejunction.svg) with 
junction=intersection. This is straight-forward to model, and I believe 
solves most of the issues for a majority of affected intersections. 
(Exceptions likely exist, but 'perfect' is the enemy of 'good', and 
right now we're at 'bad'.)


Comments would be appreciated!

Also, should I start just doing this for the areas I'm trying to use for 
my project, or is it better to wait for some degree of consensus?


(¹ https://www.eclipse.org/sumo/)

(² 
https://wiki.openstreetmap.org/wiki/Proposed_features/junction%3Dintersection)


--
Matthew

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

Re: [Tagging] Distinguishing closed office spaces and client service locations?

[Matthew Woehlke]

(Apologies if this double-posts; my mail client is telling me it 
couldn't be sent, but I've known it to lie about that...)


On 09/07/2020 18.57, Mateusz Konieczny via Tagging wrote:

Jul 9, 2020, 23:58 by pla16...@gmail.com:

I take "customers" to mean "non-employees who may access the
facility because of interactions with the controlling organization."  Not
staff.  Private means that nobody but staff (excepting emergency
services, plumbers who have been called in to deal with a problem,
etc.) have access.


Good point, I also used access=customers for churchgoers-only parking lot.


I think this makes sense also. To a previous point, I take 
access=customers to mean someone intending to visit the associated 
location, whether that's a store, a church, a doctor's office, ...


BTW, I've used access=customers for parking lots that aren't 
*explicitly* marked 'customers only', but where I would expect the 
proprietors would nevertheless be annoyed by people just using their 
lots that aren't going to the associated store (or church, or ...) at 
all. Should I not do that? Is there a clear rule for when to use 
access=customers vs. access=permissive?


(I would probably use access=permissive for e.g. a mall parking lot, 
where it's not strictly public, but where you wouldn't be expected to be 
visiting a particular building or organization such that it's much less 
clear whether or not you are a "customer".)


--
Matthew

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

Re: [Tagging] Feature Proposal - RFC - (Ground)

[Peter Elderson]

I think bare_soil or barren_soil are ok values for bare/barren soil.

I am convinced that these areas exist, bare soil without spontaneous
vegetation, whatever causes it to remain bare for many years.

Barren sounds to me to imply nothing can grow there.Bare sounds more
neutral and factual to me, it just says there is nothing but bare soil to
mark the area with.Please correct if I am wrong!

My preference would be the direct and factual *=bare_soil

The key does not really matter as long as it's not landuse, because it is
not a use of the land.
landcover=bare_soil sounds right to me.
natural=bare_soil might exclude areas which are bare because of human
causes. But it fits in with natural=bare_rock, and it is a sort of
null-option for vegetation from rain forest through grassy plains to
nothing growing there.
surface=bare_soil is not bad, but surface is generally used as an
additional key for a main feature, not a feature in itself.

Since soil is positively what you see, I don't think it's just negatively
defined. It's soil, with an important visible characteristic that it is
bare. Soil with vegatation has its own tags, but the absence of such a tag
does not indicate that it is bare soil.

All in all, I think natural=bare_soil is the best option, and that it fills
an important gap in the mapping of Earth's surface.

Question: How sure can you be from satellite imagery or aerial photography
that an area is actually bare soil?

Best, Peter Elderson


Op vr 10 jul. 2020 om 15:10 schreef Mateusz Konieczny via Tagging <
tagging@openstreetmap.org>:

>
>
>
> Jul 10, 2020, 15:04 by pla16...@gmail.com:
>
> I've just realized what prompted the back of my mind into writing the
> preceding paragraph.  landcover=barren (or natural=barren) seems
> to handle things nicely without worrying about soil/clay/humus
> distinctions.
>
> barren is horrible as it can be easily interpreted as including also paved
> surfaces,
> bare rock, areas with poor plant growth and many other cases
>
> as not a native speaker - natural=barren_soil seems more reasonable
> and harder to misinterpret
> (that specific combination may be horrible for grammar reasons,
> I am not a native speaker)
> ___
> 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] Distinguishing closed office spaces and client service locations?

[Matthew Woehlke]

On 09/07/2020 17.34, Mateusz Konieczny via Tagging wrote:

Jul 9, 2020, 20:38 by pla16...@gmail.com:

Maybe not ideal, but if you're looking for an immediate solution then
access=customers and access=private?


I like it, but it is a bit tricky as I can walk into many offices without being
a customer (though typically it is done as someone wants or
considers being one).


I wonder if we shouldn't discourage this "use case". In my experience, 
while you are correct that corporate offices *do* sometimes get "walk-in 
clients", I think most tend to discourage that sort of thing. Usually an 
office that doesn't have resources dedicated to dealing with walk-ins 
will prefer to set up appointments for a potential customer to visit.



Maybe something along amenity=customer_service?


If a space does actively encourage walk-ins, that might work. Although...


Though access=private seems perfectly fine to mark office as internal
to a company (or covering restricted set of clients).


...I would think that, yes, access=private should probably be used. I 
would expect that even access=private implies it's okay to go there if 
you're invited. (Also, if you're invited, you probably don't need to be 
asking OSM if it's okay to visit.)


As Paul notes, I would also assume that access=private includes service 
workers with a legitimate reason to access the premises; affiliated 
vendors, postal workers, maintenance persons, etc.


p.s. access=designated is *not* a thing; so saith the wiki.

--
Matthew

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

Re: [Tagging] Feature Proposal - RFC - (Ground)

[Paul Allen]

On Fri, 10 Jul 2020 at 14:10, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
> Jul 10, 2020, 15:04 by pla16...@gmail.com:
>
> I've just realized what prompted the back of my mind into writing the
> preceding paragraph.  landcover=barren (or natural=barren) seems
> to handle things nicely without worrying about soil/clay/humus
> distinctions.
>
> barren is horrible as it can be easily interpreted as including also paved
> surfaces,
>

Ummm, not really.  Not in British English.  I'd never describe paved
surfaces
as barren.  Technically, I suppose they are, but they don't fit my mental
category of barren.

bare rock, areas with poor plant growth and many other cases
>
as not a native speaker - natural=barren_soil seems more reasonable
> and harder to misinterpret
>

It doesn't feel right to me.  Bare soil, yes.  That's soil with no plants.
Barren soil means incapable of sustaining plant life, and that is
harder to determine.

You can determine that land is barren from aerial imagery (if you
have images from different seasons and years).  You need
on-the-ground survey to determine that it's bare soil.  And I
suspect that such areas are rarely uniformly bare soil but
may have patches of clay, sand, or gravel.  Also, soil
degrades or erodes given enough time - the Sahara was
once fertile land, now it's sand.

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

Re: [Tagging] Feature Proposal - RFC - (Ground)

[Mateusz Konieczny via Tagging]

Jul 10, 2020, 15:04 by pla16...@gmail.com:

> I've just realized what prompted the back of my mind into writing the
> preceding paragraph.  landcover=barren (or natural=barren) seems
> to handle things nicely without worrying about soil/clay/humus
> distinctions.
>
barren is horrible as it can be easily interpreted as including also paved 
surfaces,
bare rock, areas with poor plant growth and many other cases

as not a native speaker - natural=barren_soil seems more reasonable
and harder to misinterpret
(that specific combination may be horrible for grammar reasons,
I am not a native speaker)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Ground)

[Paul Allen]

On Fri, 10 Jul 2020 at 13:19, Warin <61sundow...@gmail.com> wrote:

> On 10/7/20 9:30 pm, Peter Elderson wrote:
>
> Looks like humus is a component of soil. So I think soil covers it, being
> a top layer consisting of mixed organic and mineral matter.
>
> To me it is hard to imagine an area as permanently natural=bare_soil.
> Wouldn't there always be some kind of vegetation within a year?
>
>
> Sorry to say but some soils have been so polluted combined with the
> resulting soil erosion vegetation has taken some decades to come back.
>
> See https://en.wikipedia.org/wiki/Queenstown,_Tasmania#Ecology
>

I don't see how an area that has suffered soil erosion can be mapped as
bare soil,
I see from the Wikipedia article you cite that "[...] the erosion of the
shallow horizon
topsoil back to the harder rock profile [...]" so we'd map that as bare
rock,
wouldn't we?

I'll take this opportunity to mention that some (not you) have suggested
that bare soil might happen through lack of rainfall, which is possible.
Others have then suggested that such cases could be mapped as
desert.  Desert is an incredibly bad tag because it is not a surface,
or a land cover, or even a natural (as used in OSM), it's a CLIMATE.
Desert means a lack of precipitation (which usually results in
the land being barren.  The Sahara (hot and sandy) is a desert, but so is
arctic tundra.  Whatever we settle on for this (if we settle on something),
desert should not be the tag.

I've just realized what prompted the back of my mind into writing the
preceding paragraph.  landcover=barren (or natural=barren) seems
to handle things nicely without worrying about soil/clay/humus
distinctions.

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

Re: [Tagging] Feature Proposal - RFC - (Ground)

[Martin Koppenhoefer]

sent from a phone

> On 10. Jul 2020, at 14:40, Kevin Kenny  wrote:
> 
> I'd imagine that pollution and erosion would result in a surface of mineral, 
> rather than organic soil;


lack of water still remains a possibility. For small areas you can also imagine 
so many people walking or driving on it that no plants make it. Or animals 
eating everything (think a pig sty or hen‘s house)

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

Re: [Tagging] Feature Proposal - RFC - (Ground)

[Kevin Kenny]

On Fri, Jul 10, 2020 at 8:19 AM Warin <61sundow...@gmail.com> wrote:

> On 10/7/20 9:30 pm, Peter Elderson wrote:
>
> Looks like humus is a component of soil. So I think soil covers it, being
> a top layer consisting of mixed organic and mineral matter.
>
> To me it is hard to imagine an area as permanently natural=bare_soil.
> Wouldn't there always be some kind of vegetation within a year?
>
>
> Not always.
>
> Sorry to say but some soils have been so polluted combined with the
> resulting soil erosion vegetation has taken some decades to come back.
>
> See https://en.wikipedia.org/wiki/Queenstown,_Tasmania#Ecology
>

I'd imagine that pollution and erosion would result in a surface of
mineral, rather than organic soil; hence the land cover would be clay,
sand, scree, or bare_rock, depending on the particle size. Even the article
you cite mentions areas eroded to bare rock.  These values are all
available for tagging a mineral surface.



-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Ground)

[Warin]

On 10/7/20 9:30 pm, Peter Elderson wrote:
Looks like humus is a component of soil. So I think soil covers it, 
being a top layer consisting of mixed organic and mineral matter.


To me it is hard to imagine an area as permanently natural=bare_soil. 
Wouldn't there always be some kind of vegetation within a year?



Not always.

Sorry to say but some soils have been so polluted combined with the 
resulting soil erosion vegetation has taken some decades to come back.


See https://en.wikipedia.org/wiki/Queenstown,_Tasmania#Ecology




Best, Peter Elderson


Op vr 10 jul. 2020 om 12:42 schreef Michael Montani 
mailto:michael.mont...@un.org>>:


I agree it could be considered as humus. The distinction between
organic soil and humus is ambiguous according to
https://en.wikipedia.org/wiki/Humus , but I think it is general
enough to target mostly organic soil.

Shall we consider to add this specification on the tagging? Or
would humus be considered as bare soil anyway?

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





*Da:* Peter Elderson mailto:pelder...@gmail.com>>
*Inviato:* venerdì 10 luglio 2020 12:02
*A:* Tag discussion, strategy and related tools
mailto:tagging@openstreetmap.org>>
*Oggetto:* Re: [Tagging] Feature Proposal - RFC - (Ground)
Organic without any mineral, would you still call that soil?

Vr gr Peter Elderson


Op vr 10 jul. 2020 om 11:55 schreef Martin Koppenhoefer
mailto:dieterdre...@gmail.com>>:



sent from a phone

> On 10. Jul 2020, at 11:39, Mateusz Konieczny via Tagging
mailto:tagging@openstreetmap.org>>
wrote:
>
> Why it would be natural=bare_ground rather than
natural=bare_soil?


+1,
I also disagree that “soil can be organic or mineral”. It has
typically both, organic and mineral components, but organic
components are a hard requirement. Otherwise it would be sand,
or rock, or silt or clay or loam etc. (depending on grain size/s).

Cheers Martin





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

Re: [Tagging] Feature Proposal - RFC - (Ground)

[Martin Koppenhoefer]

sent from a phone

> On 10. Jul 2020, at 13:33, Peter Elderson  wrote:
> 
> To me it is hard to imagine an area as permanently natural=bare_soil. 
> Wouldn't there always be some kind of vegetation within a year? 



not if there isn’t water at all, or if it is heavily contaminated

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

[Tagging] Feature Proposal - RFC - (Ground)

[Michael Montani]

Unfortunately I don't have photos of the terrain at the moment, but I will see 
if I can come back with some on the ground example.

For now, I put some example photos in the Talk page of the feature 
proposal
 . Feel free to leave a comment on any photo, e.g. whether or not you would it 
consider as soil. I would be also curious to know what tag would you use to map 
the ground of this kind of areas with the already existent tags.

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:55088391-3951-4b49-93bf-e38fd2876f34]


Da: Christoph Hormann 
Inviato: venerdì 10 luglio 2020 12:00
A: Tag discussion, strategy and related tools 
Oggetto: Re: [Tagging] Feature Proposal - RFC - (Ground)


Independent of what i already said in

https://lists.openstreetmap.org/pipermail/tagging/2020-July/053795.html

i am always wary of tags lacking any examples for on-the-ground mapping or a 
practically locally verifiable definition.  And defining a tag negatively 
trough the lack of something (vegetation) rather than positively through 
something that can be positively observed is problematic.  We have had this 
problem with natural=desert already (which some had defined equally though the 
absence of vegetation).

Overall as it stands this does not seem likely to become a successful and 
meaningful tag.  Maybe you can show some on-the-ground examples of areas you 
think this tag is suitable and needed for and get input from the wider 
community how they would suggest to characterize and tag such areas.

--
Christoph Hormann
http://www.imagico.de/

___
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 - (Ground)

[Peter Elderson]

Looks like humus is a component of soil. So I think soil covers it, being a
top layer consisting of mixed organic and mineral matter.

To me it is hard to imagine an area as permanently natural=bare_soil.
Wouldn't there always be some kind of vegetation within a year?


Best, Peter Elderson


Op vr 10 jul. 2020 om 12:42 schreef Michael Montani :

> I agree it could be considered as humus. The distinction between organic
> soil and humus is ambiguous according to
> https://en.wikipedia.org/wiki/Humus , but I think it is general enough to
> target mostly organic soil.
>
> Shall we consider to add this specification on the tagging? Or would humus
> be considered as bare soil anyway?
>
> 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
>
>
>
> --
> *Da:* Peter Elderson 
> *Inviato:* venerdì 10 luglio 2020 12:02
> *A:* Tag discussion, strategy and related tools  >
> *Oggetto:* Re: [Tagging] Feature Proposal - RFC - (Ground)
>
> Organic without any mineral, would you still call that soil?
>
> Vr gr Peter Elderson
>
>
> Op vr 10 jul. 2020 om 11:55 schreef Martin Koppenhoefer <
> dieterdre...@gmail.com>:
>
>
>
> sent from a phone
>
> > On 10. Jul 2020, at 11:39, Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> wrote:
> >
> > Why it would be natural=bare_ground rather than natural=bare_soil?
>
>
> +1,
> I also disagree that “soil can be organic or mineral”. It has typically
> both, organic and mineral components, but organic components are a hard
> requirement. Otherwise it would be sand, or rock, or silt or clay or loam
> etc. (depending on grain size/s).
>
> 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - RFC - (Ground)

[Michael Montani]

I agree it could be considered as humus. The distinction between organic soil 
and humus is ambiguous according to https://en.wikipedia.org/wiki/Humus , but I 
think it is general enough to target mostly organic soil.

Shall we consider to add this specification on the tagging? Or would humus be 
considered as bare soil anyway?

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:072fe9f2-17da-426c-b4c6-c25f4370d75b]


Da: Peter Elderson 
Inviato: venerdì 10 luglio 2020 12:02
A: Tag discussion, strategy and related tools 
Oggetto: Re: [Tagging] Feature Proposal - RFC - (Ground)

Organic without any mineral, would you still call that soil?

Vr gr Peter Elderson


Op vr 10 jul. 2020 om 11:55 schreef Martin Koppenhoefer 
mailto:dieterdre...@gmail.com>>:


sent from a phone

> On 10. Jul 2020, at 11:39, Mateusz Konieczny via Tagging 
> mailto:tagging@openstreetmap.org>> wrote:
>
> Why it would be natural=bare_ground rather than natural=bare_soil?


+1,
I also disagree that “soil can be organic or mineral”. It has typically both, 
organic and mineral components, but organic components are a hard requirement. 
Otherwise it would be sand, or rock, or silt or clay or loam etc. (depending on 
grain size/s).

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] Feature Proposal - RFC - (Ground)

[Martin Koppenhoefer]

sent from a phone

> On 10. Jul 2020, at 12:05, Peter Elderson  wrote:
> 
> Organic without any mineral, would you still call that soil? 


I’d call it humus, not sure whether the term soil can apply or not, I am not a 
native English speaker.

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

Re: [Tagging] Feature Proposal - RFC - (Ground)

[Peter Elderson]

Organic without any mineral, would you still call that soil?

Vr gr Peter Elderson


Op vr 10 jul. 2020 om 11:55 schreef Martin Koppenhoefer <
dieterdre...@gmail.com>:

>
>
> sent from a phone
>
> > On 10. Jul 2020, at 11:39, Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> wrote:
> >
> > Why it would be natural=bare_ground rather than natural=bare_soil?
>
>
> +1,
> I also disagree that “soil can be organic or mineral”. It has typically
> both, organic and mineral components, but organic components are a hard
> requirement. Otherwise it would be sand, or rock, or silt or clay or loam
> etc. (depending on grain size/s).
>
> 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] Feature Proposal - RFC - (Ground)

[Christoph Hormann]

Independent of what i already said in

https://lists.openstreetmap.org/pipermail/tagging/2020-July/053795.html

i am always wary of tags lacking any examples for on-the-ground mapping or a 
practically locally verifiable definition.  And defining a tag negatively 
trough the lack of something (vegetation) rather than positively through 
something that can be positively observed is problematic.  We have had this 
problem with natural=desert already (which some had defined equally though the 
absence of vegetation).

Overall as it stands this does not seem likely to become a successful and 
meaningful tag.  Maybe you can show some on-the-ground examples of areas you 
think this tag is suitable and needed for and get input from the wider 
community how they would suggest to characterize and tag such areas.

-- 
Christoph Hormann 
http://www.imagico.de/

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

Re: [Tagging] Feature Proposal - RFC - (Ground)

[Martin Koppenhoefer]

sent from a phone

> On 10. Jul 2020, at 11:39, Mateusz Konieczny via Tagging 
>  wrote:
> 
> Why it would be natural=bare_ground rather than natural=bare_soil?


+1, 
I also disagree that “soil can be organic or mineral”. It has typically both, 
organic and mineral components, but organic components are a hard requirement. 
Otherwise it would be sand, or rock, or silt or clay or loam etc. (depending on 
grain size/s).

Cheers Martin 



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

[Tagging] R: Feature Proposal - RFC - (Ground)

[Michael Montani]

>Why it would be natural=bare_ground rather than natural=bare_soil?

Using "ground" and defining it as "soil, not all kinds of ground" will not go 
well.

natural=bare_ground for me is clearly including also natural=bare_rock,
while natural=bare_soil would avoid this

This is a good point. The two ways I can see this problem solved:

  *   Change the proposal to natural=bare_soil (bare_soil was one of the 
proposed possible values)
  *   Collapse natural=bare_rock into a more general natural=bare_ground 
(requires cleaning and changing to the new tag...). Too general to me.

If natural=bare_soil receives enough support we can change to that one. Also 
add your thoughts to the discussion page in the wiki in such a way to keep 
track of all the suggestions.

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:dbeabd22-00aa-4ae1-90af-239b00144290]

Da: Mateusz Konieczny via Tagging 
Inviato: venerdì 10 luglio 2020 11:37
A: Tag discussion, strategy and related tools 
Cc: Mateusz Konieczny 
Oggetto: Re: [Tagging] Feature Proposal - RFC - (Ground)

Why it would be natural=bare_ground rather than natural=bare_soil?

Using "ground" and defining it as "soil, not all kinds of ground" will not go 
well.

natural=bare_ground for me is clearly including also natural=bare_rock,
while natural=bare_soil would avoid this


Jul 10, 2020, 11:16 by michael.mont...@un.org:
Dear mappers,

after the discussion we had through the tagging ML "Are we mapping ground on 
OSM?", 
it has been open a feature proposal to map ground on OSM.

Tag: natural = bare_ground (but many other options are open to discussion).
Description: "An area covered by soil, without any vegetation"
You can find the proposal wikipage 
here.

I hope this proposal will receive as many contributions possible, thank you






--
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:a486ba8f-6409-4de5-bb51-0f9f079739d9]

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

Re: [Tagging] Feature Proposal - RFC - (Ground)

[Mateusz Konieczny via Tagging]

Why it would be natural=bare_ground rather than natural=bare_soil?

Using "ground" and defining it as "soil, not all kinds of ground" will not go 
well.

natural=bare_ground for me is clearly including also natural=bare_rock,
while natural=bare_soil would avoid this


Jul 10, 2020, 11:16 by michael.mont...@un.org:

> Dear mappers,
>  
>  after the discussion we had through the tagging ML >  "Are we mapping ground 
> on OSM?" 
> > , 
> it has been open a feature proposal to map ground on OSM.
>  
>  Tag: natural = bare_ground (but many other options are open to discussion).
>  Description: "> An area covered by soil, without any vegetation> "
>  You can find the proposal wikipage > here 
> > .
>  
>  I hope this proposal will receive as many contributions possible, thank you
>
>
>
>
>
>
> --
>  > 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.monta> ni@u> n.org >  > |>  > 
> www.ungsc.org 
>
>
>

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

Re: [Tagging] Feature Proposal - RFC - (Ground)

[Mateusz Konieczny via Tagging]

"meant any soil area (which can be organic or mineral" - what you mean by that?
Soil is mixture of mineral and organic material.

See also https://wiki.openstreetmap.org/wiki/Proposed_features/Landcover_Barren

It seems that this proposal avoid many mistakes of this very similar one, but 
reviewing
what people considered as a problem may be useful.

Jul 10, 2020, 11:16 by michael.mont...@un.org:

> Dear mappers,
>  
>  after the discussion we had through the tagging ML >  "Are we mapping ground 
> on OSM?" 
> > , 
> it has been open a feature proposal to map ground on OSM.
>  
>  Tag: natural = bare_ground (but many other options are open to discussion).
>  Description: "> An area covered by soil, without any vegetation> "
>  You can find the proposal wikipage > here 
> > .
>  
>  I hope this proposal will receive as many contributions possible, thank you
>
>
>
>
>
>
> --
>  > 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.monta> ni@u> n.org >  > |>  > 
> www.ungsc.org 
>
>
>

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

[Tagging] Feature Proposal - RFC - (Ground)

[Michael Montani]

Dear mappers,

after the discussion we had through the tagging ML "Are we mapping ground on 
OSM?", 
it has been open a feature proposal to map ground on OSM.

Tag: natural = bare_ground (but many other options are open to discussion).
Description: "An area covered by soil, without any vegetation"
You can find the proposal wikipage 
here.

I hope this proposal will receive as many contributions possible, thank you

--
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:a486ba8f-6409-4de5-bb51-0f9f079739d9]
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging