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] New Tag "Departures" voting results.

[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

Re: [Tagging] [OSM-talk] Tagging disputed boundaries

[Yuri Astrakhan]

I second Joseph's comment -- the proposal has to be very short for people
to review it - e.g. less than a page, with a clear usage examples -- take a
few well known ones like Crimea and Kashmir, and just list all features
(ways/relations) and their tags.  (actually most people don't read beyond
the first paragraph... on the rare days when we read beyond the subject
line ;))

On Tue, Mar 12, 2019 at 8:57 PM Joseph Eisenberg 
wrote:

> I thought the proposal was too complicated. This made it difficult to
> review, so I was reluctant to vite. I believe a simpler, more approachabke
> proposal would have a higher chance of success.
>
> I’d recommend reading all of the objections and trying again with a much
> simpler version.
>
> On Wed, Mar 13, 2019 at 8:34 AM Graeme Fitzpatrick 
> wrote:
>
>>
>>
>> On Wed, 13 Mar 2019 at 04:22, Johnparis  wrote:
>>
>>> What surprised me, however, was the general lack of interest. I had
>>> thought this was a hot button issue, what with dozens of people registering
>>> with OSM, the big kerfuffle about Crimea, etc. If only 33 people are
>>> interested in this topic, it seems useless for me to continue to try to
>>> refine the proposal.
>>>
>>
>> John, I'm sorry your proposal didn't make it, as it seemed like quite a
>> reasonable idea.
>>
>> I've noticed this before & wonder about the numbers, or lack of them?
>>
>> Yes there's supposed to be ~75 mappers on OSM.
>>
>> I don't know how many subscribe to the Tagging list (I'm sure someone can
>> tell us?) but for Feb 2019
>> https://lists.openstreetmap.org/pipermail/tagging/2019-February/author.html,
>> there were posts by only 86 users, 20 of whom made only 1 post, while 37
>> made more than 5.
>>
>> Back to Nov 2018 when your proposal was raised
>> https://lists.openstreetmap.org/pipermail/tagging/2018-November/author.html
>> & those numbers become 76 total posters, 19 with 1 post, & 32 at +5, so
>> virtually identical.
>>
>> Of those 76 active on the list in Nov, 16 people commented on your
>> proposal. When it came to the vote, 33 people voted, but only 2 of them had
>> made comments on the list, but, strangely enough, only 2 people who
>> commented then voted!
>>
>> Please note that I am in no way criticising people for not contributing
>> to the list - I'm just pointing out that decisions that potentially effect
>> 75 mappers are seemingly being made by a mere handful of people, a lot
>> of whom apparently aren't talking to anybody about the suggestion?
>>
>> I have no idea how we could improve things so there is more feedback -
>> maybe remove the discussion page from the proposals, so all discussion has
>> to happen on the tagging list?
>>
>> 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Andrew Davidson]

On 2/3/19 10:02 am, Leif Rasmussen wrote:
> It seems like the best way forward now is for a proposal allowing 
OpenStreetMap data to be tightly integrated with outside sources (such 
as GTFS) to be created by someone.  This would avoid the issues of 
maintainability in OpenStreetMap.


I'm not interested in producing route maps or attempting to route over 
public transport without the aid of external data, so my requirements 
may not meet all of yours.


What I'd like to be able to do in OSM is:

1. Tag the most appropriate OSM object with the stop_id from a GTFS feed.
2. Have some way of tagging which GTFS feed this is from.
3. Handle the case where a stop appears in more than one GTFS feed.

So I see something along the lines of:

=
=

I noticed that someone else mentioned that the same stop can appear in a 
GTFS feed with different stop_ids. This would look like this:


=;
=

If a stop appears in more than one feed then some how we have to map the 
stop_id to the feed. One possible way would be:


:=
:=
.
.
:=the GTFS feed that stop_id_1 comes from>
:=the GTFS feed that stop_id_2 comes from>

.
.

As you can see there are quite a few design question left to be 
answered. For example, the feed_id is only needed if a stop appears in 
more than one feed. 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?


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

Re: [Tagging] [OSM-talk] Tagging disputed boundaries

[Joseph Eisenberg]

I thought the proposal was too complicated. This made it difficult to
review, so I was reluctant to vite. I believe a simpler, more approachabke
proposal would have a higher chance of success.

I’d recommend reading all of the objections and trying again with a much
simpler version.

On Wed, Mar 13, 2019 at 8:34 AM Graeme Fitzpatrick 
wrote:

>
>
> On Wed, 13 Mar 2019 at 04:22, Johnparis  wrote:
>
>> What surprised me, however, was the general lack of interest. I had
>> thought this was a hot button issue, what with dozens of people registering
>> with OSM, the big kerfuffle about Crimea, etc. If only 33 people are
>> interested in this topic, it seems useless for me to continue to try to
>> refine the proposal.
>>
>
> John, I'm sorry your proposal didn't make it, as it seemed like quite a
> reasonable idea.
>
> I've noticed this before & wonder about the numbers, or lack of them?
>
> Yes there's supposed to be ~75 mappers on OSM.
>
> I don't know how many subscribe to the Tagging list (I'm sure someone can
> tell us?) but for Feb 2019
> https://lists.openstreetmap.org/pipermail/tagging/2019-February/author.html,
> there were posts by only 86 users, 20 of whom made only 1 post, while 37
> made more than 5.
>
> Back to Nov 2018 when your proposal was raised
> https://lists.openstreetmap.org/pipermail/tagging/2018-November/author.html
> & those numbers become 76 total posters, 19 with 1 post, & 32 at +5, so
> virtually identical.
>
> Of those 76 active on the list in Nov, 16 people commented on your
> proposal. When it came to the vote, 33 people voted, but only 2 of them had
> made comments on the list, but, strangely enough, only 2 people who
> commented then voted!
>
> Please note that I am in no way criticising people for not contributing to
> the list - I'm just pointing out that decisions that potentially effect
> 75 mappers are seemingly being made by a mere handful of people, a lot
> of whom apparently aren't talking to anybody about the suggestion?
>
> I have no idea how we could improve things so there is more feedback -
> maybe remove the discussion page from the proposals, so all discussion has
> to happen on the tagging list?
>
> 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] mapping large memorial objects that roads pass through.

[Joseph Eisenberg]

Back in November and December we discussed this issue, but at a broader level:
https://lists.openstreetmap.org/pipermail/tagging/2018-November/040928.html
https://lists.openstreetmap.org/pipermail/tagging/2018-December/041211.html

I was asking about archways or gateways over the road leading into a
neighborhood, which often have a sign with the neighborhood name in
Indonesia. We considered man_made=gantry (which in general can be used
for any sort of structure than goes over a road) or man_made=archway.

There was also a suggestion to tag some of these structures as a type
of artwork, although this is only sometimes relevant.

Torii gates are a very specific type of gateway, which I believe have
religious or spiritual meaning in Japanese Shinto culture. They also
seem very artistic, but I don't know if they are considered artwork in
Japan?

Perhaps they could be man_made=archway and archway=torii?

A specific tag like man_made=torii will mainly be useful in Japan (and
in a few neighborhoods with Japanese cultural influence around the
world), but a more general tag could be used for similar artistic and
cultural structures in other places. Many Hindu and Buddhist temples
in Southeast Asia have symbolic or artistic gateways at the entrance
to the sacred area, which have a similar role to a torii.

Also, I'm not sure about tagging these as a building. They are large
columns supporting symbolic roof, with no walls, if the example photos
on wikipedia are representative. Perhaps they could be tagged as
"building=roof" however.

