Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Mateusz Konieczny]

12 Sep 2019, 02:03 by jan...@gmail.com:

> But I remember an artwork that was tagged somewhere, and it was consisted of 
> several murals spread around the city. Part:wikidata=* would be perfect for 
> that case.
>
Sounds like
https://en.m.wikipedia.org/wiki/Wroc%C5%82aw%27s_dwarfs 

(multiple sculptures distributed across city).

I still see no benefit in using part:wikipedia
or part:wikidata over current version.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Use of aeroway=taxilane vs aeroway=parking_position and aeroway=taxiway?

[Joseph Eisenberg]

The tag aeroway=taxilane has become more popular in the past year,
increasing from 600 uses to 2500, but it's still much less common than
aeroway=taxiway or aeroway=parking_position

The proposal for aeroway=taxilane said this should be used for the
routes followed by aircraft within the apron (the aircraft parking
area), while aeroway=taxiway should be for the main taxiways which
connect parking areas to the runways, more or less.

There was a suggestion to use aeroway=taxiway + taxiway=taxilane or
=apron but this has not been done yet.

There's also a tag aeroway=parking_position which started out on nodes
but now is more commonly tagged as a 2-node way, from the nearest
taxiway/taxilane to the point where the front wheel of the aircraft
stops.

Can someone with more knowledge about airport terminology check up on
these tags?

https://wiki.openstreetmap.org/wiki/Tag:aeroway%3Dparking_position
https://wiki.openstreetmap.org/wiki/Tag:aeroway%3Dtaxiway
https://wiki.openstreetmap.org/wiki/Tag:aeroway%3Dtaxilane

-Joseph Eisenberg

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

Re: [Tagging] Tourist bus stop

[Joseph Eisenberg]

The Key:bus has this definition currently
(https://wiki.openstreetmap.org/wiki/Key:bus):

"A bus is a large motor vehicle used for public transport of passengers.

"In most countries a bus is a larger public service vehicle or public
transport vehicle used to transport passengers, with more than 9 or 12
seating positions, but the specific definition may vary by location.
Long-distance and inter-city bus and coach=* vehicles may or may not
be included. Trolleybuses are usually included.

"There are two uses of this tag: 1) to specify legal access
restrictions for buses. 2) to specify the type of passenger public
transport vehicle that uses a stop or station.

"Also see the more common access tag psv=* which includes public
transport buses as well as other public service vehicles."

So if "tourist_bus=*" is for all buses which are not a "psv=*", then
it probably should include minibuses and vans, depending on the local
definition of "bus".

For example, I would think there here in Indonesia the minibuses would
be included (which are no larger than an American "minivan", but have
much higher capacity due to lack of seatbelts and use of bench seats).

Most of these are "PSVs" (public service vehicles / public transit)
but some are "for hire" like an Italian tourist bus or an English
hired motorcoach.

I agree that "[motor]coach=" might have been clearer, but I'm ok with
keeping "tourist_bus=*" since it may actually be easier to translate
into most languages, and "coach=*" can also be ambiguous, since it
used to refer to horse-drawn vehicles and passenger railway cars, so
"motorcoach" would have been needed. Also, some definitions of
"coach=" seem to be limited to larger inter-city style buses, with
seatbelts, individual seats instead of benches, etc.

See also https://wiki.openstreetmap.org/wiki/Key:coach

On 9/12/19, Martin Koppenhoefer  wrote:
> FWIW, there is in many jurisdictions a vehicle class for busses which is
> currently covered by the value: "tourist_bus" defined as bus not acting as
> a public service vehicle.
>
> As I have stated before, "motorbus" would have been a better (more
> consistent hence self-explaining) choice for the key name of the generic
> bus vehicle class (but with currently almost 8000 uses of tourist_bus, it
> seems hard to rename this).
>
> Additionally, for the context of the tourist bus stop, according to what is
> intended, this definition might not encompass every kind of vehicle that is
> intended by "tourist bus stop" (e.g. if you want to allow usage for
> vehicles used for the transportation of tourists, not included in public
> transport, but also not "buses" by definition).
>
> Cheers,
> Martin
>

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

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Janko Mihelić]

čet, 12. ruj 2019. u 00:04 Paul Allen  napisao je:

> In this case, I'm not convinced that we couldn't accept a many-to-one
> mapping of ways to
> wikidata.  But if you insist, put them in a relation of some kind.  Maybe
> a type=wikidata, even,
> although I suspect that would have more problems than benefits.
>

If anything, type=street. But I think part:wikidata=* would be fine.

If a relation makes no sense, a wikidata item shared by them probably
> doesn't, either.  I'll just
> go and look at wikidata for stolperstein...
>

I agree, Stolperstein isn't a good example, memorial=stolperstein is
enough. But I remember an artwork that was tagged somewhere, and it was
consisted of several murals spread around the city. Part:wikidata=* would
be perfect for that case.

So what you want is synonymous with "fixme."  But more complicated and
> requiring more work.
> I'm not convinced this is a good idea.
>

Well, a fixme, but also a correctly tagged link with wikidata.

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

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Paul Allen]

On Wed, 11 Sep 2019 at 22:26, Janko Mihelić  wrote:

> sri, 11. ruj 2019. u 20:24 Mateusz Konieczny 
> napisao je:
>
>> can you give specific example of case
>> where part:wikidata would be better
>> than wikidata?
>>
>
> The classic example is a street. Streets are one of those objects in OSM
> which are defined by a unique name on several ways. So if a wikidata item
> is about a street, all ways get the same part:wikidata=*
>

In this case, I'm not convinced that we couldn't accept a many-to-one
mapping of ways to
wikidata.  But if you insist, put them in a relation of some kind.  Maybe a
type=wikidata, even,
although I suspect that would have more problems than benefits.

Art or memorial installations like Stolperstein[1], which are distributed,
> but have one wikidata item. It's hard to imagine every Stolperstein will
> get its own article. And a relation with all these nodes makes no sense.
>

If a relation makes no sense, a wikidata item shared by them probably
doesn't, either.  I'll just
go and look at wikidata for stolperstein...  It's not identified as a
category, but it clearly is one.  It's
a sub-class of commemorative plaque.  It makes no more sense to apply Q26703203
to every
stolperstein than it does to apply Q532 to every village.  Don't force
round pegs into square
holes and don't whittle down trees into round pegs so you can force the
resulting round peg
into a square hole.

If you have a wikidata item for a specific, unique stolperstein then you
can tag it, if you wish.
But adding Q26703203 to every stolperstein doesn't help anyone.  A data
consumer using
the query tool of standard carto to find out what the symbol is of gets a
list of tags, amongst
them being memorial=stoperstein, and stolperstein is a link to the OSM wiki
documentation,
the OSM wiki documentation has links to the wikipedia article and the
wikidata item.  Adding
a generic stolperstein wikidata item to all stolpersteine is redundant and
unhelpful.

Not only that, what happens when a stolperstein with the generic Q26703203
gets its own
wikidata item?  Semi-colon list, causing problems for some consumers?
Delete the
part:wikidata=Q26703203 and add a wikidata=*, thus confounding anyone
thinking an
overpass query for part:wikidata=Q26703203 will find ALL stolpersteine?
You are putting
stumbling stones in everyone's path here [pun intended].

OSM and Wikidata have different worldviews.  Don't insist on fitting
wikidata items to every
object in OSM.  Accept that sometimes our views of the world diverge so
much that there's
no straightforward relationship between one and the other.

And then it could be used when the mapper isn't sure how to map a wikidata
> item, so she just tags all the parts with part:wikdiata=*. Then someone
> more experienced shows up, and creates a valid relation, and sums up all
> those parts into one wikidata=* (and deletes the part:wikidata=* tags).
>

So what you want is synonymous with "fixme."  But more complicated and
requiring more work.
I'm not convinced this is a good idea.

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

[Tagging] mesh bicycle network

[Hubert87]

Hi,

i have stumbled over the post about rcn and cycling node networks and
was wondering if you guys might have a proposal for primary bicycle
route mesh network relation(s) like this one
https://www.openstreetmap.org/relation/3585265, which is in Bremen, Germany.

