Re: [Tagging] [RFC] Feature Proposal - Cell Phone Reception

[Phake Nick]

There's already services offered by companies like Opensignal to do this
automatically through apps. And they record actual signal strength data
that one cannot access by simply pulling their phones out.
Also, signal strength as a value that vary continuously over space is like
elevation or climate data, there are no good way to record them inside OSM
over an area.

在 2023年8月7日週一 08:58，Mike Thompson  寫道：

>
>
> On Sun, Aug 6, 2023 at 6:39 PM Evan Carroll  wrote:
>
>>
>>
>> While I don't disagree, that's not an argument for OSM. OSM's job isn't
>> to mitigate real world safety issues caused by technology. It's to map
>> generally useful geographically verifiable things.
>>
> I don't understand how cell coverage isn't verifiable - visit the site
> (e.g. campground) in question, pull out your phone, note how many bars, try
> to make a call, send a text, use some data (perhaps run a speed test). Yes,
> it is only good for your carrier, but the carrier should be recorded. Yes,
> there could be network congestion, or a tower could be out, but we map
> roads, and they can be congested, or closed due to accidents, flooding,
> landslides, construction, etc.  In some way, this is getting back to our
> roots, actually getting out and surveying, rather than just relying on
> satellite/aerial imagery.
>
> Mike
> ___
> 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] RFC: vaccination / COVID-19 vaccination centres

[Phake Nick]

I think it depends on where yoj exactly are at, in Hong Kong the government
established a few dozens indoor testing spots, tested a million people and
a half, and then shutting down the facility knowing its positive rate isn't
high.

在 2020年11月27日週五 01:25，Brian M. Sperlongano  寫道：

> This [1] testing site in my state opened back in July (five months ago)
> and is dedicated to COVID testing only.
> These sites[2] opened in May (seven months ago) and are still going
> strong.  They are co-located with a pharmacy (usually in the parking lot).
>
> While they may be "temporary" as in "when the pandemic is over, they will
> be disassembled and the area will revert to its natural state", we are
> already hitting the six month threshold that is usually offered as the
> minimum standard for permanence.  If anyone thinks they know how long these
> will be here, they are frankly just guessing.  These places are useful to
> tag, and they could be here for...months? a year or more?
>
> It's anybody's guess as to whether vaccination centers will follow a
> similar pattern as testing, but it is reasonable to figure out now, while
> the issue is topical, how such a thing should be tagged given the potential
> for a sufficient level of permanence.  Anti-vaccine sentiment is a real
> thing in the United States, and there is every reason to believe that a
> mass vaccination will start slowly and take months or more, and not just a
> few weeks as has been suggested.
>
> [1]
> https://www.providencejournal.com/story/news/coronavirus/2020/07/21/new-drive-up-coronavirus-test-site-opens-at-ri-convention-center/42521793/
> [2]
> https://www.providencejournal.com/news/20200528/cvs-to-open-10-new-coronavirus-testing-sites-in-ri
>
> On Thu, Nov 26, 2020 at 9:59 AM Paul Allen  wrote:
>
>> On Thu, 26 Nov 2020 at 02:35, stevea  wrote:
>>
>>> I'm in California, where it's almost cliché we love our cars and car
>>> culture, but it is true that not only here but in many USA states, we have
>>> "drive-thru" COVID-19 testing centers.
>>
>>
>> In the UK we don't have much of a drive-thru anything except maybe some
>> fast-food outlets of American origin.  Yet all the covid-19 testing
>> centres I'm
>> aware of are strictly drive-thru.  As in you're not allowed to turn up on
>> foot,
>> because if you're infected you may pass it on to other pedestrians you
>> walk
>> near.  And they're drive-thru because the swabs are taken in the open.
>> The swabs are taken in the open because there is far less risk of
>> transmission outdoors than indoors.
>>
>>
>>>   I would guess that vaccination centers that are also "drive-thru" are
>>> likely soon (early 2021?), too.
>>
>>
>> The same reasons that make the test centres drive-thru apply to
>> vaccination centres.  Eventually, when we have herd immunity
>> (one way or another) indoor vaccination may be feasible (but
>> probably undesirable).  The health workers will be vaccinated
>> first so they won't be at risk either way, but these places will
>> be handling large numbers of people and having them all wait
>> indoors is a good way of infecting lots of people.
>>
>>
>>>   These being mapped with "indefinite duration" seems a bit much (sorry,
>>> Brian), but they are usually more of a "pop-up" kind of thing:  one-time or
>>> "only on Saturdays" or something like that.
>>
>>
>> There is a temporary, short-duration, won't be there for long, test
>> centre just
>> popped up in my town because a couple of weeks ago some idiots decided
>> to celebrate the end of firebreak restrictions by going to the pubs and
>> ignoring social distancing completely.  Fifty-five cases came of that, and
>> three hundred contacts have been traced.  I expect it to go away in a few
>> weeks if the outbreak gets under control.  I'm not confident the outbreak
>> will be under control very soon because a lot of the celebrants were
>> shop workers.
>>
>> But as well as that pop-up test centre because of the sudden surge, there
>> is an existing test centre.  That's based at the leisure centre that was
>> converted to an emergency overflow hospital several months ago. I only
>> found out the test centre was there a few days ago because we try to
>> keep their locations secret, so I probably won't map it.
>>
>> Vaccination centres are going to handle more people than test centres
>> do because nearly the entire population will have to be vaccinated but
>> only a very small fraction of the population is tested (we ought to be
>> testing everyone at least once a week, but my country's government
>> is somewhat incompetent).
>>
>> --
>> 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
>
___
Tagging mailing list

Re: [Tagging] RFC: vaccination / COVID-19 vaccination centres

[Phake Nick]

I don't thibk it is appropriate to add one-off temporary facilities into
OSM.

在 2020年11月25日週三 01:30，Tom Pfeifer  寫道：

> Following the discussion on how to tag COVID-19 vaccination centres
> previously on this list,
> I have created a proposal for the vaccination key:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/vaccination
>
> tom
>
> ___
> 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] Extremely long Amtrak route relations / coastline v. water

[Phake Nick]

Excuse me, what is the limitation here against tagging "Extremely long
Amtrak relations"? Some of those Amtrak services, while long, in my
knowledge are still far from the longest in the OSM database, like they're
shorter than the train route between Moscow to Pyongyang, which have been
tagged as a regular relationship with no observable problem to me.
In my opinion, since these long Amtrak service are still just a single
services, with no break or cha.ge of train or change of train number
in-between, it seems outright bogus to tag them separately, and would
confuse anyway who wish to use OSM data to provide navigation involving
such train routes.

在 2020年11月22日週日 19:29，Richard Fairhurst  寫道：

> [cross-posted to talk-us@ and tagging@, please choose your follow-ups
> wisely]
>
> Brian M. Sperlongano wrote:
> > It seems that we are increasingly doing things to simplify the
> > model because certain tooling can't handle the real level of
> > complexity that exists in the real world.  I'm in favor of fixing
> > the tooling rather than neutering the data.
>
> I sincerely hope "I'm in favor of fixing" translates as "I'm planning to
> fix", though I fear I may be disappointed.
>
> More broadly, we need to nip this "oh just fix the tools" stuff in the
> bud.
>
> OSM optimises for the mapper, because mappers are our most valuable
> resource. That's how it's always been and that's how it should be.
>
> But that does not mean that volunteer tool authors should rewrite their
> tools to cope with the 0.1% case; nor that it is reasonable for mappers to
> make stuff ever more complex and expect developers to automatically fall in
> line; nor that any given map has a obligation to render this 0.1%, or
> indeed, anything that the map's creator doesn't want to render.
>
> The Tongass National Forest is not "in the real world", it is an
> artificial administrative construct drawn up on some bureaucrat's desk.
> It's not an actual forest where the boundaries represent a single
> contiguous mass of trees. Nothing is lost or "neutered" by mapping it as
> several relations (with a super-relation for completeness if you insist),
> just as nothing is lost by tagging Chesapeake Bay with the series of
> letters "c","o","a","s","t","l","i","n" and "e".
>
> Richard
> ___
> 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] Update - RFC - Special Economic Zones

[Phake Nick]

How do you identify different types of soecial ecobomic zones? For exmaple,
in China, you have Hainan, which is a special economic zone for tourism,
you have Shenzhen, which is for policy innivation, you have Tianjin Binhai
new area, which is for logistics, you have a Cloud computing special
management district in Chongqing for internet, you have Shanghai Waigaoqiao
free trade zone for tax, you have Pingtan comprehensive experiment zone for
cooperation with Taiwan, and then you also have Qianhai Special economic
zone which is a service and industry themed zone within the special
economic zone of Shenzhen.

Which of them should/shouldnt be tagged as special ecobomic zone? How to
differentiate between them?

在 2020年11月3日週二 11:55，Brian M. Sperlongano  寫道：

> Folks:
>
> Last week I opened an RFC for the proposed new tag
> boundary=special_economic_zone.  That announcement generated only minimal
> discussion, resulting in a minor change to the proposal to address the
> concern raised.  I am sending this update to ensure that the community has
> adequate opportunity to provide input.  If no significant comments are
> received, I intend to proceed to a vote starting on 9 Nov, after the
> two-week minimum comment period has elapsed.
>
> Proposal:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Special_economic_zone
> ___
> 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 - parking=street_side

[Phake Nick]

See "Parking-Protected Bike Lanes | The City of Portland, Oregon":
https://www.portlandoregon.gov/transportation/77882

在 2020年10月27日週二 01:45，Supaplex  寫道：

> Do you have an example picture/mapillary or similar of such a street? You
> call this case yourself "parking lane" and the way you describe it, it
> sounds like a typical case for parking:lane:* =
> parallel/diagonal/perpendicular, but not for
> parking:lane:*/parking=street_side. "street_side" is intended for cases
> where the parking spaces are structurally (especially structured by curbs)
> located on one side of the carriageway. (That means, if - hypothetically -
> no vehicles were parked there, you could still not drive there because curb
> extensions or street furniture would block a continuous drive.)
>
> A cycleway located behind this parking area is no longer part of the
> roadway and would therefore not be "lane" but "track". But maybe I
> misinterpreted the case you meant?
>
>
> Am 26.10.20 um 15:49 schrieb Paul Johnson:
>
> On Sat, Oct 24, 2020 at 6:40 AM Supaplex  
>  wrote:
>
>
> Hey all,
>
> I would like to invite you to discuss a proposal for "parking =
> street_side" for areas suitable or designated for parking, which are
> directly adjacent to the carriageway of a road and can be reached directly
> from the roadway without having to use an access 
> way:https://wiki.openstreetmap.org/wiki/Proposed_features/parking%3Dstreet_side
>
> The proposed tagging can be used on separate parking areas as well as with
> the parking:lane-scheme. It aims not only to differentiate such
> street-accompanying parking areas from others, especially
> "parking=surface", but also addresses a contradiction in the current use of
> the amenity=parking and parking:lane-scheme, which I would like to mention
> briefly at this point: the use of "layby"/"lay_by".
>
> The value "layby" was originally intended for forms of resting places, as
> they seem to be especially common in rural areas of Great Britain, Ireland
> or the US: short-stop rest-areas along through-traffic roads intended for
> breaks during a car-trip (see Wikipedia for a 
> definition:https://en.wikipedia.org/wiki/Rest_area#Lay-bys). On areas with
> "amenity=parking" this key is also used in this sense (and mostly in Great
> Britain).
>
> Within the parking:lane-schema, however, the value "lay_by" (written with
> an underscore) has gained acceptance. According to the Wiki, this value is
> defined identically to the layby's mentioned above. Its actual use,
> however, differs from this and includes mainly street-side parking, as we
> address them in our proposal.
>
>
> How does this work out when the parking lane is not the curb lane?  This
> arrangement is increasingly common in North America, where the parking
> isn't at the side of the road, one or more bicycle lanes are.
>
>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://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 - Artificial

[Phake Nick]

在 2020年10月21日週三 17:37，Oliver Simmons  寫道：

> Agreed, if we are doing this once, we better have a way to do it again as
> doing it once guarantees that it will happen for another tag in the future.
>
>
>
> Changing in inside OSM and the OSM Wiki is the easier part though, it’s
> informing and getting all of the software to recognise the new tag
> (preferably both as the old tag will still remain on old stuff).
>
> Older software is the issue as getting that to be updated is near
> impossible.
>
> There are *tons* of styles and software e.t.c. that are going to break
>
>
>
> *From: *Colin Smale 
> *Sent: *21 October 2020 10:25
> *To: *tagging@openstreetmap.org
> *Subject: *Re: [Tagging] Feature Proposal - RFC - Artificial
>
>
>
> On 2020-10-21 10:59, Robert Delmenico wrote:
>
> I'll do some more research before the vote goes ahead. I've read quite a
> bit of research around gendered language since first mentioning this idea.
>
>
>
> I'll be sure to list them in the proposal but feel free to send through
> any sources that are both for and against the arguments I have raised. I'm
> thinking that I'll mention the arguments both for and against on the
> proposal page as this is a big proposal which if it succeeds will have a
> big impact.
>
>
>
> If anyone has any arguments for or against that they wish to have included
> in the proposal, please feel free to leave them on the talk page for the
> proposal.
>
>
>
> If this goes through, it will be traumatic, however you look at it. Do you
> have any suggestions how to abstract this specific example into a more
> generic process to a) review all tags currently in the database; b) all
> wiki content suggesting tagging; and c) all future proposals, to assess
> their appropriateness in the current and likely future environment?
>
>
>
> I don't mean to be flippant - this is a serious suggestion. If we are
> going to have this kind of discussion around any graphology incorporating
> "possibly offensive" groups of letters we had better have a proper policy
> in place and a well-oiled process to deal with it.
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


Given the history of language evolution, people keep adopting different
terms for discriminatory use and thus what uacceptable vs what is not will
always be changing. And since it is almost possible to predict what term in
the future will be used by duscriminators, it is basically impossible to
guarantee it will happen again. The best we can do is to minimize such
chance and hope next time it happens will be more than a millennium from
now.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Artificial

[Phake Nick]

在 2020年10月21日週三 15:46，Rory McCann  寫道：

> (I broke my collarbone, so I'm typing one handed and can mistype)
>
> On Wed, 21 Oct 2020, at 9:39 AM, Rory McCann wrote:
> > On Wed, 21 Oct 2020, at 6:25 AM, Mateusz Konieczny via Tagging wrote:
> > > (1) I never understood "man made" as
> > > "made by males".
> > > (4) I would prefer to not use OSM as a tool
> > > to change language, especially if done at
> > > cost of making more complicated for
> > > mappers. AFAIK term "man made" and it's
> > > meaning remains standard and is well
> > > understood
> > >
> > > Disclaimer: not a native speaker.
> > > (1) and (4) may be wrong.
> >
> It's interesting how non-native speakers of English often speak a
> quaint old fashioned version of English. Languages are often chamging
> and ir can take a little while for books, courses and teachers to catch up.
>
> So you'll hear non-natives use words like "whom" or using "he" to refer to
> generic people of any gender. It always sounds old-fashioned. 
>
> OSM prioritizes local knowledge, by the same logic non-native speakers of
> English should defer to native English speakers for the meaning of words.
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


My understanding is that OSM explicitly follow UK English, although I don't
know if it follow any specific dialect, accent or speech

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

Re: [Tagging] Proposal to change key:man_made to key:human_made

[Phake Nick]

在 2020年10月21日週三 03:25，Justin Tracey  寫道：

> On 2020-10-20 12:13 p.m., Matthew Woehlke wrote:
> >> If core aspects of the tagging schema give hints at a bias
> >> towards a particular segment of the population (in this case,
> >> English-speaking men)
> >
> > So, clearly, we need to change the language of OSM tags to loglan. Oh,
> > wait, that would *still* be biased.
>
> Correct. All the more reason to discuss how these biases manifest! :)
>


At this point it's clear enough OP is just trolling?

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

Re: [Tagging] Proposal to change key:man_made to key:human_made

[Phake Nick]

I feel like it is a cherry-picked list of comment.

在 2020年10月19日週一 22:42，Robert Delmenico  寫道：

>
> I originally put the call out really to gauge if there was much interest
> in changing the term man_made because of its use of 'man', and was
> interested in hearing the thoughts from other mappers as really this
> proposal isn't just mine. If there was no interest I would just abandon it
> and move on - that's how the system works yeah?
>
> Here's my thoughts based on the feedback received so far
>
> Regardless of the origin of the term, the current use of 'man' is to
> identify adult males.
>
> I don't think the use of 'man_made' offends women, but who am I to decide
> that as I am a adult male.
>
> I feel that by using any masculine or feminine terms where a suitable
> alternative exists instills the stereotypes based on these terms.
>
> We don't refer to firefigters as firemen anymore, not do we refer to
> airline attendants as airline hostesses. The world is changing and OSM
> should adapt to these changes if there is enough interest from the OSM
> community.
>
> I am open to alternatives and have been paying close attention to the
> feedback this far.
>
> I think artificial is a better term than man_made and human_made but there
> may be another better term out there.
>
> Dave F raises a good point though. Rather than seeing this as a gender
> issue, perhaps we should see it as the opposite of natural - because
> broadly speaking things are either natural or artificial. I see this in the
> sense of artificial, these would be considered things developed or created
> by humans.
>
> Sure it's a huge task, but regardless of the amount of tags to change I
> feel the change is needed. Perhaps there needs to be a way to implement a
> way to change a tag in bulk without affecting the date of the changeset,
> and with OSMF board approval if it affects more than 100,000 tags for
> example.
>
> There are a few ways to go from here:
> 1: change man_made to human_made
> 2: change man_made to artificial
> 3: change man_made to some other term
> 4: leave man_made as is
>
> I'm certainly leaning towards the second option.
>
> I feel that the public vote by the wiki will be an interesting exercise
> and I am glad that I have started this discussion.
>
> If the OSM community decides to stick with man_made I'm fine with that -
> even if I feel that there could be a better term out there to define these
> objects.
>
> Look forward to further discussion on this topic and I appreciate all
> feedback given thus far - being both for and against.
>
> Kind regards,
>
>
> Rob
>
> On Tue, 20 Oct 2020, 1:02 am Paul Allen,  wrote:
>
>> On Mon, 19 Oct 2020 at 14:04, Dave F via Tagging <
>> tagging@openstreetmap.org> wrote:
>>
>> I mean, *everything* is either man made or natural.
>>>
>>
>> Unless you want to argue that humans are supernatural or unnatural,
>> humans are natural.  Therefore anything humans make is natural,
>> just as beaver dams and wasps' nests are natural.
>>
>> If you wish to argue that humans are a special exception then
>> everything we make is man_made, so buildings, bridges, parks,
>> gardens, etc. is man_made.
>>
>> OSM tagging is not a good candidate for cladistic taxonomy.  There
>> is too much multiple inheritance to even consider that type of
>> taxonomy.  Houses are buildings, which are man-made, houses
>> have walls and walls are built, so man_made=house and building=wall
>> Except humans build walls, so man_made=wall.
>>
>>
>>>   We really should come up with more specific, accurate key tags.
>>>
>>
>> Perhaps in some cases.  Where such need arises it happens, such as
>> with healthcare.
>>
>> On balance, moving to human_made or artificial is a lot of pain without
>> any gain whatsoever with regard to map accuracy in order to appease
>> the feelings of those who do not understand etymology.  Are we
>> to next propose persontoric=* because those who do not understand
>> etymology object to a supposed gender bias in "historic"?
>>
>> That the proposer profusely thanks those who put forward
>> arguments against the change whilst apparently ignoring
>> those arguments does nothing to persuade me of the
>> merits of his/her case.  It smacks of the so-called
>> "non-confrontational" tactics that might better be
>> called "passive confrontational."
>>
>> --
>> 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Proposal to change key:man_made to key:human_made

[Phake Nick]

Breaking change come with a cost.
Whether it is worth is a question should be asked.

在 2020年10月19日週一 21:04，Dave F via Tagging  寫道：

> Irrelevant of any implied meaning, 'man_made' always appeared to be a
> clunky, catch-all tag. OSM was being a bit lazy.
> I mean, *everything* is either man made or natural.  We really should come
> up with more specific, accurate key tags.
>
> DaveF
>
> On 19/10/2020 12:45, Jo wrote:
>
> It would be best to first consider the consequences of such a change.
> Weigh the benefits against what we lose in time (humanhours?) and
> resources/energy. And then there is still the point that many objects will
> get new timestamps for a change that's not really a change.
>
> Anyway, artificial sounds like made up to me. artificial=dyke, not really
> a dyke, but it looks like it.
>
> man_made has the advantage of being succinct. Most people will immediately
> understand what is meant by it. Almost nobody will think women were not
> involved in the creation of the feature.
>
> Polyglot
>
> On Mon, Oct 19, 2020 at 12:42 PM Robert Delmenico 
> wrote:
>
>> Nice investigating Nathan,
>>
>> I would be open to using artificial instead of human_made.
>>
>>
>> Would it be best to change the proposal or start a second proposal?
>> Change man_made= to artificial=
>>
>> Rob
>>
>>
>> On Mon, 19 Oct 2020 at 21:14, nathan case  wrote:
>>
>>> Pros and cons aside, “human-made” is not a term that is in current
>>> widespread usage. As a native English GB speaker, I find it clunky and
>>> somewhat distracting.
>>>
>>> A better gender neutral term might be “artificial”, which is already a
>>> synonym for “man-made” and is already widely used.
>>>
>>> Indeed, the Handbook of Nonsexist Writing suggests: "artificial,
>>> handmade, hand-built, synthetic, manufactured, fabricated, machine-made,
>>> and constructed" as options instead of man-made. Presumably the majority
>>> (if not all) of OSM "man-made" tags relate to objects which are not
>>> naturally occurring. Therefore "artificial" seems to hold.
>>>
>>> Other sources:
>>> https://writingcenter.unc.edu/tips-and-tools/gender-inclusive-language/
>>>
>>> https://www.chicagomanualofstyle.org/qanda/data/faq/topics/Usage/faq0053.html
>>> https://dictionary.cambridge.org/dictionary/english/man-made
>>>
>>> An issue may arise if artificial is already being used as a tag however.
>>>
>>> Best,
>>>
>>> Nathan
>>> ___
>>> 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 
> listTagging@openstreetmap.orghttps://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] Proposal to change key:man_made to key:human_made

[Phake Nick]

No, it would still require a mass edit and breaking changes that will come
with disadvantages already listed by other participant of this discussion

在 2020年10月19日週一 18:42，Robert Delmenico  寫道：

> Nice investigating Nathan,
>
> I would be open to using artificial instead of human_made.
>
>
> Would it be best to change the proposal or start a second proposal?
> Change man_made= to artificial=
>
> Rob
>
>
> On Mon, 19 Oct 2020 at 21:14, nathan case  wrote:
>
>> Pros and cons aside, “human-made” is not a term that is in current
>> widespread usage. As a native English GB speaker, I find it clunky and
>> somewhat distracting.
>>
>> A better gender neutral term might be “artificial”, which is already a
>> synonym for “man-made” and is already widely used.
>>
>> Indeed, the Handbook of Nonsexist Writing suggests: "artificial,
>> handmade, hand-built, synthetic, manufactured, fabricated, machine-made,
>> and constructed" as options instead of man-made. Presumably the majority
>> (if not all) of OSM "man-made" tags relate to objects which are not
>> naturally occurring. Therefore "artificial" seems to hold.
>>
>> Other sources:
>> https://writingcenter.unc.edu/tips-and-tools/gender-inclusive-language/
>>
>> https://www.chicagomanualofstyle.org/qanda/data/faq/topics/Usage/faq0053.html
>> https://dictionary.cambridge.org/dictionary/english/man-made
>>
>> An issue may arise if artificial is already being used as a tag however.
>>
>> Best,
>>
>> Nathan
>> ___
>> 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] Should admin_level=1 tag be applied to EU?

[Phake Nick]

在 2020年7月31日週五 00:24，Alan Mackie  寫道：

>
>
> On Thu, 30 Jul 2020 at 16:38, Martin Koppenhoefer 
> wrote:
>
>> Am Do., 30. Juli 2020 um 17:13 Uhr schrieb Alan Mackie <
>> aamac...@gmail.com>:
>>
>>> This is why I suggested that the more practical solution would probably
>>> be to re-tag all existing admin_level=2 with admin_level=1 except for the
>>> EU ones as there are far fewer elements to be updated. Arbitrarily deciding
>>> that the EU gets its own admin_level not used by other top level entities
>>> breaks consistency with the rest of the world for the sake of local pride.
>>>
>>
>>
>> which other top level entities are you getting at? Why should we not tag
>> these with the same tag?
>>
>
> Other independent nations, this is why I suggested the promotion of all
> other admin_level=2 if we went this rote
>

admin_level=1 is by definition higher than national level.
I would say a historical example could be German Confederation, before the
unification of Germany
Another historical example could be the Communist Bloc, which is larger
than the Soviet Union.
It might also be useful to map the limit of power of other countries that
formally controls a number of tributary, vassal or proxy states beyond its
own border.

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

[Tagging] Should admin_level=1 tag be applied to EU?

[Phake Nick]

Cureently, the wiki say the admin_level=1 tag is for supernational border
like EU, but it have not be tagged as such in the OSM database itself.
Should it the tag be applied this way?
Also, another thing is taginfo seems to be showing a number of current use
of the tag admin_level=1 on different features. Are they all incorrectly
applied?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - shop=bubble_tea

[Phake Nick]

在 2020年7月3日週五 22:32，Paul Allen  寫道：

> On Fri, 3 Jul 2020 at 14:43, Joseph Eisenberg 
> wrote:
>
>> > description=* might be a better way of dealing with it (if the name of
>> the
>> place doesn't give it away).
>>
>> No, that is a bad idea. The "description" field does not provide
>> consistent data. It is always preferable to use a new, more specific tag.
>>
>
> Description is a very good idea if you think that mapping things down to
> that
> level of detail is silly.  If it concentrates on 79 flavours of coffee with
> 200 different toppings but also sells one type of tea, map just
> drink:coffee=yes.  If you want people to know they can also get a bad
> cup of tea there, with absolutely no choice, the description is fine.
>
> The problem with a tag to specify what kind of drink it focuses on
> is that it breaks when the place focuses on two types of drink.  What
> if there is an incredible variety of teas and coffees but only one
> flavour of juice?  What if there are a lot of coffees and a lot of
> juices but the tea comes from the cheapest tea bags
> available that have long passed their shelf life?
>
> So now we need a tag that can handle multiple foci.  OK,
> semicolon-delimited list.  But now it turns out that they
> do a lot of types of coffee, a lot of types of tea, five flavours
> of juice but only one flavour of carbonated drink?  So now we
> need a tag for an intermediate-level of focus.
>
> Ah, but some of the coffee is good coffee but some of it is bad
> coffee.  So now we need to tag the individual flavours of coffee
> so we can specify a quality rating for them.
>
> This is getting very silly.
>
> Do they sell coffee?  Yes or no.  Do they sell tea?  Yes or no.  Do they
> sell juice?  Yes or no.  Are there are large range of coffees?  Goes in
> the description.
>
> I don't mind micromapping, but I draw the line at picomapping.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


在 2020年7月3日週五 22:32，Paul Allen  寫道：

> On Fri, 3 Jul 2020 at 14:43, Joseph Eisenberg 
> wrote:
>
>> > description=* might be a better way of dealing with it (if the name of
>> the
>> place doesn't give it away).
>>
>> No, that is a bad idea. The "description" field does not provide
>> consistent data. It is always preferable to use a new, more specific tag.
>>
>
> Description is a very good idea if you think that mapping things down to
> that
> level of detail is silly.  If it concentrates on 79 flavours of coffee with
> 200 different toppings but also sells one type of tea, map just
> drink:coffee=yes.  If you want people to know they can also get a bad
> cup of tea there, with absolutely no choice, the description is fine.
>
> The problem with a tag to specify what kind of drink it focuses on
> is that it breaks when the place focuses on two types of drink.  What
> if there is an incredible variety of teas and coffees but only one
> flavour of juice?  What if there are a lot of coffees and a lot of
> juices but the tea comes from the cheapest tea bags
> available that have long passed their shelf life?
>
> So now we need a tag that can handle multiple foci.  OK,
> semicolon-delimited list.  But now it turns out that they
> do a lot of types of coffee, a lot of types of tea, five flavours
> of juice but only one flavour of carbonated drink?  So now we
> need a tag for an intermediate-level of focus.
>
> Ah, but some of the coffee is good coffee but some of it is bad
> coffee.  So now we need to tag the individual flavours of coffee
> so we can specify a quality rating for them.
>
> This is getting very silly.
>
> Do they sell coffee?  Yes or no.  Do they sell tea?  Yes or no.  Do they
> sell juice?  Yes or no.  Are there are large range of coffees?  Goes in
> the description.
>
> I don't mind micromapping, but I draw the line at picomapping.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


在 2020年7月3日週五 22:32，Paul Allen  寫道：

> On Fri, 3 Jul 2020 at 14:43, Joseph Eisenberg 
> wrote:
>
>> > description=* might be a better way of dealing with it (if the name of
>> the
>> place doesn't give it away).
>>
>> No, that is a bad idea. The "description" field does not provide
>> consistent data. It is always preferable to use a new, more specific tag.
>>
>
> Description is a very good idea if you think that mapping things down to
> that
> level of detail is silly.  If it concentrates on 79 flavours of coffee with
> 200 different toppings but also sells one type of tea, map just
> drink:coffee=yes.  If you want people to know they can also get a bad
> cup of tea there, with absolutely no choice, the description is fine.
>
> The problem with a tag to specify what kind of drink it focuses on
> is that it breaks when the place focuses on two types of drink.  What
> if there is an 

Re: [Tagging] Feature Proposal - RFC - shop=bubble_tea

[Phake Nick]

在 2020年6月29日週一 20:12，Andrew Harvey  寫道：

> On Mon, 29 Jun 2020 at 21:17, Martin Koppenhoefer 
> wrote:
>
>> > On 29. Jun 2020, at 12:18, Andrew Harvey 
>> wrote:
>> >
>> > I think it's better to have some kind of high level tag like
>> amenity=drinks or shop=drinks which you order at a counter (as opposed to
>> shop=beverages which is more a shop that has pre-made bottled drinks which
>> you walk around and add to your shopping basket).
>> >
>> > The "bubble_tea" part should be left as the cuisine.
>>
>>
>> I don’t believe it is helpful to cluster all kind of places where you can
>> primarily find something to drink in a generic tag. Bubble tea is very
>> specific, and unless you want bubble tea you would not want to find these
>> when you are thirsty. We already do distinguish places to drink with
>> various tags like bar, cafe, pub, and it does not seem likely that we will
>> deprecate these, so a amenity=drinks or shop=drinks would not promise more
>> consistency or ease of tagging. We also already have shop=wine,
>> shop=beverages and more. I would make bubble_tea a first level tag
>> (or maybe a subtag for pastry/sweets etc.)
>>
>
> So we have a first level tag for fruit_tea, purple_yogurt, milk_tea,
> bubble_tea, fresh_squeezed_juice, blended_juice, milkshake, smoothie? It's
> too long tail and breaks down when you have a shop that sells a mixture of
> those instead of just one, a single primary tag for all of these is better.
>
> The same way we just have amenity=restaurant and don't have
> amenity=pizza_restaurant etc.
>
> The same way a place that mostly does chocolate drinks that you sit down
> at and also does desserts is amenity=cafe + cuisine=chocolate, even if
> there is no coffee sold.
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


But we do have tags like shop=confectionery , and the different between
confectionery and bakery is just of the same nature as the different
between bubble tea and regular drink shop.

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

Re: [Tagging] [OSM-talk] Should we map things that do not exist?

[Phake Nick]

在 2020年6月6日週六 11:03，Warin <61sundow...@gmail.com> 寫道：

> On 6/6/20 8:02 am, Volker Schmidt wrote:
> > I need to reopen this thread.
> >
> >  I do object strongly to the invitation to remove the
> > razed/dismantled-railway tag in the case of railway tracks have been
> > replaced by roads with the same geometry. To the contrary this is one
> > of the more fortunate cases where the original route has been
> > conserved, and it is easy to travel along a historical railroad.
> > I admit that I have a faible for industrial archeology (like former
> > railways, watermills, old canals) but they do have touristic value and
> > for that reason should be in OSM.
>
>
> As a general tourist I would have no interest in traveling along a
> railway route here nothing remains of the railway.
>

OSM is not *only* for general tourist.

> If something remains then map the remains, not the bits that no longer
> exist.
>

As repeatedly covered in this thread with examples being cited, a
razed/dismantled railway could still leave indication for its railroad
alignment on the ground.

Where an old railway route passes through private residential houses,
> commercial buildings, car parking area .. I don't think that should be
> in OSM yet people map it...
>

You can have rows of private houses and blocks of factories building over
former railway yet the railway remain can still be visible on the ground.

A historian/archeologist may have interest in documenting the old
> railway route and facilities, they can and should use OHM.
>

They're not historical, they're currently existing as remain, and is of
interest for anyone trying to understand or utilize such area.

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

Re: [Tagging] [OSM-talk] Should we map things that do not exist?

[Phake Nick]

在 2020年6月2日週二 09:26，Warin <61sundow...@gmail.com> 寫道：

> On 30/5/20 12:48 am, Volker Schmidt wrote:
> > My main point is that out there are things that consist of visible
> > objects plus objects which have left visible traces, and also some
> > pieces that have been completely erased, but of which we have
> > documented knowledge of where they once were. The entire thing makes
> > sense only with all its parts. These things be of interest for some
> > end users of OSM data, and hence, if someone has gone to the length of
> > mapping them, should find space in OSM.
> > In my view a general rule that any mapper can erase any object from
> > the map, when he does not see any trace of it, is certainly not
> > correct , he may be removing parts of the thing thsat only with all
> > its partsmakes sense.
>
>
> Where an old railway line has been built over by houses, factories,
> shops and roads I see no reason to retain the (historical) information
> in OSM.
>
> The old railway station that still exists at one end - yes, but where
> there is nothing, not even a hint, left then no.
>

Except, it is relatively common for traces of old railway remain visible
even after new development (e.g. house, factory, shop, road) have been made
on top of their original site. So that cabnot be used as a criteria to
determine whether that should be removed or not although the exact
situation varies a lot in each individual cases.

> Anyway i am against removing apparently useless data without
> > consultation with the author, with the exception of clear errors.
>
>
>
> Disagree.
>
> Once the data is in OSM it is no longer the 'property' of the author or
> following editors.
>
> If I am not certain of something I'll ask the author/flowing editors but
> where I know something is wrong I'll change it without consultation.
>
If you are not sure of the use or validity of something then it would also
be a good idea to ask those who might know about it.

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

Re: [Tagging] [OSM-talk] Should we map things that do not exist?

[Phake Nick]

在 2020年5月25日週一 19:35，Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> 寫道：

>
>
>
> May 25, 2020, 09:47 by dieterdre...@gmail.com:
>
>
>
> sent from a phone
>
> On 25. May 2020, at 08:54, Colin Smale  wrote:
>
> 1. Live and let live - OSM has always been a broad church. It might not be
> your hobby, but it is their's. The bar to actively deleting other people's
> work should be set very high indeed.
>
>
> +1
> I completely subscribe to this
>
> +1, but something that is 100% gone can be deleted.
>
> I have seen railway=abandoned mapped across open-pit mine that was there
> for 20 years.
>
> There was zero chance of mappers recreating it (as oldest aerials will
> show open pit mine),
> it was 100% gone (like embankments, railway station and dirt 20 m below).
>
> I deleted it.
>
> Something that is fully, completely and totally gone can be deleted. If
> there are buildings
> across former track of the railway and embankment is leveled then it can
> and should
> be deleted.
>
> If there are no traces whatsoever and you need old maps to map it then it
> is out of
> scope of OSM and deleting it improves OpenStreetMap.
>
> There was railway here:
>
> https://commons.wikimedia.org/wiki/File:National_Museum_in_Krakow-Main_Building,_1,_3Maja_Av,_Krakow,Poland.jpg
>
> There are no traces whatsoever. It is not mapped, should not be mapped and
> should be deleted if mapped.
>
> I have more doubts about cases where only earthworks remain (and are used
> for
> cycleway/road/path). You can plausibly guess that railway was there but it
> is just a
> guess and typically you need old maps to confirm that it was there.
>
> And in some cases such features look like former railway but that is not
> really true.
>
> But something that is totally gone should be gone from OpenStreetMap (with
> exceptions
> for objects marked as gone and temporarily not deleted to prevent
> incorrect remapping).
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


To add on it, I think something like
https://minkara.carview.co.jp/smart/userid/177050/blog/43940205/ should
still be included in the OpenStreetMap since some of their trace still
exists on the ground and that it's still more or less possible to locate
the alignment of the abandoned rail route.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] any valid usage of admin_level=1 ?

[Phake Nick]

在 2020年5月25日週一 21:39，Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> 寫道：

>
>
>
> May 25, 2020, 15:27 by colin.sm...@xs4all.nl:
>
> On 2020-05-25 14:58, Marc M. wrote:
>
> Hello,
>
> following a small thread on irc, I have review 20 usage of admin_level=1
> all are mistakes, often by new mapper
> for ex https://www.openstreetmap.org/way/779838275
> is there a case of real use of admin_level=1?
> wiki only said that UE isn't a admin_level=1
> but don't list any valid usage of it
>
> https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative#Super-national_administrations
> https://overpass-turbo.eu/s/Umf
>
> are these all errors or is there an undocumented usecase ?
>
> I think the European Union is a good candidate for admin_level=1. It has
> all the attributes of an administration, including elected representatives
> and (in some cases) directly effective laws. It may be unique in the world,
> but that doesn't change the duck-test outcome.
>
> I agree that European Union seems to be a sole viable candidate.
>
> I don't get
> "trans-national administration is not a super-national organization"
> argument, EU clearly has administration, de facto (also de iure?) laws,
> elections and so on.
>
> Though it is area where I am not confident at all, so I am not really
> proposing to do that
> - just that I would not be surprised or opposed.
>
> I fixed https://www.openstreetmap.org/way/779838275 as clearly bogus.
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


It is in the OpenStreetMap wiki itself that EU is a
super-national.organization:
https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative

What I'm thinking about is, does Realm of New Zealand
http://en.wikipedia.org/wiki/Realm_of_New_Zealand count? Those territories
in the realm seems to still have some sort of power over comprosing
territories despite proclaimed independence.
Likewise, what about Kingdom of Denmark (relation 9110211)? It is now being
tagged as an administrative boundary but with no admin_level.
And what about British Crown Dependencies (relation 9110397) and British
Overseas Territory (relation 3969434)? The British Crown Dependencies is
now tagged as boundary=historic which seems wrong to me as it's still
current. The British Overseas Territory is tagged as
boundary=administrative but with no admin_level key.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [OSM-talk] Should we map things that do not exist?

[Phake Nick]

在 2020年5月25日週一 16:12，Florian Lohoff  寫道：

>
> Hola,
>
> On Mon, May 25, 2020 at 08:52:21AM +0200, Colin Smale wrote:
> > 1. Live and let live - OSM has always been a broad church. It might not
> > be your hobby, but it is their's. The bar to actively deleting other
> > people's work should be set very high indeed.
>
> I subscribe to this aswell. As long as it does not collide with stuff
> in use we should be able to tolerate data of historic or special purpose
> most of us probably do not aim for.
>
> The broad scope of your subject must otherwise be answered with: "No"
>
> It IS Best Common Practice to follow the "On the ground" rule with only
> very few exceptions.
>
> And IMHO we cant lift that. OSM needs to have a common ground to discuss
> matters and sometimes reality is already pretty hard to agree on. If we
> now add stuff in history or in the minds of mappers we open a pretty
> difficult can of worms.
>
> So - To quote from Postels Law - On of the inventors of the Internet:
>
> "Be conservative in what you do, be liberal in what you accept from others"
>
> Flo
> --
> Florian Lohoff f...@zz.de
> UTF-8 Test: The  ran after a , but the  ran away
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


Your email initially sound like you thinl they shouldn't be deleted but
then it sound like you think they shouldn't be kept?

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

Re: [Tagging] [OSM-talk] Should we map things that do not exist?

[Phake Nick]

I personally think such should still be tagged as long as the space, or the
right of way, still remain, but not when it have been completely removed,
integrated into surrounding area, and redeveloped, unless traces or marks
of either the remain of the rail system itself or the space previous used
by the rail can still be found despite redevelopment.

在 2020年5月25日週一 13:06，Joseph Eisenberg  寫道：

> This was originally sent to the Talk mailing list, but it is better if it
> is discussed on the Tagging mailing list:
> https://lists.openstreetmap.org/listinfo/tagging
>
> I agree that razed, completely demolished railways, where all traces of
> the former track-bed have been removed, should be removed from
> OpenStreetMap.
>
> It is still considered acceptable to map abandoned railways, where the old
> railway grade remains, even though the metal rails have been removed.
>
> However, note that there are some people who are very committed to mapping
> historical and abandoned railways, so there may be resistance to removing
> these features.
>
> See the long discussions about rendering railway=abandoned at
> https://github.com/gravitystorm/openstreetmap-carto/pull/542 and
> https://github.com/gravitystorm/openstreetmap-carto/issues/586 for
> example.
>
> Also see the previous discussion at
> https://wiki.openstreetmap.org/wiki/Talk:Railways#Abandoned_railways_where_all_evidence_has_been_removed
>
> – Joseph Eisenberg
>
> On Sun, May 24, 2020 at 9:40 PM Jack Armstrong 
> wrote:
>
>> Greetings.
>>
>>
>> Recently, a user mapped “razed” railways inside a construction zone (link
>> below). These rails had been removed by our local mappers since they don’t
>> exist anymore. Using the latest imagery (Maxar), you can see the rails have
>> been completely removed from “Project 70”, a $1.2 billion Denver-area
>> transportation corridor construction project.
>>
>>
>> I think this mapper has good intentions, but what is the point of mapping
>> something that does not exist? Doesn’t this clearly contradict the OSM Good
>> Practice wiki in regards the sections, “Verifiability”, “Map what's on the
>> ground” and “Don't map historic events and historic features”? The last
>> section states, "*Do not map objects if they do not exist currently*."
>>
>>
>> Should we tag (invisible) razed sidewalks? Should we leave (invisible)
>> destroyed buildings in place, tag them as razed and then create new
>> buildings on top of them?
>>
>>
>> https://www.openstreetmap.org/edit#map=19/39.78016/-104.94562
>>
>>
>>
>> ___
>> talk mailing list
>> t...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
> ___
> 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] Meaning of "administrative" in boundary=administrative, in your country?

[Phake Nick]

In South Korea/Japan/China/Taiwan, the minimal administrative level are
usually equivalent of neighborhoods, and have little to no substantial
administrative functions.
For example, https://www.openstreetmap.org/relation/3987250 this is
admin_level=9 in South Korea, https://www.openstreetmap.org/relation/5830985
this is admin_level=10 in Japan,
https://www.openstreetmap.org/relation/9230465 this is admin_level=9 in
Taiwan, https://www.openstreermap.org/relation/8248082 this is
admin_level=10 in China.
Note that admin_level=10 also exists in Taiwan but only a few of them have
already been mapped as a relation in OSM.

在 2020年5月14日週四 05:29，Joseph Eisenberg  寫道：

> At the US talk mailing list and
> https://wiki.openstreetmap.org/wiki/Talk:United_States_admin_level there
> has been discussion about whether or not certain features should be tagged
> as administrative boundaries in the States of Connecticut, Rhode Island and
> Massachusetts.
>
> While all these States have counties, in some cases most of the government
> functions have been lost, and are handled by the State (admin_level=4) or
> Town/City government (admin_level=8).
>
> However, I have the impression that in some countries, certain local
> administrative boundaries do not actually have "home rule", or the ability
> to make their own laws, for example in French-infuenced areas?
>
> What is the minimum qualification for a boundary to be considered a
> boundary=administrative with an admin_level in your country?
>
> -- Joseph Eisenberg
> ___
> 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] Tag:amenity=motorcycle_taxi not approved

[Phake Nick]

在 2020年5月13日週三 12:24，Mark Wagner  寫道：

> On Tue, 12 May 2020 23:53:52 +0800
> Phake Nick  wrote:
>
> > Except capacity is only one of many differences between common taxi
> > and motorcycle taxi.
>
> Are there any differences that can't be explained by the fact that a
> motorcycle taxi uses a motorcycle to carry the passengers?
>
> For example, in the United States, we've got what are called "airport
> shuttles".  These look and act a lot like a taxi, but either the start
> point or the end point of the journey must be the airport -- you can't
> use them as general point-to-point transportation like you could a taxi
>

It can be explained, but not necessarily intuitively so. Like you can
attribute the fare different and access restriction to them using
motorcycle vehicles, but these are not properties of a motorcycle itself.

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

Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

[Phake Nick]

Except capacity is only one of many differences between common taxi and
motorcycle taxi.

在 2020年5月11日週一 16:04，Marc M.  寫道：

> Hello,
>
> Le 10.05.20 à 01:24, Martin Koppenhoefer a écrit :
> > imagine you are ordering a taxi for yourself and 2 colleagues to the
> > airport and instead of a taxi (cab) they send you 3 taxi moto. Would
> > that be equally ok, wouldn’t it matter, taxi is taxi?
>
> Imagine ordering a taxi and arriving in a 4-seater car when you have
> a family of 8, it's the same problem, isn't it?
> When I order a taxi, they ask me the number of people.
> the guy won't come with a fiat 500 if I say 8
>
> I don't imagine we're going to create several objects to describe
> that a taxi waiting area has motorcycles, "normal" cars, vehicles
> with a lot of passenger seats and vehicles with a heavy
> luggage capacity.
> on the ground : one traffic sign for for all variants.
>
> Regards,
> Marc
>
> ___
> 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] Tag:amenity=motorcycle_taxi not approved

[Phake Nick]

在 2020年5月11日週一 09:18，Jarek Piórkowski  寫道：

> On Sun, 10 May 2020 at 21:04, Phake Nick  wrote:
> > I am more thinking about analysis of geographical data of cities or
> districts where taxi and motorcycle taxi would be two very different things
> to be managed.
>
> If you are managing taxis and motorcycle taxis then surely you know
> you have to check which is which. Which tag is used to check for them
> is immaterial.
>


Yes, but it would be impossible to check if the motorcycle tag become
optional, aka when motorcycle become another value chained to the taxi tag.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

[Phake Nick]

* Also, as have already been mentioned in other replies, there are various
other differences between the two services other than number of wheels and
whether they're enclosed.

在 2020年5月11日週一 09:04，Phake Nick  寫道：

> I am more thinking about analysis of geographical data of cities or
> districts where taxi and motorcycle taxi would be two very different things
> to be managed.
> Even if you view it from the viewpoint of people trying to get a ride, I
> would not expect cross-display of the two types of mobility items in the
> same format as that would lose the meaning of having the two types of
> mobility options.
>
> 在 2020年5月11日週一 08:58，Jarek Piórkowski  寫道：
>
>> On Sun, 10 May 2020 at 18:35, Phake Nick  wrote:
>> > At the end of the day we are not taking motorcycle taxi and taxi
>> themselves. What's being tagged are waiting area for taxi or motorcycle
>> taxis. What matters is that, if one is created as an optional subtag of
>> another, would not using such subtag result in incorrect analysis of data
>> when someone use those data, and the answer seems to me as yes.
>>
>> Depends what question you're asking in the analysis, surely.
>>
>> If your question is "where can get a ride" then the results won't be
>> wrong.
>>
>> If your question is "where can get a ride in an enclosed two-track
>> vehicle" then the results would be wrong in Indonesia. But if you're
>> asking that in Indonesia, you're probably also aware of the variety of
>> local modes of transportation and realize that you should ask a more
>> specific question.
>>
>> You could make a similar argument for other amenities.
>> For example, if you're looking for a parking spot, and if your region
>> some parking lots are private, you need to take that into account when
>> doing the analysis.
>> If you are looking for a rapid transit station and you're in a
>> wheelchair, and in your area not all stations are accessible, you need
>> to take that into account when doing the search. This might not occur
>> to someone from an area where all stations are accessible, so should
>> we have a railway=inaccessible_station rather than wheelchair=no to
>> prevent incorrect analysis?
>>
>> To me, this argument goes back to the same question of whether an
>> amenity=taxi is where you hire a ride, or where you hire a ride in an
>> enclosed vehicle that can fit 2+ passengers and probably a bit of
>> luggage.
>>
>> --Jarek
>>
>> ___
>> 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] Tag:amenity=motorcycle_taxi not approved

[Phake Nick]

I am more thinking about analysis of geographical data of cities or
districts where taxi and motorcycle taxi would be two very different things
to be managed.
Even if you view it from the viewpoint of people trying to get a ride, I
would not expect cross-display of the two types of mobility items in the
same format as that would lose the meaning of having the two types of
mobility options.

在 2020年5月11日週一 08:58，Jarek Piórkowski  寫道：

> On Sun, 10 May 2020 at 18:35, Phake Nick  wrote:
> > At the end of the day we are not taking motorcycle taxi and taxi
> themselves. What's being tagged are waiting area for taxi or motorcycle
> taxis. What matters is that, if one is created as an optional subtag of
> another, would not using such subtag result in incorrect analysis of data
> when someone use those data, and the answer seems to me as yes.
>
> Depends what question you're asking in the analysis, surely.
>
> If your question is "where can get a ride" then the results won't be wrong.
>
> If your question is "where can get a ride in an enclosed two-track
> vehicle" then the results would be wrong in Indonesia. But if you're
> asking that in Indonesia, you're probably also aware of the variety of
> local modes of transportation and realize that you should ask a more
> specific question.
>
> You could make a similar argument for other amenities.
> For example, if you're looking for a parking spot, and if your region
> some parking lots are private, you need to take that into account when
> doing the analysis.
> If you are looking for a rapid transit station and you're in a
> wheelchair, and in your area not all stations are accessible, you need
> to take that into account when doing the search. This might not occur
> to someone from an area where all stations are accessible, so should
> we have a railway=inaccessible_station rather than wheelchair=no to
> prevent incorrect analysis?
>
> To me, this argument goes back to the same question of whether an
> amenity=taxi is where you hire a ride, or where you hire a ride in an
> enclosed vehicle that can fit 2+ passengers and probably a bit of
> luggage.
>
> --Jarek
>
> ___
> 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] Tag:amenity=motorcycle_taxi not approved

[Phake Nick]

At the end of the day we are not taking motorcycle taxi and taxi
themselves. What's being tagged are waiting area for taxi or motorcycle
taxis. What matters is that, if one is created as an optional subtag of
another, would not using such subtag result in incorrect analysis of data
when someone use those data, and the answer seems to me as yes.

在 2020年5月11日週一 05:55，Florimond Berthoux  寫道：

> Le dim. 10 mai 2020 à 01:25, Martin Koppenhoefer 
> a écrit :
>
>> On 9. May 2020, at 22:50, Florimond Berthoux <
>> florimond.berth...@gmail.com> wrote:
>>
>> Yeah, that's the point...
>>
>> Keep it simple.
>> You know taxi key ? You know motorcycle key ? Yeah, you can contribute
>> without checking yet another wiki tag page.
>>
>> By the way, this how a taxi moto looks like in Paris
>>
>> https://www.city-bird.com/wp-content/uploads/2018/08/DSC3972_R1_optimise_bas.jpg
>>
>>
>>
>> imagine you are ordering a taxi for yourself and 2 colleagues to the
>> airport and instead of a taxi (cab) they send you 3 taxi moto. Would that
>> be equally ok, wouldn’t it matter, taxi is taxi?
>>
>
> I don't care, English is not my mother tongue and tags is not the English
> language :
> «Tags is an intermediate language between human and machine, at the end
> its just characters with definitions, but some are easier to use for
> mapping and computing.»
>
> --
> Florimond Berthoux
> ___
> 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] Tag:amenity=motorcycle_taxi not approved

[Phake Nick]

在 2020年5月10日週日 16:24，Martin Koppenhoefer  寫道：

>
>
> sent from a phone
>
> > On 10. May 2020, at 01:31, Paul Allen  wrote:
> >
> > If you use amenity=taxi + vehicle=* you
> > guarantee that any carto which renders amenity=taxi will render ojek
> ranks
> > incorrectly at first, and perhaps incorrectly for all time (if they
> decide they're
> > going to ignore the vehicle tag)
>
>
> it would only be “incorrectly” if you judged motorcycle taxis as not being
> taxis. In this case, you should not tag them amenity=taxi taxi=motorcycle
> anyway (because if taxi=motorcycle does not describe a subclass of taxi
> this is the wrong approach anyway).
>
> In this discussion it appeared that some mappers see motorcycle taxis as a
> kind of taxi, like boat taxis and helicopter taxis, and others that see
> them as their own kind of service.
>

I saw one mapper who shared their view on why motorcycle taxi should be a
type of taxi, unfortunately I cannot see the rationale within the
explanation given by the editor. I think it would be helpful of the
proposal can be modofied and RFC be restarted so that hopefully other
editors who held similar views can provide a more easy to understand
explanation on why they think so.

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

Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

[Phake Nick]

在 2020年5月10日週日 07:08，François Lacombe  寫道：

>
> Le sam. 9 mai 2020 à 19:20, Phake Nick  a écrit :
>
>>
>> What you said doesn't make sense.
>> The existence of a space within the word doesn't inherently make them
>> separateable.
>> Like for the tag amenity=charging_station, do you think the space mean ot
>> make sense to change the tagging scheme into amenity=station +
>> station=charging ?
>>
>
> It depends on what your definition of station is.
>

As you said, it depends, you can't just break down everything this way just
because they're compounded word.

>
>
>>
>> Your interpretation on public transit service is incorrect.
>> When you board a plane from London to Paris, you didn't fly to Paris
>> because they told us they would fly to Paris. You're going to Paris because
>> you have expressed interest in going to Paris. Same with rideshareing or
>> other rented mobility services.
>>
>
> You're lucky enough to take on planes you define your own destination
> first.
> "Going to Paris" doesn't mean the same for a taxicab and for a plane.
> Even in ridesharing, destination is given by passengers and driver doesn't
> know it before meeting them (face to face or with an app, same actually).
> You don't define the destination reached by plane, by train or by bus.
> This is the difference I make.
>

You can book a flight ticket through travel agents, ticketing websites,
carrier hotline, or airport counter. You don't need luck to get a flight to
Paris.


>
>>
>>
>>> We agree on that particular point.
>>> Neverthess that doesn't make a second value of amentiy legit.
>>> OSM would only have one key grouping all possible values if it was
>>> relevant.
>>>
>>
>> I am not aware of such requirement on value ever existing in OSM.
>>
>
> This was actual irony.
>

I hope you realize the irony here is that you pulled some rule out of thin
air that didn't exists in OSM.


> Le sam. 9 mai 2020 à 20:45, Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> a écrit :
>
>>
>> Neverthess that doesn't make a second value of amentiy legit.
>>
>> Why?
>>
>
> Both have taxi service in common but the vehicle is different (and implies
> really different experiences indeed)
> amenity=* represents the taxi service and I find relevant to describe the
> different vehicle in another key.
>

As have already been explained they are different types of services


>
>> OSM would only have one key grouping all possible values if it was
>> relevant.
>>
>> Why?
>>
>
> If you accept to merge similarities and differences in values you don't
> need different keys.
> Who need operator key for instance?
> amenity=taxi_with_cars_operated_by_Acompany
> amenity=taxi_with_motorbikes_operated_by_anotherCompany
> Hey it's way different things, Acompany is really bad compared to
> anotherCompany.
>

That's a ridiculous comparison, that's like saying we shouldn't have
different tag for office building versus residential building because
people night expand it to make tags like microsoft_office_building.


> Finally, Paul, I find your point about taxonomy thinking interesting and
> will try to develop it a bit in future.
> Get me well, I don't intend to ban anyone from anything.
> Query tools are really important to consume data and my point wasn't to
> downgrade tagging readability in general (nor to encourage K9842=V2179).
> To me tourists and query tools users can only be the same persons at
> different time. I've never used overpass to locate myself in any train
> station, that's all.
>
> In proposal, arguing amenity=taxi/amenity=motorbike_taxi will better
> prevent errors than amenity=taxi + vehicle=* doesn't convince me : mappers
> are always able to confuse two services, whatever the tagging they use can
> be.
>
> That was my 2 cts, good night
>

So you're saying people would be confused by a motorcycle taxi and think
they're a 4-wheeled taxi, or they might look at a 4-wheeled taxi and think
it is a motorcycle taxi?

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

Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

[Phake Nick]

Key chaining is the more complex form of representation, especially when
there are no obvious relationship between different types of objects being
represented.

在 2020年5月10日週日 04:50，Florimond Berthoux  寫道：

> Yeah, that's the point...
>
> Keep it simple.
> You know taxi key ? You know motorcycle key ? Yeah, you can contribute
> without checking yet another wiki tag page.
>
> By the way, this how a taxi moto looks like in Paris
>
> https://www.city-bird.com/wp-content/uploads/2018/08/DSC3972_R1_optimise_bas.jpg
>
> Le ven. 8 mai 2020 à 23:32, Joseph Eisenberg 
> a écrit :
>
>> The tag motorcycle=yes is already documented as defining legal access
>> restrictions for motorcycle riders, like access=yes or foot=yes
>> See https://wiki.openstreetmap.org/wiki/Tag:motorcycle%3Dyes
>>
>> -- Joseph Eisenberg
>>
>> On Fri, May 8, 2020 at 1:34 PM Florimond Berthoux <
>> florimond.berth...@gmail.com> wrote:
>> >
>> > Hi,
>> >
>> > 5) As a French I have to give you again the universal answer :
>> amenity=taxi + motorcycle=yes + whateveryourvehicle=yes|designated :)
>> >
>> > Tags is an intermediate language between human and machine, at the end
>> its just characters with definitions, but some are easier to use for
>> mapping and computing.
>> >
>> > (I read some disrespectful arguments in the following mails...)
>> >
>> > Regards
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> --
> Florimond Berthoux
> ___
> 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] Tag:amenity=motorcycle_taxi not approved

[Phake Nick]

在 2020年5月9日週六 20:35，François Lacombe  寫道：

> Hi Paul,
>
> Le sam. 9 mai 2020 à 02:29, Paul Allen  a écrit :
>
>>
>> This isn't just about optimizing the number of tags used, it's about
>> aligning with
>> how most people's mental models work.  And not just the mental models
>> of local mappers but also the mental models of tourists: locals don't
>> refer
>> to maps as often as tourists do.
>>
>
> Tourists aren't supposed to refer to tags to know which kind of taxi
> service they can use.
> Renders, tools, apps are here to ease this for them. Are you aware of
> Google Maps data model when browsing it?
> Even local mappers can use tools focused on a specific topic which makes
> tagging less important to master to contribute.
>

> Nevertheless, we're are discussing about things like amenity=taxi +
> vehicle=* which doesn't sound that complex.
> Even common language using two words "motorcycle" and "taxi" could mean we
> have something to do with several keys.
>

What you said doesn't make sense.
The existence of a space within the word doesn't inherently make them
separateable.
Like for the tag amenity=charging_station, do you think the space mean ot
make sense to change the tagging scheme into amenity=station +
station=charging ?



> Le sam. 9 mai 2020 à 06:38, Shawn K. Quinn  a
> écrit :
>
>> taxi=* is already used as an access tag, so I think taxi:type=* should
>> be considered instead. Perhaps amenity=taxi can default to motorcar if
>> there is no taxi:type=* tag.
>>
>
> Beware of :type disadvantages.
> Things like vehicle=* sounds better (or another word referring to vehicle
> used).
>
> Default to motorcar can lead to mistakes for consumers.
> It's more valuable to consider vehicle unknown if absent (and encourage
> mappers to explicitly define it)
>

And that make the tag valueless as that cannot actually indicate what exact
type of place the tag was indicating.


> Le sam. 9 mai 2020 à 08:01, Phake Nick  a écrit :
>
>>
>> "I pay a driver to take me where I want to with his vehicle" is something
>> that would also be true for any other public transit vehicles.
>>
>
> I respectably disagree regarding public transit: you're not asking them to
> take you where YOU want but if they actually go where THEY told us they
> will.
> Every word counts here.
>

Your interpretation on public transit service is incorrect.
When you board a plane from London to Paris, you didn't fly to Paris
because they told us they would fly to Paris. You're going to Paris because
you have expressed interest in going to Paris. Same with rideshareing or
other rented mobility services.


>
>> Motorcycle taxi is different from 4-wheeled taxi because they provide a
>> different experience with different speed, charge different fare, have
>> different level of convenience, can access different area, and various
>> other factors.
>>
>
> We agree on that particular point.
> Neverthess that doesn't make a second value of amentiy legit.
> OSM would only have one key grouping all possible values if it was
> relevant.
>

I am not aware of such requirement on value ever existing in OSM.


>
>
>> In addition to them being different kind of services, for the purpose of
>> openstreetmap tagging, it's better to remember that a motorcycle taxi stand
>> would look quite different from a taxi stand, use the streetspace
>> differently, and thus mixing them together would also hurt any downstream
>> data user who might wish to understand the situation of 4-wheeled taxi
>> penetration in certain geographical area due to conflating the data with
>> others that aren't of the same type. They're often regulated by different
>> laws and face different operational restrictions also.
>>
>
> That could eventually be a point if all those differences were known
> precisely and described.
> There are many many kind of public transit stations but we're still
> calling them stations and platforms.
>

That would be a big departure from the way how these features are currently
tagged within OSM.

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

Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

[Phake Nick]

在 2020年5月9日週六 07:07，François Lacombe  寫道：

> Hi
>
> Le ven. 8 mai 2020 à 20:48, Phake Nick  a écrit :
>
>> motorcycle are not the same type of service as regular taxi.
>>
>
> Then may I ask you why ?
> I pay a driver to take me where I want to with his vehicle.
>


"I pay a driver to take me where I want to with his vehicle" is something
that would also be true for any other public transit vehicles.
Motorcycle taxi is different from 4-wheeled taxi because they provide a
different experience with different speed, charge different fare, have
different level of convenience, can access different area, and various
other factors.


>
>> The reaso  why you get the feeling of people saying "you don't
>> understand" to you is because you couldn't tell others why your concern is
>> legitimate, thus making it read like nonsense, even if they might make
>> sense to you, thought I am still not sure about how the distinction of
>> electric power or not is going to on the same level as different types of
>> services.
>>
>
> There is a lack of understanding in both sides here because I don't get
> why having two different amenity values is a benefit.
>

That's why I suggest clarifying the proposal and restart the discussion
process so that RFC can be centered around such idea. Or we are actually
doing it now.

>
> Back in 2009 a wiki contributor explained he's using amenity=taxi +
> motorcycle=yes. Despite motorcycle=yes can be awkward as it is used as an
> access tag, the idea to complete taxi service with explicit vehicle
> definition is useful.
> https://wiki.openstreetmap.org/wiki/Talk:Tag:amenity%3Dtaxi#Motorcycles.3F
> As I assume motorcycle taxi service is the same as taxicab service (change
> my mind upside), I find convenient to only define extra vehicule types
> instead of the whole service we already have in amenity=taxi.
>

In addition to them being different kind of services, for the purpose of
openstreetmap tagging, it's better to remember that a motorcycle taxi stand
would look quite different from a taxi stand, use the streetspace
differently, and thus mixing them together would also hurt any downstream
data user who might wish to understand the situation of 4-wheeled taxi
penetration in certain geographical area due to conflating the data with
others that aren't of the same type. They're often regulated by different
laws and face different operational restrictions also.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

[Phake Nick]

That they exists doesn't mean they make a different. Taxi with low
pollution and taxi with electric power are same type of taxi as regular
taxi while motorcycle are not the same type of service as regular taxi.
That is like saying we shouldn't have a separate tag for bus versus cars
because there are many different types of cars, including electric car and
fuel efficient cars.:

The reaso  why you get the feeling of people saying "you don't understand"
to you is because you couldn't tell others why your concern is legitimate,
thus making it read like nonsense, even if they might make sense to you,
thought I am still not sure about how the distinction of electric power or
not is going to on the same level as different types of services.

在 2020年5月9日週六 01:19，Marc M.  寫道：

> apart from the joke with the foot_taxi, I used all the others, what to
> reply to someone who tells me it's not common and therefore gives the
> impression that only this usecase is important and therefore requires a
> top-level tag just for that ?
>
> that's why it gives the impression that you're saying "you didn't
> understand", without your answer explaining my argument : I'm talking
> about "the same *service*" and you reply with the number of *wheels*
>
> Le 08.05.20 à 18:17, Joseph Eisenberg a écrit :
> > For the record, I responded to Marc Marc’s comment on this list,
> > and there was not a response back:
> >
> > “ On 2/20/20, marc marc wrote:
> >> Le 20.02.20 à 12:45, Joseph Eisenberg a écrit :
> >>> Can't we have an easy to use top-level feature tag, instead of having
> >>> to add 3 tags like amenity=taxi + motorcar=no + motorcycle=yes to
> >>> define one very common, unique feature?
> >>
> >> did we need to have a top-level feature for every "unique" combination
> >> of the same service ?
> >> if yes, we need a lot of them
> >> amenity=foot_taxi
> >> amenity=moto_taxi
> >> amenity=sidecar_taxi
> >> amenity=taxi_low_local_pollution
> >> amenity=taxi_powered_by_renewable_energy etc.
> >> but all of these are part of the same type of service,
> >> regardless of the number of wheels and the driving force.
> >
> > Not all of these actually are in real-world use.
> >
> > The only 4 options in common use today are:
> >
> > 1) motorcar, 4 wheels, enclosed (amenity=taxi)
> > 2) motorcycle, 2 wheels, open (amenity=motorcycle_taxi)
> > 3) pedicabs / 3-wheel tricycles (amenity=pedicab?) - non-motorized
> > 4) autorickshaws, 3 wheels, enclosed (could be amenity=taxi or perhaps
> > amenity=autorickshaw - but these are not common where I live, though I
> > know they are common in Thailand, India and some other countries).
> >
> > There used to be human-pulled rickshaws, but these no longer exist.
> > They were take over by pedicabs / aka bicycle rickshaws, since those
> > are much more efficient.
> >
> > I will consider proposing the other 2 tags later, but motorcyle taxis
> > are by far the most common. I would bet there are more "ojek" stands
> > in Indonesia than taxi
> >  stands in all of Europe.”
> >
> >
> https://lists.openstreetmap.org/pipermail/tagging/2020-February/051233.html
> >
> > — Joseph Eisenberg
> >
> > On Fri, May 8, 2020 at 8:47 AM Marc M.  > > wrote:
> >
> > Hello,
> >
> > > If these arguments were given beforehand
> >
> > except memory problem, I exposed this opinion here during the RFC
> > (=consider that taxi is a service independent of the propulsion
> > of the engine which is a sub-tag), and I have the impression that
> > the answer was "you didn't understand".
> >
> > I would have liked to understand why I was wrong, but I have the
> > impression that this was not the goal of this rfc which is a mistake
> for
> > the quality (and it is not the first proposal that fails for lack of
> > quality either in the tag, either in the explanation of why this tag)
> >
> > Regards,
> > Marc
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org 
> > https://lists.openstreetmap.org/listinfo/tagging
> >
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
> >
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

[Phake Nick]

在 2020年5月8日週五 23:47，Marc M.  寫道：

> Hello,
>
> > If these arguments were given beforehand
>
> except memory problem, I exposed this opinion here during the RFC
> (=consider that taxi is a service independent of the propulsion
> of the engine which is a sub-tag), and I have the impression that
> the answer was "you didn't understand".
>
> I would have liked to understand why I was wrong, but I have the
> impression that this was not the goal of this rfc which is a mistake for
> the quality (and it is not the first proposal that fails for lack of
> quality either in the tag, either in the explanation of why this tag)
>
> Regards,
> Marc
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


Because the difference between motorcycle taxi and 4-wheeled taxi is not
propulsion? Your argument was like saying we should use a amenity=stop tag
for all bus stop, taxi stop, helicopter stop, and cruise ship stop because
they are just "services with different propulsion engine" which obviously
wasn't their main differences.

If you don't understand why they're different, you can ask, but you didn't
and just said "They are the same therefore " which obviously didn't
make sense.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

[Phake Nick]

On 2020-05-08 Fri 20:45, Jarek Piórkowski  wrote:

>
> How much discussion do you think should be necessary before voting "I
> oppose, because I think using sub-tags is better"? If someone thinks
> that, they think that. A discussion would just print the arguments
> back and forth.
>

Given the proportion of opposing comment being raised, I would say "more
than what have been discussed", as barely anyone raised the point during
the discussion. The only two remotely relevant mentions about it during the
discussion process was 1. one user who think there should be a new parents
tag that cover both regular taxi and motorcycle taxi, and 2. another who
incorrectly assuned "motorcycle taxi" is a combination of two different
features just because the term come with a space. That clearly indicate
discussion was not sufficient and that the proposal should restart the
discussion process.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

[Phake Nick]

Since the wiki say,

> Rejected features may be resubmitted, modified, and moved back to the RFC
process.

, and given most reason appeared on the voting page, I would say the
correct action right now is to improve the reasons listed in the paragraph
on why alternative tagging are not available, and then enter discussion
phase again to see if such similar opinion still surface, and then head
into the voting phase again.

在 2020年5月8日週五 02:51，Joseph Eisenberg  寫道：

> The voting period closed for amenity=motorcycle_taxi with 11 votes to
> approve and 8 votes in opposition, therefore it is not approved, since the
> 74% majority requirement was not met.
>
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:amenity%3Dmotorcycle_taxi#Voting
>
> Opposing voters preferred using amenity=taxi + motorcycle=yes or
> amenity=taxi + taxi=motorcycle
>
> Surprisingly, at least 2 opposing voters would be willing to use
> amenity=taxi + taxi=submarine or taxi=airplane for a location where you
> could hire a submarine or airplane.
>
> However, several "yes" voters were strongly opposed to expanding the
> definition of amenity=taxi which currently is limited to taxicabs
> (generally assumed to be 4-wheel motor vehicles in contemporary British
> English).
>
> So, what's the next step?
>
> 1) Propose using taxi=motorcar, =motorcycle, =boat, =airplane, and get
> that idea officially rejected (it appears it would be certain to fail), or
> is that a waste of everyone's time?
>
> 2) Make a proposal to clarify the definition of amenity=taxi as only
> applying to motorcars, then try to propose the tag again?
>
> 3) Propose amenity=ojek and just hold the vote in the Indonesian
> community, like how the Japanese mapper community proposes locally-relevant
> definitions?
>
> 4) Give up on mapping things which are not found in western Europe, and
> recognize that this is in practice a project dominated by
> English/German/American culture, which will not accept new ideas which were
> not invented in the West?
>
> -- Joseph Eisenberg
> ___
> 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] contact:google_plus status discardable ?

[Phake Nick]

Google Plus for Corporate is still functional.

在 2020年4月14日週二 06:25，Marc M.  寫道：

> Hello,
>
> the service was shutdown on 2 avril 2019
> can we set the status as discardable ?
>
> Regards,
> Marc
>
> ___
> 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] Which languages are admissible for name:xx tags?

[Phake Nick]

在 2020年3月27日週五 21:05，Paul Allen  寫道：

> On Fri, 27 Mar 2020 at 12:31, Simon Poole  wrote:
>
>> Pretending that they do isn't a useful concept and yes they typically
>> won't have transliterations either.
>>
> I'm not pretending the street I'm on has a name in Mandarin.  But the
> country I'm in does.  As does the capital of my country.  My town,
> probably not.
>
> There is valid reason to permit foreign-language names where such exist
> and to permit transliterations where orthography is sufficiently different
> to make the local name incomprehensible.  Duplicating the name=*
> in other languages than the local one(s) isn't sensible.
>

1. Let say you are on a random street named "East Okmulgee Street". There
are probably no preexisting translation to the street name in Chinese. But
why shouldn't a translation be made? A Chinese monolingual speaker is not
going to read a street that is named as "East Okmulgee Street". It is same
as a English Speaker would not be able to read the name of a street named
"شارع الإمام محمد بن عبدالوهاب" on the map. There are no person speaking
Mandarin in an area doesn't mean Mandarin speakers from around the world
wouldn't have a chance to look at the map of your place.
Transliteration make no sense in such scenario either. Like the Arabic
street name I just quoted can be transliterated into "sharie al'imam
muhamad bin ebdalwhab" but this is not going to make any sense or help
English speakers in any tangible way to know where they are. They need to
be translated into the English name, which is "Imam Muhammad bin Abdul
Wahab Street", for general English speaking reader to understand the name
of the street.
2. As for duplicating local name, as previously stated, how else are you
going to tell whether the absence of alternative language key is intended
or not? And how can you tell whether a fallback is desirable or not? If a
monolingual English user is navigating a map feature with the following
keys:
name=ཁྲོམ་གཟིགས་ཁང་། 小昭寺
name:bo=ཁྲོམ་གཟིགས་ཁང་།
name:zh=小昭寺
How can the map software know whether they should transliterate or
translate or simply display the values in the original form because it
might be intended?

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

Re: [Tagging] Which languages are admissible for name:xx tags?

[Phake Nick]

在 2020年3月27日週五 17:14，  寫道：

>
>
> On March 25, 2020 11:50:15 AM GMT+01:00, Phake Nick 
> wrote:
> >在 2020年3月25日週三 18:34，Frederik Ramm  寫道：
> >
> >> Hi,
> >>
> >> On 25.03.20 11:19, Phake Nick wrote:
> >> > My guess is that about 5% of name:xx tags in OSM actually
> >represent a
> >> > unique name in its own right; all others are either copies of
> >the
> >> name
> >> > tag ("this city does not have its own name in language XX but I
> >want
> >> > every city to have a name:xx tag so I'll just copy the name
> >tag"), or
> >> > transliterations (or, worst case, even literal translations).
> >> >
> >> > Isn't that the function of the key?
> >>
> >> Unsure which of my list items you mean - copying the original name is
> >> not the function of the key; a data user can simply fall back to the
> >> name tag if no name:xx is given. Making a transliteration is also not
> >> the the function of the key, since transliterations can be automated.
> >> Making a translation is *certainly* not wanted!
> >>
> >
> >How can a data consumer know that whether end user of a certain
> >language is
> >going to understand the original language?
> >And transliteration cannot be automated. There are many specific rules
> >and
> >exceptions when transliterting place names in different language
> >software.
> >There are already some OSM-based software that would offer automatic
> >transliteration but their results are far from being usable. Making
> >translation is *absolutely essential* for people from different part of
> >the
> >world to make use of OSM data. Last time when I was travelling in some
> >foreign nations, I have to give up using OSM because of poor coverage
> >of
> >translated name for my language in that country which make me unable to
> >understand what the OSM map is saying.
> >
>
> Could you elaborate on this? I would like an example object that you tried
> navigating to and failed.
>
> Thanks in advance.
>

As an example, https://www.openstreetmap.org/relation/3970414 is a relation
for a district named as "Dalseo-gu" in Korea. To transliterate Korean name
into Chinese or Cantonese language, the general rule is that one need to
identify the etymology root of the Korean word. In this case it is "Dal
City (Ancient name of Daegu)'s Western District". The best software that
can do this matching is Google Translate the machine translation site but
even they can only offer ~90% accuracy in identify name of places (They
failed in this example), and that's barring name of places that don't
follow this rule including all Korean name that have no Chinese roots.
Those words need to independently phonetically or etymologically
translated. After identifying the etymological root, one can then
transmiterate the etymological root into Chinese characters, which have a
smaller but still non-zero chance of failing due to the simplification rule
of the Chinese character system especially for the Simplified Chinese. And
then in the end "Dalseo-gu" in Korean will be translated into "Daxiqu" in
Mandarin Chinese and "Datsaikui" in Cantonese.

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

Re: [Tagging] Which languages are admissible for name:xx tags?

[Phake Nick]

Names in OSM map is to show the world reader what each objects are.
Unlike Wikipedia and Wikidata, OSM map everything on the ground.
Let assume the world's common language is now priparaish, and English is
now only spoken by a small insignificant African tribe, and is also the
only language in the world that use latin script. And you as a member of
the English-speaking tribe, trying to navigate the map of the world on the
OpenStreetMap, and see objects everywhere outside the area of your little
tribe are in the format of လူတိုင်းသည် တူညီ လွတ်လပ်သော , do you think you
would be able to read and use the map? If you heard a news which said a
terrorist attack occurred at Ketsumisomewhere in local language, turn to
OpenStreetMap and search for the place name, and then find out there are no
Ketsumisomewhere in the world because your language is deemed spoken by too
few to be worth including into OSM and the only name listed in OSM for the
place is केट्सुमीसोममेरे, do you think it is going to be helpful?
According to OpenStreetMap's mission statement, one of the core value of
OSM is "We want OSM data to be used as widely as possible". You cannot use
OSM data as widely as possible without providing the name of all different
features in all different languages, even if some languages might only be
spoken by relatively few people, they are still human that can digest OSM
data. Do you think it is a good idea not to translate the name of an
"Nofoaga faʻapitoa mo fesoasoani faʻafuaseʻi" object into English because
no one speak English at the place it's established even thought people from
aroind the world travelling there who speak English might come and seek
help at the emergency assistance center?

> If an Indonesian mapper adds name:id=* tags to every village in northern
Finland, how is anyone to confirm that they are right or wrong?
They are to be confirmed by other Indonesian mappers.

在 2020年3月25日週三 22:23，Joseph Eisenberg  寫道：

> > "if the name is otherwise regarded correct by mainstream media or a
> language authority."
>
> In that case, please add it to wikidata with a reference, but it would
> not be appropriate for Openstreetmap.
>
> Unlike wikipedia and wikidata, which are based on references and
> citations to "authoritative" sources, Openstreetmap has always been
> designed as a primary source: we map real, current features which you
> can visit in person.
>
> I agree that names in fictional languages should not be added to
> name: tags, nor any name which cannot possibly be confirmed to be
> true or false by local mappers.
>
> If an Indonesian mapper adds name:id=* tags to every village in
> northern Finland, how is anyone to confirm that they are right or
> wrong?
>
> -- Joseph EIsenberg
>
> On 3/25/20, Jyri-Petteri Paloposki  wrote:
> > On 25.3.2020 12.58, Christoph Hormann wrote:
> >> In terms of our traditional values and principles active use of the name
> >> is not the necessary criterion, it is verifiable local knowledge.  Like
> >> with any kind of names practical verification of names would be
> >> possible by inquiring about the name to people locally.  This
> >> essentially means the following practical requirements:
> >>
> >> * there being a sufficient number of people present locally that
> >> speak/write the language in question.  Those don't have to be people
> >> living there, it can also be visitors.
> >> * these people knowing the name in said language - being able to look it
> >> up on some external source does not count, that is wikipedia
> >> verifiability, not OSM verifiability.
> >> * these people largely consistently agreeing on the same name.
> >
> > I slightly disagree with this one. IMO a name in a foreign language
> > would be admissible if it is recognised by native speakers of the
> > language either back home or in the local community OR if the name is
> > otherwise regarded correct by mainstream media or a language authority.
> >
> > I recently checked if the foreign cities listed in the Finnish Wikipedia
> > as having a specific Finnish name were correct in OSM. I stumbled upon
> > Yokohama, for which I didn't know there's a Finnish wording (Jokohama).
> > However once I saw it, it definitely is understandable and clearly
> > Finnish. It is also used by the Finnish mainstream media[1] and endorsed
> > by the Institute for the Languages of Finland[2], which is the authority
> > responsible for recommendations concerning the Finnish language. Still,
> > if asked, I wouldn't have instantly been able to recognise the name as
> > correct despite being a native Finnish speaker.
> >
> > 1) https://yle.fi/uutiset/3-10956002
> > 2) http://www.kielitoimistonohjepankki.fi/haku/jokohama/ohje/633
> >
> > Best regards,
> > --
> > Jyri-Petteri Paloposki
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
> >
>
> ___
> Tagging mailing 

Re: [Tagging] Which languages are admissible for name:xx tags?

[Phake Nick]

在 2020年3月25日週三 18:34，Frederik Ramm  寫道：

> Hi,
>
> On 25.03.20 11:19, Phake Nick wrote:
> > My guess is that about 5% of name:xx tags in OSM actually represent a
> > unique name in its own right; all others are either copies of the
> name
> > tag ("this city does not have its own name in language XX but I want
> > every city to have a name:xx tag so I'll just copy the name tag"), or
> > transliterations (or, worst case, even literal translations).
> >
> > Isn't that the function of the key?
>
> Unsure which of my list items you mean - copying the original name is
> not the function of the key; a data user can simply fall back to the
> name tag if no name:xx is given. Making a transliteration is also not
> the the function of the key, since transliterations can be automated.
> Making a translation is *certainly* not wanted!
>

How can a data consumer know that whether end user of a certain language is
going to understand the original language?
And transliteration cannot be automated. There are many specific rules and
exceptions when transliterting place names in different language software.
There are already some OSM-based software that would offer automatic
transliteration but their results are far from being usable. Making
translation is *absolutely essential* for people from different part of the
world to make use of OSM data. Last time when I was travelling in some
foreign nations, I have to give up using OSM because of poor coverage of
translated name for my language in that country which make me unable to
understand what the OSM map is saying.

> Adding Klingon name would not cause copyright issue since vocabularies
> > are not copyrightable.
>
> If someone adds a name and specifies a source web page, and the source
> web page says "all rights reserved", then I will not start a legal
> discussion.
>

Adding the word "All right reserved" on a page doesn't mean it is actually
all right reserved. Of I write "all right reserved" under my shop's tirle,
would you stop adding my shop's name into OSM?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Which languages are admissible for name:xx tags?

[Phake Nick]

在 2020年3月25日週三 17:27，Frederik Ramm  寫道：

> Hi,
>
> the "name:xx" tags are something of an exception in OSM because while we
> defer to "local knowledge" as the highest-ranking source normally, this
> is not being done for name:xx tags. It is possible for no single citizen
> of the city of Karlsruhe to know its Russian name, but still a Russian
> name could exist. Who is the highest-ranking source for that?
>

I believe in this situation, local knowledge refer to language of users of
the language.

My guess is that about 5% of name:xx tags in OSM actually represent a
> unique name in its own right; all others are either copies of the name
> tag ("this city does not have its own name in language XX but I want
> every city to have a name:xx tag so I'll just copy the name tag"), or
> transliterations (or, worst case, even literal translations).
>

Isn't that the function of the key? How else are you supposed to use data
in OSM for users who use different languages? Even if a name isn't unique,
how can data consumer figure out the name automatically?

A while ago we had a longer discussion about Esperanto names; in that
> discussion, it was questioned whether Esperanto could be in the name tag
> but nobody disputed that adding name:eo tags is ok, even though
> Esperanto is an invented (or "constructed") language.
>

I cannot see why Esperanto being constructed language would cause any
problem to the addition of value in the language into OSM. The wiki
description for lang:xx say it accept BCP47 values, and the "xx" part of
the BCP47 is actually based on the ISO 639standard, and eo is indeed the
ISO 639-1 code for Esperanto.

Yesterday someone added a few dozen Klingon names to countries in OSM. I
> have reverted that because of a copyright issue, but I think we also
> need to discuss which languages we want to accept for name:xx tags.
>

Adding Klingon name would not cause copyright issue since vocabularies are
not copyrightable. It's like if you come up with the word "McDonald's" and
then say it is the name of your shop, you cannot stop others from speaking
or writing the word "McDomald's" or claim there are any copyright involved
in such usage.

In my opinion, a name:xx tag should only be added if you can demonstrate
> that people natively speaking the living language xx are actually using
> this name for this entity.


How are editors supposed to demonstrate that when editing OSM? This is
beyond ridiculous.

I think we have a very unhealthy inflation of
> names in OSM that are added by "single-purpose mappers" - they come in,
> stick a name:my-favourite-language tag onto everything, and go away
> again.


They are a great help to the project of OpenStreetMap and I have been
trying to find and promote tools that will help people to translate names
into their languages.

Nobody knows if these names are even correct, and nobody cares
> for their maintenance. The country North Macedonia changed its name
> almost one year ago, yet roughly half of its ~ 170 name tags are still
> what they were before this change. Nobody cares; these names suggest a
> data richness that is not backed up by an actual living community that
> cares for them.
>

That is just the same problem with TIGER map data. I don't think anyone
have ever proposed removing United States data from the OpenStreetMap
database due to lack of maintainers back then?

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

Re: [Tagging] Criticism of PTv2

[Phake Nick]

On 2020-03-11 Wed 06:03, Alan Mackie  wrote:

>
>
> On Tue, 10 Mar 2020 at 20:54, Phake Nick  wrote:
>
>> On 2020-03-10 Tue 19:47, Dave F via Tagging 
>> wrote:
>>
>>> > A platform is a platform, a perfectly flat bit of sidewalk isn't.
>>>
>>> +1
>>>
>>> DaveF
>>>
>>
>> In the sense of bus, sidewalk could be a platform because they are raised
>> from the driving road surface. You can google "bus platform" and see many
>> example of the word being used in real world.
>>
>>>
> I'll buy into that for the ones with the special raised kerb that some
> buses can get more or less level to, and for specially constructed ones in
> bus stations, but not for an unmodified area. I suspect in many regions
> it's barely higher than the road camber and despite the difficulty for
> wheelchairs etc, wouldn't normally be seen as "raised" by your hypothetical
> "average person".
>
> For me that Google search returns images that tend towards the "more
> heavily modified" end of the spectrum, but who knows what sort of
> personalisation they're running.
>
> -Alan
>

I don't think a term must be familiar by general public to be used in OSM,
people who know what it is understand the meaning of the term should
already be sufficient.

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

Re: [Tagging] Criticism of PTv2

[Phake Nick]

On 2020-03-10 Tue 19:47, Dave F via Tagging 
wrote:

> On 09/03/2020 21:00, Alan Mackie wrote:
> >
> > So it's better to label them all as platforms? I can't see any raised
> area
> > in a typical bus stop:...
> >
> >
> > Why would we tag it as if it looks like this?...
>
> This is just one example of poor concepts implemented in PTv2. We should
> be mapping *physical*, not imaginary objects. They couldn't even come up
> with an original tag so hijacked an existing one, while completely
> disregarding it's dictionary meaning.
> > A platform is a platform, a perfectly flat bit of sidewalk isn't.
>
> +1
>
> DaveF
>

In the sense of bus, sidewalk could be a platform because they are raised
from the driving road surface. You can google "bus platform" and see many
example of the word being used in real world.

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

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

[Phake Nick]

On 2020-03-11 Wed 03:20，Richard  wrote:

> On Fri, Mar 06, 2020 at 04:07:02PM +0100, Peter Elderson wrote:
>
> > I wouldn't know. It seems strange to me that established routes have to
> be
> > re-routed to display or use them. How can you be sure the re-created
> route
> > is the one that is defined by the operator? Keeping as an example the
> city
> > PT map.
>
> Is the route "defined"? I would think the operator only defines stops and
> schedules. Most of the time busses and trains tend follow a nearly fixed
> route but may deviate from it anytime if there is a reason.
>
> Richard


Here most bus routes are legally defined in term of which roads they shall
use. Deviation due to temporary situation even if it doesn't affect
existing stops would usually have prior notice unless during emergency.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

[Phake Nick]

At 2020-03-09 Mon 16:04, John Doe   wrote:

>
> Hey, thanks for sharing your views 
>
> 07-Mar-2020 03:01:41 Phake Nick :
>
> > [...] for such renderer to work, access restriction for public transit
> vehicle need to be complete, which is rather difficult not just because of
> the work it take or the current incompleteness of the amount of keys in OSM
> that can be used to represent multiple localized types of transportation,
> but also because of things like mechanical restrictions of bus models that
> would not be available in any public document and cannot be verified
> outside of the public transit company.
>
> I feel that this information can largely be approximated from road
> classifications. PT Assistant already complains if a bus route is using a
> road lower than a certain classification. As and when turn restriction data
> is added, routers can adapt the route automatically.
>

It is not the question of grade but it is related to turn diameter and
obstacles and emission regulation and such on different roads, and they
differ according to specific bus models used by each routes.


>
> > [...] how can editors know when it is necessary to add a waypoint to
> show a route correctly?
>
> I think it will always need mapper testing, as it already does. But PTv3
> does remove a lot of moving parts, and makes creation and maintenance of
> routes easier.
>

In PTv2 one can simply select all the ways and then add them into relation,
unlike this proposal where I woild need to try and see where I needs to add
waypoint, and identify if there are any way that can be rendered
differently on different renderer despite it might coincidentally appear as
expected on editor's software.

>
> > If a new road is being built next to existing road which doesn't affect
> existing public transit routes, how to preemptively make sure routing
> engines won't automatically redirected a route to the new road?
>
> In this case, since the platforms being served haven't changed, I think
> you'll find that
> 1. The likelihood of the route changing is very low. Even hail and ride
> routes shouldn't be likely to change much, since the via points used to
> define them would probably keep the routers on track.
> 2. Even if it does change, the platforms are the same and the router is
> still preferring the fastest path between them - users are unlikely to be
> greatly affected. At worst, accuracy of ETAs could be affected.
>

1. Yes, the chance of route changes are very low, and that's why I ask how
to fixate a route against such changes which would affect how routing
engines route a route.
2. As I have mentioned previously, my greatest use of PT mapping is the
geometry of the routes. So even if stops are the same that'd still affect
my intended use of those routes.


> What I have in mind is the case of Delhi's NH9, in which a road was
> changed from two to four carriageways. In such a situation, with the
> constraint of the existing stops, routers would have to ignore the new
> inner carriageways and stick to the outer carriageways, which is exactly
> what happened on the ground  If you have some other examples in mind, it
> would help us all to discuss their specifics.
>

For example, routes like route E11 in Hong Kong which continues to
use Cheung Tsing Tunnel instead of Nam Wan Tunnel after the latter finish
construction.



> > Third, way points are more transient than ways. It's more easy for a
> node to be deleted or replaced when editing geometry than ways. How to
> maintain integrity of a route geometry when others edit road geometry?
>
> To verify this, I tried deleting a stop position which was part of a route
> relation. Both JOSM and Vespucci warn you about the relation, and ask for
> confirmation. iD does not, but fortunately someone's already made an issue
> about it and they're considering it -
> https://github.com/openstreetmap/iD/issues/5846
>
> I've added FAQ entries for all these, thanks for the feedback! I hope I'm
> able to address your concerns about our proposal.
>
>
> ___
> 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 - Public Transport v3

[Phake Nick]

As my personal biggest use of the public transportation relationship is to
visualize the ways that public transit route would take, I must say I am
personally against the idea.
>From my personal experience of using a non-OSM website "wikiroutes", which
is a website that let public enter public transit information from around
the world into the platform for navigation and suggestion purpose by
letting users first pick stop.m locations on a map, then try to
automatically display the routing and finally let users correct the routing
to complete the public transit route record in thdir database, I would say
it's easier said than done to expect a software being able to auto-generate
the ways based on station location, even with additional waypoints.
First of all, I don't think there are any existing routing engines for
trains on rail or bus or minibuses on street, so they will need to be
developed first for renderer to be able to visualize these routes,
especially for roads that regular vehicles cannot use. And then, for such
renderer to work, access restriction for public transit vehicle need to be
complete, which is rather difficult not just because of the work it take or
the current incompleteness of the amount of keys in OSM that can be used to
represent multiple localized types of transportation, but also because of
things like mechanical restrictions of bus models that would not be
available in any public document and cannot be verified outside of the
public transit company.
Second, when a user map a public transit relation using waypoints to handle
a special case, how can they know when a waypoints would be needed? Even if
such renderer is built into editor to show which route it would take and
let users add waypoints when that's incorrect, different routers used by
different renderers might route a route differently, what doesn't need a
waypoint on one router maybe different on another router, how can editors
know when it is necessary to add a waypoint to show a route correctly? If a
new road is being built next to existing road which doesn't affect existing
public transit routes, how to preemptively make sure routing engines won't
automatically redirected a route to the new road?
Third, way points are more transient than ways. It's more easy for a node
to be deleted or replaced when editing geometry than ways. How to maintain
integrity of a route geometry when others edit road geometry?

At 2020-03-06 Fri 18:08, John Doe  wrote:

>
> Stereo and I have been working on a schema that makes it easier to create
> and maintain public transport route relations. We would like to invite
> feedback, questions, and suggestions, so it can mature and hopefully gain
> widespread use.
>
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Simpler_public_transport_route_relations
>
>
>
> ___
> 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] Disputed territory mapped as a country

[Phake Nick]

For disluted territory marked as country boundary, there is also
https://www.openstreetmap.org/ this big box in South China Sea.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] a kind of name:XX-modern-not-used

[Phake Nick]

You can consider using BCP 47 extension T as language tag in OpenStreetMap
follow BCP 47 practice. The extension T is for denoting content that have
been transformed from one language into another, so if you write fr-t-frm
then it would denote the content is transformed fron Middle French
(15th-17th century) to Modern French (with frm being the ISO 639 code for
Middle French, and thus you can write name:fr-t-frm=X into the object. You
can read the BCP47 original document for more information.

在 2020年1月24日週五 05:51，marc marc  寫道：

> Hello,
>
> some words in the name of some street is not understood by some people.
> these are often old notations, sometimes borrowed from another language
> but used in the official language to name this street.
> street sign have those "one-name-but-in-mixed-language" and only that.
>
> a contributor spends time trying to find the meaning of these words and
> replaces the name with a modern version, absent both from the ground and
> from use, in favour of a name that is the one that could have been
> written if this street had been created today.
> it's a bit as if this contributor added to Big Ben name:fr="Grand Ben"
> or "Nouveau York" for "New York"
> it's obviously wrong. but how could we keep track of the meanings
> of the words from the old days?
> I thinking about a kind of tag name:fr-modern-not-used or a kind of
> name:etymology but which does not inform a person but an object, a
> building, a profession, ...
>
> Any ideas?
>
> Regards,
> Marc
> ___
> 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] amenity=tourist_bus_parking

[Phake Nick]

With all those different types of parking facilities, wouldn't it be easier
to create some tag combinations like the following?
amenity=parking
parking=bus
bus=tourist_bus
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Roundtrip and closed loop in relations

[Phake Nick]

Reminder 1: There are loops within bus route doesn't mean the route is a
circular or round trip route.
Reminder 2: The roundtrip=* key is designed to use in combination with
hiking routes or bicycle routes. A hiking/bicyle route that goes A→B→A
which come back with the same start point with exact same alignment as the
other direction doesn't really mean anything so I don't think a special
value would be needed for such case. As for bus routes, whether or not it
goes back along same road doesn't really mean anything either.

在 2019年12月21日週六 17:28，Warin <61sundow...@gmail.com> 寫道：

> On 21/12/19 19:49, Francesco Ansanelli wrote:
>
> Dear Volker,
>
> I saw that someone went ahead and changed the wiki again:
>
> Use roundtrip=yes to indicate that start and end of a route are at the
> same location.
>
> I think this new definition matches your idea of roundtrip and it's fine
> for both definitions.
> My last offer is to abandon the closed_loop tag in favour of:
>
> roundtrip:type=linear|circular
>
> Do you agree?
>
>
> No.
>
> "Type" means nothing. Perhaps roundtrip:route=*???
>
> As for the values .. you will need to define them!
>
> 'My' local bus route starts off with ways that are used both directions ..
> and then separates into a loop where the segments are only used in one
> direction.
>
> I could imaging routes that have several loops  used in one direction and
> then ways that are used in both directions .. arrr there is another  route
> that does that ...
>
> So what values will there be to cover complex cases???
>
>
> Francesco
>
>
> Il ven 20 dic 2019, 22:45 Volker Schmidt  ha scritto:
>
>> Please revert the roundtrip wiki change, but let's put any other
>> wiki-changes on halt for a moment.
>> What we need to do is to find out how the roundtrip tag is being used
>> (the wiki is suposed to document the actual use, not what the use should
>> be) and in particular if there is a more-than sporadic use of
>> roundtrip=yes|no for anything else than loop=yes|no.
>> It's difficult to get reliable quantitative results, but:
>> A fast overpass turbo wizard query
>> "type:relation and route=bicycle and roundtrip=yes in
>> Italy|France|England|USA|Bayern"
>> resulted in
>> Italy: 58 lines with at best a handful of them not closed loops
>> France: 358 lines with maybe 10 non-loops
>> England:  25 lines, all loops.
>> USA:  29, about 6 non-loops
>> Bavaria 213, did not find any non-loops
>> For me this is a strong indication that the large majority of all cycle
>> route relations in these countries that have a roundrip=yes are in fact
>> loops and that that this is the de-facto use of the tag.
>> I think this is a strong case against any change.
>>
>> Taginfo points in the same direction
>> 12665 roundtrip=no
>> 21774 roundtrip=yes
>> 42 closed_loop=yes
>> no closed_loop=no
>>
>> Volker
>>
>>
>>
>>
>>
>>
>> On Fri, 20 Dec 2019 at 18:17, Francesco Ansanelli 
>> wrote:
>>
>>> In my opinion the options are:
>>>
>>> - deprecate roundtrip in favour of 2 tags with a generally agreed naming
>>> convention (best at this point)
>>> - keep roundtrip and closed_loop with the wiki definition I did change
>>> (relations must be updated accordingly)
>>>
>>> I read many of you asked a revert, I just want to point out that is not
>>> a resolution because tag is currently messed up
>>>
>>> Il ven 20 dic 2019, 15:08 Steve Doerr  ha
>>> scritto:
>>>
>>>> On 19/12/2019 22:48, Phake Nick wrote:
>>>>
>>>> Merriam Webster and some other resources you have quoted are dictionary
>>>> for American English, not the variant of English used by OSM. Posts by
>>>> original author of the topic on the wiki talk page have explained the
>>>> meaning of the term in British English.
>>>>
>>>>
>>>> The OED definitions read as follows:
>>>>
>>>> Originally U.S.
>>>>  A. n.
>>>>  1.
>>>>  a. A journey to a place and back again, along the same route; (also) a
>>>> journey to one or more places and back again which does not cover the same
>>>> ground twice, a circular tour or trip.
>>>>
>>>>  b. Baseball. A home run. Cf. round-tripper n. 2.
>>>>
>>>>  2. In extended use and figurative, esp. (Mining and Oil Industry) an
>>>&

Re: [Tagging] [Talk-us] Trunk VS primary,

[Phake Nick]

Problem with applying different road classification system from different
places with their individual tags onto local roads is that:
1. Even if we ignore countries that have different rules within different
part of a single country, there are still about 200 countries in this
world. Each of them having different road classification values, supposedly
each country should have at least a few different levels, would mean there
are thousand of different values that data consumer or renderer or routing
engine and such need to handle and process, which is a pretty big task for
anyone who wish to use these data. It also make inter-country data
comparison difficult or impossible.
2. It will be difficult for a mapper from country A to map for country B
which might be less mapped through means like satellite mapping, video
mapping or site visit, as the mapper would need to familiar themselves with
local classification instead of applying universal standards onto them.
3. Road classification system within each single country is not always
static. Country sovereignty on localities are not static either. When
either of that change, you would need to re-tag every single road in that
place or that country to the new standard if you decided to introduce
country-specific tagging, which would be a very big task.
4. If you are going to setup a table to tell people which road level in
which country is equal to what in other countries, then why not just tell
people with a table that these roads which are tagged with universal tags
corresponds to those level in local classification?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Roundtrip and closed loop in relations

[Phake Nick]

Merriam Webster and some other resources you have quoted are dictionary for
American English, not the variant of English used by OSM. Posts by original
author of the topic on the wiki talk page have explained the meaning of the
term in British English.

在 2019年12月20日週五 06:19，Francesco Ansanelli  寫道：

>
>
> Il gio 19 dic 2019, 23:00 Warin <61sundow...@gmail.com> ha scritto:
>
>> On 20/12/19 01:16, Francesco Ansanelli wrote:
>> > Dear List,
>> >
>> > I have updated the roundtrip page and created the closed loop proposal
>> > in order to address the misuse of the first tag:
>> > https://wiki.openstreetmap.org/wiki/Key:roundtrip
>> >
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:closed_loop=yes
>> >
>> > Please let me know what you think
>> >
>>
>> The word 'round' implies circular. So a 'roundtrip' could be a circular
>>
>
> I'm not a mother tongue but:
>
> https://www.merriam-webster.com/dictionary/round%20trip
> Definition of *round trip*
>
> : a trip to a place and back usually over the same route
> https://www.thefreedictionary.com/roundtrip
>
>
> A trip from one place to another and back, usually over the same route.
> https://www.yourdictionary.com/round-trip
>
> round trip
>
> noun
> A trip from one place to another and back, usually over the same route.
> Idk if it's clearer why I tried to match the definition.
>
> route that does not go from A to B and back along the same route, it
>> could go A to B to C and then back to A via D. As such your rewording is
>> wrong and does not match present use.
>>
>> Revert your change.
>>
>
> How about a voting?
>
>
>> If you want to signify a route that goes from A to B and back along the
>> same route invent another tag, roundtrip is not it.
>>
>> ___
>> 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] Roundtrip and closed loop in relations

[Phake Nick]

The current usage is that, "Use roundtrip=yes to indicate that the start
and finish of the route are at the same location". As in a route from Paris
to Milano to Frankfurt then back to Paris would be tagged as roundtrip=yes.
You have edited the wiki against established usage to make it become a no.
A word used as a key isn't perfect doesn't mean you can suddenly edit the
wiki to change its definition without regard of all the established usage
in the osm database.

在 2019年12月20日週五 01:21，Francesco Ansanelli  寫道：

> Dear Volker,
>
> I haven't change the meaning of Roundtrip, but just reworded to clarify it.
> Roundtrip yes is not a closed loop...
> Please check this discussion:
>
> https://wiki.openstreetmap.org/wiki/Talk:Key:roundtrip#loop
>
> Cheers
> Francesco
>
>
> Il gio 19 dic 2019, 15:40 Volker Schmidt  ha scritto:
>
>> Please relable your "roundtrip" proposal  as such.
>>
>> Please do not change the meaning of an established tag. roundtrip=yes|no
>> is used about 34k times, based on a different definition, see
>> https://wiki.openstreetmap.org/wiki/Cycle_routes#Relations
>>
>> Volker
>>
>> On Thu, 19 Dec 2019 at 15:18, Francesco Ansanelli 
>> wrote:
>>
>>> Dear List,
>>>
>>> I have updated the roundtrip page and created the closed loop proposal
>>> in order to address the misuse of the first tag:
>>> https://wiki.openstreetmap.org/wiki/Key:roundtrip
>>> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:closed_loop=yes
>>>
>>> Please let me know what you think
>>>
>>> Many thanks
>>> Best regards
>>> Francesco
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] refugee camp

[Phake Nick]

If you look at it from a temporary residence for the group of people
perspective, then I guess tags like place=village/town/neighbourhood could
be better choices?

在 2019年6月10日週一 20:18，Joseph Eisenberg  寫道：

> I understand why refugee camps have been mapped with
> amenity=social_facility - it's the closest existing tag, since
> tourism=camp_site is clearly wrong and landuse=residential isn't quite
> right.
>
> However, I don't think that large refugee camps are a perfect fit for
> amenity=social_facility.
>
>  Most of these are group homes (eg orphanages), nursing homes (for the
> elderly), hospices, assisted living facilities, homeless shelters,
> outreach facilities for the homelss, etc - they provide services for
> vulnerable groups in the community who have difficulty living on their
> own.
>
> Refugee camps are closer to an informal residential settlement in many
> developing countries, especially those that are larger or have been in
> place for more than a few months (these are the ones most likely to be
> mapped, I believe).
>
> I would encourage creating a proposal and a new tag specifically for
> these sorts of places. There could perhaps be a distinction between
> sites for people temporarily displaced locally (eg a camp for people
> in the same town, after a flood) versus long-distance or international
> migrants.
>
> On 6/10/19, Jan S  wrote:
> >>
> >> On 6/6/2019 5:27 PM, Graeme Fitzpatrick wrote:
> >> >>* I'd suggest something like social_facility=temporary_housing.
> >> *>>>* To me, social_facility doesn't quite cut it for "refugees".
> >> Refugees
> >> *>* strike me as people fleeing from war / massive natural disaster -
> >> *>* social_facility comes across as small scale for homeless people /
> >> *>* women's refuge sort of thing?
> >> *>>Browsing through the values of social_facility:for, it's a lot more
> >> diverse than just victims of abuse and poverty -- and
> >> social_facility:for=refugee(s) has hundreds of uses. But you definitely
> >> have a point about scale -- some of these camps house over a hundred
> >> thousand people. That's on the scale of a small city -- a community, not
> >> a facility. So maybe place=refugee_camp is a better solution.
> >>
> >> J
> >>
> >>
> > Picking up the subject again (and having noticed that the refugee camps I
> > know in my area are not tagged at all or at least very rudimentary simply
> > as amenity=social_facility), I've done another search on the internet and
> > have dug up this wiki page:
> > https://wiki.openstreetmap.org/wiki/Refugee_Camp_Mapping
> >
> > It's been modified in 2018 for the last time, is quite rudimentary in the
> > description of the tags and values proposed and apparently oriented
> mainly
> > at makeshift camps in Africa or the Levante. It would be an effort to
> bring
> > some order into this and to make it more diverse (covering anything from
> > spontaneous camps like the infamous Jungle in Calais or the already
> > dismantled Idomeini camp, to permanent structures like asylum-seeker
> > reception centres like this: https://www.openstreetmap.org/way/390153052
> ).
> >
> > I'll see if I can give it a try over the next weeks... or would that be a
> > task for a coordinated action?
> >
> > Best, Jan
> >
>
> ___
> 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] Opening hours syntax for non Gregorian calendar

[Phake Nick]

Ah, and about the Chinese calendar leap month I mentioned a while ago, it
seems like some algorithm nowadays would tweet those leap month as negative
values, for instance if it is the 8th month that get leaped, then it could
be computationally represented as Lunar month -8.

在 2019年5月24日週五 14:57，Colin Smale  寫道：

> Is the Jewish calendar in active use? I recall it has an extra month every
> few years, and rules about months not starting on a Monday or something
> like that. Might be a nightmare for opening_hours.
> ___
> 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] Opening hours syntax for non Gregorian calendar

[Phake Nick]

then again, what about month numbering in Chinese calendar? There are no
month name, only lunar month 1, lunar month 2, etc.

在 2019年5月22日週三 20:33，Paul Allen  寫道：

> On Wed, 22 May 2019 at 09:16, Rory McCann  wrote:
>
>>
>> I don't know much about the islamic calendar. Could you give some
>> examples of what data you'd like to enter? Most "opening hours" don't
>> need to include years, so is that a problem? You could just use the
>> islamic calendar month names if needed.
>>
>
> The problem with that is the same problem as allowing every language on
> the planet to
> use their own abbreviations for month names.  Only worse.
>
> For better or worse, we standardized on three-letter abbreviations for
> English month names.  We
> couldn't have gotten away with one- or two-letter abbreviations because
> then there would have been
> collisions: "M" could be March or May, "Ma" could be March or May, etc.
> Allow abbreviations in
> other languages using the Latin alphabet and you get collisions even with
> three-letter
> abbreviations.  So we use English abbreviations, applications are free to
> translate them
> into the user's own language.
>
> The problem is possibly fixable by switching to month numbering.  It
> doesn't make the translation
> aspect much easier since most modern programming languages can handle
> hashes (aka
> dictionaries, aka associative arrays) so there's no gain there.  It makes
> human comprehension
> harder, because many people have difficulty mentally translating month 8
> to August, so there's
> a disadvantage there (for those with English as a first language; for
> others it would probably
> be an advantage.  It would require editor support (not impossible) and a
> mass edit of
> the database (not impossible, especially as there's a guaranteed
> one-to-one correspondence).
> I don't see OSM making the switch to numeric months, because it's a lot of
> change for little
> gain, but I could be wrong.
>
> Now we throw in the Islamic calendar.  Which is luni-solar.  It's based
> around the phases of the
> moon, and there is not a one-to-one correspondence you get between, say,
> December and the
> Welsh Rhagfyr.   In the Islamic calendar, each month can be 29 or 30 days
> long, depending upon
> the visibility of the moon.  Except for the Shia Ismali Muslims, where
> odd-numbered months have
> 30 days and even months have 29 days.  I've neglected leap year handling
> for simplicity.  Then
> there's the Judaic calendar, which is similar in some ways to the Shia
> Islamic one, except it
> is prone to fiddling month lengths to avoid holy days falling on certain
> days of the week.
>
> Is this a real problem?  MARchesvan in the Judaic calendar is a collision
> with MARch, so we'd
> have to switch to 6-letter abbreviations.  The Islamic calendar has
> Rabi-Al-Awwal and
> Rabi-Al-Thani; Jumada-Al-Awwal and Jumada-Al-Thani; Zul-Qaadah and
> Zul-Hijjah, so that
> would need some though (are RAA, RAT, JAA, JAT, ZUQ ZUH acceptable?).  Or
> we switch to
> month numbers, remembering that Julian month 6 is not Islamic month 6 or
> Judaic month 6
> and that Shia Islamic month 6 isn't (quite) Judaic month 6 and that you
> have no idea which
> calendar is in use, just that it's month 6 in some unspecified calendar.
>
> There are other calendar systems out there.  Parts of the world still use
> the Julian calendar,
> which is currently 13 days ahead of the Gregorian calendar.
>
> As others have pointed out, we might be able to accommodate holidays.
> Although we're likely
> to end up with collisions in the two-character namespace we currently
> allow for them.  Feasible,
> maybe.  Month names are something that isn't feasible without namespacing
> opening_hours.
>
> Oh, and then there's the fact that days start at midnight in the Gregoran
> calendar but start at
> sundown in Islamic and Judaic calendars.  And some countries are on solar
> time, which
> can be up to 14 minutes behind or 16 minutes ahead of local mean time.
> Right now we
> assume that times are in the local timezone and that the timezone is
> offset by a known amount
> (usually a multiple of one hour, sometimes a multiple of 30 minutes or
> even a multiiple of
> 15 minutes) from UTC, not that local time drifts around.  If people want
> to specify times as
> solar time, because that's what their country uses, we again need to
> namespace
> opening_hours.
>
> And don't forget that whatever we come up with has to work in conditional
> statements.  So we
> can have major changes to opening_hours that will require support in
> editors and applications
> and will probably have problems that we only discover down the line or we
> namespace the
> opening_hours to keep things simple and to prevent a problem in one
> affecting all of them.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

Re: [Tagging] Opening hours syntax for non Gregorian calendar

[Phake Nick]

That doesn't seems to solve the problem that would occur. For instance, how
to represent the first Sunday (a feature in Gregorian calendar) after
Chinese traditional ceremony X (a feature in Chinese traditional calendar)
in the opening time syntax, if they're split up for "simplicity"? What
about when the opening time also cover non-holiday festivals that only
occurs according to either calendars?

On 2019-05-18 Sat 04:50, Paul Allen  wrote:

> Problem of splitting: what if a mapper gives the opening times in both
> calendar_X and calendar_Y
> and they disagree?  Consumers will have to have rules like: in country_Z
> use calendar_X if given,
> otherwise use standard opening_hours if given, otherwise use calendar_Y if
> given, otherwise
> pick at random from what is left.
>
> --
> 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] Requiring area=yes with barrier=wall, barrier=hedge and other usually linear features when mapped as an area`1

[Phake Nick]

area=no would also applies to amenity=park or landcover=* if you are
tagging them in the same object.

在 2019年4月14日週日 05:16，Warin <61sundow...@gmail.com> 寫道：

> As a closed way would normally be taken as an area,but in the case of this
> barrier it is required not to be an area, why not use the tag area=no?
>
> Tag the unusual rather than the normal?
>
> Then, as Martin says, use the way of the barrier in a multipolygon
> relation for a park.
>
>
>
> On 14/04/19 06:43, Martin Koppenhoefer wrote:
> >
> > sent from a phone
> >
> >> On 13. Apr 2019, at 19:58, Shawn K. Quinn  wrote:
> >>
> >> It makes no sense to have to add separate ways for barrier=fence and
> >> leisure=park when the fence surrounds the entire park.
> >
> > you could make the park a multipolygon.
> >
> >
> > 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] Requiring area=yes with barrier=wall, barrier=hedge and other usually linear features when mapped as an area`1

[Phake Nick]

>Example: I'm considering using the tag "area=yes" to check if a
>barrier should be rendered as an area. Right now "barrier=hedge" is
>rendered as an area in the Openstreetmap-carto if it is imported as a
>polygon. This happens for all closed ways that are tagged "area=yes",
>but it also happens if the closed way is tagged with both
"barrier=hedge" and "landuse" or "natural" or "amenity", because these
>keys are normally imported as areas

I don't think those tags like "landuse" should exist in the same OSM object
as closed way barrier tag, because the area inside closed way is a
different object from the barrier that make the closed way and thus per the
one feature one object rule they should be drawn separately
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping of indigenous sacred / ceremonial sites

[Phake Nick]

There are religion=chinese_folk and religion=vietnamese_folk for indigenous
religion for Chinese people and Vietnamese people, you might wish to check
is there similar existing value in use for Australian aboriginal religious
sites, if not you might wish to create a new value.

在 2019年4月3日週三 05:30，Graeme Fitzpatrick  寫道：

> There has been a recent discussion on the Australia list regarding mapping
> of sites that may be considered sacred by the indigenous peoples of that
> area
> https://lists.openstreetmap.org/pipermail/talk-au/2019-April/012538.html ,
> & the question has been asked as to how it's done (or not!) in other parts
> of the World?
>
> Is there an OSM policy on mapping sacred / ceremonial sites?
>
> Are there any other places where the local original inhabitants may not
> want their sites mapped, & how did you work it out?
>
> 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] Bus rapid transit: service=bus vs service=busway vs no service tag

[Phake Nick]

Then how to tag brt-bus-only road that ban regular buses?

在 2019年3月29日週五 05:40，Martin Koppenhoefer  寫道：

>
>
> sent from a phone
>
> > On 28. Mar 2019, at 21:07, Phake Nick  wrote:
> >
> > A problem with using something like service=bus is that it implies all
> buses can use it but in many cases BRT roads are only open to BRT buses and
> ban all other buses?
>
>
>
> „bus“ in OpenStreetMap, at least the key, does not mean all buses (vehicle
> category), it means all buses acting as public service vehicle.
>
> 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] Bus rapid transit: service=bus vs service=busway vs no service tag

[Phake Nick]

A problem with using something like service=bus is that it implies all
buses can use it but in many cases BRT roads are only open to BRT buses and
ban all other buses?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] I have been tagging mosques wrong all along

[Phake Nick]

So, If I understand correctly, Mosque are more like a Islamic version
Monastery?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - Top up v4

[Phake Nick]

The scheme seems a bit unnecessarily confusing by being unnecessarily
specific. Like what tag should I use for a place that can top up my Alipay
account directly?

在 2019年1月29日週二 23:06，Daniele Santini  寫道：

> The first voting for the Top up  proposal was rejected. I have changed the
> proposal removing the most disliked parts and started a new voting:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Top_up
> Kind regards
> --
> Daniele Santini
> http://www.dsantini.it
> ___
> 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] Expand the key:opening_hours

[Phake Nick]

Of course such shop will also need to indicate the closing date in
Gregorian calendar fashion, but as those date are not fixed, if you are
typing that information in Gregorian calendar into OSM then you're
effectively inputting one-off event into OSM that needs to be changed every
year to match the calendar of the year.

在 2019年3月17日週日 01:57，Simon Poole  寫道：

>
> Am 14.03.2019 um 23:18 schrieb Phake Nick:
>
>
>
> 在 2019年3月14日週四 20:38，Simon Poole  寫道：
>
>> Some more comments:
>>
>> - the OH values are currently always evaluated in the local time zone
>> (or to go even a bit further in a local context as the location they
>> apply to is always known), so a time zone indicator would be only needed
>> in the cases that require different processing, the question is if that
>> is common enough to justify the additional complication.
>>
> The three most prominent area that are still using the calendar nowadays
> are China, Korea, Vietnam. Each of them have their own version of this
> lunar calendar with the most notable difference being the meridian used to
> create the calendar. So that once in a few years you could see reports
> saying that the lunar calendar and the festival that depends on it are not
> correct on some software.
>
> Let's say you represent the Lunar New Year as L01 01. The software can
> assume it mean Chinese New Year in China, Vietnamese New Year in Vietnam,
> and Korean New Year in Korea. So far so good. But then these festivals
> aren't just celebrated within these three countries. Places like Thailand,
> Indonesia, Japan, Australia, America, and many other countries around the
> world all have different events that would take place for the Lunar New
> Year. Sometimes they're commercial events that are currently catering
> specifically to Chinese New Year. Sometimes they are diaspora population
> that celebrate the festival on the same day as their parent countries. You
> cannot know which exact day it's referring to without referring to the
> timezone being used to calculate the calendar, and at least it need to
> specify Korean/Chinese/Vietnamese version and that is assuming the region
> will not create any new timezone in the future, like how time changes
> related to the Vietnamese war caused the North Vietnam and South Vietnam
> celebrated the new year at different date back then and resulted in some
> military advantages.
>
> That's all fine and dandy, but the OSM opening_hours tags is for the
> opening hours of facilities and similar, not a general purpose event
> description facility. So I would expect that a shop in AUS that is closed
> on a Chinese holiday to indicate that in a local Gregorian calendar fashion.
>
>
> One might think it'd be easier to add CNY/KNY/VNY into the variable
> holiday separately like easter instead, but there are a number of other
> events that're celebrated based on local lunar calendar and is celebrated
> at more places than those aforementioned countries, like Confucius
> birthday, mid-autumn festival, double nine festival, and so on. If
> calendar-specific version of all these holidays are all getting their own
> values as variable-holiday then there would be too many of them.
>
> And there also other scenario that timezone value is useful, for instance
> iirc Fiji decided that the country will implement DST but the school system
> operation time will not follow the transition. Or in places like Xinjiang
> or West Bank where there are two different timezones used by different
> population living in same area.
>
>
>> - Summer and winter solstice can be, as far as I can see, modelled as
>> additional variable_date values (currently only "easter" is defined), I
>> would avoid qualifying them with months as again, that require parser
>> changes that will cause issues.
>>
>
> Except other solar terms are still used. For example March equinox and
> September equinox are national holiday in Japan. Setsubun celebration in
> Japan is mainly a day before first solar term in February but also a day
> before first solar term in May, August, November. Qing Ming (mainly China,
> Korea, etc.) is the first solar term in April.
>
>
>> - Lunar months: are there any common names for these instead of just
>> numbering? And how are the "leap" variants supposed to be different?
>>
>> Simon
>>
>
> It is usually just numbering, but in Chinese there are nickname for the
> 11th and 12th month, while in Japanese there are nickname for all the
> months. Consider that those nick name are less popular, regional-specific
> and language-specific, it seems like it would be a bad idea to name them
> after the months.
> The "leap" version are 

[Tagging] Proposal: add Tag:route=share_taxi and Tag:route=minibus for public transportation relationship

[Phake Nick]

In Hong Kong, it is previously decided that, when tagging routes or
access restriction of public service vehicles, a large-sized
franchised bus can be represented with key/value or "bus", a green
minibus can be represented with key/value of "minibus", while a red
minibus can be represented with the key/value of "share_taxi", because
of different nature of all these service. See
https://wiki.openstreetmap.org/wiki/WikiProject_Hong_Kong/Transport/Public_transport
.

However, in the PTv2 tagging scheme, it does not include support for
either route=minibus nor route=share_taxi, and alternative schemes
like route=bus+bus=minibus or route=bus+bus=share_taxi being proposed
also doesn't seems to receive any support so far. As such I would like
to propose including the tag value of route=minibus and
route=share_taxi into the PTv2 tagging scheme in order to represent
those minibus routes in the OSM database via the PTv2 tagging scheme.

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

Re: [Tagging] Tagging disputed boundaries

[Phake Nick]

Come to think of it, if the goal is to represent different perspective of
disputed territory, then mapping disputed territories as disputed territory
using claimed_by=* controlled_by=* does not seems like a good idea, as such
an area in OSM would need to include a line separating the disputed
territory from the territory it control which a number of countries would
refuse to recognize. I think it's better to simply map the outer boundary
of those countries' theoretical border and apply relevant tags describing
the identify of the area instead.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Phake Nick]

I mean, these route variants can probably be remapped as superroute if
superroute become more popular

2019年3月15日 06:34 於 "marc marc"  寫道：

a route_master isn't a superroute, isn't it ?
it's a collection off all variant of a "single" route
  and not several part of one route like superroute for E-network

route_master are well documented/used for bus route
but if someone want to convert a single type=route into a superroute (so
a type=route having relation as member), imho it's better to make a
propal with a good doc to allow app to add this case.
if not, currently valid route 'll become unusable in all app.
so sure that's the best/most need thing todo with PT version :(

Le 14.03.19 à 23:25, Phake Nick a écrit :

> It really depends on exactly how complex the route is, something like
> https://www.openstreetmap.org/relation/4776035 this bus route can
> definitely use it. (and I haven't mentioned other similar bus routes
> with different numbers in different relationship yet)
>
> 在 2019年3月15日週五 03:31，Paul Allen  <mailto:pla16...@gmail.com>> 寫道：

>
> On Thu, 14 Mar 2019 at 19:23, Peter Elderson  <mailto:pelder...@gmail.com>> wrote:
>
> Op do 14 mrt. 2019 om 18:17 schreef Paul Allen
> mailto:pla16...@gmail.com>>:

>
> On Thu, 14 Mar 2019 at 15:09, Jo  <mailto:winfi...@gmail.com>> wrote:
>
> I would definitely want routes to be composed of
> subroutes which are shared with other routes,
>
>
> I see that as less than useful for any route I know of.
>
>
> It's useful for longer routes through walking/cycling node
> networks, using the network signposting.
>
>
> Yeah, I can see it would be.  And for longer bus routes.  Just not
> for any of the bus routes I know
> around here and am likely to map.  You end up with the only common
> segments being very short
> around a central bus station, then they all diverge.  Once diverged,
> there is nothing to share.
>
> I'm not against such sharing in principle, where it makes sense.
> But if it comes at the price
> that all bus stops have to be in the aggregate relation and not in
> the subroutes then it becomes
> useless for my purposes.  And I freely admit that my purposes are a
> fairly rare case, but I'd
> still like to handle it.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/tagging

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

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

Re: [Tagging] Superroutes - good, bad or ugly?

[Phake Nick]

It really depends on exactly how complex the route is, something like
https://www.openstreetmap.org/relation/4776035 this bus route can
definitely use it. (and I haven't mentioned other similar bus routes with
different numbers in different relationship yet)

在 2019年3月15日週五 03:31，Paul Allen  寫道：

> On Thu, 14 Mar 2019 at 19:23, Peter Elderson  wrote:
>
>> Op do 14 mrt. 2019 om 18:17 schreef Paul Allen :
>>
>>> On Thu, 14 Mar 2019 at 15:09, Jo  wrote:
>>>
 I would definitely want routes to be composed of subroutes which are
 shared with other routes,

>>>
>>> I see that as less than useful for any route I know of.
>>>
>>
>> It's useful for longer routes through walking/cycling node networks,
>> using the network signposting.
>>
>
> Yeah, I can see it would be.  And for longer bus routes.  Just not for any
> of the bus routes I know
> around here and am likely to map.  You end up with the only common
> segments being very short
> around a central bus station, then they all diverge.  Once diverged, there
> is nothing to share.
>
> I'm not against such sharing in principle, where it makes sense.  But if
> it comes at the price
> that all bus stops have to be in the aggregate relation and not in the
> subroutes then it becomes
> useless for my purposes.  And I freely admit that my purposes are a fairly
> rare case, but I'd
> still like to handle it.
>
> --
> 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] Expand the key:opening_hours

[Phake Nick]

在 2019年3月14日週四 20:38，Simon Poole  寫道：

> Some more comments:
>
> - the OH values are currently always evaluated in the local time zone
> (or to go even a bit further in a local context as the location they
> apply to is always known), so a time zone indicator would be only needed
> in the cases that require different processing, the question is if that
> is common enough to justify the additional complication.
>
The three most prominent area that are still using the calendar nowadays
are China, Korea, Vietnam. Each of them have their own version of this
lunar calendar with the most notable difference being the meridian used to
create the calendar. So that once in a few years you could see reports
saying that the lunar calendar and the festival that depends on it are not
correct on some software.

Let's say you represent the Lunar New Year as L01 01. The software can
assume it mean Chinese New Year in China, Vietnamese New Year in Vietnam,
and Korean New Year in Korea. So far so good. But then these festivals
aren't just celebrated within these three countries. Places like Thailand,
Indonesia, Japan, Australia, America, and many other countries around the
world all have different events that would take place for the Lunar New
Year. Sometimes they're commercial events that are currently catering
specifically to Chinese New Year. Sometimes they are diaspora population
that celebrate the festival on the same day as their parent countries. You
cannot know which exact day it's referring to without referring to the
timezone being used to calculate the calendar, and at least it need to
specify Korean/Chinese/Vietnamese version and that is assuming the region
will not create any new timezone in the future, like how time changes
related to the Vietnamese war caused the North Vietnam and South Vietnam
celebrated the new year at different date back then and resulted in some
military advantages.

One might think it'd be easier to add CNY/KNY/VNY into the variable holiday
separately like easter instead, but there are a number of other events
that're celebrated based on local lunar calendar and is celebrated at more
places than those aforementioned countries, like Confucius birthday,
mid-autumn festival, double nine festival, and so on. If calendar-specific
version of all these holidays are all getting their own values as
variable-holiday then there would be too many of them.

And there also other scenario that timezone value is useful, for instance
iirc Fiji decided that the country will implement DST but the school system
operation time will not follow the transition. Or in places like Xinjiang
or West Bank where there are two different timezones used by different
population living in same area.


> - Summer and winter solstice can be, as far as I can see, modelled as
> additional variable_date values (currently only "easter" is defined), I
> would avoid qualifying them with months as again, that require parser
> changes that will cause issues.
>

Except other solar terms are still used. For example March equinox and
September equinox are national holiday in Japan. Setsubun celebration in
Japan is mainly a day before first solar term in February but also a day
before first solar term in May, August, November. Qing Ming (mainly China,
Korea, etc.) is the first solar term in April.

>

> - Lunar months: are there any common names for these instead of just
> numbering? And how are the "leap" variants supposed to be different?
>
> Simon
>

It is usually just numbering, but in Chinese there are nickname for the
11th and 12th month, while in Japanese there are nickname for all the
months. Consider that those nick name are less popular, regional-specific
and language-specific, it seems like it would be a bad idea to name them
after the months.
The "leap" version are for when a year have 13 lunar months. Instead of
naming the additional month the 13th month, various criteria are used to
select one of those thirteen months, and then name it as the "leap" version
of the previous month. There are on average about 7 years with leap month
in every 19 years.

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

Re: [Tagging] Expand the key:opening_hours

[Phake Nick]

Separating it from the current system might have the advantage that it
will not need to use the same syntax to support all regional specific
methods of day counting and time counting at once, but even after
separated it will still need to support the full set of current
opening_time specification in addition to those regional
specifications.

Warin <61sundow...@gmail.com> 於 2019年3月14日週四 上午8:29寫道：
>
> On 14/03/19 10:52, Simon Poole wrote:
> >
> > Just a PS: any grammar extension need to be compatible with the use of
> > OH strings in conditional restrictions too, see
> > https://wiki.openstreetmap.org/wiki/Conditional_restrictions . While I
> > haven't looked at in detail your proposal for a timezone extension
> > might have difficulties with that.
> >
> > Am 14.03.2019 um 00:38 schrieb Simon Poole:
> >> The basic problem with proposing an extension to the current OH grammar
> >> is that it is already far too complicated and full of ambiguities, there
> >> are afaik currently only two parsers that handle > 90% of the grammar
> >> and most of the other ones are rather broken, adding more stuff is
> >> definitely not going to improve things.
> >>
> >> That said, there are one or two places where extensions would be low
> >> impact (extra holiday and variable_date  values for example). However in
> >> any case I would suggest you familiarize yourself with the actual
> >> grammar
> >> https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification
> >> first , in particular your proposal begins with a couple of non-starters
> >> that conflict directly with the existing specification.
> >>
> >> Simon
> >>
> >> Am 13.03.2019 um 19:52 schrieb Phake Nick:
> >>> I found that the current way of mapping opening time of features in
> >>> OSM map are too limiting, and the opening time of some features cannot
> >>> be properly represented with only the current syntax, therefore I have
> >>> written a brief idea about how the syntax in key opening_hours could
> >>> have been expanded to match more different needs at the article's talk
> >>> page. 
> >>> Seehttps://wiki.openstreetmap.org/wiki/Talk:Key:opening_hours#Proposed_extension_to_supported_syntax_in_the_page.
> >>> . It would be nice if these features can be added into the scheme so
> >>> that relevant featurs opening days and time can be represented by the
> >>> scheme directly instead of via text description and external link.
> >>>
> >>> The most significant part of what I would like to see are support for
> >>> solar term(節氣/节气/節気/절기/Tiết khí) and (East Asia) lunar (lunisolar)
> >>> calendar(舊曆/旧历/旧暦/음력/Nông lịch). And because the calculation of both
> >>> are dependent on timezone and then when some countries celebrate these
> >>> festivals they use the calendar that is not based on their own
> >>> country's time but use the Chinese time (or time of other countries
> >>> for overseas diaspora of them) so I have also added a proposal to
> >>> support timezone specification in the scheme which is also desired by
> >>> some other users on the talk page. Note that the scheme I proposed to
> >>> express solar term and lunar month representation wasn't actually that
> >>> much intuitive but I believe it have an advantage that it's more
> >>> internationalized and thus providing a common way of tagging features
> >>> across different regions that use the calendar.
> >>>
> >>> Additionally, I have also written in the proposal that I would like to
> >>> see additional supported values for bank holidays, offset in term of
> >>> number of weeks, and also support for timestamp beyond 24 hours in the
> >>> scheme. Expressing time beyond 24 hours can be especially meaningful
> >>> when the operator of those features decided to release their time this
> >>> way and it can reduce error when inputing or transporting data into
> >>> OSM as it is not uncommon for people to forget properly converting
> >>> dates when they are asked to change the time format back to 00-23h
> >>> format.
> >>>
> >>> And while it seems like the de facto standard, I would also like to
> >>> see the formalization of the handling of time range representation
> >>> like Su 23:00-07:00 that in such syntax the 07:00 is referring to
> >>> 07:00 on the next day.
> >>>
> >>> Any thought on the proposal?
> >>>
>
> Think best to separate it from the present opening hours.
>
> Perhaps   opening_hours:persian=* (example - where the Persian calendar
> is in use).???
>
>
>
> ___
> 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] Expand the key:opening_hours

[Phake Nick]

I found that the current way of mapping opening time of features in
OSM map are too limiting, and the opening time of some features cannot
be properly represented with only the current syntax, therefore I have
written a brief idea about how the syntax in key opening_hours could
have been expanded to match more different needs at the article's talk
page. See 
https://wiki.openstreetmap.org/wiki/Talk:Key:opening_hours#Proposed_extension_to_supported_syntax_in_the_page.
. It would be nice if these features can be added into the scheme so
that relevant featurs opening days and time can be represented by the
scheme directly instead of via text description and external link.

The most significant part of what I would like to see are support for
solar term(節氣/节气/節気/절기/Tiết khí) and (East Asia) lunar (lunisolar)
calendar(舊曆/旧历/旧暦/음력/Nông lịch). And because the calculation of both
are dependent on timezone and then when some countries celebrate these
festivals they use the calendar that is not based on their own
country's time but use the Chinese time (or time of other countries
for overseas diaspora of them) so I have also added a proposal to
support timezone specification in the scheme which is also desired by
some other users on the talk page. Note that the scheme I proposed to
express solar term and lunar month representation wasn't actually that
much intuitive but I believe it have an advantage that it's more
internationalized and thus providing a common way of tagging features
across different regions that use the calendar.

Additionally, I have also written in the proposal that I would like to
see additional supported values for bank holidays, offset in term of
number of weeks, and also support for timestamp beyond 24 hours in the
scheme. Expressing time beyond 24 hours can be especially meaningful
when the operator of those features decided to release their time this
way and it can reduce error when inputing or transporting data into
OSM as it is not uncommon for people to forget properly converting
dates when they are asked to change the time format back to 00-23h
format.

And while it seems like the de facto standard, I would also like to
see the formalization of the handling of time range representation
like Su 23:00-07:00 that in such syntax the 07:00 is referring to
07:00 on the next day.

Any thought on the proposal?

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

Re: [Tagging] New Tag "Departures" voting results.

[Phake Nick]

maybe we can use some keys like eta_link:shortnameofbuscompanyA=*
and eta_link:shortnameofbuscompanyB=* to show different operators
information

在 2019年3月13日週三 15:01，Graeme Fitzpatrick  寫道：

>
>
> On Wed, 13 Mar 2019 at 14:30, Phake Nick  wrote:
>
>> but in term of GTFS I don't think anyone in the world supply data
>> individually for each stops.
>>
>
> Of course!
>
> It would be nice (but probably impossible) to have a single worldwide
> answer but I don't think that will be possible in the foreseeable future :-(
>
> I think it will finish up that we can list this info in this area, people
> can do so there, there & there, but people in those other areas
> unfortunately won't be able to.
>
> I'd say just go with what we can now, & as areas expand, they can all join
> in.
>
> 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] New Tag "Departures" voting results.

[Phake Nick]

There are processed data for each stop, but in term of GTFS I don't think
anyone in the world supply data individually for each stops. My
understanding is that each GTFS file usually cover a line or a network.

在 2019年3月13日週三 10:32，Graeme Fitzpatrick  寫道：

>
>
> On Wed, 13 Mar 2019 at 11:18, Andrew Davidson  wrote:
>
>> However, you may want to include the feed_id every
>> time to make it easier to search for stops. Also do we want to repeat
>> the same information at every stop or should we store it in a single
>> relation?
>>
>
> Unless I've misunderstood the question / problem (which is quite possible
> :-)), how about both?
>
> Stop info on each stop eg
> https://jp.translink.com.au/plan-your-journey/stops/300699
>
> & route info on the relation eg
> https://jp.translink.com.au/plan-your-journey/timetables/bus/t/756/north/2019-03-13
>
>
> 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] New Tag "Departures" voting results.

[Phake Nick]

For the coordinated schedule, as an example there is a route that departure
at the following time:
08:00, 08:00, 08:03, 08:06, 08:09, 08:12, 08:15, 08:18, 08:22, 08:25,
08:29, 08:33, 08:38, 08:38, 08:38, 08:41, 08:44, 08:47, 08:51, 08:54,
08:57, 09:01, 09:05, 09:09, 09:13, and of these departures, 08:00-08:15
departures are operated by operator A, 08:18-08:33 departures operated by
operator B, 08:38-08:54 departures operated by operator A, and then
08:57-09:13 departures are operated by operator B.

I would say if you map them as multiple relationship then end users would
have no idea which relationship is the one they want. It's also
unnecessarily increasing the number of route variants that need to be
maintained by the order of magnitude of hundreds.

在 2019年3月7日週四 22:17，Martin Koppenhoefer  寫道：

>
>
> sent from a phone
>
> > On 7. Mar 2019, at 15:02, Phake Nick  wrote:
> >
> > The route us currently operated by two different operators on
> coordinated timetable and each operator have their own ETA system. While
> they do not provide a GTFS feed for now, it can be expected that each of
> them will provide their own feed if they would like to do so in the future.
> However it doesn't make sense to have multiple relationship for them as
> they run on exact same route with exact same route number and run on a
> coordinated schedule
>
>
> IMHO it could make sense to have multiple relations, we will also have
> multiple GTFS urls in this case. There are route master relations which can
> group route variants and could be used here as well. A coordinated schedule
> means they have completely different schedules, right? (although the
> customers might not care).
>
> 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] Use of old_name (was Re: Mapping deforestation)

[Phake Nick]

Sometimes a feature is so famous that people continues to use its name to
call the place even after it have been removed. For instance one would
still told their friends let's meet up next to where the McDonald's was
located. Or how transportation companies are still telling people "This bus
terminate at Daimaru department store" even though the particular store was
closed almost a quarter century ago. As long as people are still using it,
then it should be considered "current" and be mapped on OSM, even when the
feature itself have already ceased to exists.

2019年3月13日 05:58 於 "Martin Koppenhoefer"  寫道：



sent from a phone


> On 12. Mar 2019, at 16:15, Phake Nick  wrote:
>
> It would probably be more appropriate to use lifecycle prefix if a shop
have beeb replaced by another shop. For example name=KFC+was:name=McDonald's


this is really not a suitable information for osm. We are interested in the
current state. You might find the former situation if you look at old data.

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] Use of old_name (was Re: Mapping deforestation)

[Phake Nick]

It would probably be more appropriate to use lifecycle prefix if a shop
have beeb replaced by another shop. For example name=KFC+was:name=McDonald's
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - police=*

[Phake Nick]

Is it actually a good idea to put everything under police=*? Like
prison/detainment facilities, yes in China police have some sort of
detainment facilities that can detain people for a given number of days, as
an alternative to go through juridical trial and get into actual correction
facilities, but is the difference really that big? Is it not enough to have
something like amenity=prison and operator:type=police?

Likewise, China is also building some sort of new naval base for its
coastal guard managed by their armed police unit, which are already using
ships that are at warship level and they're preparing it to fight against
forces from other countries, in this situation police=naval_base would fit
but is it really necessary to create such tag instead of simply using
military=naval_base+police=*?

Or, in China some police divisions even managed to setup their own
for-profit companies, like hospitals or construction companies, that would
serve general public and compete in business environment in order to create
additional revenue stream for their police division. I don't think it would
be wise to tag them police=hospital or police=commercial either?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tags for tutor or coaching out of school

[Phake Nick]

I have checked some of these features in Taiwan  some are tagged
office=educational_institution, some are tagged amenity=prep_school, some
are simply tagged as shop=yes.
A discussion on Japanese osm mailing list suggest using amenity=prep_school
for this type of facility.
On OSM Taiwan's hackpad it's suggested that they should be tagged with both
office=educational_institution and amenity=prep_school.


在 2019年3月10日週日 11:04，Warin <61sundow...@gmail.com> 寫道：

> Hi
>
> There are a fair number of commercial tutor/coaching establishments that
> provide after school hours tuition in various subjects/courses.
>
>
> e.g.
>
> https://www.alcentres.co.uk/small-group-tuition/
>
>   https://talent-100.com.au/
>
>
> How to tag them?
>
> They are not schools in that they are not large like a true school.
>
>
>
> ___
> 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] New Tag "Departures" voting results.

[Phake Nick]

Nope. For example: https://www.openstreetmap.org/relation/3352395 The route
us currently operated by two different operators on coordinated timetable
and each operator have their own ETA system. While they do not provide a
GTFS feed for now, it can be expected that each of them will provide their
own feed if they would like to do so in the future. However it doesn't make
sense to have multiple relationship for them as they run on exact same
route with exact same route number and run on a coordinated schedule.

在 2019年3月7日週四 14:33，Martin Koppenhoefer  寫道：

>
>
> sent from a phone
>
> > On 5. Mar 2019, at 21:33, Paul Allen  wrote:
> >
> > Routes do exist with more than one operator.
>
>
> wouldn’t these simply be tagged as several relations?
>
>
> 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] leisure=common replacement for public areas with some trees

[Phake Nick]

In Hong Kong, we have many area that are officially destinated as
"sitting-out area" that would fit the description. These area usually have
a few benches along with little bit of plantation around them for people to
sit inside. They are managed by government and usually sandwiched between
different streets or buildings. Some of them are currently tagged as park
and garden but that doesn't seems to be the most appropriate description
for these spaces.

2019年3月7日 02:27 於 "Martin Koppenhoefer"  寫道：

Am Di., 5. März 2019 um 09:02 Uhr schrieb Marián Kyral :

> Typically a small areas in the city between apartment buildings. These
> areas are not official parks, gardens or grass. It is just a green
> accessible for everoyne.
>


are these guaranteed to be accessible? Are they part of the residential
properties, or public space (by property not accessibility) between the
properties?
If they are part of the residential parcel, you could see them as kind of
gardens (within the residential landuse), if they are public property you
could distinguish the intensively maintained (garden and parks) from the
grass areas and from "urban wasteland" (leftovers).

Sometimes, public property (housing) will be sold and the new owner might
treat the public spaces around them differently (privatization of these
spaces).

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] Public Transport Timetables Proposal RFC

[Phake Nick]

Wasn't that only for the currently abandoned parts?

在 2019年2月12日週二 05:52，Jo  寫道：

> The proposal was voted upon.
>
> On Mon, Feb 11, 2019 at 9:54 PM Tijmen Stam  wrote:
>
>> On 31-10-18 00:54, Leif Rasmussen wrote:
>> > Hello everyone!
>> > I recently wrote up a proposal page for public transport schedule
>> data.
>> > This information would allow OpenStreetMap to store information about
>> > when or how often certain buses or trains arrive at a platform.
>> >
>> > https://wiki.osm.org/wiki/Proposed_features/Public_transport_schedules
>> >
>> > Please feel free to look over the page and give feedback.  I am very
>> > open to changing the proposal, so let me know if you have any ideas for
>> > improvements to it.
>> > Thanks,
>> > Leif Rasmussen
>>
>> On January 3rd this year, Leif added the "Interval" and "duration" tags
>> to the wiki for bus route:
>>
>> https://wiki.openstreetmap.org/w/index.php?title=Tag%3Aroute%3Dbus=revision=1767271=1684316
>>
>> I have sideways followed this discussion, but I had the idea there was
>> widespread opposition for having any timetable info added to OSM.
>>
>> I don't think we should have this on the wiki without proper proposal
>> voting - or did I miss something?
>>
>> ___
>> 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] The actual use of the level tag

[Phake Nick]

>
> One reason that's of particular interest to me is that SIT is intended
> to be compatible with 3D rendering, allowing for the creation of 3D
> models that represent both the inside and outside of buildings at the
> same time.
>
> At the moment, Simple 3D Buildings has no support for "half" levels, so
> if we want to preserve that feature of SIT, we would need to update both
> tagging standards at the same time.
>

For indoor tags to be compatible with 3D rendering, there should be a way
to indicate 3D position of bridge/tunnel/stair/any other structures that
connect multiple structures together. Unless I'm mistaken, I don't think
there's currently a universally accepted way in indoor tagging and 3d
tagging to tag a bridge between level 3 of a building and level 6 of
another nearby building, which is a rather common scenario for building
cluster built on a mountain or slope and thus each individual building have
different ground levels.

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

Re: [Tagging] The actual use of the level tag

[Phake Nick]

>M (for mezzanine) is often in between G and 2, and often but not always
has some notion of being less than a proper full floor
Speaking of which  many editors, users, editing software, tenderer and such
seems to assume levels must be integer which is not necessary to be
correct. For instance, I am currently sitting at level 3M of a particular
building, which is physically outside the building and is higher than level
3 while lower than level 4 of such building. If expressed in numerical
format, one might naturally say this is level=3.5, however such value
doesn't seems to be commonly understood by different tools
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal – RFC – natural=peninsula (Was: Feature Proposal – RFC – place=peninsula)

[Phake Nick]

I believe many time the boundary of a peninsula are politically defined,
for instance most would often see the Iberia peninsula end at where Spain
meet France, Indochina peninsula's boundary will probably be the southern
border of China, and Sinai peninsula's boundary would be the current border
between Israel and Egypt.

Other time there could be natural features that separate peninsula from the
mainland it connected to, like a mountain range or a low lying corridor, or
man-made structures like canal.

However there are also situation that peninsula are separated from mainland
using simply a straight line, depend on coast direction of surrounding land.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] amenity=taxi vehicle type

[Phake Nick]

And there are also Tuk Tuk (Auto-Ricksaw?) in SE Asia, the use of golf cart
to offer for-hire service at some specific enclosed locality like theme
parks, and then maybe there are still places that you can ride on a
Palanquin. (Tuk Tuk and Golf cart are automobiles but their different
nature probably warrant a separate tag if it's desired to create a vehicle
type tag for different taxi)

2019-01-06 09:05, Dave Swarthout  wrote:

> In Alaska, which is largely roadless, there are countless air-taxis and
> many water-taxis.
>
> On Sun, Jan 6, 2019 at 7:45 AM Martin Koppenhoefer 
> wrote:
>
>>
>>
>> sent from a phone
>>
>> On 5. Jan 2019, at 01:58, Joseph Eisenberg 
>> wrote:
>>
>> Alternately, we could use amenity=motorcycle_taxi and amenity=pedicab(?
>> is this the British terminology?)
>>
>>
>>
>> there are also water taxis (with boats),  Venice comes to mind, but there
>> are also others.
>>
>> https://en.m.wikipedia.org/wiki/Water_taxi
>>
>> Cheers, Martin
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> --
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Travel Blog at http://dswarthout.blogspot.com
> ___
> 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 - Mapping disputed boundaries (Version 1.6)

[Phake Nick]

※ I forgot to mention a few other possible cases of disputed border, for
one of them I would use the historical dispute of Sikkim's integration into
India as an example, where most countries including India recognized the
integration of Sikkin into India and there are also no independent
government entity for Sikkim exists after such integration, however
countries like China continues to claim there should be an independent
country for Sikkim
※ Another case is that, how about an government in exile like historically
for various European countries during WWII, especially when they have
different claims on territory from existing government of the country, like
Free France vs Vichy France? (in both the situation when such government in
exile control some overseas territory and also in situation when such
government does not control any territory)

在 2019年1月4日週五 20:22，Phake Nick  寫道：

> I think there are some cases that might not be sufficiently covered by the
> current proposal and it might be a good idea to explain how they can be
> tagged in example section of the proposal if they can be represented by it:
> * Minamitorishima, where it is undoubtably a Japanese natural feature,
> however there are dispute on the nature of the island, which affect whether
> Japan is able to enjoy 200nm EEZ from the feature.
> * Southern Sakhalin and Northern/Central Kuril Islands, where it is de
> facto controlled by Russia, and Japan have already renounced their right
> there, however Japanese government insist the ownership of these
> territories are not determined yet.
> * Sub-national disputed boundaries, for instance the recent city-level
> dispute between Hong Kong and Shenzhen over the Sha Tau Kok River
> * Different active level of claims for different parties, for instance
> Republic of China (Taiwan) still haven't renounced their claim on part of
> Russian and Myanmar territories, yet it doesn't seems right to list them as
> a party in territorial dispute between China (Mainland) and other
> surrounding countries on the same level as PRC itself
> * Other different types of claim, for instance the 9-dotted lines which
> China claims "historical right" within the line
> * The proposal supported by various governments around the world to turn
> Jerusalem into a corpus separatum
> * Dispute between a national government and a sub-national entity, for
> example dispute between Somaliland and Puntland, where according to my
> understanding Somaliland is an unrecognized country while Puntland is an
> autonomous regional government that is intended to be part of Somalia.
> * Dispute between regional government and their national government, for
> instance disputed in area for Kurdish autonomous region in Afghanistan
> * Some special situation about United States - should Wake Island be
> controlled by US or UM (US Minority outlying islands)?
> * Guantanamo Bay, where the controlling country (or force) doesn't claim
> the area but continues to control it anyway
>
>
> It would be nice if the proposal can be extended to cover them.
>
> Also, among the existing list of example, for Shebaa Farms, the
> claimed_by=* should also include Syria. For Israel-Palestine dispute, it
> should also separately list out Area A/B/C for West Bank as each of them
> have different status.
>
> 在 2019年1月2日週三 16:18，Johnparis  寫道：
>
>> I have just posted version 1.6 of my proposal on mapping disputed
>> boundaries. It tightens the definition of the "controlled by" tag in an
>> effort to improve verifiability.
>>
>> *Changelog*
>>
>>- *Version 1.6*
>>   - Defining terms for "controlled_by" tag to improve verifiability.
>>- *Version 1.5.1*
>>   - Adding role de_facto for boundary relations in Conflict Areas.
>>- *Version 1.5*
>>   - Eliminating Zones of Control as concept.
>>  - Permitting claimed_by and controlled_by tags to be placed
>>  directly on administrative boundary relations, eliminating those 
>> (now
>>  redundant) Zones of Control
>>  - Other Zones of Control become Boundary Claim relations.
>>   - *Version 1.4.2*
>>   - Changing Crimea example to conform to current administrative
>>   boundary.
>>- *Version 1.4.1*
>>   - Changing "all" keyword to a list for the value of the
>>   "controlled_by" tag.
>>   - Adding "UN" as a special value for the "controlled_by" tag.
>>- *Version 1.4*
>>   - Using maritime boundaries instead of land boundaries
>>   - Eliminating redundant or unneeded relations:
>>  - De facto relation is eliminated; it is now the same as the
>>

Re: [Tagging] Feature Proposal - RFC - Mapping disputed boundaries (Version 1.6)

[Phake Nick]

I think there are some cases that might not be sufficiently covered by the
current proposal and it might be a good idea to explain how they can be
tagged in example section of the proposal if they can be represented by it:
* Minamitorishima, where it is undoubtably a Japanese natural feature,
however there are dispute on the nature of the island, which affect whether
Japan is able to enjoy 200nm EEZ from the feature.
* Southern Sakhalin and Northern/Central Kuril Islands, where it is de
facto controlled by Russia, and Japan have already renounced their right
there, however Japanese government insist the ownership of these
territories are not determined yet.
* Sub-national disputed boundaries, for instance the recent city-level
dispute between Hong Kong and Shenzhen over the Sha Tau Kok River
* Different active level of claims for different parties, for instance
Republic of China (Taiwan) still haven't renounced their claim on part of
Russian and Myanmar territories, yet it doesn't seems right to list them as
a party in territorial dispute between China (Mainland) and other
surrounding countries on the same level as PRC itself
* Other different types of claim, for instance the 9-dotted lines which
China claims "historical right" within the line
* The proposal supported by various governments around the world to turn
Jerusalem into a corpus separatum
* Dispute between a national government and a sub-national entity, for
example dispute between Somaliland and Puntland, where according to my
understanding Somaliland is an unrecognized country while Puntland is an
autonomous regional government that is intended to be part of Somalia.
* Dispute between regional government and their national government, for
instance disputed in area for Kurdish autonomous region in Afghanistan
* Some special situation about United States - should Wake Island be
controlled by US or UM (US Minority outlying islands)?
* Guantanamo Bay, where the controlling country (or force) doesn't claim
the area but continues to control it anyway


It would be nice if the proposal can be extended to cover them.

Also, among the existing list of example, for Shebaa Farms, the
claimed_by=* should also include Syria. For Israel-Palestine dispute, it
should also separately list out Area A/B/C for West Bank as each of them
have different status.

在 2019年1月2日週三 16:18，Johnparis  寫道：

> I have just posted version 1.6 of my proposal on mapping disputed
> boundaries. It tightens the definition of the "controlled by" tag in an
> effort to improve verifiability.
>
> *Changelog*
>
>- *Version 1.6*
>   - Defining terms for "controlled_by" tag to improve verifiability.
>- *Version 1.5.1*
>   - Adding role de_facto for boundary relations in Conflict Areas.
>- *Version 1.5*
>   - Eliminating Zones of Control as concept.
>  - Permitting claimed_by and controlled_by tags to be placed
>  directly on administrative boundary relations, eliminating those (now
>  redundant) Zones of Control
>  - Other Zones of Control become Boundary Claim relations.
>   - *Version 1.4.2*
>   - Changing Crimea example to conform to current administrative
>   boundary.
>- *Version 1.4.1*
>   - Changing "all" keyword to a list for the value of the
>   "controlled_by" tag.
>   - Adding "UN" as a special value for the "controlled_by" tag.
>- *Version 1.4*
>   - Using maritime boundaries instead of land boundaries
>   - Eliminating redundant or unneeded relations:
>  - De facto relation is eliminated; it is now the same as the
>  existing administrative boundary
>  - Minimal boundary is eliminated; it is now a Zone of Control
>  with role "undisputed" in Master Claim
>  - Master Claims and Zones of Control are eliminated when not
>  needed, such as for countries with no disputes
>  - Conflict Areas are explicitly made optional
>   - Roles in Master Claim now differentiate how claimant and zone are
>   related: undisputed, joint, de facto, claimed
>   - Describing administered territories
>   - Adding how to change the criteria for the List of Claiming
>   Entities
>- *Version 1.3*
>   - Possible extensions page added
>   - Flattening the hierarchy by removing Disputed and Undisputed Areas
>   - Three Boundary Relations: de facto, master, minimal
>   - All Zones of Control have the role zone in the three Boundary
>   Relations
>   - Eliminating Lines of Control
>   - Country code tag introduced
>- *Version 1.2*
>   - Removing "according_to" tags
>   - Adding Zones of Control and Lines of Control
>   - Adding Disputed Areas and Undisputed Areas
>   - Using type=land_area + land_area=administrative
>   - Full country relations are no longer members of each other.
>- *Version 1.1*
>   - Adding "according_to" tag for relations
>- *Version 1.0*
>   -