On 3/13/19, John Willis via Tagging  wrote:
> Thanks to Kevin & Volker for the suggestions.
>
> I tagged the object as suggested.
>
> FYI, similar to pedestrian area, the road ignores the layer=* tag and
> OSM/carto renders it badly.
>
> I imagine things like this lead to a lot of tagging for the renderer.
>
> Javbw
>
>
>> On Mar 12, 2019, at 7:38 PM, Volker Schmidt  wrote:
>>
>> The minimum that is needed is a layer=1 for the torii itself as it is
>> above the road, not at the same level.
>>
>> On Tue, 12 Mar 2019 at 03:34, Kevin Kenny > > wrote:
>> On Mon, Mar 11, 2019 at 10:08 PM John Willis via Tagging
>> mailto:tagging@openstreetmap.org>> wrote:
>> >
>> > I understand about tunnel=building_passage for ways that pass through
>> > structures, but there are some objects that roads go "under", similar to
>> > bridges, but are not bridge-like items.
>> >
>> > In my local area, there are two large torii (shinto gates) that public
>> > roads pass through the center of. They are ~ 10m tall and about 10m
>> > wide, and the base poles are on their own landuse - but the public road
>> > and sidewalk go through the m.
>> >
>> > The gate is a monument, and I mapped it as a building=yes &
>> > man_made=torii . I mapped the road and sidewalk as tunnels through it,
>> > but that seems wrong. It is a large object that deserves to be mapped,
>> > but I am unsure how to do it right.
>> >
>> > I assume this comes up with footpaths that go through smaller torii,
>> > archways, trellis’, and other “overhead” structures, but often times
>> > those structures are unmapped.
>>
>> Map the entire footprint of the torii, and then map the section of the
>> road that passes under with covered=yes? That's what I've done for at
>> least one road (that passes under a building that is buit as a bridge
>> over a ravine) https://www.openstreetmap.org/way/478979357
>>  . It
>> appears to render sensibly, and the tagging makes sense to me.
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/tagging
>> 
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>
>

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

Re: [Tagging] Feature proposal - RFC - Line attachments

[Sergio Manzi]

Hello François,

So, your updated picture made it clear that it is the "insulator set" what 
should be mapped with your newly proposed tag. I suppose  that for power lines 
the same would be true in case the "line attachment" would be through a "pin 
insulator" or a "shackle insulator" or every other form of insulator.

So, when one is supposed to use the "power=insulator" tag instead?

The wiki for that tag (/which *you* wrote/) is describing insulators as "/Power 
insulator linking a power line to a support/" and also "/It's a power insulator 
linking an overhead line to another (grounded) infrastructure/".

In the examples there is also a picture of a concrete portal with the caption 
stating: "/Support : Insulators are used to *anchor *the power line on a 
concrete portal/".

*So we should tag the same node as both a "power=insulator" and 
"line_attachment=suspension", or should we map a distinct node for the 
"line_attachment"?*

I would barely understand if you only had *two values* for line_attachment *as 
properties of the "insulator" key*: suspension and anchor, distinguishing if 
the vector of forces on an insulator add-up to an essentially vertical vector 
because the "traction" forces of two catenaries compensate each other and you 
just have a vertical component of force at the binding post (/suspension/), or 
you don't have the compensation of the two catenaries (the line is attached to 
a fixed post or the two catenaries are not compensated) and you also have an 
horizontal component of force that the binding post must sustain (/anchor/). 
Not much useful to know, IMHO,  but hey, who am I to judge that?

But that's not the case, unhappily! In your proposal you also describe 
"/shackle insulators/" and "/pin insulators/" as "line attachments". For me 
they should have been documented in the "insulator" key as types of insulators 
(/yes, Warin, I know you dislike "type" and it goes under your skin.../).

*A**s I wrote you in our personal mail exchange I have the feeling that you are 
trying to map "concepts", not "things", through generalization: the Platonic 
idea of a line attachment in this case.*

You're doing the same in your current proposal about "substations" 
(/https://wiki.openstreetmap.org/wiki/Proposed_features/Substation_functions/), 
where you want to generalize the concept of "substation" and apply it to both 
the domain of power distribution (power) and fluid distributions (pipeline).

That's profoundly wrong in my opinion and I strongly feel that this should 
stop: we are not here "to put order in the universe" and categorize a and "name 
things" (/I'm an atheist, so I'm not much informed about this things, but I 
seems to remember that the Bible talks about that.../), we are here to map 
useful information about things.

And the above, of course, is in addition to my basic objection about mapping 
things that I think are more fit to AutoCAD or CATIA than OSM...

Cheers,

Sergio


On 2019-03-11 23:35, François Lacombe wrote:
> Hi Sergio,
>
> The proposal aims to map the way lines are bound to their supports.
> In my mind, attachement = {Insulator set ; clamps ; accessories to secure the 
> insulators on crossarms} for a bare power conductor.
> Further keys can give details about each item in this set (but out of the 
> current proposal).
> For insulated cables you don't have insulators but the attachment methods are 
> the same.
>
> Here are illustrations :
> https://wiki.openstreetmap.org/wiki/File:Elbekreuzung_2_traversen_crop_suspension.jpg
> https://wiki.openstreetmap.org/wiki/File:Power_cable_suspension_attachment.png
>
> Keep in mind that currently, it is possible to give the same information with 
> tower:type=suspension.
> As explained in the rationale, :type suffix is meaningless and gather too 
> much possibilities to be usable.
>
> Hope it's clearer
>
> François
>
> Le dim. 10 mars 2019 à 23:04, Sergio Manzi mailto:s...@smz.it>> 
> a écrit :
>
> François,
>
> Thank-you for addressing the mistakes I outlined (/some still needs some 
> polishing I gues/s), but anyway (/and putting aside my reluctance to map such 
> things/) I'm afraid there is still something profoundly wrong with this 
> proposal, at its very essence.
>
> I still don't understand what are *the objects* that one is expected to 
> map with this tag.
>
> Taking as an example the first tower you depict for 
> "line_attachment=suspension" 
> (https://upload.wikimedia.org/wikipedia/commons/5/50/Elbekreuzung_2_traversen_crop.jpg)
>  what are they? The tower (/BTW, shouldn't it be pylon in Brit. Eng. ?/) The 
> "/branch/" (/sorry, I'm missing the correct word.../) of the tower/pylon to 
> which the insulator sets are suspended? The rings/hooks/bolts/nuts suspending 
> the insulator sets under the "branch"? The insulator sets themselves? The 
> clamps suspending the conductors under the insulator sets?
>
> Would it be too much asking you to edit the picture by adding a red arrow 
> 

Re: [Tagging] Status of oneway=cw oneway=ccw

[Kevin Kenny]

On Tue, Mar 12, 2019 at 7:06 PM Volker Schmidt  wrote:
>
> Sorry, I am getting confused here (I am listening in as I frequently map 
> bìcycle routes).
> The "oneway" tag  would only make sense on a loop-shaped route. And only if 
> there are only ways and no nodes like signposts ecc, and if there are no 
> branches, and only if all members of the route were oneway ways. Very special 
> case.
> I normally handle oneway ways in a route which is bidirectional using the 
> forward/backward roles on the ways concerned (as is also normal practice on 
> bus routes around my part of the world). This is frequent for bicycles, but I 
> would expect it to be very rare for pedestrians.
> If you want to indicate the preferred direction of a walking route that is 
> basically loop-shaped, a concept that is different from the legally binding 
> oneway, then some kind of clockwise / anticlockwise tagging should be used.
> If a hiking route contains parts which are oneway for pedestians then this 
> should be tagged an all ways to which this applies with "oneway:foot=yes".

I'm confused, too.

There is one walking route local to me that is a circular route, about
11 km, through a small nature preserve.  It's certainly lawful to go
an any of the ways in either direction, and there are surely lots of
people in the preserve who aren't following the route but just taking
a different walk.  But the route itself goes only one way, because
it's not waymarked in the opposite direction.

In my notes, the plan is:

(1) Put oneway=yes on the route relation, not on the ways.
(2) Add the ways to the route relation in their proper sequence.
(3) Give the ways the 'forward' or 'backward' role according to
the direction that the waymarked route follows.

There isn't any 'clockwise' or 'counterclockwise'; the relation reads
from start to end, and indicates which way it runs on each way it
visits. The fact that the end node is the same as the start node is
enough to make it circular.

Or rather, that *was* the plan.  I'm copying this from my notes, and
before I got around to revising the tagging, the trail maintainers put
up waymarks in the anti-clockwise direction, so I no longer had to
work through what to do about one-way marking.

This style of tagging (a one-way route overlaid on two-way ways, or
vice versa) would even allow for the situation where a hiking route
would have a section that walks on a roadway against the direction of
traffic (add oneway:foot=no to the way, but include oneway in the
relation if needed).  Long-distance routes in the US frequently
include short sections of road walk, to borrow a bridge, or to visit a
village where everyone on a route stops to resupply anyway, or simply
because no right-of-way has been secured for the trail or no trail has
yet been constructed, so it's pretty common to have route=hiking
overlaid on a small piece of road.

I don't know what a routing engine might do in the face of this, but
frankly, the whole idea of using a routing engine to choose among
hiking paths strikes me as a solution in search of a problem.

(Memo to self: come spring,
https://www.nynjtc.org/news/victory-long-path-schoharie-section-trail-permanently-protected
https://www.nynjtc.org/news/everyday-efforts-protect-and-improve-long-path
and several other relocations need mapping!)

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

Re: [Tagging] mapping large memorial objects that roads pass through.

[John Willis via Tagging]

Thanks to Kevin & Volker for the suggestions. 

I tagged the object as suggested. 

FYI, similar to pedestrian area, the road ignores the layer=* tag and OSM/carto 
renders it badly. 

I imagine things like this lead to a lot of tagging for the renderer. 

Javbw


> On Mar 12, 2019, at 7:38 PM, Volker Schmidt  wrote:
> 
> The minimum that is needed is a layer=1 for the torii itself as it is above 
> the road, not at the same level.
> 
> On Tue, 12 Mar 2019 at 03:34, Kevin Kenny  > wrote:
> On Mon, Mar 11, 2019 at 10:08 PM John Willis via Tagging
> mailto:tagging@openstreetmap.org>> wrote:
> >
> > I understand about tunnel=building_passage for ways that pass through 
> > structures, but there are some objects that roads go "under", similar to 
> > bridges, but are not bridge-like items.
> >
> > In my local area, there are two large torii (shinto gates) that public 
> > roads pass through the center of. They are ~ 10m tall and about 10m wide, 
> > and the base poles are on their own landuse - but the public road and 
> > sidewalk go through the m.
> >
> > The gate is a monument, and I mapped it as a building=yes & man_made=torii 
> > . I mapped the road and sidewalk as tunnels through it, but that seems 
> > wrong. It is a large object that deserves to be mapped, but I am unsure how 
> > to do it right.
> >
> > I assume this comes up with footpaths that go through smaller torii, 
> > archways, trellis’, and other “overhead” structures, but often times those 
> > structures are unmapped.
> 
> Map the entire footprint of the torii, and then map the section of the
> road that passes under with covered=yes? That's what I've done for at
> least one road (that passes under a building that is buit as a bridge
> over a ravine) https://www.openstreetmap.org/way/478979357 
>  . It
> appears to render sensibly, and the tagging makes sense to me.
> 
> ___
> 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] [OSM-talk] Tagging disputed boundaries

[Graeme Fitzpatrick]

On Wed, 13 Mar 2019 at 04:22, Johnparis  wrote:

> What surprised me, however, was the general lack of interest. I had
> thought this was a hot button issue, what with dozens of people registering
> with OSM, the big kerfuffle about Crimea, etc. If only 33 people are
> interested in this topic, it seems useless for me to continue to try to
> refine the proposal.
>

John, I'm sorry your proposal didn't make it, as it seemed like quite a
reasonable idea.

I've noticed this before & wonder about the numbers, or lack of them?

Yes there's supposed to be ~75 mappers on OSM.

I don't know how many subscribe to the Tagging list (I'm sure someone can
tell us?) but for Feb 2019
https://lists.openstreetmap.org/pipermail/tagging/2019-February/author.html,
there were posts by only 86 users, 20 of whom made only 1 post, while 37
made more than 5.

Back to Nov 2018 when your proposal was raised
https://lists.openstreetmap.org/pipermail/tagging/2018-November/author.html
& those numbers become 76 total posters, 19 with 1 post, & 32 at +5, so
virtually identical.

Of those 76 active on the list in Nov, 16 people commented on your
proposal. When it came to the vote, 33 people voted, but only 2 of them had
made comments on the list, but, strangely enough, only 2 people who
commented then voted!

Please note that I am in no way criticising people for not contributing to
the list - I'm just pointing out that decisions that potentially effect
75 mappers are seemingly being made by a mere handful of people, a lot
of whom apparently aren't talking to anybody about the suggestion?

I have no idea how we could improve things so there is more feedback -
maybe remove the discussion page from the proposals, so all discussion has
to happen on the tagging list?

Thanks

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

Re: [Tagging] Status of oneway=cw oneway=ccw

[s8evq]

There seems to be some confusion from my original email as to why even have 
clockwise/counterclockwise on a hiking route _relation_. The reason is simple: 
When you have a roundtrip signposted hiking route, you can't always do the hike 
in both directions. The signs are sometimes positioned so they are only visible 
when you do the hike in one specific direction. If you would do the hiking 
route in the other direction, you wouldn't see most of the signs.

In Belgium, we have many hundreds of these walking routes mapped:
https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Local_Walking_Routes_Flanders
https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Local_Walking_Routes_Wallonie
most of these are roundtrip, and a lot with one specific direction only.



My question remains: how do you deal with this, and what about the statement 
currently in the wiki about this?



On Tue, 12 Mar 2019 10:50:37 -0700, Johnparis  wrote:

> direction=clockwise/anticlockwise makes sense for a node (like a
> miniroundabout), not for a way
> 
> on a way, the common usage is "oneway=yes" and make sure the way (which is
> by nature directional) is pointing the right direction.
> 
> It doesn't make much sense for a hiking route to use "clockwise" (why the
> "cw" abbreviation???) or "anticlockwise" ("ccw" is presumably an
> abbreviation for the American English word "counterclockwise"). Because
> those terms only make sense if the route is a closed loop that doesn't
> self-intersect, have branches, or anything complicated.
> 
> So "oneway=yes" solves all these cases quite simply. Avoid "oneway=-1" by
> the way, just use "oneway=yes" and reverse the direction of the way if it's
> wrong.
> 
> My two cents (from extensive work on bus routes, not hiking routes).
> 
> John
> 
> 
> On Tue, Mar 12, 2019 at 4:32 AM s8evq  wrote:
> 
> > Hello everyone,
> >
> > I have a question concerning the correct way to add the direction of
> > travel to roundtrip route=hiking|foot|bicycle relations.
> >
> >
> > I saw in the route=hiking wiki page that the usage of oneway=cw and
> > oneway=ccw has been added in 2017, with the word "proposal: " in front.
> >
> >
> > https://wiki.openstreetmap.org/w/index.php?title=Tag:route%3Dhiking=prev=1453761
> >
> > Since then, this tag has not been used that much:
> > https://taginfo.openstreetmap.org/tags/oneway=cw (4 times)
> > https://taginfo.openstreetmap.org/tags/oneway=ccw (6 times)
> >
> >
> > I see there is also the tag "direction=" with a lot more usage. On
> > mini-roundabouts (as documented in the wiki
> > https://wiki.openstreetmap.org/wiki/Key:direction#Clockwise_and_anticlockwise),
> > but sometimes even on route=foot, route=hiking and route=bicycle (not
> > documented in the wiki)
> >
> > Could somebody clear this up, for a novice user like me? How to correctly
> > add the direction of travel to roundtrip route=hiking|foot|bicycle
> > relations? What is the status or meaning of this "proposal: " wording? And
> > what about using direction?
> >
> > Thanks
> >
> >
> >
> >
> >
> > ___
> > 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] [OSM-talk] Tagging disputed boundaries

[Jan S]

Am Di., 12. März 2019 um 19:22 Uhr schrieb Johnparis :

> Thanks. I never did post the final vote, which was 17 yes, 14 no, and 2
> abstain. (There was an additional yes vote after the time period elapsed,
> which has no effect on the outcome.)
>
> The proposal was therefore defeated, not having achieved anywhere near 74%
> approval. I suspect that it is not possible to get anything higher that
> what the proposal achieved (about 55%). I have not gone through the
> comments to see if further changes and another vote would make a difference.
>
> What surprised me, however, was the general lack of interest. I had
> thought this was a hot button issue, what with dozens of people registering
> with OSM, the big kerfuffle about Crimea, etc. If only 33 people are
> interested in this topic, it seems useless for me to continue to try to
> refine the proposal.
>
> Having comments during the voting seems useful, but I was taken aback by
> the fact that issues were raised during the voting that were not raised
> during the Request For Comments period. That strikes me as odd, since it
> raises issues that cannot be discussed during the voting. I refer, for
> example, to the idea of the "on the ground" principle.
>
> The proposal was written specifically to SUPPORT the "on the ground"
> principle, which I felt was undermined by the vote of the OSM Foundation
> board.
>
> The problem with the current system is that it conflates two things: the
> border claim by a country and the line of control for a country.
>
> Let's start with borders. ALL borders in OSM are based on claims. All of
> them. Even when you see a fence, a border crossing post, etc., those are
> REFLECTIONS of the border claim. They are not the border itself. And all
> borders (even maritime) are based on paper. Either there was a war and a
> treaty, or there is a traditional agreement, or in the case of maritime
> borders, there is (generally) a 12-mile boundary away from "baselines", all
> of which are claims. So to be clear, every single admin_level=2 boundary in
> OSM today is based on a claim.
>
> Lines of control are different, and are based on actual "on the ground"
> control. Those are fluid and difficult to ascertain in some cases, which is
> why the proposal spelled out a system that anyone could apply to know where
> and how to (literally) draw the line.
>
> Because it's basically impossible to eliminate the border claims (they are
> inherent to the OSM map), and because they are not observable "on the
> ground", the proposal was designed to eliminate the conflation between
> border claims and lines of control. The purpose of this is to support the
> on the ground principle. I am surprised that some people thought it might
> undermine it.
>
> Similarly with the list of claiming entities. There is ALREADY such a list
> ("political entities with ISO codes"), it is simply not consistently
> followed. The proposal offered specific criteria so everyone would know
> who's in and who's out, as well as a way to change the criteria.
>
> But enough of that. These things could have been discussed during the RFC.
> They weren't. I doubt with such a controversial topic, however, that a 74%
> vote would ever be possible. So I am content to mark it as "defeated".
>
> I do like Nathaniel's idea, and since we have "any tag you like" there is
> nothing to stop people from implementing the proposal as is. I do suspect
> that edit wars (as we have already seen) will follow, and I feel sorry for
> the Data Working Group and the OSM Foundation board -- I certainly wouldn't
> want to arbitrate those.
>
> John
>

Hi John,

I don't think that there's a lack of interest in the issue of disputed
territories, but rather that you've hit a fundamental issue in OSM (and
that might also appear in any other community-driven project).  Mapping
disputed territories is a complex, because it requires (hobby) mappers to
involve themselves into issues of international politics. Questions of
territorial control, the status of disputes and recognition of states and
other entities involve international politics and law. The question of how
to map the borders of Crimea, Western Sahara or Israel, which entities are
involved and how such conflicts are being resolved go beyond the scope of
everyday mapping. It simply is much more demanding to take a stand on such
a politically charged issue than e.g. on how to map police facilites, where
there is usually no dispute about their existence.

Taking into account the complexity of the issue at hand, I haven't been
surprised at all that there were few mappers commenting and voting on your
proposal. I haven't mapped international boundaries myself, simply because
I didn't have the time to familiarise myself with the current OSM mapping
policy and the technical details of mapping such long ways in JOSM. Still,
I have voted your proposal, because I have a professional background that
has allowed me to easily make up my mind on the issue at hand.

Re: [Tagging] Status of oneway=cw oneway=ccw

[Volker Schmidt]

Sorry, I am getting confused here (I am listening in as I frequently map
bìcycle routes).
The "oneway" tag  would only make sense on a loop-shaped route. And only if
there are only ways and no nodes like signposts ecc, and if there are no
branches, and only if all members of the route were oneway ways. Very
special case.
I normally handle oneway ways in a route which is bidirectional using the
forward/backward roles on the ways concerned (as is also normal practice on
bus routes around my part of the world). This is frequent for bicycles, but
I would expect it to be very rare for pedestrians.
If you want to indicate the preferred direction of a walking route that is
basically loop-shaped, a concept that is different from the legally binding
oneway, then some kind of clockwise / anticlockwise tagging should be used.
If a hiking route contains parts which are oneway for pedestians then this
should be tagged an all ways to which this applies with "oneway:foot=yes".



On Tue, 12 Mar 2019 at 23:19, Jmapb  wrote:

> On 3/12/2019 6:09 PM, Warin wrote:
>
> > On 13/03/19 08:59, Jmapb wrote:
> >>
> >> Is there any point in considering a tag for oneways that are not
> >> enforced but generally done nonetheless? oneway=traditional,
> >> oneway=suggested, something like that? (Again, I know I've seen
> >> these, but I can't think of an example offhand.)
> >>
> >
> > oneway=recommended? matches present use of  4wd=recommended
>
> I like it. Now I just have to remember where to put 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] 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)

[marc marc]

Le 12.03.19 à 13:35, Paul Allen a écrit :
> On Tue, 12 Mar 2019 at 12:17, Marc Gemis wrote:
> What if some friends say we'll meet next year again in front of the
> Whizzo.
> 
> If I decide to meet with a friend AGAIN in front of Whizzo, we both 
> already know where it is.

congratulations if you ever need gps to go to a place where you have 
already been (I wonder in this case why commercial gps have a "go home" 
shortcut since everyone has already been there)

> I also recall you saying that you primarily used old_name
> for the benefit of other mappers, to prevent them making changes 
> based on outdated information.

I think you mix the opinion of 2 different Marc :)
that is my use of old_name, maybe not's Marc Gemis's use.

> note=* can be used to also say why 
> the name changed (such as change of use).

note is used to transmit information between mappers.
the fact that a business has closed or changed is also useful for the 
end user.
moreover, I find that having to put notes to explain tags is like saying 
that the tag schema is not clear enough.
there is even at least one QA tool that allows you to search for/display 
tag note=* to see if they should not be transformed into a tag... I have 
converted many times.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Status of oneway=cw oneway=ccw

[Jmapb]

On 3/12/2019 6:09 PM, Warin wrote:


On 13/03/19 08:59, Jmapb wrote:


Is there any point in considering a tag for oneways that are not 
enforced but generally done nonetheless? oneway=traditional, 
oneway=suggested, something like that? (Again, I know I've seen 
these, but I can't think of an example offhand.)




oneway=recommended? matches present use of  4wd=recommended


I like it. Now I just have to remember where to put it.

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

Re: [Tagging] Status of oneway=cw oneway=ccw

[Warin]

On 13/03/19 08:59, Jmapb wrote:

On 3/12/2019 5:53 PM, Warin wrote:

On 13/03/19 08:43, Graeme Fitzpatrick wrote:


I do know of one that is one-way - admittedly it's only ~300 m's 
long & it's on a elevated suspension bridge!, not a normal track, 
but it is posted as entrance only at this end & exit only at the other.


The overland track is one way during the normal walking season, and 
it does have a number of resident rangers to enforce the rules. (~60 km)

walking not working, though for some it is 'work'.

https://www.parks.tas.gov.au/file.aspx?id=37728
The milford track has similar restrictions (~50 km)
https://www.doc.govt.nz/milfordtrack

There are probably more...


Thanks both of you for the examples... I was trying to think of one 
but came up short. These show what oneway=yes on a footway is for.


Is there any point in considering a tag for oneways that are not 
enforced but generally done nonetheless? oneway=traditional, 
oneway=suggested, something like that? (Again, I know I've seen these, 
but I can't think of an example offhand.)




oneway=recommended? matches present use of  4wd=recommended
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Status of oneway=cw oneway=ccw

[Jmapb]

On 3/12/2019 5:53 PM, Warin wrote:

On 13/03/19 08:43, Graeme Fitzpatrick wrote:


I do know of one that is one-way - admittedly it's only ~300 m's long 
& it's on a elevated suspension bridge!, not a normal track, but it 
is posted as entrance only at this end & exit only at the other.


The overland track is one way during the normal working season, and it 
does have a number of resident rangers to enforce the rules. (~60 km)

https://www.parks.tas.gov.au/file.aspx?id=37728
The milford track has similar restrictions (~50 km)
https://www.doc.govt.nz/milfordtrack

There are probably more...


Thanks both of you for the examples... I was trying to think of one but 
came up short. These show what oneway=yes on a footway is for.


Is there any point in considering a tag for oneways that are not 
enforced but generally done nonetheless? oneway=traditional, 
oneway=suggested, something like that? (Again, I know I've seen these, 
but I can't think of an example offhand.)


J


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

Re: [Tagging] Use of old_name (was Re: Mapping deforestation)

[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

Re: [Tagging] Status of oneway=cw oneway=ccw

[Warin]

On 13/03/19 08:43, Graeme Fitzpatrick wrote:



On Wed, 13 Mar 2019 at 04:51, Philip Barnes > wrote:





Although the oneway tag implies a legal restriction, and I doubt
it is illegal to walk a hiking route in the 'wrong' direction.


I do know of one that is one-way - admittedly it's only ~300 m's long 
& it's on a elevated suspension bridge!, not a normal track, but it is 
posted as entrance only at this end & exit only at the other.


The overland track is one way during the normal working season, and it 
does have a number of resident rangers to enforce the rules. (~60 km)

https://www.parks.tas.gov.au/file.aspx?id=37728
The milford track has similar restrictions (~50 km)
https://www.doc.govt.nz/milfordtrack

There are probably more...
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Status of oneway=cw oneway=ccw

[Graeme Fitzpatrick]

On Wed, 13 Mar 2019 at 04:51, Philip Barnes  wrote:

>
> Although the oneway tag implies a legal restriction, and I doubt it is
> illegal to walk a hiking route in the 'wrong' direction.
>

I do know of one that is one-way - admittedly it's only ~300 m's long &
it's on a elevated suspension bridge!, not a normal track, but it is posted
as entrance only at this end & exit only at the other.

https://www.natureplayqld.org.au/places/o-reilly-s-tree-top-walk

https://www.openstreetmap.org/#map=19/-28.23272/153.13800

But oneway=yes is definitely the way to go (sorry, that just slipped out!),
rather then clockwise.

Thanks

Graeme

>
> I am gradually working my way along a local long distance hiking route and
> whilst I walk all the sections in order, I do not walk them all in the same
> direction as starting at a remote bus stop in the sticks is ok but not for
> finishing.
>
> Phil (trigpoint)
> ___
> 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 - Groundskeeping Shop

[Graeme Fitzpatrick]

On Wed, 13 Mar 2019 at 03:14, Andy Townsend  wrote:

> For an example of what _would_ be called groundskeeping in the UK (think
> kit to create, manage and maintain sports grounds specifically)
>

Yes, I'd agree with the others.

For Australia as well, groundskeeper / groundsman would suggest the person
that grooms & maintains football & cricket grounds or golf courses, not
somebody looking after their own backyard.

I also agree with you that there is currently no appropriate tag for a shop
selling & servicing lawnmowers & similar, but don't think this tag quite
hits the spot. I'd suggest  possibly changing it to shop=garden_equipment /
=garden_maintenance / or just =lawnmower!, which would all seem to work
better?

Thanks

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

Re: [Tagging] [OSM-talk] Tagging disputed boundaries

[Yuri Astrakhan]

John, thanks for all the work on this.

What surprises me is that some people are so oppose to the principal value
of OSM itself -- to allow mappers to map.  Disputed territories still need
to be mapped - because they reflect reality of the dispute, and because
many data consumers need it.  Without this data, I as a data consumer [1]
must bend over backwards to process data by hand, while sacrificing the
main appeal of the openness -- easy access to the community curated data --
see our recent work on India's counties [2]...

[1] -- Elastic maps service https://maps.elastic.co
[2] -- India disputed territories
https://github.com/elastic/ems-file-service/pull/89

On Tue, Mar 12, 2019 at 2:22 PM Johnparis  wrote:

> Thanks. I never did post the final vote, which was 17 yes, 14 no, and 2
> abstain. (There was an additional yes vote after the time period elapsed,
> which has no effect on the outcome.)
>
> The proposal was therefore defeated, not having achieved anywhere near 74%
> approval. I suspect that it is not possible to get anything higher that
> what the proposal achieved (about 55%). I have not gone through the
> comments to see if further changes and another vote would make a difference.
>
> What surprised me, however, was the general lack of interest. I had
> thought this was a hot button issue, what with dozens of people registering
> with OSM, the big kerfuffle about Crimea, etc. If only 33 people are
> interested in this topic, it seems useless for me to continue to try to
> refine the proposal.
>
> Having comments during the voting seems useful, but I was taken aback by
> the fact that issues were raised during the voting that were not raised
> during the Request For Comments period. That strikes me as odd, since it
> raises issues that cannot be discussed during the voting. I refer, for
> example, to the idea of the "on the ground" principle.
>
> The proposal was written specifically to SUPPORT the "on the ground"
> principle, which I felt was undermined by the vote of the OSM Foundation
> board.
>
> The problem with the current system is that it conflates two things: the
> border claim by a country and the line of control for a country.
>
> Let's start with borders. ALL borders in OSM are based on claims. All of
> them. Even when you see a fence, a border crossing post, etc., those are
> REFLECTIONS of the border claim. They are not the border itself. And all
> borders (even maritime) are based on paper. Either there was a war and a
> treaty, or there is a traditional agreement, or in the case of maritime
> borders, there is (generally) a 12-mile boundary away from "baselines", all
> of which are claims. So to be clear, every single admin_level=2 boundary in
> OSM today is based on a claim.
>
> Lines of control are different, and are based on actual "on the ground"
> control. Those are fluid and difficult to ascertain in some cases, which is
> why the proposal spelled out a system that anyone could apply to know where
> and how to (literally) draw the line.
>
> Because it's basically impossible to eliminate the border claims (they are
> inherent to the OSM map), and because they are not observable "on the
> ground", the proposal was designed to eliminate the conflation between
> border claims and lines of control. The purpose of this is to support the
> on the ground principle. I am surprised that some people thought it might
> undermine it.
>
> Similarly with the list of claiming entities. There is ALREADY such a list
> ("political entities with ISO codes"), it is simply not consistently
> followed. The proposal offered specific criteria so everyone would know
> who's in and who's out, as well as a way to change the criteria.
>
> But enough of that. These things could have been discussed during the RFC.
> They weren't. I doubt with such a controversial topic, however, that a 74%
> vote would ever be possible. So I am content to mark it as "defeated".
>
> I do like Nathaniel's idea, and since we have "any tag you like" there is
> nothing to stop people from implementing the proposal as is. I do suspect
> that edit wars (as we have already seen) will follow, and I feel sorry for
> the Data Working Group and the OSM Foundation board -- I certainly wouldn't
> want to arbitrate those.
>
> John
>
>
>
>
> On Mon, Mar 11, 2019 at 8:50 PM Nathaniel V. Kelso 
> wrote:
>
>> Hi fellow mapping enthusiasts,
>>
>> Just a friendly heads up I've started to tag more disputed administrative
>> boundary lines in OpenStreetMap with tags for disputed=yes (but will leave
>> the existing dispute=yes alone), adding disputed_by=* on disputed ways, and
>> adding claimed_by=* on their relations to support multiple points-of-view.
>>
>> I posted a diary entry about this sprint here:
>> https://www.openstreetmap.org/user/nvk/diary/47890
>>
>> So far I've limited editing to existing features (like in Kashmir,
>> Crimea, Western Sahara), but there actually aren't that may so I may start
>> adding missing ones later this 

Re: [Tagging] Status of oneway=cw oneway=ccw

[Philip Barnes]

On Tue, 2019-03-12 at 10:50 -0700, Johnparis wrote:
> direction=clockwise/anticlockwise makes sense for a node (like a
> miniroundabout), not for a way
> 
> on a way, the common usage is "oneway=yes" and make sure the way
> (which is by nature directional) is pointing the right direction.
> 
> It doesn't make much sense for a hiking route to use "clockwise" (why
> the "cw" abbreviation???) or "anticlockwise" ("ccw" is presumably an
> abbreviation for the American English word "counterclockwise").
> Because those terms only make sense if the route is a closed loop
> that doesn't self-intersect, have branches, or anything complicated.
> 
> So "oneway=yes" solves all these cases quite simply. Avoid "oneway=-
> 1" by the way, just use "oneway=yes" and reverse the direction of the
> way if it's wrong.
> 
> My two cents (from extensive work on bus routes, not hiking routes).
> 
Although the oneway tag implies a legal restriction, and I doubt it is
illegal to walk a hiking route in the 'wrong' direction. 

I am gradually working my way along a local long distance hiking route
and whilst I walk all the sections in order, I do not walk them all in
the same direction as starting at a remote bus stop in the sticks is ok
but not for finishing.

Phil (trigpoint)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [OSM-talk] Tagging disputed boundaries

[Johnparis]

Thanks. I never did post the final vote, which was 17 yes, 14 no, and 2
abstain. (There was an additional yes vote after the time period elapsed,
which has no effect on the outcome.)

The proposal was therefore defeated, not having achieved anywhere near 74%
approval. I suspect that it is not possible to get anything higher that
what the proposal achieved (about 55%). I have not gone through the
comments to see if further changes and another vote would make a difference.

What surprised me, however, was the general lack of interest. I had thought
this was a hot button issue, what with dozens of people registering with
OSM, the big kerfuffle about Crimea, etc. If only 33 people are interested
in this topic, it seems useless for me to continue to try to refine the
proposal.

Having comments during the voting seems useful, but I was taken aback by
the fact that issues were raised during the voting that were not raised
during the Request For Comments period. That strikes me as odd, since it
raises issues that cannot be discussed during the voting. I refer, for
example, to the idea of the "on the ground" principle.

The proposal was written specifically to SUPPORT the "on the ground"
principle, which I felt was undermined by the vote of the OSM Foundation
board.

The problem with the current system is that it conflates two things: the
border claim by a country and the line of control for a country.

Let's start with borders. ALL borders in OSM are based on claims. All of
them. Even when you see a fence, a border crossing post, etc., those are
REFLECTIONS of the border claim. They are not the border itself. And all
borders (even maritime) are based on paper. Either there was a war and a
treaty, or there is a traditional agreement, or in the case of maritime
borders, there is (generally) a 12-mile boundary away from "baselines", all
of which are claims. So to be clear, every single admin_level=2 boundary in
OSM today is based on a claim.

Lines of control are different, and are based on actual "on the ground"
control. Those are fluid and difficult to ascertain in some cases, which is
why the proposal spelled out a system that anyone could apply to know where
and how to (literally) draw the line.

Because it's basically impossible to eliminate the border claims (they are
inherent to the OSM map), and because they are not observable "on the
ground", the proposal was designed to eliminate the conflation between
border claims and lines of control. The purpose of this is to support the
on the ground principle. I am surprised that some people thought it might
undermine it.

Similarly with the list of claiming entities. There is ALREADY such a list
("political entities with ISO codes"), it is simply not consistently
followed. The proposal offered specific criteria so everyone would know
who's in and who's out, as well as a way to change the criteria.

But enough of that. These things could have been discussed during the RFC.
They weren't. I doubt with such a controversial topic, however, that a 74%
vote would ever be possible. So I am content to mark it as "defeated".

I do like Nathaniel's idea, and since we have "any tag you like" there is
nothing to stop people from implementing the proposal as is. I do suspect
that edit wars (as we have already seen) will follow, and I feel sorry for
the Data Working Group and the OSM Foundation board -- I certainly wouldn't
want to arbitrate those.

John




On Mon, Mar 11, 2019 at 8:50 PM Nathaniel V. Kelso 
wrote:

> Hi fellow mapping enthusiasts,
>
> Just a friendly heads up I've started to tag more disputed administrative
> boundary lines in OpenStreetMap with tags for disputed=yes (but will leave
> the existing dispute=yes alone), adding disputed_by=* on disputed ways, and
> adding claimed_by=* on their relations to support multiple points-of-view.
>
> I posted a diary entry about this sprint here:
> https://www.openstreetmap.org/user/nvk/diary/47890
>
> So far I've limited editing to existing features (like in Kashmir, Crimea,
> Western Sahara), but there actually aren't that may so I may start adding
> missing ones later this month.
>
> If you have any questions please let me know, and if you want to help out
> let's coordinate :)
>
> Cheers,
>
> _Nathaniel
>
>
> ___
> talk mailing list
> t...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Status of oneway=cw oneway=ccw

[Johnparis]

direction=clockwise/anticlockwise makes sense for a node (like a
miniroundabout), not for a way

on a way, the common usage is "oneway=yes" and make sure the way (which is
by nature directional) is pointing the right direction.

It doesn't make much sense for a hiking route to use "clockwise" (why the
"cw" abbreviation???) or "anticlockwise" ("ccw" is presumably an
abbreviation for the American English word "counterclockwise"). Because
those terms only make sense if the route is a closed loop that doesn't
self-intersect, have branches, or anything complicated.

So "oneway=yes" solves all these cases quite simply. Avoid "oneway=-1" by
the way, just use "oneway=yes" and reverse the direction of the way if it's
wrong.

My two cents (from extensive work on bus routes, not hiking routes).

John


On Tue, Mar 12, 2019 at 4:32 AM s8evq  wrote:

> Hello everyone,
>
> I have a question concerning the correct way to add the direction of
> travel to roundtrip route=hiking|foot|bicycle relations.
>
>
> I saw in the route=hiking wiki page that the usage of oneway=cw and
> oneway=ccw has been added in 2017, with the word "proposal: " in front.
>
>
> https://wiki.openstreetmap.org/w/index.php?title=Tag:route%3Dhiking=prev=1453761
>
> Since then, this tag has not been used that much:
> https://taginfo.openstreetmap.org/tags/oneway=cw (4 times)
> https://taginfo.openstreetmap.org/tags/oneway=ccw (6 times)
>
>
> I see there is also the tag "direction=" with a lot more usage. On
> mini-roundabouts (as documented in the wiki
> https://wiki.openstreetmap.org/wiki/Key:direction#Clockwise_and_anticlockwise),
> but sometimes even on route=foot, route=hiking and route=bicycle (not
> documented in the wiki)
>
> Could somebody clear this up, for a novice user like me? How to correctly
> add the direction of travel to roundtrip route=hiking|foot|bicycle
> relations? What is the status or meaning of this "proposal: " wording? And
> what about using direction?
>
> Thanks
>
>
>
>
>
> ___
> 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 - Groundskeeping Shop

[Andy Townsend]

On 12/03/2019 14:34, lamplighter wrote:

This proposal is to create the tag shop=groundkeeping

Description
A shop selling groundskeeping equipment, equipment service and supplies for
groundskeeping to businesses and homeowners.


Maybe it's a US / UK difference, but that wouldn't be "groundskeeping" 
in the UK.  When looking for a tag for 
https://www.openstreetmap.org/node/4898117884 I went with 
"shop=garden_machinery" after looking at taginfo. 
https://taginfo.openstreetmap.org/search?q=groundskeeping#values does 
have higher usage, but isn't really the correct English term.


For an example of what _would_ be called groundskeeping in the UK (think 
kit to create, manage and maintain sports grounds specifically) 
https://www.openstreetmap.org/way/171855256 is I think one, and 
https://www.openstreetmap.org/way/192123860 nearly is too, but I 
couldn't think of a good tag for either.


Best Regards,

Andy




___
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 - Groundskeeping Shop

[phil]

I am not sure I understand this proposal, the term is completely new to me.

Why would I not search for either garden equipment or lawnmowers if that is 
what I need?

Phil (trigpoint)

On Tuesday, 12 March 2019, lamplighter wrote:
> This proposal is to create the tag shop=groundkeeping
> 
> Description
> A shop selling groundskeeping equipment, equipment service and supplies for 
> groundskeeping to businesses and homeowners.
> 
> Please see the proposal page at
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/groundskeeping
> 
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

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

[Tagging] Feature Proposal - RFC - Groundskeeping Shop

[lamplighter]

This proposal is to create the tag shop=groundkeeping

Description
A shop selling groundskeeping equipment, equipment service and supplies for 
groundskeeping to businesses and homeowners.

Please see the proposal page at

https://wiki.openstreetmap.org/wiki/Proposed_features/groundskeeping



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

Re: [Tagging] Use of old_name (was Re: Mapping deforestation)

[Martin Koppenhoefer]

Am Di., 12. März 2019 um 13:17 Uhr schrieb Marc Gemis :

> What if some friends say we'll meet next year again in front of the Whizzo.
> In the meantime, the Whizzo closes and is replaced with a restaurant
> Eatwell.
> If they can then search for the old name it's useful, because they
> might not be overly familiar with the area and don't know the place
> has changed.
> They will also see the new name and the new function within the tags.
> So they now know they have to meet in front of a restaurant now.
>


to me, the tag "old_name" means the old name of what is mapped, a name that
was once in use for this "thing" and is now commonly replaced by a
different "name". If there once was a restaurant Whizzo, which closed or
moved away and now there is an Eatwell, then for me "Whizzo" is not
generally the old_name of the Eatwell (it would be if Whizzo at some time
decided to rebrand itself as Eatwell or it could be if the restaurant
basically looked the same and only the name (and maybe operator) changed).
old_name may be clearer for place names, where it is often not in question
that it is about the same place (e.g. Chemnitz -> Karl-Marx-Stadt ->
Chemnitz couldn't find traces of old_name in this case though) while most
of the restaurant tags refer to the service and operating business. It may
also be useful for subway stations or renamed streets (you may even find
old street signs, especially if they are engraved into building walls they
will typically not be "scratched over").

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

Re: [Tagging] Use of old_name (was Re: Mapping deforestation)

[Paul Allen]

On Tue, 12 Mar 2019 at 12:17, Marc Gemis  wrote:

> What if some friends say we'll meet next year again in front of the Whizzo.
> In the meantime, the Whizzo closes and is replaced with a restaurant
> Eatwell.
> If they can then search for the old name it's useful, because they
> might not be overly familiar with the area and don't know the place
> has changed.
>

Logic error detected!

If I decide to meet with a friend AGAIN in front of Whizzo, we both already
know where it is.

If I decide to meet with a friend next year at somewhere we have never
been, the Whizzo
restaurant and it's now a motorcycle shop, maybe it's better we know that
Whizzo no longer
exists than we both decide it must still be a restaurant because old_name.

I take your point, though, there are edge cases either way.  But I also
recall you saying that you
primarily used old_name for the benefit of other mappers, to prevent them
making changes
based on outdated information.

BTW, this is of course if you use Nominatim. OsmAnd, Magic Earth etc,
> do not search on old_name AFAIK.
>

So old_name isn't useful to people using those tools, anyway.  Which means
there's no
reason to use old_name instead of note.

I'm not persuaded it's useful to use old_name the way you do.  Particularly
when old_name
merely indicates a change of name but note=* can be used to also say why
the name changed
(such as change of use).

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

Re: [Tagging] discouraging shop=fashion

[Jean-Marc Liotier]

On Tue, March 12, 2019 5:23 am, Marc Gemis wrote:
> Before deprecating the shop=fashion tag, shouldn't we reach out to the
> mappers that use shop=fashion ?
>
> Maybe they have a lot more domain knowledge than the people on this
> mailing list

There is of course value in sourcing outside of our group of
self-appointed priesthood - the values of clothes=* are a complicated
matter full of non-orthogonal dimensions, that absolutely requires input
from domain experts outside of this list... I did not know about the term
"fast fashion" until two minutes ago
(https://en.wikipedia.org/wiki/Fast_fashion).

But it will be nice when this mess is relegated to the clothes=* subtag
while shop=clothes provides a simple and universally recognized category
that contributors with no domain knowledge can apply easily with few
mistakes.

There will be arguments for a distinct shop=fashion category - some may
remark that shop=fashion sells some shoes and some accessories... But
those are accessory - the main product is clothes and I claim that, in the
present case, taxonomic compactness is more valuable than this minor
distinction.

While large groups are superior in providing more information, they are
incapable of simplification - pushing it requires a small group and the
proposal can then be submitted to the community as a whole.

> and can explain why they used shop=fashion and not
> shop=clothes; clothes=...

From the Openstreetmap data, I see no distinction in most cases - the
others look like they belong elsewhere, such as shop=cosmetics or
shop=bag.


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

[Tagging] Use of old_name (was Re: Mapping deforestation)

[Marc Gemis]

What if some friends say we'll meet next year again in front of the Whizzo.
In the meantime, the Whizzo closes and is replaced with a restaurant Eatwell.
If they can then search for the old name it's useful, because they
might not be overly familiar with the area and don't know the place
has changed.
They will also see the new name and the new function within the tags.
So they now know they have to meet in front of a restaurant now.


BTW, this is of course if you use Nominatim. OsmAnd, Magic Earth etc,
do not search on old_name AFAIK.

So for me, the old_name seems useful, even though the representation
by some renderers (Nominatim in this case) might not be perfect.

m.

On Tue, Mar 12, 2019 at 12:36 PM Paul Allen  wrote:
>
> On Tue, 12 Mar 2019 at 00:51, marc marc  wrote:
>
>> When one shop is replaced by another, I always keep the old name with
>> old_name even if no one else uses it to designate the new store. the
>> primary purpose is to prevent someone from re-encoding the old store
>> with an older source than mine.
>
>
> I do that with a note because Nominatim will return answers for old_name as 
> well as name.
> So if the supermaket chain Whizzo (fictional name) has closed down its store 
> in one town,
> using old_name=Whizzo will lead people from out of area searching for their 
> nearest Whizzo
> to think it's still there but has rebranded (it's still Whizzo but with a new 
> name).  That's why
> note=* exists, to let other mappers know why a thing is mapped a certain way 
> when reasons
> exist to assume it ought not be.
>
> There are cases where I'd use old_name: where the name has changed but not 
> the function.
> Houses of significance (such as listed buildings, mansions, etc.) which have 
> changed name
> but references may be found in older books (and even on-line) to the old 
> name.  You may not
> know that Castell Malgwyn Hotel became Hammet House after you find a 
> reference to
> Castell Malgwyn somewhere (still a hotel: it may revert to theold name soon, 
> and if it does
> I'll swap name and old_name).  Pubs sometimes change name with a change of 
> landlord,
> and again references to the old name abound.
>
> Where I'd definitely not use old name is where (for example) a general store 
> closed down
> and a restaurant re-opened in its place: Siop y Cardi (general store) in 
> Cardigan is now Crwst
> (restaurant).  Using old_name for that would be highly misleading and benefit 
> nobody.  If I
> thought another mapper might come along and rename back to Siop y Cardi then 
> I would have
> added a note saying that was the building's previous incarnation, not used 
> old_name.
>
> --
> 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] Mapping deforestation

[Paul Allen]

On Tue, 12 Mar 2019 at 00:51, marc marc  wrote:

When one shop is replaced by another, I always keep the old name with
> old_name even if no one else uses it to designate the new store. the
> primary purpose is to prevent someone from re-encoding the old store
> with an older source than mine.
>

I do that with a note because Nominatim will return answers for old_name as
well as name.
So if the supermaket chain Whizzo (fictional name) has closed down its
store in one town,
using old_name=Whizzo will lead people from out of area searching for their
nearest Whizzo
to think it's still there but has rebranded (it's still Whizzo but with a
new name).  That's why
note=* exists, to let other mappers know why a thing is mapped a certain
way when reasons
exist to assume it ought not be.

There are cases where I'd use old_name: where the name has changed but not
the function.
Houses of significance (such as listed buildings, mansions, etc.) which
have changed name
but references may be found in older books (and even on-line) to the old
name.  You may not
know that Castell Malgwyn Hotel became Hammet House after you find a
reference to
Castell Malgwyn somewhere (still a hotel: it may revert to theold name
soon, and if it does
I'll swap name and old_name).  Pubs sometimes change name with a change of
landlord,
and again references to the old name abound.

Where I'd definitely not use old name is where (for example) a general
store closed down
and a restaurant re-opened in its place: Siop y Cardi (general store) in
Cardigan is now Crwst
(restaurant).  Using old_name for that would be highly misleading and
benefit nobody.  If I
thought another mapper might come along and rename back to Siop y Cardi
then I would have
added a note saying that was the building's previous incarnation, not used
old_name.

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

[Tagging] Status of oneway=cw oneway=ccw

[s8evq]

Hello everyone,

I have a question concerning the correct way to add the direction of travel to 
roundtrip route=hiking|foot|bicycle relations.


I saw in the route=hiking wiki page that the usage of oneway=cw and oneway=ccw 
has been added in 2017, with the word "proposal: " in front.

https://wiki.openstreetmap.org/w/index.php?title=Tag:route%3Dhiking=prev=1453761

Since then, this tag has not been used that much:
https://taginfo.openstreetmap.org/tags/oneway=cw (4 times)
https://taginfo.openstreetmap.org/tags/oneway=ccw (6 times)


I see there is also the tag "direction=" with a lot more usage. On 
mini-roundabouts (as documented in the wiki 
https://wiki.openstreetmap.org/wiki/Key:direction#Clockwise_and_anticlockwise), 
but sometimes even on route=foot, route=hiking and route=bicycle (not 
documented in the wiki)

Could somebody clear this up, for a novice user like me? How to correctly add 
the direction of travel to roundtrip route=hiking|foot|bicycle relations? What 
is the status or meaning of this "proposal: " wording? And what about using 
direction?

Thanks





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

Re: [Tagging] Hotel dataset import? / Re: Baby-sitting

[Cascafico Giovanni]

Il giorno lun 11 mar 2019 alle ore 12:20 Cascafico Giovanni <
cascaf...@gmail.com> ha scritto:

> > You were criticized for stretching the opening_hours syntax to describe
> seasonal operations ("Jan 01
> > - Dec 31"), but did not respond nor adjust your tagging.
>
> Sorry for that. Is it wrong? I did test it with JOSM OpeningHoursEditor
> [2] plugin. If anybopdy in this ML prefers 24/7 I will change the values. I
> used "Jan 01 - Dec 31" just to set a value consistent to overall hotel
> dataset opening periods.
>



> > Your import focuses on soft business policies, such as allowing pets or
> supervising kids. Such
> > policies can change even more rapidly, and are better shown in separate
> datasets and not OSM itself.
>
> This consideration raises a huge question about italian fuel stations,
> since operators, brands and names come and go.
> In case of a future regular import, I'll remove pets and childcare,
> inserting just phisical elements like gymn, garage, air-conditioning,
> welness etc.
>

I'm preparing in import wiki. Any thought about the above points?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] mapping large memorial objects that roads pass through.

[Volker Schmidt]

The minimum that is needed is a layer=1 for the torii itself as it is above
the road, not at the same level.

On Tue, 12 Mar 2019 at 03:34, Kevin Kenny  wrote:

> On Mon, Mar 11, 2019 at 10:08 PM John Willis via Tagging
>  wrote:
> >
> > I understand about tunnel=building_passage for ways that pass through
> structures, but there are some objects that roads go "under", similar to
> bridges, but are not bridge-like items.
> >
> > In my local area, there are two large torii (shinto gates) that public
> roads pass through the center of. They are ~ 10m tall and about 10m wide,
> and the base poles are on their own landuse - but the public road and
> sidewalk go through the m.
> >
> > The gate is a monument, and I mapped it as a building=yes &
> man_made=torii . I mapped the road and sidewalk as tunnels through it, but
> that seems wrong. It is a large object that deserves to be mapped, but I am
> unsure how to do it right.
> >
> > I assume this comes up with footpaths that go through smaller torii,
> archways, trellis’, and other “overhead” structures, but often times those
> structures are unmapped.
>
> Map the entire footprint of the torii, and then map the section of the
> road that passes under with covered=yes? That's what I've done for at
> least one road (that passes under a building that is buit as a bridge
> over a ravine) https://www.openstreetmap.org/way/478979357 . It
> appears to render sensibly, and the tagging makes sense to me.
>
> ___
> 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] Mapping deforestation

[Peter Elderson]

Key:landcoverTags: landcover=trees & landcover=grassUsage: The landcover
key is used to describe what covers the land. Currently, the most used
values are trees and grass. What is tagged: A landcover tag is used to map
a physical area of (currently) grass or trees in two cases:

   1. when the human use of the land is not known, e.g. an area of grass
   not visibly dedicated to any purpose, or
   2. when landcover differs from the implied landcover of the underlying
   landuse, eg a grass clearing within a forest, or patches of trees within an
   industrial, residential or military area.



In this context, “underlying landuse” includes other tags which represent
types of landuse such as leisure=park.

Combination of landuse and landcover: Area features can have both landuse
and landcover tags. The landuse indicates what the land is used for; the
landcover indicates what it is covered with.

Where landuse implies a landcover and the above two use cases are not
applicable or foreseen, adding landcover is redundant.

Fr gr Peter Elderson


Op di 12 mrt. 2019 om 01:02 schreef Peter Elderson :

> Organized mapping is ok mapping. Mapping of landcover has been pretty
> decent and sensible overall, not a bunch of fanatics, no data destruction.
> I’ve described current mapping practice for landcover=grass and
> landcover=trees. It covers most of the usage including the Paraguay mapping
> project.
>
> It’s a movement, not a conspiracy.  It’s growing despite not being
> rendered.
>
> Mvg Peter Elderson
>
> > Op 12 mrt. 2019 om 00:19 heeft Christoph Hormann  het
> volgende geschreven:
> >
> >> On Monday 11 March 2019, Peter Elderson wrote:
> >> Sorry, 2000.
> >
> > IIRC the saying is "two wrongs does not make a right".
> >
> > Original use of tags with the landcover key, that is mappers creating a
> > new geometry with a landcover tag, is as follows (based on data from
> > 2019-02-28):
> >
> > 72848 ways/relations (more of half of these created in organized mapping
> > with tagging not being the free choice of the mapper)
> > 1310 different users
> > 494 of which have used the key exactly once (this, i.e. that about 1/3
> > to half of the genuine active users of a tag have only used it once is
> > pretty standard but still this has to be kept in mind when
> > contemplating such numbers)
> >
> > The reason why taginfo reports only the number of users who have last
> > touched features with this key is not because this is particularly
> > meaningful information but because this can be counted quite easily
> > when processing a planet file (which is what taginfo does on a daily
> > basis) while numbers on active users (i.e. who maps features with a tag
> > or who adds a tag to features) can only be determined from the history.
> >
> > I can highly recommend Frederik's talk on the matter of OSM statistics
> > which discusses this in detail:
> >
> > https://www.youtube.com/watch?v=Kx0KuvkbvfQ
> >
> > --
> > Christoph Hormann
> > http://www.imagico.de/
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging