Re: [Tagging] Stop the large feature madness (was: Tag for a plateau or tableland?)

[Graeme Fitzpatrick]

On Fri, 19 Apr 2019 at 07:26, Christoph Hormann  wrote:

> On Thursday 18 April 2019, Kevin Kenny wrote:
> > > And how do you verifiably determine if two things are part of the
> > > same physical object?
>
> But as already hinted i am not sure if the Drake Passage is something i
> would consider mappable in OSM based on local knowledge.
>

But, without wishing to sound facetious, how do we then have coastlines for
Eurasia, Greenland & Antarctica mapped?

*Nobody* has "local knowledge" of the full coastline of any of them, & for
Greenland & Antarctica, what is mapped - the ice cap, which is constantly
moving, or the deep underlying rock? Should we erase them off the map as
they're not "verifiable"?

Thanks

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

Re: [Tagging] diaper subkey for wheelchair toilets including a changing table

[Warin]

On 19/04/19 05:21, Paul Allen wrote:
On Thu, 18 Apr 2019 at 19:54, Valor Naram > wrote:



https://wiki.openstreetmap.org/wiki/Proposal_process#Proposal_list
guided me to you. I have the following situation: I want to tag a
changing table but this changing table is in the toilet room for
wheelchair users. The page at
https://wiki.openstreetmap.org/wiki/Key:d
iaper states tagging for changing tables is just available in toilets
for women,-men and unisex but not in toilets for wheelchair users.


At first glance I thought you wanted to tag places where people in 
wheelchairs

could change their own diapers.  Then I checked with the wiki page and
realized what you mean.

And then I realized diaper=* is not a good idea for a key.  In British 
English we call
them nappies (singular nappy), not diapers.   And what the toilet has 
is not a supply
of nappies (diapers) but a CHANGING TABLE.  Which is what you 
described it as,
because that's what it is.  And had the key been nappy_changing_table 
instead of diaper
I wouldn't have (briefly) misunderstood what you wanted to tag (a 
changing table in
a toilet for wheelchair users, not a place where wheelchair users can 
change their

own nappy).


+1 ... change table!

Wheelies (wheelchair users) also use catheters with bags. Much easier to 
deal with compared to a diaper.



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

Re: [Tagging] Tag for a plateau or tableland?

[Joseph Eisenberg]

> there are many cases in OSM where different things are all tagged the
same ...
> brook, creek, stream, rivulet -> stream

These are mapped with one tag because there is not an objective distinction
between these names for waterways. There is waterway=stream vs
waterway=river for wide natural waterways vs narrow (“too big to jump
across” vs “jumpable”)

> bay, cove -> bay
Coves are small bays, but I do t think there is a clear way to distinguish
them

> peak, knob, hill, mound, mountain, pinnacle, tops -> peak
Several of these may refer to a ridge or massif rather than to an OSM peak,
which is a local high point. We do have natural=ridge for some of these,
which is a linear feature rather than a point.

Another example is cape vs peninsula. The tag natural=cape is used for
headlands, points, capes, etc and is a node at the extreme point of land.
Peninsula is used to describe an area of land that is mostly surrounded by
water. Some capes, like Cape Cod and they Cape of Good Hope, are both a
named peninsula and a cape with the same name, but can be mapped as 2
feature in OSM.

This is also similar to a place=hamlet mapped as a point, which may be in a
landuse=residential area, and might also be surrounded by an administrative
boundary with the same name (though in this case it would not be normal to
tag the landuse=residential with the same name)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tag for a plateau or tableland?

[Joseph Eisenberg]

Fri, Apr 19, 2019 at 7:.

> I was wondering about leaving them all under peak?
>
> natural=peak
> peak=hill/mountain/plateau/butte/mesa
>
> Would that work?
>

A peak is well defined as the local high point. A Mesa or butte will always
have at least one peak, but the peak may be in one corner, which could be
several kilometers from the center of a mesa, and a Mesa might have a dozen
different peaks around it.

Similarly, one named natural=ridge can have a dozen peaks, sometime with
different names.

Those Australian geological definitions are good, and match the American
ones that I found. A Mesa and Butte are both bordered by an escarpment
(cliff), while a “plateau” can also just be an elevated level area without
cliffs.

Since buttes are small they can usually be tagged just as a peak, but mesas
need a tag for the center of the area.

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

Re: [Tagging] Tag for a plateau or tableland?

[Graeme Fitzpatrick]

On Thu, 18 Apr 2019 at 23:40, Andrew Harvey 
wrote:

> It may be worth having different definitions, but I did want to point out
> there are many cases in OSM where different things are all tagged the same,
>
> peak, knob, hill, mound, mountain, pinnacle, tops -> peak
>

On Thu, 18 Apr 2019 at 16:09, Andrew Harvey 
wrote:

>
> An alternative is natural=plateau + plateau=butte|mesa or something like
that.

I was wondering about leaving them all under peak?

natural=peak
peak=hill/mountain/plateau/butte/mesa

Would that work?

Thanks

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

Re: [Tagging] Stop the large feature madness (was: Tag for a plateau or tableland?)

[Christoph Hormann]

On Thursday 18 April 2019, Kevin Kenny wrote:
> > And how do you verifiably determine if two things are part of the
> > same physical object?  For example: [examples snipped]
>
> I'm all for a rule of, 'if in doubt, split,' possibly paired with
> creating a new relation to carry the grouping.  You seem to favour a
> rule of 'never join,' which is perverse for the common case where
> there is broad consensus about object identity.

As mentioned in terms of physical geography the only cases where there 
is broad consensus on the identity of large size features and if and 
how to represent them in the OSM are lakes and islands.  For most other 
things mapped mostly with polygons, in particular stuff rendered 
typically with a color fill, it is widely accepted that polygons are 
split and most mappers prefer small and easy to handle divisions.  Many 
mapping conventions we have even require this - for example if part of 
a forest is needleleaved, part is mixed, you have to split it to 
represent this fact in the data.

Even for lakes we have cases where this applies by the way.  Lake 
Balkhash is a lake of which part is freshwater and part is saltwater 
which is mapped separately despite the name applying to both parts:

https://www.openstreetmap.org/relation/35904
https://www.openstreetmap.org/relation/3367363

If you consider this a bad idea that's fine.  But it stems from the 
fundamental idea of mapping local geographic knowledge.  For locals at 
the eastern part this is locally Lake Balkhash and it is saltwater.  
For locals at the western part this is also Lake Balkhash and it is 
freshwater.  And that is perfectly fine and nothing should require 
these mappers to settle for a uniform but locally inaccurate 
representation of the geography.

> > I distinguish between names and labels.  Labels are graphical
> > representations of names or other strings in map renderings.  The
> > OSM database should not contain labels, it should contain names.
>
> On this, we agree. To what object should the name, 'Jamaica Bay' be
> assigned? How can such an object be constructed? The locals can
> clearly define its extents, except for very small indefinite
> boundaries over narrow entrances and exits. What should be done to
> give that object, which unquestionably is observable in the field as
> an entity distinct from the ocean, existence in OSM?

I respect your desire to find a consensus for how to represent this 
particular feature but this doesn't really have much to do with the 
subject here, that is to what extent we can and should map large size 
concepts in OSM.  Jamaica Bay is beyond any doubt small enough to be 
mapped under the rule of thumb i proposed so discussing this is IMO not 
a matter of if it should be mapped but only potentially what is the 
best way to map it recording all verifiable knowledge of it in an 
efficient way.  I would like to separate that discussion from the 
subject here.  IIRC in our previous discussion on this i made a 
principal point that creating a polygon is unnecessary even here but i 
don't think i really objected to using one.

> We have that at one extreme, a case where almost all the boundaries
> are indefinite.  Nevertheless, the Drake Passage has some sort of
> existence.

Yes.  Leaving aside for the moment the question if something like the 
Drake Passage should be represented in OSM - the Drake Passage is a 
great example for a strait where no geometric information is required 
beyond a node to fully represent the feature in its spatial 
characteristics.

The Drake Passage is the passage/strait between Cape Horn (the southern 
end of South America) and the Antarctic.  As a prototype of a strait 
between two convex land masses it has no length but only a width.  It 
is perfectly documented with a node placed half way from Cape Horn to 
the closest point in the Antarctic (on the South Shetland Islands).

But as already hinted i am not sure if the Drake Passage is something i 
would consider mappable in OSM based on local knowledge.  Of course as 
long as it was mapped with a simple node it did not really bother 
anyone - you could as a mapper or data user simply ignore it.

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

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

[Tagging] Stop the large feature madness

[Michael Patrick]

 > The idea that every object, even among those that can be easily mapped
in a day, has a single True Name, is simply an incorrect assumption
around here.

A few months ago, I went to a mixer hosted by a new online real estate
startup, and the attendees were an interesting mix of neighborhood low
income housing activists, property managers, and city officials.

I was noticed some of their listing had notations that the property was in
'neighborhood Y', when actually it was, IMHO, in 'neighborhood X' because I
had lived their, and according to the city 'association' map, it was in
'neighborhood Z'. Now, 'neighborhood X' had historically been of somewhat
ill repute ( like newspaper crime and environmental reporting ), and 'X'
had some fairly definite walking, connectivity, commerce ( The' X Market'
), and boundary elements.

The city people admitted that their map was made quickly and they had
basically used Census boundaries and never checked with anyone, and nobody
ever complained, and said they were really open to changing it, that it was
only a temporary place holder. The activist noted their neighborhood had
been divided and assigned to two others, essentially erasing their
semi-official status. The property management people were looking really
uncomfortable, and as I continued scanning the listings, found that they
had invented a few new 'plausible' neighborhoods 'neighborhood "T Street'
and 'neighborhood S Street' and assigned some listings to the higher income
'neighborhood Y'. When I pressed them, they said it was because they could
charge higher lease rates, and based on client feedback, nobody wanted to
live in 'neighborhood X' when a Google Search was done.

I gave the start-up founder my copy of 'Seattle Geographies' in sympathy,
advised him to read it, and left before the serious blood letting began:
http://www.aag.org/cs/aag_bookstore/other_publications/seattle_geographies

There's been a long term feud going about the local 'International
District':
https://www.seattletimes.com/seattle-news/name-feud-clouds-opening-of-library/

+1 on "There is no single True Name"

Kenny, that was an absolutely wonderful post on New England geographies.

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

Re: [Tagging] diaper subkey for wheelchair toilets including a changing table

[bkil]

This sounds reasonable.

On Thu, Apr 18, 2019 at 10:10 PM marc marc 
wrote:

> Le 18.04.19 à 20:53, Valor Naram a écrit :
> > I want to tag a changing table but this changing table
> > is in the toilet room for wheelchair users.
>
> imho diaper is a little ugly : documented values are mix
> of how many, what and where.
>
> if I wanted to fill this in as precisely as you do,
> I would do it like this :
>
> 1) If both toilets are mapped as a separated node
> amenity=toilets
> wheelchair=designated
> diaper=yes
>
> amenity=toilets
> wheelchair=no
> diaper=no
>
> 2) if both toilets are mapped as a single node
> amenity=toilets
> wheelchair=yes
> diaper=yes
> diaper:location=wheelchair_toilets
>
> 3= if toilet that belongs to an amenity or a building doesn't have it's
> own object, for ex with a bar
> amenity=bar
> toilets:wheelchair=yes
> diaper=yes
> diaper:location=wheelchair_toilets
> ___
> 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] Stop the large feature madness

[marc marc]

Le 18.04.19 à 20:29, Christoph Hormann a écrit :
> you verify the information on the ground and if there is still 
> disagreement it is by definition something that is not verifiable
> (because several mappers evaluating the situation independently 
> do not consistently come to the same results). 

with your argument, if I disagree with the boundaries of a country,
it will be necessary to remove all the nodes of the boundary except 
historical landmarks, border crossings and where there would be a sign
because everything else is not "on ground verifiable" ?
welcome to OpenPurgedMap :-)

with a municipality I am working on, in one year I only found 2 
historical landmarks, whereas there are 404 nodes in osm. I hope
that nobody will contest the verifiable of the border, otherwise
a municipality boundary with 2 nodes will be ridiculous.
imho this demonstrate by the absurdity that the argument "in case
of disagreement, only on-ground verifiable information is kept"
does not work. it's so extreme that it's inapplicable.
please come back to reality or fork a OpenGroundOnlyMap
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tag for a plateau or tableland?

[Michael Patrick]

>> But if a locality represents only a historic location that has no
>>  physical presence today, it is debatable if this is a “real and
>>  current” feature that is appropriate for OSM rather than a historical
>>  map.

> If the name is still in present use then it belongs in OSM, even if
> there is no physical presence on the ground people still use the name to
> define the place.

We might get some ideas about how to handle these issues about what goes on
the map from organizations that have already dealt with them ( some like
the British Ordnance Survey, over hundreds of years ). They publish their
naming policies ( Toponymic Nomenclature  ), and almost every country ( and
the U.N. ) has one, The U.N. links to these from
https://unstats.un.org/Unsd/geoinfo/UNGEGN/nna.html and the Canadian one,
for example is at
https://unstats.un.org/Unsd/geoinfo/UNGEGN/docs/NNA/GNBC_english_accessible.pdf
- refer to 'Principle 2', for example: "NAMES IN GENERAL PUBLIC USE" - First
priority shall be given to names with long-standing local usage by the general
public. Unless there are good reasons to the contrary, this principle should
prevail. Most U.S. states also have a board:
https://www.jstor.org/stable/20615877?seq=1#page_scan_tab_contents

Unlike most agency documents, these can be a pretty fun read, imaging the
arguments that created the item in the first place: " ... Examples are
Pekwachnamaykoskwaskwaypinwanik
Lake in Manitoba and Île Kuchistiniwamiskahikan in Quebec."!

Remote mapping, it is really hard to tell if a name is in use locally, and
frequently I've encountered names like 'Jackson's Barn' that the original
landmark rotted away fifty years ago.


> but when the thing is gone, (a rail line stop that is no longer there),
or is a collection of larger items that get named like a city or a village
- yet have zero residents - seems like a good use for locality to me.

+1

> Thus mesas and buttes could be mapped as nodes or areas, but plateaus
could only be mapped as nodes. Thoughts?

I scanned the NGA name server, and plateaus seem to be large areas, and
mapped as points.

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

Re: [Tagging] Stop the large feature madness (was: Tag for a plateau or tableland?)

[Paul Allen]

On Thu, 18 Apr 2019 at 21:00, Kevin Kenny  wrote:

>
> The controversy lies not in the choice of tag but rather in the
> presence of long indefinite boundaries.
>

I thought part of the controversy was the very large polygons involved.
You can map a
strait as a way or a node.

Some may think of it as label painting, but that is a definite geographical
feature.  A passage
which is generally preferred to other routes through narrower straits even
though the weather
is a little rougher.

I'm with you on this one.  If the rules we work to insist that we cannot
map features such as
this so that people can see them on OSM then the rules are wrong.

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

Re: [Tagging] Stop the large feature madness

[Kevin Kenny]

On Thu, Apr 18, 2019 at 2:30 PM Christoph Hormann  wrote:
> No, the concept of verifiability defines a clear path for resolving
> disagreement - you verify the information on the ground and if there is
> still disagreement it is by definition something that is not verifiable
> (because several mappers evaluating the situation independently do not
> consistently come to the same results).

In the specific case of names, we've invented name:language and
alt_name and old_name and name_1, name_2, etc. to deal with the cases
of, 'everyone agrees that there's a pond/mountain/building/whatever
here, but not all the locals call it by the same name.' The name may
be verifiable in that if you have a sufficiently large sample of
locals, you'll hear it, or if you ask, you may get the answer, "yes,
that's what some people call it."

I do recognize that you tend toward the 'strict verifiability' camp,
and that I've somewhat caricatured it by saying 'if a stranger dropped
into a location can verify everything about it by direct observation
without consulting the locals or outside sources.' That strict a
definition excludes a good many names, at least in the rural US, which
isn't big on hanging a sign on every named feature.

The idea that every object, even among those that can be easily mapped
in a day, has a single True Name, is simply an incorrect assumption
around here.

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

Re: [Tagging] diaper subkey for wheelchair toilets including a changing table

[marc marc]

Le 18.04.19 à 20:53, Valor Naram a écrit :
> I want to tag a changing table but this changing table
> is in the toilet room for wheelchair users.

imho diaper is a little ugly : documented values are mix
of how many, what and where.

if I wanted to fill this in as precisely as you do,
I would do it like this :

1) If both toilets are mapped as a separated node
amenity=toilets
wheelchair=designated
diaper=yes

amenity=toilets
wheelchair=no
diaper=no

2) if both toilets are mapped as a single node
amenity=toilets
wheelchair=yes
diaper=yes
diaper:location=wheelchair_toilets

3= if toilet that belongs to an amenity or a building doesn't have it's 
own object, for ex with a bar
amenity=bar
toilets:wheelchair=yes
diaper=yes
diaper:location=wheelchair_toilets
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Stop the large feature madness (was: Tag for a plateau or tableland?)

[Kevin Kenny]

On Thu, Apr 18, 2019 at 3:49 PM Paul Allen  wrote:
> How about natural=strait?  For very large values of "strait."  Or, if you 
> don't like the idea
> of large values of strait, rewrite the wiki page changing
>
> A strait is a narrow area of water surrounded by land on two sides and by 
> water on two other sides forming a connection between those bodies of water.
> to
> A strait is a channel of water surrounded by land on two sides and by water 
> on two other sides forming a connection between those bodies of water.
>
> Because the point of a strait is not that it is narrow in absolute terms but 
> that it is narrower than
> the bodies of water it connects.  OTOH, it is a very large value of "strait."

The controversy lies not in the choice of tag but rather in the
presence of long indefinite boundaries.

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

Re: [Tagging] Avoid using place=locality - find more specific tags instead

[Kevin Kenny]

On Thu, Apr 18, 2019 at 1:09 PM Greg Troxel  wrote:
> Warin <61sundow...@gmail.com> writes:
> > If the name is still in present use then it belongs in OSM, even if
> > there is no physical presence on the ground people still use the name
> > to define the place.
>
> Agreed.  Around me, my impression is that most place=locality are place
> names that people use.
>
> Part of the core issue is the separation between our modern notion of
> place as defined by administrative boundaries vs. the older notion of a
> town/village center and things that are near it.  At least in the
> northeast US, I think there's a been a vast shift in the past 200 years.

Part of that is that as our population has grown, so have our
settlements, to where we have to give greater respect to the
boundaries between them.

Also, as communications have improved, we've needed more definition.
People need to know what post office serves them, and the name they
give to their home town is usually the name of the post office - or
they'll say something like, "It's the Schenectady post office, but I'm
actually outside the city line in Niskayuna."  The post office name is
more visible from day to day than which municipality is collecting the
property tax - but it was nearly a non-issue in a time when people had
few contacts outside their home villages and perhaps a few
neighbouring ones.

The administrative boundaries do, of course give rise to corner cases.
My brother lives in the Town of Tusten in New York.  His mail comes
through the Narrowsburg post office, but he's some miles from
Narrowsburg village.  He's actually quite close to the Tusten
settlement, but that's a ghost town. There's still a little church
there, which no longer conducts regular services, some old roads that
have been little improved since their construction in the eighteenth
century, a fine stone-arch bridge to nowhere spanning the Ten Mile
River (the road beyond was destroyed in the construction of the Erie
Railroad), and stone foundations where buildings once stood. There are
still apple trees and rose bushes in among the beeches and maples that
have grown since the place was inhabited. Despite its near-complete
abandonment, it still lends its name to the township, which now has
its town hall-cum-library-cum-police station-cum-firehouse in
Narrowsburg.

In New England, the townships were established early, so you get the
anomalies of uninhabited townships (Wentworth Location, NH, or Second
College Grant, NH), villages named because they were founded near the
center of the townships (so that Hanover township has both a town
named Hanover and a village named Hanover Center - the situation is
not uncommon), and so on. The Naming of Names is complicated.

I'd say that localities without physical or administrative features
are rare, but they are not entirely unheard-of.  They usually have
complex history, but if that history isn't visible on the ground, it's
a more fitting subject for OHM. If the name is still in common use
despite the lack of a feature, observable today, to bind it, it's a
locality - hence Tusten the township is an administrative boundary,
but Tusten the settlement is a locality and an abandoned:place=hamlet.

This idea will surely offend those purists who believe that the only
things that can be mapped are those that can be observed directly by a
stranger deposited in their midst, without allowing the stranger to
consult locals or outside reference sources. If the name isn't on a
sign that the stranger can observe, it doesn't exist.

In rural America, we've never been much for putting up signs, and have
been known to take a perverse delight in misinforming and misdirecting
travelers. The locals often have names that aren't signed.

And what can I say?  I've been to Agloe, New York.
(https://en.wikipedia.org/wiki/Agloe,_New_York) Before John Green
wrote the book, even.

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

Re: [Tagging] Stop the large feature madness (was: Tag for a plateau or tableland?)

[Paul Allen]

On Thu, 18 Apr 2019 at 20:27, Kevin Kenny  wrote:

>
> We have that at one extreme, a case where almost all the boundaries
> are indefinite.  Nevertheless, the Drake Passage has some sort of
> existence. If a map user reads the sentence, 'The _Nancie Belle,_
> having survived the perilous journey through the Drake Passage, turned
> to the north and made for Buenos Aires,' then that user might well
> ask, "Where's the Drake Passage?". Should OpenStreetMap contain the
> information needed to answer that question, perhaps through a
> Nominatim query?  If so, in what form should that information be
> represented?  Ought that information be in such a form that a map of
> the Southern Ocean can render it competently, or is that rendering not
> a job for OSM?
>

How about natural=strait?  For very large values of "strait."  Or, if you
don't like the idea
of large values of strait, rewrite the wiki page changing

A strait is a narrow area of water surrounded by land on two sides and by
water on two other sides forming a connection between those bodies of
water.
to
A strait is a channel of water surrounded by land on two sides and by water
on two other sides forming a connection between those bodies of water.

Because the point of a strait is not that it is narrow in absolute terms
but that it is narrower than
the bodies of water it connects.  OTOH, it is a very large value of
"strait."

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

Re: [Tagging] Stop the large feature madness

[Michael Patrick]

... INRE: http://bit.ly/2IGkgoj

> Nobody proposed ban on mapping things far away from your place of
residence.

> That's an amazing image, thanks Michael.

Hmmm ... it's not a really a bona fide 'map',
per se,it's really just a silly snarky sarcastic
cartoon based on narrow assumptions and
a highly suspect data model - inspired by
my personal knee jerk reaction to other
community members perfectly justifiable
philosophies of what OSM 'is'.

> I take it that's the home location of all OSM contributors?

Ummm ... No, I stated a hypothetical 'What
if' scenario: " If everyone on Earth joined OSM ...",
so the 'locations' are based on the entire
global population derived from:*"*Center for
International Earth Science Information Network
- CIESIN - Columbia University. 2016. Gridded
Population of the World, Version 4 (GPWv4):
Population Density. Palisades, NY: NASA
Socioeconomic Data and Applications Center
(SEDAC). http://dx.doi.org/10.7927/H4NP22DQ
that I use frequently.

I also do time space / mapping, so for the second
'constraint', '...and limited their mapping to their
own local knowledge', from my knowledge of
Torsten Hägerstrand's ( et. al. ) framework of
time / space trajectories of individual humans
in the environment, I made S.W.A.G. to get a
'home range' of our set of global mappers.
( https://www.spektrum.de/lexika/images/geogr/fff59_w.jpg ).
I then made a mad leap to a conclusion that this
'range' was approximately the same as the grid
size. ( maybe not so mad, there is a vast literature
around this: http://meipokwan.org/Gallery/STPaths.htm
... and some folks have even extended the model into
'virtual spaces' like WoW ).

I then sampled some area like the middle of the
Sahara, Siberia, Yukon Territory to get a lower
bound ( nobody lives here ) and did a blunt
overly simplified binary classification, and used
this as a mask to punch out the OSM world map.

The projection used is psychological, not
geographical ( https://en.wikipedia.org/wiki/Psychological_projection ).

> ... also a bit surprised that Australia & NZ have
dropped back into the Ocean - I thought there
were a few more of us than that? ..

See http://worldpopulationreview.com/countries/countries-by-density/
Australia is 225 ( out of 230 ) and NZ is 198.
It's actually even more dramatic than this,
the Australian Census even has a special
distinction for remote areas. It's also an
artifact of the population dataset in
relation to the resolution of the final
graphic. If you are feeling left out, I
can adjust that single pixel value.

> (cc'ed to AU list for interest's sake :-))

Please tell them this wasn't serious, I
don't want to get kicked out of the union.

> Nice and funny illustration of OSM problems
with global and remote natural areas. How did
you create it?

Thank you, and see above. A little used
GIS tool called InkScape ( perfectly
good for doing raster analysis, most
'art' tools ( like 'burning', etc. ) are
equivalent to some GIS raster math.

> Nobody proposed ban on mapping
> things far away from your place of residence.

Embedded in Hägerstrand( et. al. ) is that
notion of what is 'near' and 'far' for an
individual and their experiences. I can
look out an airplane window and make
a pretty good guess what state I'm over
by the road network ( http://www.legallandconverter.com/images/RSS1.jpg ),
but while my neighbor gets lost walking
to the store - but he can tell you every
landmark in his online games. We're all
different.

> That would probably only add to this picture
some spots (remote settlements and touristic
attractions) and thin lines (along routes).And
probably only spots, if single day would be the limit.

You hit the nail on the head. Humans have
just so much attentional bandwidth.

> OSM started as a very local enterprise, but
the world is much wider, so we should rethink
how to deal with them, because the world is
not gonna shrink...

https://www.newscientist.com/article/dn27875-earths-shrinking-crust-could-leave-us-living-on-a-water-world/
... but you do have a point, there. :-)

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

Re: [Tagging] Stop the large feature madness (was: Tag for a plateau or tableland?)

[Kevin Kenny]

On Thu, Apr 18, 2019 at 12:53 PM Christoph Hormann  wrote:

> How should they determine that based on local knowledge?  What if there
> is disagreement?  Is
> https://www.openstreetmap.org/way/83015625
> the same river as
> https://www.openstreetmap.org/way/4769426
> or
> https://www.openstreetmap.org/way/174752117
> or
> https://www.openstreetmap.org/way/234008385

I can't comment, not being familiar with the local situation.
Certainly, there is a well-known situation in the US, the 'Ohio', the
'Allegheny' and the 'Monongahela' rivers are considered by the locals
to be three distinct objects, with the first formed by the confluence
of the other two. The Ohio begins in Pittsburgh. Neither of its two
tributaries is the Ohio.  If your example is similar, it's appropriate
to separate them in the database.  I presume that 'Aar', 'Vorderrhein'
and 'Hinterrhein' are conceptually similar - sections, tributaries or
distributaries of the Rhine, with their own distinct identities.

> What if the local mappers do not speak the same language?  Do those who
> speak English automatically get to overrule those who don't?

We've dealt with the issue of names in different languages before, and
it's not necessarily a problem. A few tens of km north of me, nobody
would argue that 'Lac du Saint-Sacrement' and 'Lake George' are
distinct lakes. Whether a mapper speaks English or French, they'd
recognize the lake itself as being the same object, with different
names in two languages. 'Fleuve Saint-Laurent' and the 'Saint Lawrence
River' are the same river, and the speakers of both languages agree on
its identity, even if not its name. It's when the different cultures
or language groups disagree on the object boundaries that things get
difficult, but for the purpose of this particular discussion I'm
trying to focus on "medium sized" objects - too big to map in a day
(or maybe too big for a single mapper to maintain), but for which
there is a broad consensus about object identity.  I'm trying to
address the Jamaica Bays, Cape Cods, and the like, which at least in
my part of the world are much commoner than any objects that have
horrible political implications.

> > > Everything else in physical geography is typically mapped locally
> > > piece by piece like the rivers and creating large features - while
> > > done by some mappers for the purpose of label painting - is
> > > generally disliked by most mappers because it is very hard to work
> > > with these and represents no additional meaningful information.
> >
> > That's where we disagree. The additional information is that the
> > multiple features represent the same physical object.
>
> And how do you verifiably determine if two things are part of the same
> physical object?  For example: [examples snipped]

I'm all for a rule of, 'if in doubt, split,' possibly paired with
creating a new relation to carry the grouping.  You seem to favour a
rule of 'never join,' which is perverse for the common case where
there is broad consensus about object identity.

> > Please avoid the term "label painting." What you call "label
> > painting" is the entirely reasonable desire to have recognized, named
> > objects appear on the map with their names.
>
> I distinguish between names and labels.  Labels are graphical
> representations of names or other strings in map renderings.  The OSM
> database should not contain labels, it should contain names.

On this, we agree. To what object should the name, 'Jamaica Bay' be
assigned? How can such an object be constructed? The locals can
clearly define its extents, except for very small indefinite
boundaries over narrow entrances and exits. What should be done to
give that object, which unquestionably is observable in the field as
an entity distinct from the ocean, existence in OSM?

The last time that we had this discussion, you dismissed wanting to
have Jamaica Bay exist as a named object as 'label painting.' I was
forced then to conclude that your definition of 'label painting' is
considerably broader than simply putting meaningless objects in the
database so that names will appear. Let it be clear: my wish for
Jamaica Bay is to identify the definite portions of its boundary
accurately, to complete its indefinite boundaries for topologic
consistency, and to have it appear in the database as the area feature
that it is, with its name. Note that I did not refer to rendering in
that request. *Part* of my wish to have the name in turn triggers a
wish to render the name. That's an ordinary human desire. Map users,
when there are objects on maps, expect to see them labeled.

Since my use of OSM does not involve intensive use of OSM-Carto, I
really consider its rendering to be secondary.  If I have the named
feature, I'll worry about how to render it in the maps I produce. If I
don't have the feature somewhere, then no conceivable rendering can
show it.  But it goes beyond rendering: I want to be able to do things
like 'gaging stations in Jamaica Bay or 

Re: [Tagging] diaper subkey for wheelchair toilets including a changing table

[Paul Allen]

On Thu, 18 Apr 2019 at 19:54, Valor Naram  wrote:

>
> https://wiki.openstreetmap.org/wiki/Proposal_process#Proposal_list
> guided me to you. I have the following situation: I want to tag a
> changing table but this changing table is in the toilet room for
> wheelchair users. The page at https://wiki.openstreetmap.org/wiki/Key:d
> iaper states tagging for changing tables is just available in toilets
> for women,-men and unisex but not in toilets for wheelchair users.
>

At first glance I thought you wanted to tag places where people in
wheelchairs
could change their own diapers.  Then I checked with the wiki page and
realized what you mean.

And then I realized diaper=* is not a good idea for a key.  In British
English we call
them nappies (singular nappy), not diapers.   And what the toilet has is
not a supply
of nappies (diapers) but a CHANGING TABLE.  Which is what you described it
as,
because that's what it is.  And had the key been nappy_changing_table
instead of diaper
I wouldn't have (briefly) misunderstood what you wanted to tag (a changing
table in
a toilet for wheelchair users, not a place where wheelchair users can
change their
own nappy).

I think this is a very bad tag.  I'm not sure I'm doing it right, but I
can't find a proposal for this
tag.

My question is: Is there any possibility to tag a changing table in a
> toilet for wheelchair users similiar or equal to
> 'diaper:wheelchair="yes"' I didn't find such specification at https://w
> iki.openstreetmap.org/wiki/Key:diaper or it exists but isn't documented
> yet.
>

That fits in with the others, but I'm not convinced we should be trying to
add to what I
consider to be a bad key.  I'd prefer to see a proposal for
nappy_changing_table*=* or
something similar.  But I expect there will be many who disagree with me.

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

[Tagging] diaper subkey for wheelchair toilets including a changing table

[Valor Naram]

Hello there,

https://wiki.openstreetmap.org/wiki/Proposal_process#Proposal_list
guided me to you. I have the following situation: I want to tag a
changing table but this changing table is in the toilet room for
wheelchair users. The page at https://wiki.openstreetmap.org/wiki/Key:d
iaper states tagging for changing tables is just available in toilets
for women,-men and unisex but not in toilets for wheelchair users.

My question is: Is there any possibility to tag a changing table in a
toilet for wheelchair users similiar or equal to
'diaper:wheelchair="yes"' I didn't find such specification at https://w
iki.openstreetmap.org/wiki/Key:diaper or it exists but isn't documented
yet. If such tagging doesn't exist, I will write a proposal for you to
discuss and vote on.


Cheerio

Sören alias Valor Naram.

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

Re: [Tagging] Stop the large feature madness

[Christoph Hormann]

On Thursday 18 April 2019, marc marc wrote:
> > What if there is disagreement?
>
> it's not related to large feature, it's a issue with all
> source=local knownledge changeset (or no source at all).

No, the concept of verifiability defines a clear path for resolving 
disagreement - you verify the information on the ground and if there is 
still disagreement it is by definition something that is not verifiable 
(because several mappers evaluating the situation independently do not 
consistently come to the same results).

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

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

Re: [Tagging] Stop the large feature madness

[marc marc]

Le 18.04.19 à 18:52, Christoph Hormann a écrit :
> What if there is disagreement?

it's not related to large feature, it's a issue with all
source=local knownledge changeset (or no source at all).
a hudge river may have a sign every km
a road in a village I like doesn't have a sign.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Avoid using place=locality - find more specific tags instead

[Greg Troxel]

Warin <61sundow...@gmail.com> writes:

> On 18/04/19 09:52, Joseph Eisenberg wrote:
>>
>>
>>
>> But if a locality represents only a historic location that has no
>> physical presence today, it is debatable if this is a “real and
>> current” feature that is appropriate for OSM rather than a
>> historical map.
>
> If the name is still in present use then it belongs in OSM, even if
> there is no physical presence on the ground people still use the name
> to define the place.

Agreed.  Around me, my impression is that most place=locality are place
names that people use.

Part of the core issue is the separation between our modern notion of
place as defined by administrative boundaries vs. the older notion of a
town/village center and things that are near it.  At least in the
northeast US, I think there's a been a vast shift in the past 200 years.

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

Re: [Tagging] Stop the large feature madness (was: Tag for a plateau or tableland?)

[Christoph Hormann]

On Thursday 18 April 2019, Kevin Kenny wrote:
>
> And therefore the Amazon, the Nile, or the Mississippi ought not to
> be named in such a way that a large-scale map can show the names?

Map producers are obviously free to show labels however they want.  They 
don't need mappers to hand curate dedicated labeling objects for that.  
Ironically the waterway relations we have are not really of much use if 
you want to label rivers in a map.

> Essentially, you're making the statement here that if local mappers
> pool their knowledge to realize that the river in Alexandria is the
> same river in Aswan, that's a mere social convention and has no place
> on the map.

How should they determine that based on local knowledge?  What if there 
is disagreement?  Is 

https://www.openstreetmap.org/way/83015625

the same river as

https://www.openstreetmap.org/way/4769426

or

https://www.openstreetmap.org/way/174752117

or

https://www.openstreetmap.org/way/234008385

What if the local mappers do not speak the same language?  Do those who 
speak English automatically get to overrule those who don't?

> > Everything else in physical geography is typically mapped locally
> > piece by piece like the rivers and creating large features - while
> > done by some mappers for the purpose of label painting - is
> > generally disliked by most mappers because it is very hard to work
> > with these and represents no additional meaningful information.
>
> That's where we disagree. The additional information is that the
> multiple features represent the same physical object.

And how do you verifiably determine if two things are part of the same 
physical object?  For example:

https://www.openstreetmap.org/way/335279145
https://www.openstreetmap.org/way/301691395

which a map producer might want to label the Amazon Rain Forest.

Or these two:

https://www.openstreetmap.org/relation/5567277
https://www.openstreetmap.org/way/470015023

which another map producer might want to label the Eurasian Taiga.

> Please avoid the term "label painting." What you call "label
> painting" is the entirely reasonable desire to have recognized, named
> objects appear on the map with their names.

I distinguish between names and labels.  Labels are graphical 
representations of names or other strings in map renderings.  The OSM 
database should not contain labels, it should contain names.

This:

https://www.openstreetmap.org/relation/9359806

is not a named representation of a verifiable element of the geography, 
it is a labeling geometry.  Creating such is not mapping, it is label 
drawing or label painting.  It is neither meant nor suited to do 
anything other than performing a relatively simple label placement.

Note by speaking of "label painting" i do not intend to assign one sided 
blame to mappers for doing so.  In most cases this is as much the fault 
of map designers encouraging this as it is of mappers to respond to 
this incentive.

> The "hard to work with" argument is what I said is a technological
> limitation.

With "hard to work with" i was referring to work for the mapper in 
maintanance, editing and also just dealing with the object being in the 
way when editing other things.  That is not a technological limitation.

When you talked about technological limitations you were referring to 
problems of data users.

> Now, I could imagine that if the world were other than as it is,
> another culture might insist that the main stem of the river was the
> Missouri, rather than the upper MIssissippi, leading to disagreement
> about the boundaries. That disagreement could be very ugly if the
> cultures were, say, continually embroiled in political conflict about
> other matters. In that case, making a single decision about the
> boundaries might conceivably be imperialistic.

I am glad you understand the problem.  If you now look at examples 
outside the United States (where if i may say so the originally 
different cultures have been largely "homogenized" a long time ago) you 
will realize that the situation is often not that simple in other parts 
of the world.  The fact that people from more than a hundred countries 
from all over the world with very different cultures, world views and 
languages in OSM work together in collecting local knowledge despite in 
many cases not even being able to verbally communicate with each other 
is quite remarkable.  But this amazing cross cultural cooperation 
hinges on on the local verifiability of those things people map.  
Adding large scale concepts to the database that are not verifiable 
based on local knowledge means throwing a wrench into the gears of this 
amazing machine.

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

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

Re: [Tagging] Stop the large feature madness (was: Tag for a plateau or tableland?)

[Kevin Kenny]

On Thu, Apr 18, 2019 at 5:49 AM Christoph Hormann  wrote:
> You apparently misunderstood what i said.  My 'surveyable in a single
> day by a single mapper' rule of thumb refers to mapping something as a
> single feature.  A river several thousand kilometers long for example.
> The river is locally still a verifiable element of the geography and
> can be mapped - piece by piece as it is generally established practice
> in OSM.  But if you create a feature for the whole river extending over
> thousands of kilometers that is not something you do based on local
> knowledge, that is based on social conventions you have read up in a
> book, on wikipedia or elsewhere.

And therefore the Amazon, the Nile, or the Mississippi ought not to be
named in such a way that a large-scale map can show the names?
Essentially, you're making the statement here that if local mappers
pool their knowledge to realize that the river in Alexandria is the
same river in Aswan, that's a mere social convention and has no place
on the map. Yesterday, Farouk maps one piece of its shoreline, and
today Karim maps an adjacent piece. According to your argument, those
ways ought never to be merged because ... why, exactly? Because
there's no provable single mapper with local knowledge of both of
them?  If a few dozen mappers do that, you can wind up with a feature
that's a thousand km long. They have each contributed the local name -
and it's the Nile for the entire extent, as the boatman who plies its
length could have told them.

> Everything else in physical geography is typically mapped locally piece
> by piece like the rivers and creating large features - while done by
> some mappers for the purpose of label painting - is generally disliked
> by most mappers because it is very hard to work with these and
> represents no additional meaningful information.

That's where we disagree. The additional information is that the
multiple features represent the same physical object.  Without that
information, dealing with them at large scale becomes an exercise in
ambiguity - trying to build up larger features from tiny ones, by
guessing that adjacent ones with similar attributes are parts of the
same whole. One misplaced node on a shared boundary, and the whole
thing falls apart.  That's one of several things that relations are
for - identifying that some number of small features are parts of a
larger one.

Please avoid the term "label painting." What you call "label painting"
is the entirely reasonable desire to have recognized, named objects
appear on the map with their names.  Calling it "label painting" and
saying that it provides no useful information is stating, "you
shouldn't want to work with that identified, named object, only its
parts or only some arbitrarily chosen part within it." It belittles
the user, and cuts off the conversation. There are much more
productive approaches: "I understand your want, and you can't have
that right now because we haven't worked out how to do it. Can you
help us define the needs?" is one. "That doesn't fit exactly with the
way we structure the data right now, would it be an acceptable
alternative if you were to ..." is another.

The "hard to work with" argument is what I said is a technological
limitation. If the Gulf of Aqaba - a well-defined object except for an
imaginary line across its narrow mouth - cannot be mapped because the
resulting relation would be too large, or because the data model
cannot cope with the indefiniteness of having two adjacent waterbodies
(waterbodies ordinarily do not have a well-defined bright line
separating them), that's a limitation of the data model or the tools
that work with it. Those are technological limitations, pure and
simple.

I return to an example that I used a few months ago, which I still
haven't attempted to map because largely of your and Frederik's
extremely vociferous objections: Jamaica Bay.  Let me point you to
maps that include the bay, created by skilled human cartographers:
https://caltopo.com/l/1UL6

What you see at that link includes the boundaries of several map
sheets. Note that Jamaica Bay is lettered as a prominent feature on
all of them.  The smaller features - Island Channel, Pumpkiin Patch
Channel, Grassy Bay and so on are parts of it, and are typically known
only to those who go out on the water - many land-dwellers around the
bay typically do not know their names. But the bay is known to all of
them. When I lived down that way, near https://caltopo.com/l/TPG3, my
neighbours might not know the individual parts were named Mott's
Basin, Nr Bar Channel (Nr bar is now Johnson Bar, and not a
moment too soon!) or the Head of the Bay - but everyone knew Jamaica
Bay!

If you simply left it as 'coastline' they'd look at you as if you had
two heads, and even more so if you called it the Atlantic Ocean.  The
ocean is a short distance to the south. It has pounding surf; the bay
has slack water. The ocean is salt, the bay is brackish. The bay has 

Re: [Tagging] More large feature problems: Seas, Bays and Straits

[marc marc]

Le 18.04.19 à 15:42, Joseph Eisenberg a écrit :
> I am thinking of changing the place=sea wiki page back to the earlier
> version that only recommended mapping as nodes, because I cannot
> download and manage these new huge relations.

Should Russia or the USA boundary relationship be reduced
into a node because their boundary relationship is too big for you ?
I think that's a very bad reason.

The real argument in my opinion is: do we have a valid and uncontested 
opendata source to define this object ? or any information to survey
to define this area (the problem is often the marine part) ?
if so, there will inevitably be contributors who will transform
the nodes into a area.

if there is no source available or if it is contradictory,
then it does not make much sense to convert an imprecise node
into a surface, half right, half wrong.
but too many changeset lack a valid source tag filled
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] More large feature problems: Seas, Bays and Straits

[Joseph Eisenberg]

Either seas should be mapped as areas, or should bays and straits
should not be mapped as areas. Which is the best option?

Right now, mappers are changing seas to bays and mapping as large
multipolygons to get them to render. In the past year the number of
natural=bay relations has increased from 2,000 to almost 5,000, while
the number of nodes only increased from 45k to 46k. Relations tagged
natural=strait increased from 290 in March 2018 to 945 today.

This happened after bays and straits mapped as polygons were rendered
at low zoom levels in the Openstreetmap-Carto style. The rendering
change also encouraged mappers to use natural=bay for very large
features that are called a "gulf" or "bay" even though they are larger
than the average "sea".

The wiki page for place=sea has said this since 2011: "A large body of
marine water and part of an ocean: seas, gulfs, bights and very large
bays such as the Bay of Biscay."

Yet the Bay of Biscay is now mapped as a multipolygon tagged
natural=bay (likely so that it will be rendered at low zoom levels).

The original wiki page for place=sea only recommended using a node.
Another users added a suggestion to map with a multipolygon, but the
list of acceptable objects was not changed to include "area" until
January 2018. At that time, there were over 120 place=sea mapped as
nodes and less than 20 mapped as relations (see
https://taghistory.raifer.tech). Now there are 68 place=sea nodes and
63 place=sea relations.

Clearly, a few mappers have spent a good deal of time changing bay,
strait and sea nodes to multipolygons in the past several months.

I am thinking of changing the place=sea wiki page back to the earlier
version that only recommended mapping as nodes, because I cannot
download and manage these new huge relations.

Also see: https://github.com/gravitystorm/openstreetmap-carto/pull/3750

However, perhaps others disagree?

I also think that if seas should be mapped, large bays should also be
mapped as nodes rather than large multipolygons.

(Straits and narrow bays like fjords can also be mapped as linear ways)

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

Re: [Tagging] Tag for a plateau or tableland?

[Andrew Harvey]

It may be worth having different definitions, but I did want to point out
there are many cases in OSM where different things are all tagged the same,
which I generally think is a good thing (easier for mappers to find the
right tag and less disagreement on which tag to use). Just some food for
thought.

brook, creek, stream, rivulet -> stream
bay, cove -> bay
peak, knob, hill, mound, mountain, pinnacle, tops -> peak

I checked some local Australian definitions of these terms below. To be
honest, as a non-geologist I find it hard to work out which tag to use,
unless of course you're just basing it what's used in the name. Calling
them all plateau would be easier, but I wouldn't stop people who know more
about geology from mapping down to more detail.

MESA
A flat table-like upland, which falls away steeply on all
sides (escarpments). It is larger in area than a ‘butte’ but
smaller than a ‘plateau’.

BUTTE
A small residual of a mesa. The level top being the upper
surface of the hard stratum but little lowered by erosion.
The slopes on all sides are escarpments and its maximum
horizontal dimension in any one direction is about 400
metres.

PLATEAU
An elevated tract of comparatively flat or level land,
having a large part of its total surface at or near the
summit level. Its local relief may be very great in cases
where it is cut by gorges, or it may have a small local
relief like a plain in cases where erosion has not been
severe. Its minimum horizontal dimension in any
direction generally exceeds 1.6km.

TABLELAND
An elevated tract of land with a generally level surface of
considerable extent, generally with a minimum area of
2,500 hectares.


On Thu, 18 Apr 2019 at 17:33, Paul Allen  wrote:

> On Thu, 18 Apr 2019 at 07:09, Andrew Harvey 
> wrote:
>
>> This does make it harder for mappers to decide which one they should use,
>> but if in doubt they can just pick one they think is best.
>>
>
> The local convention as to what it is may help them decide.
>
> An alternative is natural=plateau + plateau=butte|mesa or something like
>> that.
>>
>
> The problem with that is that plateau, butte and mesa refer to (depending
> upon which Wikipedia
> article you look at) either different absolute sizes or different
> height/area ratios.  And while
> plateau=butte and plateau=mesa may not offend too many sensibilities,
> plateau=plateau looks
> rather silly.  And you can't use plateau=yes because that might be used
> for "it's flat but I can't
> tell if it's a butte or a mesa."
>
> --
> Paul
>
> ___
> 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] Stop the large feature madness

[Christoph Hormann]

On Thursday 18 April 2019, Warin wrote:
>
> There are also 'points' and 'heads' to name a few other landforms
> missing in OSM.

While i have an understanding of what a mesa and a butte are i have no 
idea how you define a 'point' or 'head' so no comment on that.

> To say that they should not be mapped is to deny there existence.

No, to say some things should not be mapped acknowledges that OSM is 
about recording verifiable local knowledge and not "everything that 
exists" - whatever that means.

> It is not unusual to look for these things .. OSM failure to map them
> leads to other sources being used.

Exactly.  We need to establish that there are things outside the scope 
of OSM for which you need other projects to collect data about them.

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

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

Re: [Tagging] Stop the large feature madness (was: Tag for a plateau or tableland?)

[Christoph Hormann]

On Thursday 18 April 2019, Kevin Kenny wrote:
>
> I doubt very much that you're saying what you intended here.
>
> It comes across as saying, for instance, that lakes too big to map on
> the ground in a single day should not be mapped, or should not be
> named. I think that making large waterbodies disappear would be
> ridiculous.

You apparently misunderstood what i said.  My 'surveyable in a single 
day by a single mapper' rule of thumb refers to mapping something as a 
single feature.  A river several thousand kilometers long for example.  
The river is locally still a verifiable element of the geography and 
can be mapped - piece by piece as it is generally established practice 
in OSM.  But if you create a feature for the whole river extending over 
thousands of kilometers that is not something you do based on local 
knowledge, that is based on social conventions you have read up in a 
book, on wikipedia or elsewhere.

As far as physical geography is concerned (so i leave out boundary and 
route relations here - which are a different thing) we have essentially 
only two types of feature that are generally accepted to be mapped with 
large relations:  lakes and islands.  Both of these were not always 
mapped this way - large lakes were for a long time mapped only 
locally - like the coastline.  Both of these are technically 
unnecessary to be mapped this way (there is no actual information 
transported in assembling the ways into an MP relation) because their 
geometry derives non-ambiguously from the locally mapped water 
outlines.  The decision to create MPs none the less mostly comes from 
the desire to have consistency with smaller features (which are 
obviously locally verifiable as a whole).

Everything else in physical geography is typically mapped locally piece 
by piece like the rivers and creating large features - while done by 
some mappers for the purpose of label painting - is generally disliked 
by most mappers because it is very hard to work with these and 
represents no additional meaningful information.

> Moreover, if you've mapped something on the ground, what difference
> does it make how long it took?

It is a rule of thumb.  The rule itself has no meaning on its own, it is 
designed to make it easy to determine a reasonable limit.

> I understand that there are fairly severe technological issues at
> present, where a plethora of enormous multipolygons breaks some of
> the software tools.

My argument is not a technological one, it is a social one.  Mapping 
only things verifiable based on local knowledge in OSM is essential for 
the social cohesion of the project across many different cultures world 
wide without creating an imperialistic dominance of some cultures over 
others.

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

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

Re: [Tagging] Subtag for place=locality?

[Martin Koppenhoefer]

sent from a phone

> On 17. Apr 2019, at 01:48, Joseph Eisenberg  
> wrote:
> 
> Yes, that’s my recommendation. You just need a tag that is for groups of 
> lakes. 


multipolygon relations have different semantics, they “combine” the parts while 
the group is about an ensemble. With the group relation you do not “just need” 
a tag for groups of lakes, trees, stones, sculptures, summits, and any other 
group of things.


> 
> Archipelagos are mapped as multipolygon relations tagged with 
> place=archipelago, name= and type=multipolygon. This makes it easy to search 
> for, does not duplicate the place=island tags on each island, and can be 
> rendered with existing tools.


and doesn’t work for islands mapped as nodes. I agree that place=archipelago 
has a well defined meaning and helps to better understand what the object is 
about, especially those represented with a multipolygon relation, where it 
isn’t clear from the members what kind of thing the whole is.



> 
> A named group of lakes is similar to a water equivalent of an archipelago 
> (especially if they are not connected by rivers)


all groups of things are similar in this regard. The most meaningful property 
(the reason people would usually want to create an explicit relation between 
the parts, on top of the already existing implicit relation through proximity), 
is a common name that wo/mankind has given to it. 

For rendering support (or search / geocoding support), the group relation would 
probably depend on osm2pgsql supporting it. Derivative auxiliary geometry (and 
ontology, possibly size information) would be created in the osm2pgsql step, so 
the rendering team would not have to walk down the list of members to guess the 
domain of the thing, where it is or how big it is.

For humans looking at the data, a group of trees, lakes, dunes, tombs or 
sculptures will be easily understandable, computers may have a harder time but 
would usually not need to „understand“ it, for most applications a rough idea 
of the domain (e.g. key level meaning like “historic”, “natural”) and extent is 
all they actually need to know.

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

Re: [Tagging] Tag for a plateau or tableland?

[Paul Allen]

On Thu, 18 Apr 2019 at 07:09, Andrew Harvey 
wrote:

> This does make it harder for mappers to decide which one they should use,
> but if in doubt they can just pick one they think is best.
>

The local convention as to what it is may help them decide.

An alternative is natural=plateau + plateau=butte|mesa or something like
> that.
>

The problem with that is that plateau, butte and mesa refer to (depending
upon which Wikipedia
article you look at) either different absolute sizes or different
height/area ratios.  And while
plateau=butte and plateau=mesa may not offend too many sensibilities,
plateau=plateau looks
rather silly.  And you can't use plateau=yes because that might be used for
"it's flat but I can't
tell if it's a butte or a mesa."

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

Re: [Tagging] Stop the large feature madness

[Mateusz Konieczny]

Apr 18, 2019, 12:12 AM by graemefi...@gmail.com:

>
>
> On Thu, 18 Apr 2019 at 03:35, Michael Patrick <> geodes...@gmail.com 
> > > wrote:
>
>> our map would look like this :-)   >> http://bit.ly/2IGkgoj 
>> 
>>
>
> That's an amazing image, thanks Michael.
>
> I take it that's the home location of all OSM contributors?
>
missing legend is missing, but for me it looks like world map limited to areas 
with
population density (of all humans, not just OSM mappers) above some threshold.

Maybe flooded areas are officially uninhabited.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tag for a plateau or tableland?

[Andrew Harvey]

This does make it harder for mappers to decide which one they should use,
but if in doubt they can just pick one they think is best.

An alternative is natural=plateau + plateau=butte|mesa or something like
that.

> Thus mesas and buttes could be mapped as nodes or areas, but plateaus
could only be mapped as nodes.

I still think plateaus should be mapped as areas (only use nodes as a first
pass), areas are important for reverse geocoding, identifying size of the
feature and cartographic labelling.

On Thu, 18 Apr 2019 at 15:55, Joseph Eisenberg 
wrote:

> I originally thought that just using the existing tag natural=plateau
> was easiest, but a couple people have been in favor of using 2 new
> tags.
>
> 1) natural=butte for hills with small flat tops surrounded by cliffs,
> where the width of the flat area is less than the height of the hill.
> Wikipedia: " an isolated hill with steep, often vertical sides and a
> small, relatively flat top" (https://en.wikipedia.org/wiki/Butte)
> These buttes in Monument Valley are a very famous example:
> https://en.wikipedia.org/wiki/File:Monument_Valley,_late_afternoon.jpg
> Courthouse butte in Sedona:
> https://en.wikipedia.org/wiki/File:Butte_pdphoto_roadtrip_24_bg_021604.jpg
>
> 2) natural=mesa for mountains and hills with flat tops surrounded by
> cliffs, where the width of the flat tableland is greater than the
> height.
> See https://en.wikipedia.org/wiki/Mesa "an elevated area of land with
> a flat top and sides that are usually steep cliffs"
> Eg these mesas in Canyonlands National Park, Utah:
> https://en.wikipedia.org/wiki/File:IslandInTheSky.JPG
> Lower Table Rock:
> https://en.wikipedia.org/wiki/File:Lower_Table_Rock_from_the_south.jpg
>
> These definitions are found in https://en.wikipedia.org/wiki/Butte -
> "geographers use the rule of thumb that a mesa has a top that is wider
> than its height, while a butte has a top that is narrower than its
> height" (citing
>
> http://www.scienceclarified.com/landforms/Faults-to-Mountains/Mesa-and-Butte.html
> as a source)
>
> This would leave natural=plateau for any other "area of a highland,
> usually consisting of relatively flat terrain, that is raised
> significantly above the surrounding area, often with one or more sides
> with steep slopes", including large highlands that are less well
> defined, and small plateaus that lack the cliffs or steep slopes on
> all sides that define a mesa or butte.
>
> Thus mesas and buttes could be mapped as nodes or areas, but plateaus
> could only be mapped as nodes.
>
> Thoughts?
>
>
> On 4/18/19, Paul Allen  wrote:
> > On Wed, 17 Apr 2019 at 19:11, Mark Wagner  wrote:
> >
> >>
> >> I don't think there's an English English term for them -- England
> >> barely has any topographical relief at all.  They even had to import
> >> "mountain" from the French.
> >
> >
> > The UK does have some topographical relief but not any plateaus that I
> can
> > think of.  However,
> > we Brits are familiar with the word - we stole various parts of the world
> > from indigenous
> > inhabitants which had that sort of topography.
> >
> > Unless there's something I'm missing, we're going to need to pick an
> >> English import
> >> from one of the countries that does have plateaus, mesas, or buttes.
> >>
> >
> > We may have to use all of those words.  From looking at the three
> relevant
> > articles on
> > Wikipedia, it appears that mesas are larger than buttes and plateaus are
> > larger than mesas.
> > Tableland is a synonym of plateau.  I'd say natural=plateau/mesa/butte.
> > But I expect there will
> > be many people who disagree with that - there are as many opinions on
> this
> > list as there
> > are subscribers.
> >
> > --
> > Paul
> >
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging