Re: [Tagging] Feature Proposal - RFC - changing table

2019-05-20 Thread Warin
It is a 'property' tag .. like height etc and can only be used with some 
other feature so the definition should not be about the physical 
presence of a table.


I'd go with a definition that says something along the lines of 
"indicates the provision for changing a nappy/diaper usually on a table."


On 20/05/19 15:05, Valor Naram wrote:
What do you mean with "feature"? Do you mean the whole proposal? Do 
you mean the "feature" subtag ( changing_table:features )?



 Original Message 
Subject: Re: [Tagging] Feature Proposal - RFC - changing table
From: Martin Koppenhoefer
To: "Tag discussion, strategy and related tools"
CC:




sent from a phone

> On 19. May 2019, at 20:31, Valor Naram wrote:
>
> I have rewritten my proposal to hopefully please the critic.
Please check it out:
https://wiki.openstreetmap.org/wiki/Proposed_featu res/changing_table
>
> Author: Valor Naram
> Definition: A tag to mark the possibility to change the baby's
nappy. It makes tagging of changing tables possible. See
https://en.oxforddict ionaries.com/definition/changing_table for
the definition.


IMHO you should provide a definition for the feature in the
proposal and be explicit if this is for a “possibility to change
the baby’s nappy” or more specifically a “changing table”.


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


Re: [Tagging] Feature Proposal - RFC - changing table

2019-05-20 Thread Martin Koppenhoefer
Am Mo., 20. Mai 2019 um 07:07 Uhr schrieb Valor Naram :

> What do you mean with "feature"? Do you mean the whole proposal? Do you
> mean the "feature" subtag ( changing_table:features )?



 "feature" is referring to whatever thing you are intending the tag for, or
"property" if it is intended as a property for some other "feature".
I see you have now added "A tag for tagging changing tables." ,which is
fine, I found the former, generic description "A tag to mark the
possibility to change the baby's nappy." confusing, and would suggest to
remove it (because "a possibility to ..." is much broader in meaning than
just a changing table).

>From what I understand, the tag seems to be intended as a property only
(requires a "feature" to add to), right?

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


Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

2019-05-20 Thread Martin Koppenhoefer
Am Mo., 20. Mai 2019 um 07:53 Uhr schrieb Nick Bolten :

> Hello everyone, this is a late addition to this thread (I'll start a new
> one soon after I improve the proposal page), but I want to give an example
> of a crossing that has lights but no markings that is traversed by
> (guessing) thousands of people per day:
> https://www.bing.com/maps?osid=0fa511ff-b1e5-4011-b16c-d96c0c4ce8a5&cp=47.611664~-122.336542&lvl=19&dir=251.4678&pi=-22.174986&style=x&mo=z.0&v=2&sV=2&form=S00027.
> Despite having a lot of interesting art, there is no way to distinguish the
> crossing location from non-crossing locations via markings on the ground.
>
> This is topical, as crossing=traffic_signals is often claimed to imply
> crossing=marked.
>


It is very common to see markings at traffic signal controlled crossings,
but I would not see them as a requirement, and I do not think it is written
anywhere that it should be. From my understanding, it seemed not
interesting for most mappers to distinguish traffic light controlled
markings from unmarked ones, and you will likely have a hard time to
convince them (as this thread shows) to retag all crossings just because
there may be exceptions or situations where it may be relevant.

In your example it could even be interpreted as if there were some kind of
"markings" (different paving, designated pedestrian waiting area), but
moving forward, the next crossing does not, so we can safely assume it is a
situation that actually occurs.

I would suggest to tag the exception, i.e. the absence of crossing markings
where there is a pedestrian traffic light controlled crossing, with an
additional property for the crossing node.

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


Re: [Tagging] Feature Proposal - RFC - changing table

2019-05-20 Thread Valor Naram
> From what I understand, the tag seems to be intended as a property only (requires a "feature" to add to), right?It intends to deprecate the diaper key which is currently used for tagging changing tables. I will deprecate the key for some reasons:- Key `diaper` is poor documented- Key `diaper` didn't go through the proposal process- Key `diaper` does not support shematic tagging- Key `diaper` leads to confusion of what it intends to tag- Key `diaper` does not allow us to tag changing tables inside a restroom for wheelchair users- Its subkey `diaper:wheelchair` is used but not documented yet and its meaning remains unclear. Original Message Subject: Re: [Tagging] Feature Proposal - RFC - changing tableFrom: Martin Koppenhoefer To: "Tag discussion, strategy and related tools" CC: Am Mo., 20. Mai 2019 um 07:07 Uhr schrieb Valor Naram :What do you mean with "feature"? Do you mean the whole proposal? Do you mean the "feature" subtag ( changing_table:features )? "feature" is referring to whatever thing you are intending the tag for, or "property" if it is intended as a property for some other "feature".I see you have now added "A tag for tagging changing tables." ,which is fine, I found the former, generic description "A tag to mark the possibility to change the baby's nappy." confusing, and would suggest to remove it (because "a possibility to ..." is much broader in meaning than just a changing table).From what I understand, the tag seems to be intended as a property only (requires a "feature" to add to), right?Cheers,Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - Voting - camp_site=camp_pitch

2019-05-20 Thread Joseph Eisenberg
It appears that the proposal for camp_site=camp_pitch will be rejected
with 12 votes in opposition out of 26 votes total, for

A couple of those who voted in opposition would prefer to use
"tourism=camp_pitch" instead. There were also a couple of people who
suggested "tourism=camp_site:part" and a couple in favor of
"camp_site:part=camp_pitch". Several other people voted in opposition
but did not specify a preferred alternative.

So what's that best tag to try instead?

I think "camp_site:part=*" is rather convoluted, and
"tourism=camp_pitch" has the benefit of using a well-known key, but
perhaps there are other suggestions?

On 5/8/19, Joseph Eisenberg  wrote:
> Reminder: voting is underway to approve the tag  camp_site=camp_pitch
> since May 1st so it  will continue for the next week till May 14th
> https://wiki.openstreetmap.org/wiki/Proposed_features/camp_site_pitch
>
> Please check out the proposal page and add your comments or votes:
> https://wiki.openstreetmap.org/wiki/Proposed_features/camp_site_pitch#Voting
>
> On 5/1/19, Joseph Eisenberg  wrote:
>> I believe the discussion about the tag camp_site=camp_pitch is now
>> complete here. Also see the talk page:
>> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/camp_site_pitch
>>
>> You can now vote to approve or reject this tag. See:
>> https://wiki.openstreetmap.org/wiki/Proposed_features/camp_site_pitch
>>
>> Description of camp_site=camp_pitch:
>> "An tent or caravan pitch location within a camp site"
>>
>> This proposal provides a way to tag individual pitches within a
>> campground or caravan site. A "camp pitch" in this context is the free
>> space used to place a tent or or caravan within a tourism=camp_site or
>> tourism=caravan_site area. Usually only one caravan is permitted in an
>> individual pitch, but more than 1 tent may be allowed on a single
>> pitch in some cases."
>>
>> Please read the proposal and vote:
>> https://wiki.openstreetmap.org/wiki/Proposed_features/camp_site_pitch#Voting
>>
>

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


Re: [Tagging] Feature Proposal - RFC - changing table

2019-05-20 Thread Martin Koppenhoefer
Am Mo., 20. Mai 2019 um 11:00 Uhr schrieb Valor Naram :

> > From what I understand, the tag seems to be intended as a property only
> (requires a "feature" to add to), right?
>
> It intends to deprecate the diaper key which is currently used for tagging
> changing tables.



To be precise, the page first pretends to be either tagging "changing
tables" or "separated rooms" (I guess it should be "separate rooms"?), but
the way the tag is structured it is the presence of a changing table that
is tagged, not the table itself. Then the diaper key is defined as a
property ("in combination with..."), so if you intend to replace this,
yours would likely become a property (only) as well

"A key for diaper changing tables
 or separated rooms
(sometimes known as a parents room) include a nappy/diaper changing table;
in combination with toilets, shops, restaurants, service areas or something
like that."

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


Re: [Tagging] Feature Proposal - RFC - changing table

2019-05-20 Thread Valor Naram
> [...] so if you intend to replace this, yours would likely become a property (only) as wellOk. Does it matter? From what I understood so far most wiki pages describe `properties` e.g.: Key `highway`CheerioValor Naram alias Sören Original Message Subject: Re: [Tagging] Feature Proposal - RFC - changing tableFrom: Martin Koppenhoefer To: "Tag discussion, strategy and related tools" CC: Am Mo., 20. Mai 2019 um 11:00 Uhr schrieb Valor Naram :> From what I understand, the tag seems to be intended as a property only (requires a "feature" to add to), right?It intends to deprecate the diaper key which is currently used for tagging changing tables. To be precise, the page first pretends to be either tagging "changing tables" or "separated rooms" (I guess it should be "separate rooms"?), but the way the tag is structured it is the presence of a changing table that is tagged, not the table itself. Then the diaper key is defined as a property ("in combination with..."), so if you intend to replace this, yours would likely become a property (only) as well"A key for diaper changing tables
 or separated rooms (sometimes known as a parents room) include a 
nappy/diaper changing table; in combination with toilets, shops, 
restaurants, service areas or something like that."Cheers,Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] "Unambiguous crossings" proposals and related questions

2019-05-20 Thread Andy Townsend

On 20/05/2019 06:20, Nick Bolten wrote:
> if you are having trouble where people are “fixing” your mapping, 
then draw a way with no highway=* tag put crossing=no on it.


Is this an established strategy? I'd be happy to promote it + update 
the wiki if it's communally supported. If it's not necessarily an 
established strategy, I'd also be interested in making a new thread 
about it in the hopes of making it one.


Adding ways where people might think there ought to be ways (but there 
aren't really) is certainly established.  As an example, 
https://www.openstreetmap.org/way/691036735 is one that I did 
yesterday.  Historically I suspect that there was a legal right of way 
across here (and there might still be, although there is nothing 
signed), and there is gap in the barrier that appears to have been 
created to allow crossing, but I wouldn't try it unless you fancy 
playing "human frogger".


Best Regards,

Andy



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


Re: [Tagging] tagging large farm complexes

2019-05-20 Thread Mateusz Konieczny



20 May 2019, 02:05 by tagging@openstreetmap.org:

> to me the individual areas are obviously farmyards, and the other areas are 
> easily mappable - but what about the entire landuse? is it  commercial? 
> farmyard?
>
> I currently tagged as commercial, but I have the suspicion that is wrong - or 
> every farm in Japan would be landuse=commercial, but this is like a weird 
> tourist-farm-zoo kind of place. 
>
landuse=commercial seems to be for trade/service ("tertiary sector").

So while a typical farm would not be landuse=commercial one that is more 
tourism attraction
that a farm may qualify.

Though I am not aware about zoos within landuse=commercial areas.

I would probably not map it as landuse=commercial but also not revert edit that 
added 
landuse=commercial (assuming that it is a de facto zoo).___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] tagging large farm complexes

2019-05-20 Thread Martin Koppenhoefer
Am Mo., 20. Mai 2019 um 12:59 Uhr schrieb Mateusz Konieczny <
matkoni...@tutanota.com>:

>
>
>
> 20 May 2019, 02:05 by tagging@openstreetmap.org:
>
> to me the individual areas are obviously farmyards, and the other areas
> are easily mappable - but what about the entire landuse? is it  commercial?
> farmyard?
>
> I currently tagged as commercial, but I have the suspicion that is wrong -
> or every farm in Japan would be landuse=commercial, but this is like a
> weird tourist-farm-zoo kind of place.
>
> landuse=commercial seems to be for trade/service ("tertiary sector").
>
> So while a typical farm would not be landuse=commercial one that is more
> tourism attraction
> that a farm may qualify.
>


I would not tag a zoo or a farm as "commercial" landuse. landuse=commercial
in OSM is basically about administration, because retail has its own tag.
On the other hand I agree, as there wasn't a definition (beside an example)
for this for a very long time, the meaning of the tag may not be clear in
general, and eventually, retail may be considered a subclass of a
commercial landuse (as well in OSM). It is not completely unseen to have
different levels of specifity on the same level of landuse (e.g.
landuse=farmland / orchard / vineyard /...). Basically, landuse is a mess,
and it tends to get worse with the time (e.g. landuse=religious which may
be orthogonal to residential, commercial, ... ). Different readings are
normal because the tag is not well defined.


> I would probably not map it as landuse=commercial but also not revert edit
> that added
> landuse=commercial (assuming that it is a de facto zoo).
>

+1

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


Re: [Tagging] Feature Proposal - RFC - changing table

2019-05-20 Thread Martin Koppenhoefer
Am Mo., 20. Mai 2019 um 12:36 Uhr schrieb Valor Naram :

> > [...] so if you intend to replace this, yours would likely become a
> property (only) as well
> Ok. Does it matter? From what I understood so far most wiki pages describe
> `properties` e.g.: Key `highway`



the difference of a feature and a property is that a property cannot be
tagged alone, it requires a feature (e.g. "surface", or "oneway", or
"height"). On the other hand, a feature is defining a "thing", e.g. a
highway defined through the tag "highway". It is not a property, but a
feature (and the values are different "classes" of this feature).

OSM does actually not explicitly make this distinction (AFAIK), but it is
implicit in how people are using the tags.

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


[Tagging] Aerodrome classification

2019-05-20 Thread Joseph Eisenberg
How should we classify different types of aerodromes?

We can already distinguish private aerodromes with the access tag
"access=private" and military aerodromes with "military=airfield", and
heliports have their own tag, but currently large international
airports and tiny airstrips are not clearly distinguished.

I believe we can make a reasonable distinction between major classes
of aerodromes:

1) Airstrips without buildings or any other developed features

2) Developed general aviation aerodromes which do not offer any
regularly scheduled public, commercial passenger service

3) Commercial airports which offer regularly scheduled commercial
passenger service

History:

In the very early years of OSM, there were three types of features
where planes could land: aeroway=airport for airports,
aeroway=airfield for undeveloped airstrips, and  aeroway=aerodrome for
general aviation sites, if I understand the history correctly. These
were rendered differently back in 2008, it appears, based on the old
discussion in the talk pages.

However, at some point all of the aeroway=airport and aeroway=airfield
features were edited (I don't know if it was done over a few months or
all at once) to aeroway=aerodrome, which was defined to mean any place
where aviation operations regularly take place, except for military
airports, which are tagged miltary=airfield.

Unfortunately, while this may work for pilots and aviation usage, it's
not very sensible for general mappers. Some mappers have used
aeroway=airstrip for small airfields without buildings or any other
developed features, so that they will not be rendered. Others have
proposed tags to specify the type of aerodrome.

The oldest classification system used "type=*" but this conflicts with
the key used for relations such as type=multipolygon.

Another option was "aerodrome:type=" which has been used a couple of
thousand times, but has not been clearly defined:
https://wiki.openstreetmap.org/wiki/Key:aerodrome:type

The most recent proposal in 2014 suggested using "aerodrome=*" which
seems to fit best with the usual way of tagging the type or main
classification of a feature.
https://wiki.openstreetmap.org/wiki/Proposed_features/Aerodrome

I think this last option should be developed further, but we need to
decide which values of "aerodrome=*" are viable.

Mainly I'm interested in places with or without regular passenger
service, since this is of greatest interest to most map users, but
perhaps there could also be specific tags for cargo-only aerodromes
and other specialized facilities.

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


Re: [Tagging] Feature Proposal - RFC - changing table