It is neither a cycling node network nor a classical bicycle route but a
set of
guideposts(https://www.mapillary.com/map/im/AlXYW3arx59dkSlruUsWjg)
showing poi destinations and distances completed with addition smaller
signs (https://www.mapillary.com/map/im/9pqoiH4eH4o7Ieh6IXRnfg) in
between guideposts pointing in the right direction.

All classical bicycle routes seem to be part of this network, but it
contains more routes. Additionally these routes do not have a beginning
or end or a closed loops, but are more a kind of mesh like the node
network; except for the nodes.

Also, as far a I can tell, the main guidepost are sorted into 5 regions
(Nord, Süd, Ost, West, Mitte), which is coded in the small print
(mi=mitte) on the guideposts, as can be seen in the first example picture.

There is a discussion in the german forum
(https://forum.openstreetmap.org/viewtopic.php?pid=762131) about
deleting these relations and just tagging its highways with lcn=yes.
But I'd really looking for a different solution.
Can someone point me to a possible solution?

Yours
Hubert87



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

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Janko Mihelić]

sri, 11. ruj 2019. u 20:24 Mateusz Konieczny 
napisao je:

> can you give specific example of case
> where part:wikidata would be better
> than wikidata?
>

The classic example is a street. Streets are one of those objects in OSM
which are defined by a unique name on several ways. So if a wikidata item
is about a street, all ways get the same part:wikidata=*

Art or memorial installations like Stolperstein[1], which are distributed,
but have one wikidata item. It's hard to imagine every Stolperstein will
get its own article. And a relation with all these nodes makes no sense.

And then it could be used when the mapper isn't sure how to map a wikidata
item, so she just tags all the parts with part:wikdiata=*. Then someone
more experienced shows up, and creates a valid relation, and sums up all
those parts into one wikidata=* (and deletes the part:wikidata=* tags).

[1] - https://en.wikipedia.org/wiki/Stolperstein
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Paul Allen]

On Wed, 11 Sep 2019 at 20:18, Mateusz Konieczny 
wrote:

>
>
>
> 11 Sep 2019, 21:48 by pla16...@gmail.com:
>
> On Wed, 11 Sep 2019 at 19:43, Mateusz Konieczny 
> wrote:
>
>
> It gets tricky where wikidata has a
> single object for things like
> lake and surrounding wetlands
>
>
> Then the wikidata item is for the wetlands, which happen to have a lake
> within them.
>
> Wikidata item was generated by bots.
> Wikipedia article was about lake and surrounding wetlands.
>

WIthout seeing the article I can't determine what it actually depicts.  The
Wikipedia article
about Cardigan mentions it's in the county of Ceredigion but it's an
article about Cardigan,
the title says Cardigan, the URL says Cardigan and the wikidata is about
Cardigan.  Is
the wikipedia article about the lake and mentions it's in wetlands, is it
about the wetlands and
it mentions the lake in them, or is it specifically about both?  Does the
wikidata item match
what the article says?  If the article and wikidata match, then associate
them with the lake or
the wetlands or (using a multipolygon) both, as appropriate.  If the
wikidata item doesn't
match the article then fix one or the other, or wait for somebody else to
do that, then map
accordingly.

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

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Mateusz Konieczny]

11 Sep 2019, 21:48 by pla16...@gmail.com:

> On Wed, 11 Sep 2019 at 19:43, Mateusz Konieczny <> matkoni...@tutanota.com 
> > > wrote:
>
>>
>> It gets tricky where wikidata has a
>> single object for things like
>> lake and surrounding wetlands
>>
>
> Then the wikidata item is for the wetlands, which happen to have a lake 
> within them.
>
Wikidata item was generated by bots.
Wikipedia article was about lake and surrounding wetlands.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Paul Allen]

On Wed, 11 Sep 2019 at 19:43, Mateusz Konieczny 
wrote:

>
> It gets tricky where wikidata has a
> single object for things like
> lake and surrounding wetlands
>

Then the wikidata item is for the wetlands, which happen to have a lake
within them.  Map
the wetlands and add the wikidata tag to it.  This is no different from the
lamp post near me
being in Cardigan - it doesn't get the Cardigan wikidata tag.  Oh, but you
want somebody
querying the db about the lake to see the wikidata.  Multipolygon it (which
you should probably
have done anyway) and apply the wikidata to the relation not the components.

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

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Paul Allen]

On Wed, 11 Sep 2019 at 19:35, Yuri Astrakhan 
wrote:

> One of the issues I frequently observed is that mappers keep trying to add
> a wikidata=... tag even when there is no perfect match. Having a
> part:wikidata or a similar tag would help those mappers - indicating that
> there is no perfect 1:1 match, but someone already looked at this specific
> object and found another item to be a partial match.
>

I got the impression part:wikidata (or is it wikidata:part?) was for
situations where two OSM
objects matched one wikidata item (better handled as a multipolygon and
adding the wikidata
to the multipolygon itself) or two wikidata items match a single OSM object
(better handled by
decomposing the OSM object into a multipolygon and adding wikidata to the
outers).  Now you
propose using this for fuzzy matching: it's sorta this wikidata item but
not really.  I think in situations
like that we should remove all associations to wikidata - otherwise it's
square peg/round hole.

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

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Mateusz Konieczny]

11 Sep 2019, 19:59 by pla16...@gmail.com:
> Rule 3: If an object is a multipolygon relation containing several outers, 
> such as some
> university campuses, then the relation itself gets the wikidata tag for that 
> university,
> not the constituent polygons.
>
For object represented by single
area (closed way or multipolygon)
it works.

It gets tricky where wikidata has a
single object for things like
lake and surrounding wetlands___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Yuri Astrakhan]

One of the issues I frequently observed is that mappers keep trying to add
a wikidata=... tag even when there is no perfect match. Having a
part:wikidata or a similar tag would help those mappers - indicating that
there is no perfect 1:1 match, but someone already looked at this specific
object and found another item to be a partial match.

On Wed, Sep 11, 2019 at 2:24 PM Paul Allen  wrote:

> On Wed, 11 Sep 2019 at 18:31, Martin Koppenhoefer 
> wrote:
>
>> Am Mi., 11. Sept. 2019 um 19:01 Uhr schrieb Paul Allen <
>> pla16...@gmail.com>:
>>
>> to give a practical example:
>> https://www.wikidata.org/wiki/Q3734793
>> https://www.wikidata.org/wiki/Q1368377
>>
>> How should these be linked to OSM?
>>
>
> I have no real understanding of the legislative or other boundaries of
> quartieres in Rome.  The
> question I'd consider important is have you mapped those two things as
> distinct OSM objects?
> If you have, then add the appropriate wikidata tags to them.  If you
> haven't mapped them
> as distinct OSM objects then there is nothing for you to add a wikidata
> tag to.
>
> These are moving targets, they change nature every now and then
>> (administrative entity, or not, etc.).
>>
>
> If the wikidata is about the same object with the same boundaries then use
> it.  If they don't match
> then don't use it (or remap accordingly).  We're not trying to map
> everything that is in wikidata,
> we're adding wikidata, where appropriate, to things we have mapped.
>
> The basic assumption that crosslinked wikipedia articles are about the
>> same thing, already breaks, because different ("groups of") articles are
>> structured differently, what has one article in one language may have
>> several in another language.
>>
>
> Where wikipedia articles in a language do not match the wikidata then the
> article or the wikidata
> is incorrect.  But again, it's not about trying to map everything in
> wikidata or on wikipedia, it's
> about adding those tags, where appropriate, to things that are mapped.
>
> If there's a matching wikidata item to an OSM object then you're free to
> tag it (if you wish) but if
> there's not a matching wikidata item then don't add a mismatched item to
> an OSM object.  It's
> not possible to add wikidata tags to every object in OSM (like lamp posts
> or unnamed ponds,
> or specific park benches) and it's not possible to map everything that has
> a wikidata tag.  It
> is simply that if there is a wikidata item matching an OSM object then it
> is convenient for data
> consumers who wish to get more information about an object if we tag it.
> It's not mandatory
> for us to add wikidata and we certainly shouldn't force square pegs into
> round holes.
>
> Hmmm.  Rule 0: Don't force square wikidata items into round OSM objects.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Paul Allen]

On Wed, 11 Sep 2019 at 18:31, Martin Koppenhoefer 
wrote:

> Am Mi., 11. Sept. 2019 um 19:01 Uhr schrieb Paul Allen  >:
>
> to give a practical example:
> https://www.wikidata.org/wiki/Q3734793
> https://www.wikidata.org/wiki/Q1368377
>
> How should these be linked to OSM?
>

I have no real understanding of the legislative or other boundaries of
quartieres in Rome.  The
question I'd consider important is have you mapped those two things as
distinct OSM objects?
If you have, then add the appropriate wikidata tags to them.  If you
haven't mapped them
as distinct OSM objects then there is nothing for you to add a wikidata tag
to.

These are moving targets, they change nature every now and then
> (administrative entity, or not, etc.).
>

If the wikidata is about the same object with the same boundaries then use
it.  If they don't match
then don't use it (or remap accordingly).  We're not trying to map
everything that is in wikidata,
we're adding wikidata, where appropriate, to things we have mapped.

The basic assumption that crosslinked wikipedia articles are about the same
> thing, already breaks, because different ("groups of") articles are
> structured differently, what has one article in one language may have
> several in another language.
>

Where wikipedia articles in a language do not match the wikidata then the
article or the wikidata
is incorrect.  But again, it's not about trying to map everything in
wikidata or on wikipedia, it's
about adding those tags, where appropriate, to things that are mapped.

If there's a matching wikidata item to an OSM object then you're free to
tag it (if you wish) but if
there's not a matching wikidata item then don't add a mismatched item to an
OSM object.  It's
not possible to add wikidata tags to every object in OSM (like lamp posts
or unnamed ponds,
or specific park benches) and it's not possible to map everything that has
a wikidata tag.  It
is simply that if there is a wikidata item matching an OSM object then it
is convenient for data
consumers who wish to get more information about an object if we tag it.
It's not mandatory
for us to add wikidata and we certainly shouldn't force square pegs into
round holes.

Hmmm.  Rule 0: Don't force square wikidata items into round OSM objects.

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

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Mateusz Konieczny]

can you give specific example of case
where part:wikidata would be better
than wikidata?

11 Sep 2019, 20:38 by jan...@gmail.com:

> On Wed, Sep 11, 2019, 19:31 Martin Koppenhoefer <> dieterdre...@gmail.com 
> > > wrote:
>
>> I am also against restricting wikidata tags to a 1:1 relationship. It would 
>> require restructuring of specific items either in osm or in wikidata, or 
>> both, just to have them linked nicely (at a certain point in time, because 
>> from then on, they will diverge again, inevitably).
>>
>
> I agree that 1:1 isn't always possible, that's why I propose part:wikidata=*.
>
>>
>>___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Janko Mihelić]

On Wed, Sep 11, 2019, 19:31 Martin Koppenhoefer 
wrote:

> I am also against restricting wikidata tags to a 1:1 relationship. It
> would require restructuring of specific items either in osm or in wikidata,
> or both, just to have them linked nicely (at a certain point in time,
> because from then on, they will diverge again, inevitably).
>

I agree that 1:1 isn't always possible, that's why I propose
part:wikidata=*.

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

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Martin Koppenhoefer]

Am Mi., 11. Sept. 2019 um 19:01 Uhr schrieb Paul Allen :

> Rule 1: We only tag terminal instantiations which are unique objects, not
> categories.
> It is appropriate to use wikidata=Q275 for the Forth Railway Bridge; it is
> not appropriate
> to use wikidata=Q8471277 (category railway bridges) for the Forth Railway
> Bridge.
> Nor is it appropriate to use wikidata=532 (category village) for a village
> which does
> not have its own unique wikidata reference.
>


we do have wikidata subtags which will not always be used only for terminal
instantiations
We also have wikidata refs for tags in the wiki.



>
> Rule 2: "Lesser" objects goegraphically within an object that has a
> wikidata entry do not
> inherit that wikidata entry.  If the wikidata entry is for a particular
> town then objects
> within the town do not also get that wikidata tag.  My street is within
> the town
> of Cardigan but does not get the wikidata tag for Cardigan, nor does a
> lamp post
> on that street, nor does my house.  Two reasons: first, it would lead to a
> massive
> proliferation of tags; second, an article about Cardigan doesn't tell you
> about my
> house or the nearby lamp post.
>


to give a practical example:
https://www.wikidata.org/wiki/Q3734793
https://www.wikidata.org/wiki/Q1368377

How should these be linked to OSM?
These are moving targets, they change nature every now and then
(administrative entity, or not, etc.).
The basic assumption that crosslinked wikipedia articles are about the same
thing, already breaks, because different ("groups of") articles are
structured differently, what has one article in one language may have
several in another language.




>
> Rule 4: For city states it all depends on whether the wikidata item is for
> the city,
> the state, or the city state.  In this case I'd be willing to use the same
> wikidata tag
> for a city state on two different OSM objects (the city and the country),
> but others will
> disagree.
>


I am also against restricting wikidata tags to a 1:1 relationship. It would
require restructuring of specific items either in osm or in wikidata, or
both, just to have them linked nicely (at a certain point in time, because
from then on, they will diverge again, inevitably).

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

Re: [Tagging] Open Defecation Areas

[Martin Koppenhoefer]

>From what I have seen in an open defecation google image search I got to
the impression we cannot map these as landuse features. I can understand
someone could draw a map and mark the "open defecation areas", on a city
scale, but likely not on a street scale, these are not punctual features
like toilets, nor are they clearly delimited areas. How would it be
verifiable, especially the borders will likely be soft/fuzzy borders and
not suitable for a representation with polygons in the OSM data model.

We could do it the other way round: map which buildings don't have toilets,
but this would require a very fine grained survey and might also raise
privacy concerns.

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

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Paul Allen]

On Wed, 11 Sep 2019 at 14:31, Janko Mihelić  wrote:

> The rule I'm trying to implement, "A Wikidata item cannot be connected to
> more than one OSM item", might also be interpreted as a DRY rule. But I'm
> at least proposing part:wikidata, so we can have the benefits of DRY, as
> well as easiness of tagging WET tags.
>

I think we have different people understanding this in different ways (or
I'm misunderstanding
them).  So this is how I see it...

Firstly, we're talking about Wikipedia's wikidata, and objects are tagged
with wikidata=*.
We're not talking about the wikidata OSM's own wiki maintains.  I don't
think anybody has
confused the two so far, but at one point I wasn't sure until I re-read a
sentence.

Rule 1: We only tag terminal instantiations which are unique objects, not
categories.
It is appropriate to use wikidata=Q275 for the Forth Railway Bridge; it is
not appropriate
to use wikidata=Q8471277 (category railway bridges) for the Forth Railway
Bridge.
Nor is it appropriate to use wikidata=532 (category village) for a village
which does
not have its own unique wikidata reference.

Rule 2: "Lesser" objects goegraphically within an object that has a
wikidata entry do not
inherit that wikidata entry.  If the wikidata entry is for a particular
town then objects
within the town do not also get that wikidata tag.  My street is within the
town
of Cardigan but does not get the wikidata tag for Cardigan, nor does a lamp
post
on that street, nor does my house.  Two reasons: first, it would lead to a
massive
proliferation of tags; second, an article about Cardigan doesn't tell you
about my
house or the nearby lamp post.

Rule 3: If an object is a multipolygon relation containing several outers,
such as some
university campuses, then the relation itself gets the wikidata tag for
that university,
not the constituent polygons.

Rule 4: For city states it all depends on whether the wikidata item is for
the city,
the state, or the city state.  In this case I'd be willing to use the same
wikidata tag
for a city state on two different OSM objects (the city and the country),
but others will
disagree.

I'm guessing that of all the objections I'm going to get, most will be
about rule 3.  Because
I can see reasons to have it both ways.  So maybe it's not a rule, just a
suggestion.

Or maybe I'm missing the whole point of what you're trying to do.  Wouldn't
be the first
time.

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

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Imre Samu]

> if we enforce the "unique wikidata id" rule.

imho: lot of unintended consequences.
The 2 community/database has a different rules, different focus, and
activity.
and I don't believe that 1:1 relationship is possible with the current osm
data model.

And mapping with a mobile phone,  it is impossible to fix a wikidata errors
for a beginners.
so I prefer the  loosely coupled relationship of the 2 system.

on the other hand - we need to analyze the problem more deeper, because lot
of (wikidata) tagging errors is hidden now.
so need some solutions ( QA checks )   ..   but we need to keep the
compatibility - as we can ...

As I know - the "wikidata" tags used mostly for labelling - so your
proposed change will be painful.
The "Localized map rendering" is also a high priority.  (
https://wiki.openstreetmap.org/wiki/Top_Ten_Tasks#Localized_map_rendering
 )
so your proposal need some solutions for this problem - because the 2
problem is related.



Janko Mihelić  ezt írta (időpont: 2019. szept. 11., Sze,
16:32):

> sri, 11. ruj 2019. u 15:37 Imre Samu  napisao je:
>
>>
>> imho:  The wikidata taxonomy is in very early stage.  but we can create
>> some SPARQL validating with https://sophox.org/ ;
>> but this is not for the average osm editors.  it is too complex task
>> - fixing wikidata and osm parallel ...
>>
>
> I agree, it won't be easy. But I also think it will be possible only if we
> enforce the "unique wikidata id" rule. If we don't enforce this, and just
> let the wikidata tag go it's own course, we'll get into a mess that will be
> hard to dig out of.
> ___
> 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] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Martin Koppenhoefer]

Am Mi., 11. Sept. 2019 um 18:04 Uhr schrieb Mateusz Konieczny <
matkoni...@tutanota.com>:

> AFAIK it is about structural needs of
> Wikidata itself. Entries about shop brands
> (used in name suggestion index) got deleted.
>


>From personal experience I was more fortunate in Wikidata so far, but maybe
they just haven't yet discovered my contributions, because a wikipedia
article I had set up for the same topic (a not-world-famous artist who is
making his living from art and has a long list of minor mentions in
national newspapers) got deleted in WP within a few hours but lives in
Wikidata for some years now.

The structural needs would IMHO be fulfilled: if you split  a wikidata
object (that is not contested, e.g. has a wikipedia page referenced) into
more objects and link them, they all depend structurally on each other
(within wikidata).

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

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Mateusz Konieczny]

11 Sep 2019, 19:00 by dieterdre...@gmail.com:

>
>
> Am Mi., 11. Sept. 2019 um 17:56 Uhr schrieb Mateusz Konieczny <> 
> matkoni...@tutanota.com > >:
>
>> 11 Sep 2019, 15:32 by >> joseph.eisenb...@gmail.com 
>> >> :
>>
>>> Doesn't this mean that it would be better to create separate Wikidata
>>> items for each separate OSM feature, rather than creating a new OSM
>>> tag?
>>>
>> impossible due to Wikidata rules.
>>
>> for example
>> https://en.m.wikipedia.org/wiki/Israeli_West_Bank_barrier 
>> 
>> changes from fence to wall to other
>> such sections are unlikely to pass
>> https://m.wikidata.org/wiki/Wikidata:Notabilit 
>> >> y
>>
>
>
> there's the rule "It fulfills a > structural need> , for example: it is 
> needed to make statements made in other items more useful."
>
AFAIK it is about structural needs of
Wikidata itself. Entries about shop brands
(used in name suggestion index) got deleted.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Martin Koppenhoefer]

Am Mi., 11. Sept. 2019 um 17:56 Uhr schrieb Mateusz Konieczny <
matkoni...@tutanota.com>:

> 11 Sep 2019, 15:32 by joseph.eisenb...@gmail.com:
>
> Doesn't this mean that it would be better to create separate Wikidata
> items for each separate OSM feature, rather than creating a new OSM
> tag?
>
> impossible due to Wikidata rules.
>
> for example
> https://en.m.wikipedia.org/wiki/Israeli_West_Bank_barrier
> changes from fence to wall to other
> such sections are unlikely to pass
> https://m.wikidata.org/wiki/Wikidata:Notabilit
> y
>


there's the rule "It fulfills a *structural need*, for example: it is
needed to make statements made in other items more useful."

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

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Mateusz Konieczny]

11 Sep 2019, 15:32 by joseph.eisenb...@gmail.com:

> Doesn't this mean that it would be better to create separate Wikidata
> items for each separate OSM feature, rather than creating a new OSM
> tag?
>
impossible due to Wikidata rules.

for example
https://en.m.wikipedia.org/wiki/Israeli_West_Bank_barrier 

changes from fence to wall to othersuch sections are unlikely to 
passhttps://m.wikidata.org/wiki/Wikidata:Notabilit 
y___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tourist bus stop

[Martin Koppenhoefer]

FWIW, there is in many jurisdictions a vehicle class for busses which is
currently covered by the value: "tourist_bus" defined as bus not acting as
a public service vehicle.

As I have stated before, "motorbus" would have been a better (more
consistent hence self-explaining) choice for the key name of the generic
bus vehicle class (but with currently almost 8000 uses of tourist_bus, it
seems hard to rename this).

Additionally, for the context of the tourist bus stop, according to what is
intended, this definition might not encompass every kind of vehicle that is
intended by "tourist bus stop" (e.g. if you want to allow usage for
vehicles used for the transportation of tourists, not included in public
transport, but also not "buses" by definition).

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

Re: [Tagging] Tourist bus stop

[Johnparis]

I believe that tourism is a characteristic of the line, not the stop. PTv2
handles this (as it does so many cases) quite easily.

Here's an example in central Paris of a stop that is served by a "public"
bus line and a "tourist" bus line:

https://www.openstreetmap.org/node/5292142706

The tagging for the stop is fairly straightforward:
bus=yes
highway=bus_stop
public_transport=platform
ref:FR:Open_Tour=17
route_ref=69;OpenTour

Line 69 is operated by the RATP, the regional transit agency. Open Tour is
a tourist line.

By the way, your proposed tag highway=tourist_bus_stop will not render in
OSM Carto, the main map people see when they visit openstreetmap.org. As a
result, many (if not all) potential mappers will be scared away. This
has been a problem for years since PTv2 was introduced; apparently one
person (as I understand it) in the OSM Carto world doesn't like PTv2, and
so has blocked its implementation there. After many years, the main editors
(iD and JOSM) have finally implemented presets for PTv2, so that's no
longer a problem. (Thanks, Polyglot et al.) But the presets unfortunately
must include the legacy tags, because OSM Carto won't render PTv2 without
them. (Despite comments I sometimes see to the contrary, PTv2 has been
wildly successful in terms of usage.)

I frankly don't see the difference, either, between a "tourist" line and a
"public" line. Tourist buses are open to the public and charge a fee, just
as public buses do, and in fact "public" bus lines are often privately
owned. If you look at the tagging for the Open Tour line (relation, not the
individual stop) you will see this:

https://www.openstreetmap.org/relation/7282206
description=bus touristique
name=Open Tour : Ligne Bleue
network=Open Tour
operator=Open Tour
public_transport:version=2
ref=Bleue
route=bus
type=route

That "description" tag is the only one to differentiate this route from a
"public" route. If you really feel such a tag is needed, perhaps simplest
would be to add a tag like this to the route:
tourist=only
...or some such

Finally, it would be a good idea to also send a notice of your proposal to
the talk-transit list, where others might have good suggestions.

Cheers,

John





On Wed, Sep 11, 2019 at 3:48 PM Paul Allen  wrote:

> On Wed, 11 Sep 2019 at 14:31, Philip Barnes  wrote:
>
>>
>> The  description here describes coaches, which are more comfortable than
>> buses and are used for long distances. In French for example this would be
>> the difference between Autocar and Autobus.
>>
>
> That's one end of the spectrum.  I'm not sure I'd call it a tourist bus
> (English usage).  It's
> a long-distance, comfortable bus.  It's just for getting from A to B, not
> what you do at B
> or requiring you to also return.
>
> I would have considered a tourist bus, to be the buses that travel around
>> Central London giving a guided commentary where tourists can get on and off
>> a certain dedicated bus stops close to tourist attractions.
>>
>
> That's the other end of the spectrum.  Tourists turn up in London
> (somehow) and get one of
> those things for a guided tour.
>
> Another point on the spectrum is day tours from town A to town B or event
> C, such as
> https://www.richardsbros.co.uk/day-tours/  They're not daily, or
> regularly scheduled, and you
> need to book, so not public buses.
>
> Elsewhere on the spectrum is coach holidays, from town A to town B, with a
> tour of town
> B (similar to the kind offered by London tourist buses), such as
> https://www.richardsbros.co.uk/coach-holidays/
>
> Both of those examples are from my local bus operator, who runs public
> buses in my
> area: https://www.richardsbros.co.uk/local-bus-services/
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Janko Mihelić]

sri, 11. ruj 2019. u 15:37 Imre Samu  napisao je:

>
> imho:  The wikidata taxonomy is in very early stage.  but we can create
> some SPARQL validating with https://sophox.org/ ;
> but this is not for the average osm editors.  it is too complex task -
> fixing wikidata and osm parallel ...
>

I agree, it won't be easy. But I also think it will be possible only if we
enforce the "unique wikidata id" rule. If we don't enforce this, and just
let the wikidata tag go it's own course, we'll get into a mess that will be
hard to dig out of.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] building typology vs usage

[Martin Koppenhoefer]

By the way, there are currently 5 objects with the tagging on the same
object.
{
  "type": "way",
  "id": 59218539,
"tags": {
"addr:housenumber": "8",
"addr:street": "Pier Place",
"building": "church",
"leisure": "sports_centre",
"name": "Alien Rock",
"note": "former St Andrew's Church",
"phone": "+44 131 552 7211",
"source": "NLS_OS_Edinburgh_map_1940s;Bing;survey",
"sport": "climbing",
"url": "http://www.alienrock.co.uk/;
  }
},
{
  "type": "way",
  "id": 93180076,
  "tags": {
"building": "church",
"leisure": "sports_centre",
"name": "Kletterkirche",
"old_name": "St. Peter",
"sport": "climbing",
"wheelchair": "no",
"wikidata": "Q20181755"
  }
},
{
  "type": "way",
  "id": 202350995,
  "tags": {
"building": "church",
"leisure": "fitness_station",
"name": "Three Wise Monkeys",
"source": "OS_OpenData_StreetView",
"source:location": "Bing",
"sport": "climbing"
  }
},
{
  "type": "way",
  "id": 275133732,
  "tags": {
"HE_ref": "1025007",
"alt_name": "The Bristol Climbing Centre",
"building": "church",
"listed_status": "Grade II*",
"name": "Undercover Rock",
"old_name": "Saint Werburgh's Church",
"sport": "climbing",
"wikidata": "Q7595628",
"wikipedia": "en:St Werburgh's Church, Bristol"
  }
},
{
  "type": "way",
  "id": 381773790,
  "tags": {
"addr:city": "Newcastle Upon Tyne",
"addr:street": "Shields Road",
"building": "church",
"building:material": "stone",
"leisure": "sports_centre",
"name": "Newcastle Climbing Centre",
"note": "formerly St Marks Church",
"phone": "+44 191 265 6060",
"sport": "climbing",
"website": "www.newcastleclimbingcentre.co.uk"
  }
}
  ]
}
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] building typology vs usage

[Paul Allen]

On Wed, 11 Sep 2019 at 14:38, Martin Koppenhoefer 
wrote:

> Am So., 8. Sept. 2019 um 15:13 Uhr schrieb Paul Allen  >:
>
>> Good idea.  A better idea might be to add it to the description, since it
>> is information that
>> may be useful to non-mappers: data consumers may suppress notes but allow
>> the
>> display of descriptions.  It's useful to know that the art studio you're
>> looking for is in a
>> church...
>>
>
>
> these descriptions could be autogenerated from semantically detailed
> tagging, localized for every language. You can add a lot of useful
> information to the descriptions, but it shouldn't substitute good tagging.
> Semantic tagging makes it possible to find church buildings where you can
> climb, descriptions don't.
>

I think you took my paragraph in isolation and missed the point.  I said
that if it was a church and
looks like a church then tag the building as a church even if it now
functions as something else.
Somebody said he added a note to the effect that it was once a church, I
said that note might be
better as a description.

The note or description are there to clarify the tagging in order to
minimize the risk of confusion
in somebody who has trouble reconciling building=church with
shop=convenience.

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

Re: [Tagging] Tourist bus stop

[Paul Allen]

On Wed, 11 Sep 2019 at 14:31, Philip Barnes  wrote:

>
> The  description here describes coaches, which are more comfortable than
> buses and are used for long distances. In French for example this would be
> the difference between Autocar and Autobus.
>

That's one end of the spectrum.  I'm not sure I'd call it a tourist bus
(English usage).  It's
a long-distance, comfortable bus.  It's just for getting from A to B, not
what you do at B
or requiring you to also return.

I would have considered a tourist bus, to be the buses that travel around
> Central London giving a guided commentary where tourists can get on and off
> a certain dedicated bus stops close to tourist attractions.
>

That's the other end of the spectrum.  Tourists turn up in London (somehow)
and get one of
those things for a guided tour.

Another point on the spectrum is day tours from town A to town B or event
C, such as
https://www.richardsbros.co.uk/day-tours/  They're not daily, or regularly
scheduled, and you
need to book, so not public buses.

Elsewhere on the spectrum is coach holidays, from town A to town B, with a
tour of town
B (similar to the kind offered by London tourist buses), such as
https://www.richardsbros.co.uk/coach-holidays/

Both of those examples are from my local bus operator, who runs public
buses in my
area: https://www.richardsbros.co.uk/local-bus-services/

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

Re: [Tagging] building typology vs usage

[Martin Koppenhoefer]

Am So., 8. Sept. 2019 um 15:13 Uhr schrieb Paul Allen :

> Good idea.  A better idea might be to add it to the description, since it
> is information that
> may be useful to non-mappers: data consumers may suppress notes but allow
> the
> display of descriptions.  It's useful to know that the art studio you're
> looking for is in a
> church...
>



these descriptions could be autogenerated from semantically detailed
tagging, localized for every language. You can add a lot of useful
information to the descriptions, but it shouldn't substitute good tagging.
Semantic tagging makes it possible to find church buildings where you can
climb, descriptions don't.


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

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Imre Samu]

> we can't enforce some rules like "tag leisure=stadium can only be
connected
> to something that is, or is derived from Q483110 (Stadium) in Wikidata"

imho:  The wikidata taxonomy is in very early stage.  but we can create
some SPARQL validating with https://sophox.org/ ;
but this is not for the average osm editors.  it is too complex task -
fixing wikidata and osm parallel ...

$ wdtaxonomy Q483110
stadium (Q483110) •82 ×7252 ↑↑
├──Olympic Stadium (Q589481) •31 ×5
├──baseball park (Q595452) •8 ×240
├──Domed stadium (Q625797) •4 ×1
├──baseball field (Q809889) •8 ×25 ↑↑
├──velodrome (Q830528) •35 ×255 ↑
│  └──keirin racing track (Q11598565) •1 ×46
├──Dohyō (Q832429) •8
├──multi-purpose stadium (Q1049757) •8 ×104
├──association football stadium (Q1154710) •11 ×3241 ↑
│  ├──National Olympic Stadium (Q330033) •33 ↑↑
│  ├──Niigata City Athletic Stadium (Q7034374) •2 ↑↑
│  └──Estadio Independiente MRCI (Q66036711) •2 ↑
├──bullring (Q1193438) •17 ×246
├──naumachia (Q1431232) •20 ×1
├──athletics stadium (Q4256984) •2 ×12
│  ╞══National Olympic Stadium (Q330033) •33 ↑↑ …
│  ╘══Niigata City Athletic Stadium (Q7034374) •2 ↑↑ …
├──all-seater stadium (Q4728370) •1 ×3
├──Modular stadium (Q6889733) •2
├──Solar Powered Stadiums (Q7555943) •1
├──??? (Q11573504) •1 ×7
├──ice stadium (Q12019965) •9 ×138 ↑
│  └──ice hockey arena (Q3498109) •2 ×20 ↑
├──??? (Q17240246) •1
├──stadium project (Q20981001) ×2
├──Greyhound racing stadium (Q28174251) ×1
├──skiing stadium (Q31157863) ×4
├──??? (Q37025296) ×2
├──American football stadium (Q37985280) ×7
├──rugby league stadium (Q45290083) ×2
╘══Estadio Independiente MRCI (Q66036711) •2 ↑ …

( created with https://github.com/nichtich/wikidata-taxonomy tool )

Janko Mihelić  ezt írta (időpont: 2019. szept. 6., P,
15:08):

> Last year there was a little discussion about unique wikidata ids in the
> openstreetmap database:
> https://lists.openstreetmap.org/pipermail/tagging/2018-August/038249.html
>
> It was more or less decided there was no problem with this. Nevertheless,
> I think we should consider having a hard rule of "*A Wikidata item cannot
> be connected to more than one OSM item*".
>
> Problems with not enforcing this rule:
>
> - the problem of a partially downloaded database, where one is never sure
> if a wikidata item is fully downloaded unless the whole database is
> downloaded.
>
> - we could get a flood of wikidata tags where one would, for example, tag
> every building in a town with the wikidata id of the town, because that
> building is a part of the town. Is that wrong tagging? Well, if the above
> rule is not in place, I'm not sure.
>
> - if a road segment has two road routes that are using it, then we should
> tag it as "wikidata=Q1234;Q5678". That means, if we want to find any
> wikidata id, we should be prepared to parse all wikidata tags and be
> prepared for semicolons. This slows down any wikidata searches
>
> - we can't enforce some rules like "tag leisure=stadium can only be
> connected to something that is, or is derived from Q483110 (Stadium) in
> Wikidata" because, if we tag all the parts of an entity, we can also tag a
> water fountain in the stadium, because that is a part of it.
>
> So I propose we enforce this rule, and we tag, for example, railways only
> on the route relation.
>
> If one wants to tag all route segments with a wikidata tag, I propose a
> general usage "*part:wikidata=**" which would be used when a single
> wikidata tag just isn't viable. Proposal wiki page here:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/part:wikidata
>
> Thanks for reading,
> Janko Mihelić
> ___
> 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] Tourist bus stop

[Philip Barnes]

On Wednesday, 11 September 2019, Paul Allen wrote:
> On Wed, 11 Sep 2019 at 10:43, Martin Koppenhoefer 
> wrote:
> 
> >
> > Am Mi., 11. Sept. 2019 um 04:39 Uhr schrieb Leif Rasmussen <
> > 354...@gmail.com>:
> >
> > if both can stop, it is not a tourist bus stop but a regular bus stop
> > where coaches can stop. I have difficulties imagining it, but I would not
> > exclude the possibility.
> >
> 
> I'm glad you wouldn't exclude the possibility.  There is a bus stop like
> that in my town.  Occasionally
> tourist buses stop there to allow passengers to board so they can go on
> holiday.  As it happens,
> the same company that runs the public buses around here also has a tourist
> operation which
> takes people in the area on holidays, tours, etc.
> 
> 
> > Usually these tourist bus stops are set up in areas with a lot of traffic
> > and few parking space, in these settings you would not want tourist busses
> > to block pt bus stops, the setting where it would be imaginable are low
> > density places where it doesn't matter anyway where you stop (no problem,
> > next bus in 4 hours).
> >
> 
> Ummm, the one here is on what is effectively the high street (and used to
> be named that
> many, many years ago).  Several different hourly services stop there.  It's
> actually a long
> "platform," long enough that two buses can stop there at once, which
> sometimes happens if one
> is running a little late.  So there's enough room for an ordinary bus and a
> tourist bus.
> 
> The other place tourist buses stop is a public car park.  Fortunately the
> annual fair (with
> mobile fairground rides) that takes over the car park a few days a year
> does so in November
> when there aren't as many people wanting to travel.
> 
> In other places I've lived, tourist and long-distance buses shared a bus
> station with ordinary
> buses.
> 
Am still not 100% clear what was originally meant by Tourist bus.

The  description here describes coaches, which are more comfortable than buses 
and are used for long distances. In French for example this would be the 
difference between Autocar and Autobus.

I would have considered a tourist bus, to be the buses that travel around 
Central London giving a guided commentary where tourists can get on and off a 
certain dedicated bus stops close to tourist attractions.

Phil (trigpoint) 

-- 
Sent from my Sailfish device
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Janko Mihelić]

The rule I'm trying to implement, "A Wikidata item cannot be connected to
more than one OSM item", might also be interpreted as a DRY rule. But I'm
at least proposing part:wikidata, so we can have the benefits of DRY, as
well as easiness of tagging WET tags.

sri, 11. ruj 2019. u 14:59 Paul Allen  napisao je:

>
> This will come as a shock and a surprise to people on this list, but some
> open-source
> projects become obsessive about an overly-rigid interpretation of rules.
> In this case it is
> that if there is a property shared by all members of a group then it MUST
> be marked on
> the group ALONE and not also on individual members.  It doesn't matter
> that users would
> find it far more useful to be able to see that an individual saint is
> canonized, those users
> MUST be savvy enough about Wikipedia rules to know that they should then
> look at the
> parent group in order to get all the information they wish.  DRY (don't
> repeat yourself)
> is rigidly enforced.
>
> Yes, I've been bitten by this before.  Marking up Wikimedia images as
> being listed
> buildings.  All went fine until I happened to mark a few that were
> collected in a group
> of "Listed buildings in ."  Those changes were reverted because
> the
> grouping itself was flagged as being of listed buildings.  It matters not
> that when
> individual buildings are tagged the tag includes the listed building ID,
> which links
> to an external page describing the building and its reason for listing,
> whilst the
> collective tag cannot have that information.  It matters not that if you
> look at non-grouped
> listed buildings you see clearly that they are listed buildings but if you
> look at
> grouped listed buildings you have no idea that they are listed.  DRY.
> Rules is
> rules.
>
> Anyone who thinks the preceding paragraph is off-topic because it's about
> Wikimedia should try to recall all the times on this list when somebody has
> insisted that rules is rules, even when the outcome of following those
> rules is sub-optimal.
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tourist bus stop

[Martin Koppenhoefer]

Am Mi., 11. Sept. 2019 um 15:12 Uhr schrieb Paul Allen :

> On Wed, 11 Sep 2019 at 10:43, Martin Koppenhoefer 
> wrote:
>
>> Usually these tourist bus stops are set up in areas with a lot of traffic
>> and few parking space, in these settings you would not want tourist busses
>> to block pt bus stops, the setting where it would be imaginable are low
>> density places where it doesn't matter anyway where you stop (no problem,
>> next bus in 4 hours).
>>
>
> Ummm, the one here is on what is effectively the high street (and used to
> be named that
> many, many years ago).  Several different hourly services stop there.
> It's actually a long
> "platform," long enough that two buses can stop there at once, which
> sometimes happens if one
> is running a little late.  So there's enough room for an ordinary bus and
> a tourist bus.
>


I was a bit exaggerating to make the point, but I guess you would agree
that tourist busses stopping at bus stops in central London would not be
appreciated. Around here (Rome), many bus stops have room for 2 busses, but
with busses approaching every few minutes it would not work having coaches
use them as well. In smaller towns it can be possible, but it isn't usual.



>
> In other places I've lived, tourist and long-distance buses shared a bus
> station with ordinary
> buses.
>



this is probably common (also close to or combined with a train station or
a subway station)

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

Re: [Tagging] Tourist bus stop

[Paul Allen]

On Wed, 11 Sep 2019 at 10:43, Martin Koppenhoefer 
wrote:

>
> Am Mi., 11. Sept. 2019 um 04:39 Uhr schrieb Leif Rasmussen <
> 354...@gmail.com>:
>
> if both can stop, it is not a tourist bus stop but a regular bus stop
> where coaches can stop. I have difficulties imagining it, but I would not
> exclude the possibility.
>

I'm glad you wouldn't exclude the possibility.  There is a bus stop like
that in my town.  Occasionally
tourist buses stop there to allow passengers to board so they can go on
holiday.  As it happens,
the same company that runs the public buses around here also has a tourist
operation which
takes people in the area on holidays, tours, etc.


> Usually these tourist bus stops are set up in areas with a lot of traffic
> and few parking space, in these settings you would not want tourist busses
> to block pt bus stops, the setting where it would be imaginable are low
> density places where it doesn't matter anyway where you stop (no problem,
> next bus in 4 hours).
>

Ummm, the one here is on what is effectively the high street (and used to
be named that
many, many years ago).  Several different hourly services stop there.  It's
actually a long
"platform," long enough that two buses can stop there at once, which
sometimes happens if one
is running a little late.  So there's enough room for an ordinary bus and a
tourist bus.

The other place tourist buses stop is a public car park.  Fortunately the
annual fair (with
mobile fairground rides) that takes over the car park a few days a year
does so in November
when there aren't as many people wanting to travel.

In other places I've lived, tourist and long-distance buses shared a bus
station with ordinary
buses.

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

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Paul Allen]

On Wed, 11 Sep 2019 at 13:35, Martin Koppenhoefer 
wrote:

>
> great. Typical issues one would expect are properties associated with the
> "wrong" object though, and looking at the example, it seems here is such an
> issue with the "canonization status"=catholic saint. Why do the individual
> saints not have the property, but the group has it?
>

This will come as a shock and a surprise to people on this list, but some
open-source
projects become obsessive about an overly-rigid interpretation of rules.
In this case it is
that if there is a property shared by all members of a group then it MUST
be marked on
the group ALONE and not also on individual members.  It doesn't matter that
users would
find it far more useful to be able to see that an individual saint is
canonized, those users
MUST be savvy enough about Wikipedia rules to know that they should then
look at the
parent group in order to get all the information they wish.  DRY (don't
repeat yourself)
is rigidly enforced.

Yes, I've been bitten by this before.  Marking up Wikimedia images as being
listed
buildings.  All went fine until I happened to mark a few that were
collected in a group
of "Listed buildings in ."  Those changes were reverted because
the
grouping itself was flagged as being of listed buildings.  It matters not
that when
individual buildings are tagged the tag includes the listed building ID,
which links
to an external page describing the building and its reason for listing,
whilst the
collective tag cannot have that information.  It matters not that if you
look at non-grouped
listed buildings you see clearly that they are listed buildings but if you
look at
grouped listed buildings you have no idea that they are listed.  DRY.
Rules is
rules.

Anyone who thinks the preceding paragraph is off-topic because it's about
Wikimedia should try to recall all the times on this list when somebody has
insisted that rules is rules, even when the outcome of following those
rules is sub-optimal.

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

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Janko Mihelić]

sri, 11. ruj 2019. u 14:35 Martin Koppenhoefer 
napisao je:

> Why do the individual saints not have the property, but the group has it?
>

 I'm suspecting it's "tagging for the renderer". They probably have
infoboxes in the Wikipedia article, and they would like that box to show
"saint". That should be fixed if a smarter infobox comes, which would show
two boxes, or something like that. But there is nothing stopping you to add
all the right properties to the two individual saints.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Janko Mihelić]

sri, 11. ruj 2019. u 14:34 Joseph Eisenberg 
napisao je:

> Doesn't this mean that it would be better to create separate Wikidata
> items for each separate OSM feature, rather than creating a new OSM
> tag?
>

You have examples like tagging all ways that are a part of a street with
the wikidata item about that street. You can't define those parts in
Wikidata.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Martin Koppenhoefer]

Am Mi., 11. Sept. 2019 um 14:22 Uhr schrieb Janko Mihelić :

> sri, 11. ruj 2019. u 13:04 Martin Koppenhoefer 
> napisao je:
>
>> One problem is that wikidata does not allow to have the same wikipedia
>> article for several wikidata objects.
>>
>
> Yes it does. Look at this object:
>
> https://www.wikidata.org/wiki/Q23837517
>
> Its about one saint, Constantia, who was always mentioned together with
> Felix, her saint brother. She has no wikipedia articles about her, only
> about them both:
>
> https://en.wikipedia.org/wiki/Felix_and_Constantia
>
> and so there is a wikidata item about them both, and it has a property
> "has part" which has values of Constantia and Felix objects. Constantia and
> Felix have a property "part of".
>


great. Typical issues one would expect are properties associated with the
"wrong" object though, and looking at the example, it seems here is such an
issue with the "canonization status"=catholic saint. Why do the individual
saints not have the property, but the group has it?

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

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Joseph Eisenberg]

"and so there is a wikidata item about them both, and it has a
property "has part" which has values of Constantia and Felix objects.
Constantia and Felix have a property "part of"."

Doesn't this mean that it would be better to create separate Wikidata
items for each separate OSM feature, rather than creating a new OSM
tag?

On 9/11/19, Janko Mihelić  wrote:
> sri, 11. ruj 2019. u 13:04 Martin Koppenhoefer 
> napisao je:
>
>> One problem is that wikidata does not allow to have the same wikipedia
>> article for several wikidata objects.
>>
>
> Yes it does. Look at this object:
>
> https://www.wikidata.org/wiki/Q23837517
>
> Its about one saint, Constantia, who was always mentioned together with
> Felix, her saint brother. She has no wikipedia articles about her, only
> about them both:
>
> https://en.wikipedia.org/wiki/Felix_and_Constantia
>
> and so there is a wikidata item about them both, and it has a property "has
> part" which has values of Constantia and Felix objects. Constantia and
> Felix have a property "part of".
>
> So in some cases we can divide the wikidata object if it helps with
> identifying the OSM object. But again, I'm not sure this is the case with
> Malta, because the article is about the state, and the city is "inside" the
> state. When you reference the state, you imply the city inside it. Felix
> and Constantia are totally separate entities, and you don't imply one when
> you reference the other.
>
> Janko
>

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

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Janko Mihelić]

sri, 11. ruj 2019. u 13:04 Martin Koppenhoefer 
napisao je:

> One problem is that wikidata does not allow to have the same wikipedia
> article for several wikidata objects.
>

Yes it does. Look at this object:

https://www.wikidata.org/wiki/Q23837517

Its about one saint, Constantia, who was always mentioned together with
Felix, her saint brother. She has no wikipedia articles about her, only
about them both:

https://en.wikipedia.org/wiki/Felix_and_Constantia

and so there is a wikidata item about them both, and it has a property "has
part" which has values of Constantia and Felix objects. Constantia and
Felix have a property "part of".

So in some cases we can divide the wikidata object if it helps with
identifying the OSM object. But again, I'm not sure this is the case with
Malta, because the article is about the state, and the city is "inside" the
state. When you reference the state, you imply the city inside it. Felix
and Constantia are totally separate entities, and you don't imply one when
you reference the other.

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

Re: [Tagging] Feature Proposal - RFC - appointment

[Simon Poole]

Am 10.09.2019 um 10:00 schrieb Martin Koppenhoefer:
>
>
> sent from a phone
>
> On 8. Sep 2019, at 22:11, Simon Poole  > wrote:
>
>> Isn't this semantically in the end not the same as "unknown" (as in any
>> application would have to equate this to  "you have to inquire if it is
>> open")?
>
>
> it may be the same for apps, it isn’t for mappers, “unknown” is an
> imperative for surveying it.

This is -not- supported by the existing documentation
https://wiki.openstreetmap.org/wiki/Key:opening_hours#Summary_syntax


> It may also make a difference for some searching for such features,
> because unknown means you might be lucky and they’ll serve you, by
> appointment means you must not even try if they might be open.
>
That on the other hand might be a useful distinction.

Simon


> I welcome documenting this value, as it is already used with varying
> syntax more than 500 times, so it is clear mappers want
> it: https://taginfo.openstreetmap.org/keys/opening_hours#values
>
> Cheers Martin 
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


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

Re: [Tagging] Feature Proposal - RFC - appointment

[Martin Koppenhoefer]

I would use the "phone" key rather than mixing phone numbers in the opening
hours value. If there are several phone numbers and one is dedicated for
making appointments, it could be a phone subtag like phone:appointments=###

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

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Martin Koppenhoefer]

Am Di., 10. Sept. 2019 um 13:54 Uhr schrieb Janko Mihelić :

> Then in OSM city and city-state are different things. In Wikidata we only
> have an article about the city-state. This article also talks about the
> city, but the overall theme is the city-state. That means, only the
> admin_level=2 should get the wikidata tag. If we tagged everything that the
> article describes, we could tag every entity inside the relation
> (Monaco-Ville, formula race track, the port) with wikidata=Q235, and that
> makes no sense. We only tag the one entity that best points to the subject
> of the article.
>
> If that is not possible, use part:wikidata=*.
>


One problem is that wikidata does not allow to have the same wikipedia
article for several wikidata objects. This dependency makes it difficult to
split wikidata objects into fainer grained objects. Maybe in cases like
these, I would have to split the wikidata object in 3: one combining object
that is linked to the article and different objects for the city and the
state?

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

Re: [Tagging] Open Defecation Areas

[Warin]

On 11/09/19 15:47, Mateusz Konieczny wrote:




11 Sep 2019, 01:54 by pla16...@gmail.com:

On Tue, 10 Sep 2019 at 23:41, Graeme Fitzpatrick
mailto:graemefi...@gmail.com>> wrote:


Would it need a multipolygon? My impression of the ODA is an
open patch of ground in / beside a residential area. If that
is the case, wouldn't it be much simpler to just mark a new
area in as landuse=o_d_a? (accept it wouldn't be abbreviated)


Overlapping landuse often works, but only because the carto people
juggle z-indexes
to make it work.  They're not overly happy doing that, I believe.

well, reality is that sometimes area
is actually both tree-covered area and
for example university or residential area.


Trees are a land cover, not necessarily a land use.

Universities and residential areas are a land use.


It also doesn't always
work well: if ever you've put a pond in a wood without a
multipolygon you get
waterlogged trees.

this is intentional to encourage correct
mapping of tree-covered areas.


I wish there was more rendering that showed errors.


  It also makes database queries somewhat more simpler if you're
asking what is at point A and you get one answer rather than two
answers, or one of
two answers chosen at random.

note that in many cases getting two
answers correctly represents reality

Or even 3..
Land cover e.g sand
Land use and e.g. quarry
Land form e.g. dune



  A multipolygon is a little more work for the mapper,
but not much more.

Now I expect both the carto and db people to tell me I'm wrong
about that.  If they do,
I'll just point out that it's not wrong to use a multipolygon for this

and in even more cases multipolygon
should be used


Many people have problems with multipolygon relations..
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tourist bus stop

[Martin Koppenhoefer]

Am Mi., 11. Sept. 2019 um 04:39 Uhr schrieb Leif Rasmussen <354...@gmail.com
>:

> My main concern is that some bus stops could be both for tourist buses and
> for public buses. Using ptv2 instead, with public_transport=platform +
> coach=designated or tourist_bus=designated would be easier.
>


if both can stop, it is not a tourist bus stop but a regular bus stop where
coaches can stop. I have difficulties imagining it, but I would not exclude
the possibility. Usually these tourist bus stops are set up in areas with a
lot of traffic and few parking space, in these settings you would not want
tourist busses to block pt bus stops, the setting where it would be
imaginable are low density places where it doesn't matter anyway where you
stop (no problem, next bus in 4 hours). For these cases, it could be a
property for highway=bus_stop (e.g. tourist_bus=yes / boarding(?))

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

Re: [Tagging] Tourist bus stop

[Martin Koppenhoefer]

Am Mi., 11. Sept. 2019 um 02:35 Uhr schrieb Joseph Eisenberg <
joseph.eisenb...@gmail.com>:

> Thank you for making a proposal, Francesco.
>
> “A tourist bus stop is a stop reserved to tourist buses.”
>
> The main issue is describing the term “tourist bus” clearly.
>
> The related wiki page Key:tourist_bus says:
>
> “The key tourist_bus=* is used to tag legal access restrictions on roads
> for buses that are not acting as public transport vehicle (for the latter
> see bus =*).”
>
> “This tag originated from a literal translation of the Italian word Autobus
> turistici[1]
> , which
> can be understood to be synonymous to a coach.”
>
> https://wiki.openstreetmap.org/wiki/Key:tourist_bus
>
> So is “tourist_bus=yes” identical to “coach=yes”?
>
> Does this include “minibuses” and large “vans” used as vehicles for hire?
>
>

the details may depend on the legislation in the country. Technically, in
many countries a bus is a vehicle where more than 8 people can be
transported. According to the access definition of tourist bus it would
depend on this. (By the way: when the tourist bus tag was invented it
should have become "motor_bus" instead, would have been more consistent and
understandable).

For the boarding area that is proposed here, I am not sure whether vehicles
smaller as coaches, which are used for the same purpose, are allowed to
stop there, but the idea is to have a boarding area which is not the same
as for the regular transport, so if minibusses and vans are part of the
regular (even informal) transport of your area, and they can only stop at
designated bus stops (or minibus stops), then this tag might exclude them
(maybe, what would you suggest? In Italy there is no such network of vans
and minibusses, and while I have used these in other countries, I didn't
completely understand how they were organized and what their legal status
was).



> I assume it excludes intercity buses or buses to national parks, if they
> run on a regular schedule and sell tickets to the general public?
>


it may be up to the local conditions/customs. Think about theses places as
an area where the bus can only stop to board or unboard people, they may
not stay longer, and where public transport does not stop.

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

Re: [Tagging] Draft proposal for Key:aerodrome

[Martin Koppenhoefer]

I believe we should tag passenger numbers a year. We would not have to tag
all airports with this, especially for small airports these might be hard
to get, and we do not necessarily need up to date numbers, just a number of
one of the past years. This will usually be available for the big airports
and the presence of the information (and a reasonable threshold) would make
it possible to show the significant airports much earlier while those with
low or no numbers could be de-emphasized. I'm sure it would give a fairly
good indication of importance.

I'm not completely opposed to different main airport types (military,
scheduled commercial passenger flights, ...), but from the mentioned there
are known problems, e.g. "international" has been subject to former
criticism, because it is not clear in meaning and not suitable for
distinction: for example an airport in Germany which has flights to
Germany, Switzerland and Austria is a whole different kind of airport than
one that offers flights to Hongkong, Houston and Harare.

Because there will often be combinations (e.g. military part of a general
aviation airport, or a part for small private planes, etc.) I agree we
should better capture the details with several tags for well defined
properties as suggested by Christoph.

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

Re: [Tagging] Feature Proposal - RFC - Campsite properties

[Sven Geggus]

Joseph Eisenberg  wrote:

> (While I wouldn't have picked the key "permanent_camping" myself if
> it's only on a seasonal or annual basis, I think it's probably fine,
> and I can't think of a better English term.)

I can not talk for other countries, but in Germany this setting is
definitely *permanent* in a way that people typically have their caravans on
the same pitch for years.  Its only the fee which is charged on a seasonal
or annual basis.

Sven

-- 
"Thinking of using NT for your critical apps?
  Isn't there enough suffering in the world?"
   (Advertisement of Sun Microsystems in Wall Street Journal)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [Tagging] Draft proposal for Key:aerodrome

[Colin Smale]

On 2019-09-11 09:05, Graeme Fitzpatrick wrote:

> On Tue, 10 Sep 2019 at 20:24, Andy Townsend  wrote: 
> 
>> That seems like a bad idea because aerodrome:type is one of the ways 
>> that mappers distinguish between military and non-military airfields.
> 
> We have at least 3 aerodromes that I know of (& I know there are others 
> worldwide) where a common runway is shared between an Air Force base on one 
> side, & a civilian airport on the other.

We should seperate physical characteristics (it's a runway) from
facilities provided (customs?) and usage modes (civilian and military)
and other non-mutually-exclusive dimensions. This discussion is all
about how people want to try to map an enormous number of combinations
of different aspects onto a very limited set of categories and expect it
to suit every case. It never will. We map the physical, verifiable
aspects, and not subjective data. A few people arguing not about the
objective characteristics, but about what THEY would call it in their
culture/experience, is not the best use of everyone's time. The
renderer/data consumer should be able to decide which airports to give
prominence to; we should provide the data they need to make that
judgement. If a map wants to consider all airports with a runway of at
least 3000m, an IATA code and customs facilities as "international", we
facilitate that by tagging runway length, IATA code and the presence of
customs as discrete characteristics. That's the only way to stop these
endless circular discussions which never reach real consensus anyway,
and can be considered to be "tagging for the renderer" as the tagging is
being designed to produce a particular outcome.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Draft proposal for Key:aerodrome

[Graeme Fitzpatrick]

On Tue, 10 Sep 2019 at 17:37, Joseph Eisenberg 
wrote:

> I've started a new proposal for Key:aerodrome.
>
> See https://wiki.openstreetmap.org/wiki/Proposed_features/Key:aerodrome
>
> This proposal uses aerodrome=* for classification of an
> aeroway=aerodrome as an international airport, other commercial
> airport, general aviation aerodrome, private aerodrome, or airstrip.
>
> It would deprecate aeroway=airstrip and aerodrome:type=*
>
> Values to be approved:
> * aerodrome=international - already common
> * aerodrome=commercial  - new tag
> * aerodrome=general_aviation  - new tag (default type)
> * aerodrome=private  - already common
> * aerodrome=airstrip
>

Our local airport has international, domestic, cargo, general, private,
tourist, flying school, skydiving & helicopter operations!

Which should it be?

Thanks

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

Re: [Tagging] Draft proposal for Key:aerodrome

[Graeme Fitzpatrick]

On Tue, 10 Sep 2019 at 20:24, Andy Townsend  wrote:

>
> That seems like a bad idea because aerodrome:type is one of the ways
> that mappers distinguish between military and non-military airfields.
>

We have at least 3 aerodromes that I know of (& I know there are others
worldwide) where a common runway is shared between an Air Force base on one
side, & a civilian airport on the other.

How to map those?

Thanks

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