Re: [Tagging] Feature Proposal - RFC - Place areas

[Martin Koppenhoefer]

While I believe that this is in general a good idea, I don't agree with
tagging those place objects with admin_level tags. It would lead to more
confusion and I don't see why we would need it, or what it would solve
(rather the opposite: it would contradict the place concept of a place
being something orthogonal to administrative structures).

Clearly (and I think you wanted to say this but have just omitted it by
accident), place=* should be added to these place entities (to indicate the
kind of place, like city, suburb, etc.).

I don't think (boundary) relations are strictly needed (the only advantage
is explicit coupling of the node with the area, which otherwise would have
to be done by name comparison and spatial analysis), but if it makes
mapping those easier I won't oppose. Naturally multipolygon relations can
make sense if the area is big / has complex boundaries.

I very much agree on separating landuses from places / quarters / etc.

Btw.: never quite understood why we (still) have place values like
"county", "municipality", "state", "borough", "district", "subdivision",
"country", "province" and some others, which clearly refer to
administration. As you're already tackling places, IMHO you could try to
deprecate these in the same go.

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

Re: [Tagging] dispersed settlements / scattered settlements

[Martin Koppenhoefer]

2017-06-18 17:44 GMT+02:00 Joachim :

> Currently we categorize settlements by number of inhabitants, modified
> by importance. I would rather not open another dimension. The type of
> of a settlement can be deduced by processing the landuse inside. If
> there is use in a binary (yes/no) property it should be added to the
> place=* feature: e.g. dispersed_settlement=yes. But this looks more
> like job for Wikidata.
>


we base our settlement classification not only on population, the
population numbers serve as an indicator what size we expect from certain
classes in certain areas, but they are not hard limits. Other factors we
consider: part of a settlement or whole settlement, functional/cultural
parameters (a place which is officially a "town" in Italy will be a town in
OSM, a place which isn't a "town" will not become more than a "village")
and maybe more.


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

Re: [Tagging] Feature Proposal - RFC - Place areas

[Christoph Hormann]

On Sunday 18 June 2017, Joachim wrote:
>
> Detailed proposal with summary tables:
> https://wiki.openstreetmap.org/wiki/Proposed_features/place_areas

I have to say i don't quite understand what you are actually proposing 
with the different scenarios described.

Also i have some trouble understanding your proposal in general, 
could you explain what "the extend of a settlement" is, how i can map 
this on the ground?

Your introductory remark:

> It is also a well understood principle of OSM that mapping spatial
> features as node is a precursor to the more detailed mapping as area.

by the way is wrong.  Nodes and areas are two abstract concepts within 
OSM used to represent elements of reality.  While there are features 
that would normally be represented as areas that are occasionally as a 
simplified representation mapped as nodes (like a lake) there are also 
many things that are represented as nodes that should never be 
attempted to be mapped as areas - either by convention (like 
place=ocean) or due to their nature (like natural=peak).

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

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

Re: [Tagging] Feature Proposal - RFC - Place areas

[Martin Koppenhoefer]

2017-06-19 12:44 GMT+02:00 Christoph Hormann :

> by the way is wrong.  Nodes and areas are two abstract concepts within
> OSM used to represent elements of reality.  While there are features
> that would normally be represented as areas that are occasionally as a
> simplified representation mapped as nodes (like a lake) there are also
> many things that are represented as nodes that should never be
> attempted to be mapped as areas - either by convention (like
> place=ocean) or due to their nature (like natural=peak).
>


yes, features that are a spot in reality (like a peak) should be
represented as a node.

But already when it comes to very small areas, like an amenity=post_box or
atm for example, mapping them as a node has some disadvantages (e.g. if the
post box is attached to a building wall, you don't know whether the post
box is inside or outside when the building is just an area (as opposed to
walls etc. mapped in detail) and the post box is only a node). So clearly
there is a tradeoff to be made, and we have to weigh in pros and cons to
see what we recommend (and what mappers find practicable). In the case of a
post box, a telephone booth, a drinking water fountain or an atm I guess
there will not be much opposition to map these as nodes. When it comes to
gates, benches and others, the situation might already change (often easier
to map a gate as a linear way rather than estimating the width and add it
as an attribute, especially if you want to add information about the
orientation, like for the benches)

For mapping an ocean or continent as a node there really aren't any good
arguments besides technical limitations and the way we have structured our
data (e.g. if the ocean boundary consisted of several segments (linear
relations themselves) rather than a single multipolygon relation with ways
as members, we could reduce the probability of editing conflicts to an
amount that it would become possible to map them, similar to how we do with
very long routes).

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

Re: [Tagging] Feature Proposal - RFC - Place areas

[Frederik Ramm]

Hi,

On 06/18/2017 06:59 PM, Joachim wrote:
> * The extend of a settlement is not explicitly defined
> (https://en.wikipedia.org/wiki/Settlement_geography). This might lead
> to disputes

Then we shouldn't map it.

> For the first two points I present a solution. For the third I thrust
> national/local mappers to converge.

I think that this is a bad idea. We have enough fighting over a matter
that should be as clear-cut as administrative boundaries. Adding another
layer to that will only create more fighting over whether something "is
part of" something else. For example, an old village that has long since
been assimilated by the big city and retains its name as a city quarter
might suddenly declare not being part of the "city place area", which
will only confuse the hell out of everybody. And I'm not even starting
to talk about the usual fights between nationalists/patriots of all
kinds over what should be called how.

If you can't point to a sign on the ground, don't map topoynms.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [Tagging] Feature Proposal - RFC - Place areas

[Martin Koppenhoefer]

sent from a phone

> On 19. Jun 2017, at 15:15, Frederik Ramm  wrote:
> 
> If you can't point to a sign on the ground, don't map topoynms.


-1, our criterion for mapping something is that it can be verified, signs are 
only a part of it. 

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

Re: [Tagging] Feature Proposal - RFC - Place areas

[Javier Sánchez Portero]

2017-06-19 14:15 GMT+01:00 Frederik Ramm :

> If you can't point to a sign on the ground, don't map topoynms.
>

-1. May be in some urban areas it's usual to find signs for toponyms, but
more frequently -mainly in rural and wild areas- the toponyms are in the
knowledge of the local people, not in signs. Especially for that reason
they must be collected in the maps.

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

Re: [Tagging] Feature Proposal - RFC - Place areas

[Frederik Ramm]

Hi,

On 06/19/2017 05:31 PM, Martin Koppenhoefer wrote:
>> If you can't point to a sign on the ground, don't map topoynms.
> 
> -1, our criterion for mapping something is that it can be verified, signs are 
> only a part of it. 

*Ideally* verified on the ground, but yes, other means of verifiability
can be acceptable. However, the OP in this case explicitly said that
"The extent of a settlement is not explicitly defined" which certainly
thwarts *any* kind of verification, doesn't it?

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [Tagging] Feature Proposal - RFC - Place areas

[Christoph Hormann]

On Monday 19 June 2017, Frederik Ramm wrote:
>
> *Ideally* verified on the ground, but yes, other means of
> verifiability can be acceptable. However, the OP in this case
> explicitly said that "The extent of a settlement is not explicitly
> defined" which certainly thwarts *any* kind of verification, doesn't
> it?

Not necessarily, this is why i asked for the practical meaning of "the 
extend of a settlement".

As i read it "not explicitly defined" just means it is not directly 
observable on the ground but that does not necessarily mean it is not 
practically verifiable.  To give an abstract example - you could for 
example implicitly define a city area as the sum of all points on the 
surface that are closer to this city centre than to any other city 
centre.  This would not make much sense and it would make even less 
sense to map this as an area but this is theoretically a well defined 
concept of a city area that is not explicitly defined.

Regarding names of geographic features - these are rarely verifiable on 
the ground, especially for natural objects, verifiability here often is 
equivalent to "you get consistent answers if you ask locals about the 
name of this feature".

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

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

Re: [Tagging] dispersed settlements / scattered settlements

[Warin]

On 19-Jun-17 08:30 PM, Martin Koppenhoefer wrote:


2017-06-18 17:44 GMT+02:00 Joachim >:


Currently we categorize settlements by number of inhabitants, modified
by importance. I would rather not open another dimension. The type of
of a settlement can be deduced by processing the landuse inside. If
there is use in a binary (yes/no) property it should be added to the
place=* feature: e.g. dispersed_settlement=yes. But this looks more
like job for Wikidata.



we base our settlement classification not only on population, the 
population numbers serve as an indicator what size we expect from 
certain classes in certain areas, but they are not hard limits. Other 
factors we consider: part of a settlement or whole settlement, 
functional/cultural parameters (a place which is officially a "town" 
in Italy will be a town in OSM, a place which isn't a "town" will not 
become more than a "village") and maybe more.


The functional aspect counts to a fair degree in Australia. As the over 
all population density is low a small remote settlement will usually 
have more facilities that a European would expect from the settlements 
population size.
Settlements can serve a vast area with high demand for these facilities. 
If a settlement failed to provide these facilities travelling times to 
obtain these services would be large (days there and back).



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

Re: [Tagging] Feature Proposal - RFC - Place areas

[Martin Koppenhoefer]

sent from a phone

> On 19. Jun 2017, at 23:21, Christoph Hormann  wrote:
> 
> Regarding names of geographic features - these are rarely verifiable on 
> the ground, especially for natural objects, verifiability here often is 
> equivalent to "you get consistent answers if you ask locals about the 
> name of this feature".


+1, which is kind of "on the ground ". You ask people on the ground (nearby) 
and they answer consistently.

Toponyms are an area where a crowdsourced map can make a significant 
contribution to the documentation of this local knowledge, where the collection 
is time consuming and requires a lot of field work.

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

[Tagging] Pool decks?

[John Willis]

When mapping pool complexes and water parks, often times there is a significant 
area around the pool, often referred to as the pool deck in the US (I don't 
know about elsewhere). This is often concrete, and can be almost as much area 
as the pool itself. 

For a water park, often times there is also significant areas of concrete or a 
paving material similar to tartan (used on running tracks) for people playing 
on the different attractions. 

Sometimes, at malls and other places in hot climates, there is a similar place 
to a water park attraction where water squirts out of the ground and gets you 
(mostly small kids) wet, like a fountain hidden in the ground - but it is a 
pedestrian walkway, and anyone can walk through, and no standing water is 
present. 

I assume, minimally,

Highway=pedestrian
Area=yes

on such areas is acceptable minimal tagging, but if I wanted to add an 
additional tag, similar to the footway=* tag, to it to say "this is the 
pedestrian area around/for a water feature, meant for people enjoying the 
water" 
Pedestrian=pool_deck
Pedestrian=water
Etc

I initially thought of access=*, but that would clash with the overall access 
of the area (customers for a mall, private for a swim club, etc).  

I also think tagging it as a pitch is a bad idea. 

As a person who used to spend hours a day on a pool deck, it is a special kind 
of pedestrian-only access area, and I would like a way to differentiate it from 
a plaza. 

Any ideas? 

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

Re: [Tagging] Pool decks?

[Warin]

On 20-Jun-17 02:01 PM, John Willis wrote:

When mapping pool complexes and water parks, often times there is a significant 
area around the pool, often referred to as the pool deck in the US (I don't 
know about elsewhere). This is often concrete, and can be almost as much area 
as the pool itself.

For a water park, often times there is also significant areas of concrete or a 
paving material similar to tartan (used on running tracks) for people playing 
on the different attractions.


What makes a deck a pool deck? The proximity of the pool. Some decks are at the 
seaside, others beside a river, lake.
The areas are not so much for walking, as for sitting.
So I would think not pedestrian, but more leisure? leisure=deck ?

However people have been using pedestrian for some time e.g.
http://www.openstreetmap.org/relation/3076138#map=19/58.32068/15.12290



Sometimes, at malls and other places in hot climates, there is a similar place 
to a water park attraction where water squirts out of the ground and gets you 
(mostly small kids) wet, like a fountain hidden in the ground - but it is a 
pedestrian walkway, and anyone can walk through, and no standing water is 
present.


A form of fountain with foot access... possibly a combination of fountain and 
pedestrian/foot?



I also think tagging it as a pitch is a bad idea.


A pitch is for playing sport, not relaxation.


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

Re: [Tagging] Pool decks?

[John Willis]

> On Jun 20, 2017, at 2:10 PM, Warin <61sundow...@gmail.com> wrote:
> 
> What makes a deck a pool deck?

The proximity to an artificial pool for leisure, and often their inclusion with 
the pool inside in the barrier=* around the pool. 

So The pool deck is the flat area inside the fence around the pool, the walkway 
around the outside of the fence is not. 

It is usually not for sunbathing or lounging - but I guess the usage for a 
poolside area at a hotel and a fenced off pool deck at a school are mapped in 
very similar ways, so I would put them into the same category:

** 
a hard-surfaced pedestrian-only area adjacent to a leisure item featuring water 
(i.e.:not a dock or platform next to a lake) for the use of people who are 
using/observing the leisure item. It is often separated by a barrier=* in some 
manner, but not required. ** 

In a water park, it is the areas adjacent or surrounding attractions, used by 
people enjoying/observing those attractions, but not the walkways connecting 
them. These usually are a different surface=* than the walkways. 

Javbw. 


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

Re: [Tagging] Pool decks?

[John Willis]

> On Jun 20, 2017, at 2:10 PM, Warin <61sundow...@gmail.com> wrote:
> 
> A pitch is for playing sport, not relaxation

My experience with pools is mainly in a sports setting - lap swimming and water 
polo in High School. Most schools in Japan have shallow lap pools for the 
students to swim in for PE class (sports) - there are _very_ few 
mappable/outdoor pools not for sports in Japan - usually in city-operated water 
parks. This is very different from California, where there are probably 10x 
more private leisure pools at houses than sports ones for public use. 

This came up because the area I am mapping currently has a city-operated water 
park and many schools with their separate lap pools in one very small area, so 
I was thinking about how to map these pedestrian areas. 

I brought up "pitches" because the pool is where the actual activity is, but 
the pool-deck is often the staging grounds for the athletes - like footballers 
sitting on the sidelines of a pitch waiting to play. Often times, that is part 
of the "pitch" when mapped - but it is different in this scenario, as pools 
have been separated from pitches.

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