2019-05-20 Thread Valor Naram
then it's a property Original Message Subject: Re: [Tagging] Feature Proposal - RFC - changing tableFrom: Martin Koppenhoefer To: "Tag discussion, strategy and related tools" CC: Am Mo., 20. Mai 2019 um 12:36 Uhr schrieb Valor Naram :> [...] so if you intend to replace this, yours would likely become a property (only) as wellOk. Does it matter? From what I understood so far most wiki pages describe `properties` e.g.: Key `highway`the difference of a feature and a property is that a property cannot be tagged alone, it requires a feature (e.g. "surface", or "oneway", or "height"). On the other hand, a feature is defining a "thing", e.g. a highway defined through the tag "highway". It is not a property, but a feature (and the values are different "classes" of this feature).OSM does actually not explicitly make this distinction (AFAIK), but it is implicit in how people are using the tags.Cheers,Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

2019-05-20 Thread Paul Allen
On Mon, 20 May 2019 at 06:53, Nick Bolten  wrote:

>
> This is topical, as crossing=traffic_signals is often claimed to imply
> crossing=marked.
>

It is?  I hadn't noticed.  I take a very different view, that
crossing=traffic_signals says that
the crossing is controlled by traffic signals.  There may or may not be
markings.  Those
markings may or may not be similar to markings at crossings without traffic
signals but,
if the lights are functioning those markings have no legal significance and
do not
determine rights of way.

I, like some others here, think it rather obsessive of you to insist on
mapping what we
consider to be an irrelevancy.  The crossing is CONTROLLED by the lights
and that
is the important factor.  Sure, if you can come up with something that
isn't disruptive and
has other benefits, then it MAY be worth coming up with a tagging scheme
that allows
us to indicate whether a crossing controlled by lights also has markings.

At best, all I've seen indicates that maybe editors should make it clearer
to mappers if
they change a crossing tagged as traffic signals to one with markings that
perhaps they're
using aerial imagery to undo what somebody has verified on the ground.  I
don't deny that
such edits may be a problem, I'm not convinced your proposal is the best
solution.

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


Re: [Tagging] Aerodrome classification

2019-05-20 Thread Colin Smale
Let's separate the tagging from the rendering, like we are supposed to
do. 

Firstly, the tagging: how do we model an aerodrome. 

There are so many ways of classifying aerodromes. From a pilot's
perspective, there are at least the physical aspects (how long/wide is
the runway?), the aviation facilities (instrument approaches etc) and
the ground facilities (refuelling, repairs, customs, ...). Then there
are dimensions like movements per year, military/commercial/GA, etc. 

http://www.airfieldcharts.com/airportcategorisation.htm

Each one of these dimensions can (should!) be represented independently
in OSM. They are objective and verifiable. 

But now, the question is what combinations of these attributes should be
rendered in a specific way? Pleasing to whose eyes? 

C. 

On 2019-05-20 14:10, Joseph Eisenberg wrote:

> How should we classify different types of aerodromes?
> 
> We can already distinguish private aerodromes with the access tag
> "access=private" and military aerodromes with "military=airfield", and
> heliports have their own tag, but currently large international
> airports and tiny airstrips are not clearly distinguished.
> 
> I believe we can make a reasonable distinction between major classes
> of aerodromes:
> 
> 1) Airstrips without buildings or any other developed features
> 
> 2) Developed general aviation aerodromes which do not offer any
> regularly scheduled public, commercial passenger service
> 
> 3) Commercial airports which offer regularly scheduled commercial
> passenger service
> 
> History:
> 
> In the very early years of OSM, there were three types of features
> where planes could land: aeroway=airport for airports,
> aeroway=airfield for undeveloped airstrips, and  aeroway=aerodrome for
> general aviation sites, if I understand the history correctly. These
> were rendered differently back in 2008, it appears, based on the old
> discussion in the talk pages.
> 
> However, at some point all of the aeroway=airport and aeroway=airfield
> features were edited (I don't know if it was done over a few months or
> all at once) to aeroway=aerodrome, which was defined to mean any place
> where aviation operations regularly take place, except for military
> airports, which are tagged miltary=airfield.
> 
> Unfortunately, while this may work for pilots and aviation usage, it's
> not very sensible for general mappers. Some mappers have used
> aeroway=airstrip for small airfields without buildings or any other
> developed features, so that they will not be rendered. Others have
> proposed tags to specify the type of aerodrome.
> 
> The oldest classification system used "type=*" but this conflicts with
> the key used for relations such as type=multipolygon.
> 
> Another option was "aerodrome:type=" which has been used a couple of
> thousand times, but has not been clearly defined:
> https://wiki.openstreetmap.org/wiki/Key:aerodrome:type
> 
> The most recent proposal in 2014 suggested using "aerodrome=*" which
> seems to fit best with the usual way of tagging the type or main
> classification of a feature.
> https://wiki.openstreetmap.org/wiki/Proposed_features/Aerodrome
> 
> I think this last option should be developed further, but we need to
> decide which values of "aerodrome=*" are viable.
> 
> Mainly I'm interested in places with or without regular passenger
> service, since this is of greatest interest to most map users, but
> perhaps there could also be specific tags for cargo-only aerodromes
> and other specialized facilities.
> 
> ___
> 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] Aerodrome classification

2019-05-20 Thread Martin Koppenhoefer
Am Mo., 20. Mai 2019 um 14:12 Uhr schrieb Joseph Eisenberg <
joseph.eisenb...@gmail.com>:

> How should we classify different types of aerodromes?
>
> We can already distinguish private aerodromes with the access tag
> "access=private" and military aerodromes with "military=airfield", and
> heliports have their own tag, but currently large international
> airports and tiny airstrips are not clearly distinguished.
>
> I believe we can make a reasonable distinction between major classes
> of aerodromes:
>
> 1) Airstrips without buildings or any other developed features
>
> 2) Developed general aviation aerodromes which do not offer any
> regularly scheduled public, commercial passenger service
>
> 3) Commercial airports which offer regularly scheduled commercial
> passenger service
>


other proposed classification systems have referred to number, size and
surface of runways.



>
> History:
>
> In the very early years of OSM, there were three types of features
> where planes could land: aeroway=airport for airports,
> aeroway=airfield for undeveloped airstrips, and  aeroway=aerodrome for
> general aviation sites, if I understand the history correctly. These
> were rendered differently back in 2008, it appears, based on the old
> discussion in the talk pages.
>


IIRR, airfield and airport were never promoted in the wiki, although there
have been rendering rules, this wasn't established tagging by the time, and
was more occassional than frequent use. There have been other rules as well
(e.g. place=metropolis), which have never had any usage at all (unlike
aeroway=airport, which had almost 450 uses by the beginning of 2008 and was
then mass retagged).


...Some mappers have used

> aeroway=airstrip for small airfields without buildings or any other
> developed features, so that they will not be rendered. Others have
> proposed tags to specify the type of aerodrome.
>


indeed aeroway=airstrip is "quite common" (4474 uses now, compared to 41000
aerodromes and 5 runways)

Current tags for"subtagging" are

3 110 aerodrome:type

with these values:
public 1 291
private 337
regional 309
military 293
military/public 262
airfield 237
international 201
gliding 66
civil 54
airstrip 20


1 379 aerodrome

with these values:
international 386
airstrip 193
public 167
private 137
regional 131
airsport 77
airfield 73
mountain␣airfield 43
gliding 41
military 31
domestic 24





The most recent proposal in 2014 suggested using "aerodrome=*" which
seems to fit best with the usual way of tagging the type or main
classification of a feature.
https://wiki.openstreetmap.org/wiki/Proposed_features/Aerodrome

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


Re: [Tagging] Aerodrome classification

2019-05-20 Thread Joseph Eisenberg
> "number, size and surface of runways."

This information can already be mapped, but it isn't very helpful for
a person search for "closest airports to me" in an application.

There are a number of large aerodromes that do not have public
flights. Military airfields are a common example, but there are also
cargo-only airports, and airports that have been built, but lack
commercial service.

The airport in Everett, Washington just recently started commercial
passenger flights, but before it was used by Boeing to ship out their
new planes for years.

Their is a large airport in Palmdale, California which was built by
the organization that manages LAX, intended to server Los Angeles, but
it has not had any scheduled flights for over 10 years:
https://en.m.wikipedia.org/wiki/Palmdale_Regional_Airport

It seem to me that the presence of public passenger flights is the
basic idea of the word "airport" to the general public (pilots certain
have different ideas, but they have their own specialized databases),
and it would be good if we could tag this in a consistent way.

For use by pilots, and for people considering charter flights, it may
be useful to make a distinction between "general aviation" airports
that have services like hangars, fuel, staff etc, versus an airstrip
in a farmer's field which lacks any services or facilities other than
an unpaved runway.

On 5/20/19, Martin Koppenhoefer  wrote:
> Am Mo., 20. Mai 2019 um 14:12 Uhr schrieb Joseph Eisenberg <
> joseph.eisenb...@gmail.com>:
>
>> How should we classify different types of aerodromes?
>>
>> We can already distinguish private aerodromes with the access tag
>> "access=private" and military aerodromes with "military=airfield", and
>> heliports have their own tag, but currently large international
>> airports and tiny airstrips are not clearly distinguished.
>>
>> I believe we can make a reasonable distinction between major classes
>> of aerodromes:
>>
>> 1) Airstrips without buildings or any other developed features
>>
>> 2) Developed general aviation aerodromes which do not offer any
>> regularly scheduled public, commercial passenger service
>>
>> 3) Commercial airports which offer regularly scheduled commercial
>> passenger service
>>
>
>
> other proposed classification systems have referred to number, size and
> surface of runways.
>
>
>
>>
>> History:
>>
>> In the very early years of OSM, there were three types of features
>> where planes could land: aeroway=airport for airports,
>> aeroway=airfield for undeveloped airstrips, and  aeroway=aerodrome for
>> general aviation sites, if I understand the history correctly. These
>> were rendered differently back in 2008, it appears, based on the old
>> discussion in the talk pages.
>>
>
>
> IIRR, airfield and airport were never promoted in the wiki, although there
> have been rendering rules, this wasn't established tagging by the time, and
> was more occassional than frequent use. There have been other rules as well
> (e.g. place=metropolis), which have never had any usage at all (unlike
> aeroway=airport, which had almost 450 uses by the beginning of 2008 and was
> then mass retagged).
>
>
> ...Some mappers have used
>
>> aeroway=airstrip for small airfields without buildings or any other
>> developed features, so that they will not be rendered. Others have
>> proposed tags to specify the type of aerodrome.
>>
>
>
> indeed aeroway=airstrip is "quite common" (4474 uses now, compared to 41000
> aerodromes and 5 runways)
>
> Current tags for"subtagging" are
>
> 3 110 aerodrome:type
>
> with these values:
> public 1 291
> private 337
> regional 309
> military 293
> military/public 262
> airfield 237
> international 201
> gliding 66
> civil 54
> airstrip 20
>
>
> 1 379 aerodrome
>
> with these values:
> international 386
> airstrip 193
> public 167
> private 137
> regional 131
> airsport 77
> airfield 73
> mountain␣airfield 43
> gliding 41
> military 31
> domestic 24
>
>
>
>
>
> The most recent proposal in 2014 suggested using "aerodrome=*" which
> seems to fit best with the usual way of tagging the type or main
> classification of a feature.
> https://wiki.openstreetmap.org/wiki/Proposed_features/Aerodrome
>
> Cheers,
> Martin
>

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


Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

2019-05-20 Thread Nick Bolten
> It is very common to see markings at traffic signal controlled crossings,
but I would not see them as a requirement, and I do not think it is written
anywhere that it should be.

I agree, and this is one of the criticisms I list for this tag. Every time
I have made this criticism - here or with a wider OSM group - several
people have chimed in to say that they've never seen a crossing with
traffic signals but no markings and thought it was a moot point. There's
one right now responding a bit condescendingly in another thread, in fact.

> From my understanding, it seemed not interesting for most mappers to
distinguish traffic light controlled markings from unmarked ones, and you
will likely have a hard time to convince them (as this thread shows) to
retag all crossings just because there may be exceptions or situations
where it may be relevant.

This is not the sole problem with the tag, so that is not a fair
characterization of this proposal. There is also no part of this proposal
asking anyone to remap their own past work. But I'll push back: as best I
can tell from old mailing list archives and the wiki, these tags did not
emerge from any attempt to map "interesting" things, let alone adequate
ones for pedestrians, but were simply intended to replace the UK-specific
zebra, pelican, toucan, etc tags. You can even see, "uncontrolled" morph
meanings ad hoc. Finally, I get several emails per month from
municipalities and civic tech groups that want to map these exact things,
and I have no legitimate schema to give them. I say this because there are
actually very few tagged crossings, despite the numbers or retagging
seeming impressive at first glance - they will be dwarfed in short order by
any real attempt to map these features.

> In your example it could even be interpreted as if there were some kind
of "markings" (different paving, designated pedestrian waiting area), but
moving forward, the next crossing does not, so we can safely assume it is a
situation that actually occurs.

Hmm, I'm not seeing any markings on the ground (on the street) that
distinguish the crossing location from the street at all.

> I would suggest to tag the exception, i.e. the absence of crossing
markings where there is a pedestrian traffic light controlled crossing,
with an additional property for the crossing node.

I'm not following, could you give an example?

Best,

Nick

On Mon, May 20, 2019, 12:54 AM Martin Koppenhoefer 
wrote:

>
>
> Am Mo., 20. Mai 2019 um 07:53 Uhr schrieb Nick Bolten :
>
>> Hello everyone, this is a late addition to this thread (I'll start a new
>> one soon after I improve the proposal page), but I want to give an example
>> of a crossing that has lights but no markings that is traversed by
>> (guessing) thousands of people per day:
>> https://www.bing.com/maps?osid=0fa511ff-b1e5-4011-b16c-d96c0c4ce8a5&cp=47.611664~-122.336542&lvl=19&dir=251.4678&pi=-22.174986&style=x&mo=z.0&v=2&sV=2&form=S00027.
>> Despite having a lot of interesting art, there is no way to distinguish the
>> crossing location from non-crossing locations via markings on the ground.
>>
>> This is topical, as crossing=traffic_signals is often claimed to imply
>> crossing=marked.
>>
>
>
> It is very common to see markings at traffic signal controlled crossings,
> but I would not see them as a requirement, and I do not think it is written
> anywhere that it should be. From my understanding, it seemed not
> interesting for most mappers to distinguish traffic light controlled
> markings from unmarked ones, and you will likely have a hard time to
> convince them (as this thread shows) to retag all crossings just because
> there may be exceptions or situations where it may be relevant.
>
> In your example it could even be interpreted as if there were some kind of
> "markings" (different paving, designated pedestrian waiting area), but
> moving forward, the next crossing does not, so we can safely assume it is a
> situation that actually occurs.
>
> I would suggest to tag the exception, i.e. the absence of crossing
> markings where there is a pedestrian traffic light controlled crossing,
> with an additional property for the crossing node.
>
> 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 - Voting - camp_site=camp_pitch

2019-05-20 Thread Jan S
Hi,

I find camp_site:part=* somewhat complicated, too. Also, it wouldn't be 
consistent with the use of camp_site=* to describe the type of camping site, 
either.

I'd prefer tourism=camp_pitch. This also has the advantage that this key can be 
used for isolated camping pitches that are not part of a proper camping ground.

Best, Jan

Am 20. Mai 2019 11:39:17 MESZ schrieb Joseph Eisenberg 
:
>It appears that the proposal for camp_site=camp_pitch will be rejected
>with 12 votes in opposition out of 26 votes total, for
>
>A couple of those who voted in opposition would prefer to use
>"tourism=camp_pitch" instead. There were also a couple of people who
>suggested "tourism=camp_site:part" and a couple in favor of
>"camp_site:part=camp_pitch". Several other people voted in opposition
>but did not specify a preferred alternative.
>
>So what's that best tag to try instead?
>
>I think "camp_site:part=*" is rather convoluted, and
>"tourism=camp_pitch" has the benefit of using a well-known key, but
>perhaps there are other suggestions?
>
>On 5/8/19, Joseph Eisenberg  wrote:
>> Reminder: voting is underway to approve the tag  camp_site=camp_pitch
>> since May 1st so it  will continue for the next week till May 14th
>> https://wiki.openstreetmap.org/wiki/Proposed_features/camp_site_pitch
>>
>> Please check out the proposal page and add your comments or votes:
>>
>https://wiki.openstreetmap.org/wiki/Proposed_features/camp_site_pitch#Voting
>>
>> On 5/1/19, Joseph Eisenberg  wrote:
>>> I believe the discussion about the tag camp_site=camp_pitch is now
>>> complete here. Also see the talk page:
>>>
>https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/camp_site_pitch
>>>
>>> You can now vote to approve or reject this tag. See:
>>>
>https://wiki.openstreetmap.org/wiki/Proposed_features/camp_site_pitch
>>>
>>> Description of camp_site=camp_pitch:
>>> "An tent or caravan pitch location within a camp site"
>>>
>>> This proposal provides a way to tag individual pitches within a
>>> campground or caravan site. A "camp pitch" in this context is the
>free
>>> space used to place a tent or or caravan within a tourism=camp_site
>or
>>> tourism=caravan_site area. Usually only one caravan is permitted in
>an
>>> individual pitch, but more than 1 tent may be allowed on a single
>>> pitch in some cases."
>>>
>>> Please read the proposal and vote:
>>>
>https://wiki.openstreetmap.org/wiki/Proposed_features/camp_site_pitch#Voting
>>>
>>
>
>___
>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 (etc) for crossing:signals

2019-05-20 Thread Nick Bolten
> It is?  I hadn't noticed.

Yes.

> I take a very different view, that crossing=traffic_signals says that the
crossing is controlled by traffic signals.  There may or may not be
markings.  Those markings may or may not be similar to markings at
crossings without traffic signals but, if the lights are functioning those
markings have no legal significance and do not determine rights of way.

This is still not true. Cars cannot occupy that space, per law, in my area.
I assume this is probably true in yours as well.

I'd be happy if everyone had this interpretation, however, because it would
make my job of arguing about orthogonality very easy.

> I, like some others here, think it rather obsessive of you to insist on
mapping what we consider to be an irrelevancy.

First, we already map this. It's what the tag crossing=uncontrolled means,
per the wiki: a marked crossing, like a crosswalk in the US. You have to
put aside this idea of what "controlled" and "uncontrolled" mean, they are
apparently irrelevant. Perhaps we should change the schema so this kind of
error stops happening...

Anyways, that's a strange way to frame "mapping something I don't care
about". How is it obsessive? I've already listed several important use
cases, so I will be blunt: do you think people with low vision are
irrelevant and don't matter? Is this an ableist community? Do pedestrians
getting struck by cars not matter? Is it okay that they die?

> The crossing is CONTROLLED by the lights and that is the important factor.

This is completely unstated in the tag definitions. It's not actually the
important factor, per the most official-ish sources we have. Clearly
absolutely everyone (including you) is confused about how to use these tags.

> Sure, if you can come up with something that isn't disruptive and has
other benefits, then it MAY be worth coming up with a tagging scheme that
allows
us to indicate whether a crossing controlled by lights also has markings.

I did. It's this proposal. You should check it out, it makes a
multi-pronged argument regarding the problems of this tag and benefits of
changing it. I'm sure the proposal could always be improved, and I'm very
interested in feedback, but continually rehashing inaccurate and myopic
misrepresentations isn't productive.

> At best, all I've seen indicates that maybe editors should make it
clearer to mappers if they change a crossing tagged as traffic signals to
one with markings that perhaps they're
using aerial imagery to undo what somebody has verified on the ground.

There are currently four headings pointing out problems with
crossing=traffic_signals, several follow-up arguments about disambiguating
the whole traffic_signals namespace, definitions of what the new schema
would be, and a simplification of mapping down to two straightforward
questions (extremely easy to support in an editor) vs. the current
confusing trade-off schema.

The example you list is worse than you've stated, though. The *original*
mapping can easily be from aerial imagery and state crossing=uncontrolled.
Because the crossing subtag is now populated, QA tools / Overpass Turbo
will no longer pick it up as unset and needing data. Only a thorough
in-person audit / broken use case will detect the error.

> I don't deny that such edits may be a problem, I'm not convinced your
proposal is the best solution.

I'm open to other strategies. What do you propose?


On Mon, May 20, 2019 at 5:53 AM Paul Allen  wrote:

> On Mon, 20 May 2019 at 06:53, Nick Bolten  wrote:
>
>>
>> This is topical, as crossing=traffic_signals is often claimed to imply
>> crossing=marked.
>>
>
> It is?  I hadn't noticed.  I take a very different view, that
> crossing=traffic_signals says that
> the crossing is controlled by traffic signals.  There may or may not be
> markings.  Those
> markings may or may not be similar to markings at crossings without
> traffic signals but,
> if the lights are functioning those markings have no legal significance
> and do not
> determine rights of way.
>
> I, like some others here, think it rather obsessive of you to insist on
> mapping what we
> consider to be an irrelevancy.  The crossing is CONTROLLED by the lights
> and that
> is the important factor.  Sure, if you can come up with something that
> isn't disruptive and
> has other benefits, then it MAY be worth coming up with a tagging scheme
> that allows
> us to indicate whether a crossing controlled by lights also has markings.
>
> At best, all I've seen indicates that maybe editors should make it clearer
> to mappers if
> they change a crossing tagged as traffic signals to one with markings that
> perhaps they're
> using aerial imagery to undo what somebody has verified on the ground.  I
> don't deny that
> such edits may be a problem, I'm not convinced your proposal is the best
> solution.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listi

Re: [Tagging] Aerodrome classification

2019-05-20 Thread Jan S


Am 20. Mai 2019 16:30:30 MESZ schrieb Joseph Eisenberg 
:
>
>It seem to me that the presence of public passenger flights is the
>basic idea of the word "airport" to the general public (pilots certain
>have different ideas, but they have their own specialized databases),
>and it would be good if we could tag this in a consistent way.
>
>For use by pilots, and for people considering charter flights, it may
>be useful to make a distinction between "general aviation" airports
>that have services like hangars, fuel, staff etc, versus an airstrip
>in a farmer's field which lacks any services or facilities other than
>an unpaved runway.

I assume that OSM will not be used for aviatory navigation purposes out of 
security reasons ( at least I hope the pilots flying me around do so following 
aviation-specific maps...) . Rather, it's aim is to serve people on the ground. 
So we shouldn't primarily look at the requirements of pilots but of ordinary 
users. So I agree with Joseph that the relevant differentiation happens between 
airfields with only general aviation and airports with commercial services. 
This line should be clearly drawn in mapping. Also, this enables renderers to 
only show commercial airports on larger scales and not any airstrip in the same 
way as big international airports.

Facilities at airports that may be relevant to pilots should then be tagged 
apart from the classification of the airport.

Best, Jan

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


Re: [Tagging] Feature Proposal - Voting - camp_site=camp_pitch

2019-05-20 Thread Markus
On Mon, 20 May 2019 at 11:41, Joseph Eisenberg
 wrote:
>
> So what's that best tag to try instead?
>
> I think "camp_site:part=*" is rather convoluted, and
> "tourism=camp_pitch" has the benefit of using a well-known key, but
> perhaps there are other suggestions?

I prefer the camp_site:part=camp_pitch because the :part suffix is
already in use in building:part=* and could become a standard suffix
for parts of other objects, such as named parts of forests or lakes,
numbered grave fields of cemeteries or thematic parts of botanical
gardens or parks (e.g. medicinal herbs, asian plants, succulents).

Regards

Markus

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


Re: [Tagging] Aerodrome classification

2019-05-20 Thread Colin Smale
On 2019-05-20 17:49, Jan S wrote:

> Am 20. Mai 2019 16:30:30 MESZ schrieb Joseph Eisenberg 
> : 
> 
>> It seem to me that the presence of public passenger flights is the
>> basic idea of the word "airport" to the general public (pilots certain
>> have different ideas, but they have their own specialized databases),
>> and it would be good if we could tag this in a consistent way.
>> 
>> For use by pilots, and for people considering charter flights, it may
>> be useful to make a distinction between "general aviation" airports
>> that have services like hangars, fuel, staff etc, versus an airstrip
>> in a farmer's field which lacks any services or facilities other than
>> an unpaved runway.
> 
> I assume that OSM will not be used for aviatory navigation purposes out of 
> security reasons ( at least I hope the pilots flying me around do so 
> following aviation-specific maps...) . Rather, it's aim is to serve people on 
> the ground. So we shouldn't primarily look at the requirements of pilots but 
> of ordinary users. So I agree with Joseph that the relevant differentiation 
> happens between airfields with only general aviation and airports with 
> commercial services. This line should be clearly drawn in mapping. Also, this 
> enables renderers to only show commercial airports on larger scales and not 
> any airstrip in the same way as big international airports.
> 
> Facilities at airports that may be relevant to pilots should then be tagged 
> apart from the classification of the airport.

There are plenty of tiny airports with commercial services, and plenty
of larger facilities without. Is Barra (BRR)[1] going to be more
prominent than a giant military airfield? 

[1]
https://www.tripadvisor.co.za/LocationPhotoDirectLink-g675088-d662156-i273934730-Heathbank-Isle_of_Barra_Outer_Hebrides_The_Hebrides_Scotland.html


The renderer (cartographer) decides what is to be prominent on the map.
The role of OSM tagging is to enable these choices. If it is aiming at
giving the commercial passenger a graphical overview as a use case, then
I might agree with your "filter" but there are other use cases which are
just as valid, such as the visual landmark function for ground or air
navigation in which case the presence of commercial services is not as
relevant as the size of the campus and associated buildings. 

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


Re: [Tagging] Feature Proposal - Voting - camp_site=camp_pitch

2019-05-20 Thread marc marc
Le 20.05.19 à 17:36, Jan S a écrit :
> I find camp_site:part=* somewhat complicated, too. Also, it wouldn't be 
> consistent with the use of camp_site=* to describe the type of camping 
> site, either.

tourism=camp_site + camp_site=basic/standard/serviced/deluxe

and if you cut the site in several parts,
camp_site:part=(camp_)pitch to describe each part

> I'd prefer tourism=camp_pitch. This also has the advantage that this key 
> can be used for isolated camping pitches that are not part of a proper 
> camping ground.

I find that it is precisely a defect. a camp_pitch does not define
a basic camp_site limited to a single pitch (use tourism=camp_site + 
camp_site=basic for this, no need to add a part if the part=the whole 
camp_site).

camp_pitch:part=* describes a part of a camp_site like building:part=* 
doesn't descript a building with one-part only.
so a part always need to be in a camp_site like a building part
need to be inside a building.

but you can have a site with only one pitch and a deluxe service
or have a site with a lot of pitch but basic service,
there is no link between the number and quality
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] "Unambiguous crossings" proposals and related questions

2019-05-20 Thread Graeme Fitzpatrick
On Mon, 20 May 2019 at 20:58, Andy Townsend  wrote:

>
> Adding ways where people might think there ought to be ways (but there
> aren't really) is certainly established.  As an example,
> https://www.openstreetmap.org/way/691036735 is one that I did
> yesterday.  Historically I suspect that there was a legal right of way
> across here (and there might still be, although there is nothing
> signed), and there is gap in the barrier that appears to have been
> created to allow crossing, but I wouldn't try it unless you fancy
> playing "human frogger".
>

Nice one Andy!

Just wondering if that would be better as a description, or both note &
description?

Thanks

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


Re: [Tagging] "Unambiguous crossings" proposals and related questions

2019-05-20 Thread Nick Bolten
That is an interesting case!

Looking at mapillary, it looks like part of it is paved. I'm not sure
whether that makes it a footway or not, but it looks incredibly dangerous
to cross there:
https://www.mapillary.com/app/?lat=53.91808029997222&lng=-1.164232900018&z=17.363583160262273&focus=photo&pKey=Bn5q8Eay8Sar3ELAEaHXFg&x=0.5127641245746908&y=0.55074602568446&zoom=0

This is a case where I feel my own subjectivity comes into play when it
comes to mapping: do I map a potentially unsafe crossing (sometimes the
only one available for miles) and hope that data consumers contextualize it
properly (a multi-part unmarked crossing on a primary highway) or do I
dictate crossing=no / add notes? I don't feel confident in either option,
personally, and actually tend to just not map it and hope for the best.

On Mon, May 20, 2019 at 2:31 PM Graeme Fitzpatrick 
wrote:

>
>
> On Mon, 20 May 2019 at 20:58, Andy Townsend  wrote:
>
>>
>> Adding ways where people might think there ought to be ways (but there
>> aren't really) is certainly established.  As an example,
>> https://www.openstreetmap.org/way/691036735 is one that I did
>> yesterday.  Historically I suspect that there was a legal right of way
>> across here (and there might still be, although there is nothing
>> signed), and there is gap in the barrier that appears to have been
>> created to allow crossing, but I wouldn't try it unless you fancy
>> playing "human frogger".
>>
>
> Nice one Andy!
>
> Just wondering if that would be better as a description, or both note &
> description?
>
> Thanks
>
> Graeme
> ___
> 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] Aerodrome classification

2019-05-20 Thread Graeme Fitzpatrick
On Mon, 20 May 2019 at 22:12, Joseph Eisenberg 
wrote:

>
> I believe we can make a reasonable distinction between major classes
> of aerodromes:
>
> 1) Airstrips without buildings or any other developed features
>
> 2) Developed general aviation aerodromes which do not offer any
> regularly scheduled public, commercial passenger service
>
> 3) Commercial airports which offer regularly scheduled commercial
> passenger service
>

I'd go along with these definitions

*Airstrips* are simple grass or dirt strips with no, or very limited,
facilities, that may be either private, or open to all aircraft.

*Aerodromes* are established facilities, usually with a sealed runway/s &
taxiways & other facilities eg hangars & fuel, but which don't operate
commercial services. These would often be flying clubs eg
https://www.gcsfc.org.au/

*Airports* are anything that operate what is called RPT:

*Regular Public Transport*

Flight operations performed for remuneration and conducted to fixed
schedules over specific routes, and on which seats and/or cargo space is
available to the general public.
It doesn't matter whether it's the above mentioned Barra or Heathrow / LAX
/ Frankfurt - if it operates RPT it's an airport, if it doesn't, it's not.
Also note that cargo is still classified as RPT, so a cargo-only airport,
would still be an airport.

I'm not certain how best to work places such as Newcastle Airport
https://en.wikipedia.org/wiki/Newcastle_Airport_(New_South_Wales) / RAAF
Williamtown https://en.wikipedia.org/wiki/RAAF_Base_Williamtown, which
share a common runway, with the civillian terminal on one side & military
operations on the other - 2 tags, one airway=airport & the other
military=airbase?

Thanks

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


Re: [Tagging] Aerodrome classification

2019-05-20 Thread John Willis via Tagging


> On May 20, 2019, at 9:10 PM, Joseph Eisenberg  
> wrote:
> 
> Some mappers have used
> aeroway=airstrip for small airfields without buildings or any other
> developed features

I have mapped airstrips like this. The tag is important, beyond any decision to 
more granularly map =aerodrome areas. 

Airstrips are usually:

- very short
- an unimproved surface like dirt or grass
- little to no improvement or maintenance beyond what a tractor provides. 
- little-to-no navigation aids
- little-to-no amenities for planes or pilots 
- very limited use by locals or a single purpose company (crop spraying, 
gliders, etc). 


Publically available flight maps for pilots also make these kinds of 
distinctions. Large airports of any kind (general aviation, commercial 
passenger, military) are mapped quite similar, but private dirt airstrips are 
mapped very differently. They merely are marked.

Here is a proper permanent runway - a nice maintained asphalt runway for 
smaller planes, center line paint, apron for parking - but with no tower / 
amenities /navigation aids of any kind: Agua Caliente. It is the smallest 
runway I would map as an  =areodrome I could think of. 

http://vfrmap.com/?type=vfrc&lat=32.956&lon=-116.295&zoom=10

See how it is just a purple mark? These grass airstrips are not even mapped 
that way. To the north, The Desert Wings Sky is mapped with an R. It is a short 
bulldozed flat sandy area in the middle of an old ranch. The surface, 
condition, length, lack of any navigation aids, and *expected usage* (glider 
tugs) all set it apart from even the most meager and rarely used maintained 
runways like Agua Caliente. 

Boreggo Valley (further north) is the local areodrome with a large runway, 
fuel, staff, and navigation aids. Even without a control tower, this is easily 
an areodrome.

In my mapping, there are several grass strips, with no improvements of any kind 
(beyond what a lawnmower could provide), used for tug-plane or winch-launched 
gliders and skydiving planes to operate out of in the middle of a swamp or 
along the river in the flood plain. 

There is no way in hell I would map them as an areoway=areodrome - putting it 
on the map in any way similar to the local general aviation airports or the 
military and civilian heliports is A-number-one bad mapping - like mapping an 
anthill as an apartment complex; they are not the same thing whatsoever. 

Similar to the "R" used in flight maps, using =airstrip to designate these 
low-quality and limited-use airstrips is proper. They should be mapped - but 
differently. 

And similar to other mapping issues in OSM, perhaps a grass strip in some 
countries is worthy of being an aerodrome because it is the only runway 
available, similar to how some bad roads are considered trunk roads in some 
places due to a lack of any other roads -  but in most countries where there is 
a vast spectrum of avation facilities, granular tagging is essential, and 
airstrip plays a role in that. 

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


Re: [Tagging] Feature Proposal - Voting - camp_site=camp_pitch

2019-05-20 Thread Joseph Eisenberg
I think “camp_site:part=camp_pitch” is too long.

Also,  remember that the existing tag is used for pitches within
campgrounds and caravan sites.

And, the British English term is “campsite”, without a space.

The shortest option with a new key would be “camp=pitch”.

But tourism=camp_pitch has the advantage of being in use, and it uses an
existing feature key.

I don’t feel enthusiastic about creating a 4th competing tagging standard
to go along with camp_site=pitch, camp_site=camp_pitch and
tourism=camp_pitch

On Tue, May 21, 2019 at 2:05 AM marc marc  wrote:

> Le 20.05.19 à 17:36, Jan S a écrit :
> > I find camp_site:part=* somewhat complicated, too. Also, it wouldn't be
> > consistent with the use of camp_site=* to describe the type of camping
> > site, either.
>
> tourism=camp_site + camp_site=basic/standard/serviced/deluxe
>
> and if you cut the site in several parts,
> camp_site:part=(camp_)pitch to describe each part
>
> > I'd prefer tourism=camp_pitch. This also has the advantage that this key
> > can be used for isolated camping pitches that are not part of a proper
> > camping ground.
>
> I find that it is precisely a defect. a camp_pitch does not define
> a basic camp_site limited to a single pitch (use tourism=camp_site +
> camp_site=basic for this, no need to add a part if the part=the whole
> camp_site).
>
> camp_pitch:part=* describes a part of a camp_site like building:part=*
> doesn't descript a building with one-part only.
> so a part always need to be in a camp_site like a building part
> need to be inside a building.
>
> but you can have a site with only one pitch and a deluxe service
> or have a site with a lot of pitch but basic service,
> there is no link between the number and quality
> ___
> 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] Aerodrome classification

2019-05-20 Thread Graeme Fitzpatrick
On Tue, 21 May 2019 at 08:38, John Willis via Tagging <
tagging@openstreetmap.org> wrote:

>
> http://vfrmap.com/?type=vfrc&lat=32.956&lon=-116.295&zoom=10
>

Wow, John - you've got crowded air! :-)

Thanks

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


Re: [Tagging] Feature Proposal - Voting - camp_site=camp_pitch

2019-05-20 Thread marc marc
Le 21.05.19 à 00:58, Joseph Eisenberg a écrit :
> I don’t feel enthusiastic about creating a 4th competing tagging 
> standard to go along with camp_site=pitch, camp_site=camp_pitch  
> and tourism=camp_pitch

it's an argument that makes sense.
perhaps in this case, should we start by proposing to depreciate 
camp_site=pitch and camp_site=camp_pitch since these are the 2 most 
problematic in the logic of tag linking

both depreciated tags would be temporarily converted into 
tourism=camp_pitch but without voting on the choice of the final key,
dividing the problem in two would allow, i hope, to have almost 
unanimity on the first step
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - changing table

2019-05-20 Thread Warin

On 20/05/19 22:20, Valor Naram wrote:

then it's a property


Yes.

The tag highway=residential says that is a road here,  a physical presence.

The tag surface=grass says that whatever is here has a grass surface, 
but does not say what the physical presence is.


If there is a thing tagged with both highway=residential and 
surface=grass then it says there is a road with a grass surface.


For change tables they would commonly be combined with toilets, possibly 
other things too like libraries, community halls, camp sites etc.


So the description of surface does not say what the physical presence 
is, nor should change table. For change table it is the provision of the 
activity.





 Original Message 
Subject: Re: [Tagging] Feature Proposal - RFC - changing table
From: Martin Koppenhoefer
To: "Tag discussion, strategy and related tools"
CC:



Am Mo., 20. Mai 2019 um 12:36 Uhr schrieb Valor Naram
mailto:valin...@gmx.net>>:

> [...] so if you intend to replace this, yours would likely
become a property (only) as well
Ok. Does it matter? From what I understood so far most wiki
pages describe `properties` e.g.: Key `highway`



the difference of a feature and a property is that a property
cannot be tagged alone, it requires a feature (e.g. "surface", or
"oneway", or "height"). On the other hand, a feature is defining a
"thing", e.g. a highway defined through the tag "highway". It is
not a property, but a feature (and the values are different
"classes" of this feature).

OSM does actually not explicitly make this distinction (AFAIK),
but it is implicit in how people are using the tags.

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] Aerodrome classification

2019-05-20 Thread John Willis via Tagging


> On May 21, 2019, at 8:12 AM, Graeme Fitzpatrick  wrote:
> 
> Wow, John - you've got crowded air! :-)

Yes, taking flight training out of Gillespie (in east San Diego),  you 
basically head southeast to avoid all the airspace restrictions around San 
Diego - but after that it is pretty easy. 

I saw a mid-air collision between two Cesenas out the window of my home, as 
there is near-constant air traffic of all types, sizes, and altitudes around my 
home southwest of Gillespie.

https://www.ntsb.gov/_layouts/ntsb.aviation/brief2.aspx?ev_id=20060215X00204&ntsbno=LAX06FA106B&akey=2
 

 

The airspace is so regulated because of a mid-air collision in 1978 between a 
small plane and 727.
http://www.sdpolicemuseum.com/PSA-Flight-182.html 
  There haven’t been any 
other airliner collisions since. 

I have passed basic flight school and took some training flights 20 years ago, 
I haven’t been back in the cockpit since.

 It is interesting to have some of my old flight knowledge be useful when 
mapping airports and their navigation aids now in OSM. 

Here in Japan, there are no general-purpose airports in my region and very 
little private traffic - I see mostly gliders and military helicopters when out 
cycling (and airliners at cruise). 

These are the airstrips round me:
https://www.openstreetmap.org/way/385305602 

winch-launched gliders (a parked winch truck pulls them airborne with a 
high-speed winch, like a catapult)

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

tow-launched gliders. 

skydiving airstrip. the plane and skydivers use the same field. The only 
amenity is the nearby trees for picnicking under. 
https://www.openstreetmap.org/way/539768744 


compare:

a military rough helipad
https://www.openstreetmap.org/way/550770469 


our only regional air travel option, the Gunma Heliport
https://www.openstreetmap.org/way/304172626 


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


Re: [Tagging] Feature Proposal - RFC - changing table

2019-05-20 Thread marc marc
Hello,

 > https://wiki.openstreetmap.org/wiki/Proposed_features/changing_table

questions / minor suggestions :

in changing_table:location=room what's the usecase of :
"or the floor to the toilets" ? maybe just drop it.
if someone wants to put their child on the floor, I don't see how
we could describe that this floor is adapted but not this other one

the first sentence of the tagging paragraph is about the rational (why 
some other existing tag doesn't fit the need),
drop or move it to the rational paragraph

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


Re: [Tagging] Feature Proposal - Voting - camp_site=camp_pitch

2019-05-20 Thread Tod Fitch


> On May 20, 2019, at 4:28 PM, marc marc  wrote:
> 
> Le 21.05.19 à 00:58, Joseph Eisenberg a écrit :
>> I don’t feel enthusiastic about creating a 4th competing tagging
>> standard to go along with camp_site=pitch, camp_site=camp_pitch
>> and tourism=camp_pitch
> 
> it's an argument that makes sense.
> perhaps in this case, should we start by proposing to depreciate
> camp_site=pitch and camp_site=camp_pitch since these are the 2 most
> problematic in the logic of tag linking
> 
> both depreciated tags would be temporarily converted into
> tourism=camp_pitch but without voting on the choice of the final key,
> dividing the problem in two would allow, i hope, to have almost
> unanimity on the first step

Is there some overall agreed upon “logic of tag linking” that I’ve missed 
reading about?

Near as I can tell tag formation/structure/logic is all over the place, 
obviously evolving with time and the opinion(s) of whoever decided they needed 
to map a particular set of features.

If there is someplace I can read up on this “logic of tag linking”? I’d love to 
have a link.

Thanks!




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


[Tagging] Runway area mapping?

2019-05-20 Thread Joseph Eisenberg
I've seen a number of runways mapped only as areas.

This seems like a bad idea, since it loses the information of the
runway centerline and length. Adding a width tag to a linear way
should be enough to clearly define most runways.

The current wiki page suggests using "aeroway:area=runway" to map the
outline of the runway, and mapping the "aeroway=runway" as a line
along the center of the runway.

Does everyone agree that aeroway:area is the right way to map runway
areas, if this is considered necessary?

And do we agree that runways should be mapped as linear ways, like
highways and railways, not only as an area?

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


Re: [Tagging] Runway area mapping?

2019-05-20 Thread Graeme Fitzpatrick
On Tue, 21 May 2019 at 11:36, Joseph Eisenberg 
wrote:

> The current wiki page suggests using "aeroway:area=runway" to map the
> outline of the runway, and mapping the "aeroway=runway" as a line
> along the center of the runway.
>
> Does everyone agree that aeroway:area is the right way to map runway
> areas, if this is considered necessary?
>
> And do we agree that runways should be mapped as linear ways, like
> highways and railways, not only as an area?
>

I must admit that I only ever map the runway as a way, not an area.

On the subject, I've just had a look at a few, & I see that there's now an
option (in iD at least) for "Runway number", which then apparently appears
as ref=.

I've always put the runway number "14/32" in as the name=, & it's always
seemed to work OK.

Is there any real preference?

Thanks

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


Re: [Tagging] Runway area mapping?

2019-05-20 Thread Joseph Eisenberg
I agree that “14/32” is a ref, not a name. Its similar to “I-80” for a
motorway.

(In the Openstreetmap-Carto style we render the runway ref, not the name,
but only when it is mapped as a linear way)

On Tue, May 21, 2019 at 11:58 AM Graeme Fitzpatrick 
wrote:

>
>
> On Tue, 21 May 2019 at 11:36, Joseph Eisenberg 
> wrote:
>
>> The current wiki page suggests using "aeroway:area=runway" to map the
>> outline of the runway, and mapping the "aeroway=runway" as a line
>> along the center of the runway.
>>
>> Does everyone agree that aeroway:area is the right way to map runway
>> areas, if this is considered necessary?
>>
>> And do we agree that runways should be mapped as linear ways, like
>> highways and railways, not only as an area?
>>
>
> I must admit that I only ever map the runway as a way, not an area.
>
> On the subject, I've just had a look at a few, & I see that there's now an
> option (in iD at least) for "Runway number", which then apparently appears
> as ref=.
>
> I've always put the runway number "14/32" in as the name=, & it's always
> seemed to work OK.
>
> Is there any real preference?
>
> Thanks
>
> Graeme
> ___
> 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] Runway area mapping?

2019-05-20 Thread John Willis via Tagging


> On May 21, 2019, at 10:35 AM, Joseph Eisenberg  
> wrote:
> 
>  if this is considered necessary?


Similar to riverbank, sometimes the shape (and it’s irregular outline, where it 
meets taxiways and aprons) is good to have for rendering at higher zoom levels 
where lines no longer show the proper land usage and areas more accurately 
reflect reality. anything that takes up the space of a village or a town should 
be mappable with a polygon in some fashion. 

As most airport facilities are already mapped via area (the apron, the overall 
airport grounds, the terminals, the grassy areas, parking, etc), so having 
*the* major feature that takes up a ton of space and is also easily mappable 
from imagery also mappable as an area seems like a common thing to map as an 
area.

keeping the information on the way (like the ref and other details) and using 
this :area tag modifier to map the extent of the surface seems great to me.  

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


Re: [Tagging] Runway area mapping?

2019-05-20 Thread Andrew Harvey
On Tue, 21 May 2019 at 11:36, Joseph Eisenberg 
wrote:

> I've seen a number of runways mapped only as areas.
>
> This seems like a bad idea, since it loses the information of the
> runway centerline and length. Adding a width tag to a linear way
> should be enough to clearly define most runways.
>
> The current wiki page suggests using "aeroway:area=runway" to map the
> outline of the runway, and mapping the "aeroway=runway" as a line
> along the center of the runway.


> Does everyone agree that aeroway:area is the right way to map runway
> areas, if this is considered necessary?
>
> And do we agree that runways should be mapped as linear ways, like
> highways and railways, not only as an area?
>

I agree, they should be always mapped as linear ways, then optionally
mapped as aeroway:area=runway if people want to include the whole area.

It's much easier and reliable to determine, length, bearing, centerline
when mapped as a line
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

2019-05-20 Thread Martin Koppenhoefer


sent from a phone

> On 20. May 2019, at 17:17, Nick Bolten  wrote:
> 
> > I would suggest to tag the exception, i.e. the absence of crossing markings 
> > where there is a pedestrian traffic light controlled crossing, with an 
> > additional property for the crossing node.
> 
> I'm not following, could you give an example?


crossing=traffic_signals
crossing:markings=no

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