Re: [Tagging] defining service on railway=tram

[Jarek Piórkowski]

Hi all,

Last month I wrote about defining service=* tag values for
railway=tram ways, which were previously not defined and used somewhat
varyingly in the wild. Thanks Mateusz for your help refining the
definitions!

I have now written
https://wiki.openstreetmap.org/wiki/User:Jarek_Pi%C3%B3rkowski/Key:service
with a draft of new section I am suggesting to add to Key:service.
Please feel free to edit that wiki page, or comment here on mailing
list.

Should this go through proposal process? It's not defining a new tag,
but it is suggesting newly defined meanings that in some cases differ
slightly from current use (in particular not using service=spur).

Thanks,
--Jarek

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

Re: [Tagging] Feature Proposal - Voting - building:soft_storey

[Graeme Fitzpatrick]

Typo in link!

Correct link is:
https://wiki.openstreetmap.org/wiki/Proposed_features/building:soft_storey

Thanks

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

Re: [Tagging] tree rows vs individual trees

[Warin]

On 11/02/19 11:57, Paul Allen wrote:


On Mon, 11 Feb 2019 at 00:35, Martin Koppenhoefer 
mailto:dieterdre...@gmail.com>> wrote:




On 11. Feb 2019, at 01:24, Paul Allen mailto:pla16...@gmail.com>> wrote:


Many of them are more
than just hedges.


there are different kind of hedges, trees may occur within hedges


So far, so good.



http://www.gartencenter-altenberge.de/wp-content/uploads/2013/07/Buxus2028Buchsbaumhecke2920niedrig20an20Beet201.jpg


Difficult to be sure, but that looks like a very low hedge.  As in I 
could walk over it.




https://niedersachsen.nabu.de/imperia/md/nabu/images/natur-landschaft/lebensraeume/hecken/141230-nabu-herbstliche-hecke-helge-may.jpeg


And that looks like an unkempt hedge.  Still a hedge.

[Crocodile Dundee voice] Now THIS is a hedge.


How to trim your 'hedge', even if it is a tree row
https://www.youtube.com/watch?v=nrw5kxCmSRg
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tree rows vs individual trees

[Paul Allen]

On Mon, 11 Feb 2019 at 00:35, Martin Koppenhoefer 
wrote:

>
>
> On 11. Feb 2019, at 01:24, Paul Allen  wrote:
>
> Many of them are more
> than just hedges.
>
>
> there are different kind of hedges, trees may occur within hedges
>

So far, so good.

>
>
> http://www.gartencenter-altenberge.de/wp-content/uploads/2013/07/Buxus2028Buchsbaumhecke2920niedrig20an20Beet201.jpg
>

Difficult to be sure, but that looks like a very low hedge.  As in I could
walk over it.

>
>
> https://niedersachsen.nabu.de/imperia/md/nabu/images/natur-landschaft/lebensraeume/hecken/141230-nabu-herbstliche-hecke-helge-may.jpeg
>

And that looks like an unkempt hedge.  Still a hedge.

[Crocodile Dundee voice] Now THIS is a hedge.

https://www.google.co.uk/maps/@52.0882022,-4.6463255,3a,75y,346.74h,95.55t/data=!3m6!1e1!3m4!1s_q18XE04pp24t2Rd-jG8-Q!2e0!7i13312!8i6656

I don't use google for OSM work, but it's occasionally useful to make a
point here because
you can take a look around.  Lining the A487 is part hedge, part fence, all
tree.  And it's
a common feature all around a large part of the countryside.

And this is what the same area looks like in iD:
https://www.openstreetmap.org/edit#map=17/52.08753/-4.64727

You can see ordinary hedges in the fields immediately to the east as
compared with the
hedge/fence/ tree rows lining the A487.  You can see the crowns of the
trees lining the
A487.  That's how you tell the difference between a tree row and a hedge.

>
> you may also consider natural =scrub
>
> Your two examples could be scrub, apart from the fact that scrub can't be
applied to linear ways.
My examples are tree rows.  Not neat, tidy, regularly-spaced tree rows, but
rows of trees
nonetheless.  If I mapped them as a hedge it would be consfusing: "I
thought we were here on
the map but it shows a hedge and this is a lot of trees."

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

Re: [Tagging] man_made=storage_tank for open containers?

[marc marc]

Le 11.02.19 à 00:14, Graeme Fitzpatrick a écrit :
> On Mon, 11 Feb 2019 at 08:48, marc marc wrote:
>>  if you are in front of a tank, man_made=tank
> man_made=storage

what value will you use when the tank is made for an industrial
process (e. g. oxygenation in a wastewater treatment plant,
the reactor of a chemical reaction, ...) and not as storage ?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tree rows vs individual trees

[Martin Koppenhoefer]

sent from a phone

> On 11. Feb 2019, at 01:33, Graeme Fitzpatrick  wrote:
> 
> & at what level does a hedge become a tree row, & vice versa? :-)
> 
> https://www.google.com/maps/@-28.0839404,153.4133042,3a,75y,78.53h,84.98t/data=!3m6!1e1!3m4!1skH3zHyokMiuFfbFxTGAezQ!2e0!7i13312!8i6656
>  


this is a hedge. A tree row typically is about rhythm, the distances between 
the trees are regular and every tree is purposefully placed.

A tree row and a hedge are different features, a hedge will not become a tree 
row just because it grows.

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

Re: [Tagging] tree rows vs individual trees

[Graeme Fitzpatrick]

On Mon, 11 Feb 2019 at 10:26, Paul Allen  wrote:

>
>
> On Mon, 11 Feb 2019 at 00:07, Martin Koppenhoefer 
> wrote:
>
>> barrier=hedge
>> I would not tag these as tree rows.
>>
>
> Check the shadows.  Some of those are hedges.  Some of those are hedges
> with occasional
> trees.  And some are hedges with a continuous tree canopy.  Those trees
> are closer-spaced
> than in other tree row examples posted here and the trees are as high.
> Many of them are more
> than just hedges.
>

& at what level does a hedge become a tree row, & vice versa? :-)

https://www.google.com/maps/@-28.0839404,153.4133042,3a,75y,78.53h,84.98t/data=!3m6!1e1!3m4!1skH3zHyokMiuFfbFxTGAezQ!2e0!7i13312!8i6656


Thanks

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

Re: [Tagging] tree rows vs individual trees

[Martin Koppenhoefer]

sent from a phone

> On 11. Feb 2019, at 01:24, Paul Allen  wrote:
> 
> Many of them are more
> than just hedges.


there are different kind of hedges, trees may occur within hedges 


http://www.gartencenter-altenberge.de/wp-content/uploads/2013/07/Buxus2028Buchsbaumhecke2920niedrig20an20Beet201.jpg

https://niedersachsen.nabu.de/imperia/md/nabu/images/natur-landschaft/lebensraeume/hecken/141230-nabu-herbstliche-hecke-helge-may.jpeg

you may also consider natural =scrub 

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

[Tagging] Feature Proposal - Voting - building:soft_storey

[Stefano Maffulli]

Thanks to all who contributed to refine the proposal. I addressed all 
the concerns raised on the talk page on on the mailing list. I opened 
the voting phase today on


https://wiki.openstreetmap.org/wiki/Proposed_featur/building:soft_storey

Definition: a type of construction where any one floor is significantly 
more flexible (less stiff) than those above and below it


Please cast your vote! Thank you,
Stefano

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

Re: [Tagging] tree rows vs individual trees

[Paul Allen]

On Mon, 11 Feb 2019 at 00:07, Martin Koppenhoefer 
wrote:

>
>
> > On 11. Feb 2019, at 01:02, Paul Allen  wrote:
> >
> > All very neat and planned.  Most of what I see around here are much
> closer together.  Sort of like
> > overgrown hedges.  Which they might well be.
>
>
> barrier=hedge
> I would not tag these as tree rows.
>

Check the shadows.  Some of those are hedges.  Some of those are hedges
with occasional
trees.  And some are hedges with a continuous tree canopy.  Those trees are
closer-spaced
than in other tree row examples posted here and the trees are as high.
Many of them are more
than just hedges.

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

Re: [Tagging] tree rows vs individual trees

[Martin Koppenhoefer]

sent from a phone

> On 11. Feb 2019, at 01:02, Paul Allen  wrote:
> 
> All very neat and planned.  Most of what I see around here are much closer 
> together.  Sort of like
> overgrown hedges.  Which they might well be.


barrier=hedge 
I would not tag these as tree rows.


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

Re: [Tagging] tree rows vs individual trees

[Joseph Eisenberg]

I’d recommend using the tree row tag alone in rural areas. A tree row is
very similar to a hedge, though it is usually not a barrier. I hope we are
not going to start mapping only rye individual shrubs that make up a hedge,
or the individual trees that make up a woodland.

If you do add the individual trees, please include each one as a node of
the tree_row so that data users can easily tell which trees are part of the
row, but don’t delete the tree_row in rural areas.

For medium scale / zoom level maps, the tree row is something you can show
much sooner than individual trees.
On Mon, Feb 11, 2019 at 8:47 AM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> On 10. Feb 2019, at 23:10, Tom Pfeifer  wrote:
>
> As said before, I could call any two trees a "row", e.g. each pair of
> trees on the opposite sides of the road.
>
>
>
> this is up to the mapper. In architecture, a tree row is seen as a linear
> space, it structures land in a “soft” way or puts emphasis on linear
> features, especially roads and waterways.
>
> You can see it, a purposefully placed linear feature. Two trees might be a
> tree row in very exceptional cases, usually we’d expect more trees in a row.
>
> some random examples:
> https://rennradler.it/wp-content/uploads/2015/06/Toscana-2015_6.jpg
>
> http://www.landschaftsfotos.eu/1200/baumreihe-teil-bockwindmuehle-schaeferwagen-lwl-freilichtmuseum-26908.jpg
>
> https://www.gannett-cdn.com/-mm-/ebd1e48e8f6474f58c10a9c8e163075922b92c6b/c=0-153-3000-1848&r=x1683&c=3200x1680/local/-/media/2018/06/18/PalmSprings/PalmSprings/636649293079757348-expired-tribal-lease-road-1-.jpg
>
> 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] tree rows vs individual trees

[Paul Allen]

On Sun, 10 Feb 2019 at 23:47, Martin Koppenhoefer 
wrote:

>
> some random examples:
>

All very neat and planned.  Most of what I see around here are much closer
together.  Sort of like
overgrown hedges.  Which they might well be.  But they're very common, so i
think it's deliberate,
possibly as a way of dealing with ground that would otherwise be
waterlogged and need a lot
of ditches.  Or maybe they're all too lazy to trim their hedges.  See, for
example, some of
the hedges/tree rows around here:
https://www.openstreetmap.org/edit#map=16/52.1707/-4.3885
Adding those as individual trees would be a lot of work.  Far too much to
be sensible.

Not that I map hedges and tree rows indiscriminately.  I figure a farmer
growing crops or
raising livestock doesn't need a map to know where the hedges are.  But if,
as is common
around here, the farm has a holiday cottage or two, or if a public footpath
goes through a green
lane, I'll map hedges that would be useful for tourists to know about.  One
day, far in the future,
when everything else has been mapped, people can add the other hedges.  And
if they're
REALLY bored, they can replace the tree rows with individual trees.

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

Re: [Tagging] tree rows vs individual trees

[Martin Koppenhoefer]

sorry for the many posts, but here is a real life example with many tree rows 
of 3 trees: 
https://www.openstreetmap.org/way/620795490#map=19/52.52921/13.37787&layers=D

I know the location and agree with the tagging, but for me individual trees 
could be added as well (you might want to add specific detail to an individual 
tree for example).

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

Re: [Tagging] tree rows vs individual trees

[Martin Koppenhoefer]

sent from a phone

> On 10. Feb 2019, at 23:10, Tom Pfeifer  wrote:
> 
> As said before, I could call any two trees a "row", e.g. each pair of trees 
> on the opposite sides of the road.


this is up to the mapper. In architecture, a tree row is seen as a linear 
space, it structures land in a “soft” way or puts emphasis on linear features, 
especially roads and waterways.

You can see it, a purposefully placed linear feature. Two trees might be a tree 
row in very exceptional cases, usually we’d expect more trees in a row.

some random examples:
https://rennradler.it/wp-content/uploads/2015/06/Toscana-2015_6.jpg
http://www.landschaftsfotos.eu/1200/baumreihe-teil-bockwindmuehle-schaeferwagen-lwl-freilichtmuseum-26908.jpg
https://www.gannett-cdn.com/-mm-/ebd1e48e8f6474f58c10a9c8e163075922b92c6b/c=0-153-3000-1848&r=x1683&c=3200x1680/local/-/media/2018/06/18/PalmSprings/PalmSprings/636649293079757348-expired-tribal-lease-road-1-.jpg

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

Re: [Tagging] tree rows vs individual trees

[Martin Koppenhoefer]

sent from a phone

> On 10. Feb 2019, at 23:10, Tom Pfeifer  wrote:
> 
> Thus it is more comparable to the addr:interpolation which we use before all 
> addr:housenumber are mapped individually. Once we have achieved that, the 
> interpolation line becomes obsolete.


I believe this is disputable. Personally, I have never used the tree row tag, I 
always mapped single trees, in a row or not, but I think there could be a sense 
in explicitly stating a tree row that goes beyond address interpolation, which 
really is redundant when the individual numbers are there. For example there 
can be anomalies like missing trees or corners where different tree rows meet, 
and an algorithm might not be able to get it right (also because information 
like tree types could be missing, a human looking at the scene would understand 
the rows because she sees more than just a binary tree or not, she will see 
age/height/color/shape (and other species related properties) and be able to 
distinguish them, even without expert knowledge like knowing the species, just 
by looking at it. A short way to tell which trees belong together (or which row 
is interrupted) would be the tree row tag.

I see no harm in having both, provided the individual trees are part of the 
tree row way.

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

Re: [Tagging] tree rows vs individual trees

[Martin Koppenhoefer]

sent from a phone

> On 10. Feb 2019, at 23:10, Tom Pfeifer  wrote:
> 
> The tree_row is then unverifiable, as there is no definition where it begins 
> and where it ends.


Seems easy: starts at the first tree (or even tree stump if you like) and ends 
at the last tree of the row. I would expect crossing streets to end rows.

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

Re: [Tagging] man_made=storage_tank for open containers?

[Graeme Fitzpatrick]

On Mon, 11 Feb 2019 at 08:48, marc marc  wrote:

> if you are in front of a tank, man_made=tank
>

I'd suggest possibly man_made=storage
"type"=tank / silo / bin
 then

> after, you can add (sub)tags describing :
> - if a cover/roof exist or not
> - if its use is storage or an industrial process (e.g. sewage treatment
> plant basin)
> - if the content is clean water, dirty, fuel, corn...
> - if its underground, on the ground or half-half
> - whether it is inside a building or outside
>

Thanks

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

Re: [Tagging] man_made=storage_tank for open containers?

[marc marc]

Le 10.02.19 à 23:27, Warin a écrit :
> On 11/02/19 07:31, Martin Koppenhoefer wrote:
>>> On 10. Feb 2019, at 09:45, Markus  wrote:
>>>
>>> According to the wiki, covered=no would signify that the storage tank
>>> isn't covered by something else, not that it isn't closed. Therefore
>>> my suggestion with open_top=yes (or maybe just open=yes).
>>
>> I would have imagined a man_made=storage_tank to be a closed 
>> container, and would rather invent tags for open containers like 
>> man_made=slurry_pit,
> 
> Too specific. What about other open tanks. Perhaps 
> man_made=open_storage_tank?

instead of creating a main tag value for each variety,
I am as often in favor of dividing things into categories.
if you are in front of a tank, man_made=tank
after, you can add (sub)tags describing :
- if a cover/roof exist or not
- if its use is storage or an industrial process (e.g. sewage treatment 
plant basin)
- if the content is clean water, dirty, fuel, corn...
- if its underground, on the ground or half-half
- whether it is inside a building or outside
...

but not a man_made= value for every combinaison of all above.
not a 
man_made=a-blue-semi-underground-concrett-tank-without-roof-but-inside-a-building-used-as
 
an-oxygenation-tank-in-a wastewater-treatment-plant :-)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tree rows vs individual trees

[Jarek Piórkowski]

On Sun, 10 Feb 2019 at 17:10, Tom Pfeifer  wrote:
> In a related discussion I have heard the argument that, after mapping the 
> individual trees, "if we
> delete the tree_row way, we lose the information that they are part of a tree 
> row."
>
> The problem with that argument is that a tree_row only exists as an
> abstraction/simplification/interpolation of a number of not-yet-mapped trees.

Likely not all things currently mapped as tree_row are distinctive "tree rows".

But there do exist tree rows which are distinctly noticeable:
consisting of a row of trees that were mostly planted at the same
time, and so are roughly same height, and are either same species or
are of a designed variety. This is described in Wikipedia as
https://en.wikipedia.org/wiki/Avenue_(landscape)

Certainly we could tag each of the trees with its species, height,
planting date, etc, and have data consumers infer that they form an
avenue / tree row. Or make a man_made=avenue tag. Or reuse the
natural=tree_row tag for simplicity?


--Jarek

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

Re: [Tagging] man_made=storage_tank for open containers?

[Warin]

On 11/02/19 07:31, Martin Koppenhoefer wrote:



sent from a phone


On 10. Feb 2019, at 09:45, Markus  wrote:

According to the wiki, covered=no would signify that the storage tank
isn't covered by something else, not that it isn't closed. Therefore
my suggestion with open_top=yes (or maybe just open=yes).


I would have imagined a man_made=storage_tank to be a closed container, and 
would rather invent tags for open containers like man_made=slurry_pit,


Too specific. What about other open tanks. Perhaps man_made=open_storage_tank?


or whatever you need, plus in case of water there are already tags for basins 
and reservoirs.


An open water tank is no a basin nor a reservoir.


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

Re: [Tagging] tree rows vs individual trees

[Tom Pfeifer]

On 10.02.2019 09:53, Markus wrote:

On Sat, 9 Feb 2019 at 20:41, Paul Allen  wrote:


[...] I see individual trees
and tree rows as alternative ways of dealing with things and plotting 
individual trees on a
tree row seems bizarre (a row of individual trees is obviously a tree row, 
there's no need to
map both at the same time).


That's my opinion too.


Thanks Paul, Markus, that's what I mean.

In a related discussion I have heard the argument that, after mapping the individual trees, "if we 
delete the tree_row way, we lose the information that they are part of a tree row."


The problem with that argument is that a tree_row only exists as an 
abstraction/simplification/interpolation of a number of not-yet-mapped trees.


Thus it is more comparable to the addr:interpolation which we use before all addr:housenumber are 
mapped individually. Once we have achieved that, the interpolation line becomes obsolete.


So, once the trees are mapped individually, we have all the information we need. The tree_row is 
then unverifiable, as there is no definition where it begins and where it ends. As said before, I 
could call any two trees a "row", e.g. each pair of trees on the opposite sides of the road. Or, I 
could say I need a new row once a tree is missing in some equidistant spacing, or I could ignore 
missing trees.


tom

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

Re: [Tagging] Drain vs ditch

[Martin Koppenhoefer]

sent from a phone

On 10. Feb 2019, at 13:28, Eugene Podshivalov  wrote:

>> (tunnel=culvert and man_made=pipeline)  
>  tunnel=culvert is supposed to be used with waterway=*, isn't it?


yes, what I meant was either tunnel=culvert with a waterway tag, or 
man_made=pipeline location=underground. Sorry for the brevity.

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

Re: [Tagging] man_made=storage_tank for open containers?

[Martin Koppenhoefer]

sent from a phone

> On 10. Feb 2019, at 09:45, Markus  wrote:
> 
> According to the wiki, covered=no would signify that the storage tank
> isn't covered by something else, not that it isn't closed. Therefore
> my suggestion with open_top=yes (or maybe just open=yes).


I would have imagined a man_made=storage_tank to be a closed container, and 
would rather invent tags for open containers like man_made=slurry_pit, or 
whatever you need, plus in case of water there are already tags for basins and 
reservoirs.

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

Re: [Tagging] Drain vs ditch

[Mark Wagner]

On Sun, 10 Feb 2019 15:28:00 +0300
Eugene Podshivalov  wrote:

> >
> > пн, 4 февр. 2019 г. в 02:55, Martin Koppenhoefer
> >  > >:  
> > there is established tagging for buried man made waterways
> > (tunnel=culvert and man_made=pipeline)  
> 
>  tunnel=culvert is supposed to be used with waterway=*, isn't it?

And anything else that's goes through a culvert.  They're a common way
of running farm and service roads under motorways in the western United
States, for example.

-- 
Mark

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

Re: [Tagging] club=scout for similar organisations

[marc marc]

Le 10.02.19 à 14:34, s8evq a écrit :
> On Sun, 3 Feb 2019 14:58:42 +1100, Warin <61sundow...@gmail.com> wrote:
> 
>> On 03/02/19 13:37, Graeme Fitzpatrick wrote:
>>>
>>> On Sun, 3 Feb 2019 at 12:07, marc marc >> > wrote:
>>>
>>>  I think it would be better to continue the current club=scout
>>>  system and add precision with
>>>  scouts=Scouts|Guiding|Patro|Chiro or any other tag to describe the
>>>  "upstream" organisation/variant.
>>>
>>>
>>> That's a nice neat solution +1
>> -1
>> I think
>> club=youth
>> youth=scout/* is a better approach ...

I wouldn't classify "les routiers", a club=scouts division with people 
up to 25 years old in a youth club. but I note that someone who does 
chiron doesn't want to be considered as part of the "scouts-like" category.
In fact, apart from the emotional side, for what difference they are not 
in your opignon in the same category ?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Micronations

[Sergio Manzi]

There is something really wrong going on around that bogus micronation: more 
than half of Harmony Way (from the crossing with Allens Lane to the one with 
Mont Vernon Avenue) has disappeared, leaving many other ways isolated (e.g. 
Rose Avenue and Walnut Hills Drive).

Beside, the f..ing thing is still visible at some Z values.

Is someone looking at this?

Cheers

Sergio


On 2019-02-10 01:39, Graeme Fitzpatrick wrote:
>
> On Sun, 10 Feb 2019 at 05:42, Simon Poole  > wrote:
>
> The user in question has already been blocked and at least their initial 
> changesets were reverted 2 months ago. Naturally any remaining fictional 
> edits should be reverted too and the user reported again to tho DWG.
>
>
> Thanks Simon
>
> The whole thing is still there as of yesterday, so something either didn't 
> work, or they're very persistent!
>
> Message has been forwarded to DWG for action.
>
> Thanks


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Drain vs ditch

[Eugene Podshivalov]

Short summary of what we have ended up with so far.
-
*Variant #1*
Keep both "drain" and "ditch" tags but update their definitions to make a
clear cut between the meanings:

drain - Small artificial free flow waterways usually lined with concrete or
> similar used for carrying away superflous liquid like rain water or
> industrial discharge without letting it soak into the ground. Consider
> using waterway=ditch for unlined channels used to drain nearby wet land.
> Consider using waterway=canal for large unlined land drainage channels.

https://lists.openstreetmap.org/pipermail/tagging/2019-January/042543.html

ditch - Small artificial free flow waterways used to directly distribute
> water to dry land (for irrigation) or collect water from wet land (for
> drainage). Irrigation ditches can be lined or unlined, drainage ditches are
> usually unlined to let water soak through the land into them. Ditches may
> have short lined segments at waterway turning points or intersections with
> roads or paths to prevent erosion. Consider using waterway=canal for larger
> channels *that convey water from or to ditches. Consider using
> waterway=drain for usually lined superflous liquid drainage channels.

 https://lists.openstreetmap.org/pipermail/tagging/2019-January/042566.html

*Variant #2*
Combine "ditch" and "drain" tags into one.

ditch - a narrow channel dug at the side of a road or field, to hold, bring
or carry away water or industrial discharge.
(a) The purspose can be clarified by usage=irrigation/drainage attribute.
Drainage is assumed by default if not defined.
(b) Industrial discharge ditches can be clarified by
industrial_discharge=yes attribute.
(c) Lined channels can be clarified by lined=yes+liner= attribute.

note: I'm not sure about the attribute names.
-
Personally I lean toward variant 2 because
- if a drain is a digged out channel, then it is a ditch, and no need to
clarify the purpose because drainage is assumed by default
- if a drain is not a digged out channel, then some absolutely different
tags should be used like man_made=* or pipe_line=*
- if you want to specify industrial discharge drainage then you have to use
an additional attribute anyway to distinguish it from storm water drains.
- if we had a separate tag for "drains" then lined would be assumed by
default, but you would have to define lined=no attribute for unlined drains
then. This seems to be the only point which would make the life easier with
two separate tags.

Cheers,
Eugene


сб, 2 февр. 2019 г. в 19:44, Eugene Podshivalov :

> Not all ditches can be called drains and not all drains can be called
> ditches and there is some overlapping in their meanings which causes the
> confusion.
>
> I see three ways to go:
> 1. Define the basic meanings from dictionaries and let users decide on
> which tag to use, similar to Peter Elderson's version from the preceding
> post.
> 2. Allow some deviation from dictionary definitions to make a clear cut
> between the two. This is similar to how "stream" is currently restricted to
> the maning of "you can jump over it".
> 3. Introduce some abstract notions with clear definitions of each
> sub-notion. Similar to highway=track + tracktype=grade1,grade2 etc. or
> boundary=administrative + admin_level=2,3 etc.
>
> Cheers,
> Eugene
>
> сб, 2 февр. 2019 г. в 18:48, Peter Elderson :
>
>> If there is a drain worth mapping, I will map it as a drain.
>>
>> If the drain has the form of a ditch and I can see its only function is
>> to be a drain, I will map a drain. Size and lining may be indicators, not
>> definers.
>>
>> If a ditch has unclear function or multiple functions, I will map a
>> ditch. If I think it’s worth mapping.
>>
>> I will not systematically retag drains to ditches unless the national
>> community decides to do so. Automated edits: no way.
>>
>> Mvg Peter Elderson
>>
>> > Op 2 feb. 2019 om 14:22 heeft Hufkratzer  het
>> volgende geschreven:
>> >
>> > If we were discussing a proposal I would agree, but replacing
>> waterway=drain by waterway=ditch + usage=drainage or sth. like that is not
>> such an easy task.  We already have 800k drains. I assume it requires a
>> proposal with volting to deprecate drain, adaption of the presets, perhaps
>> a mass edit. Who will do all this? Is the advantage of using waterway=ditch
>> + usage=drainage instead of waterway=drain so immense that it is worth the
>> effort?
>> >
>> > Am 02.02.2019 13:58, schrieb nwastra:
>> >> +1
>> >>
>> >> N
>> >>
>>  On 2 Feb 2019, at 10:39 pm, Markus 
>> wrote:
>> 
>>  On Sat, 2 Feb 2019 at 11:21, Sergio Manzi  wrote:
>> 
>>  Thank-you for confirming that, Mark.
>> 
>>  Personally I think we, in OSM, should stop with this folly of
>> overloading English words with meanings they do not have in any dictionary
>> (be it AmE, BrE, CaE, or whatever).
>> 
>>  Both the "ditch" and "drain" words can be used to describe certain
>> features in English. The difference is essentia

Re: [Tagging] club=scout for similar organisations

[s8evq]

On Sun, 3 Feb 2019 14:58:42 +1100, Warin <61sundow...@gmail.com> wrote:

> On 03/02/19 13:37, Graeme Fitzpatrick wrote:
> >
> > On Sun, 3 Feb 2019 at 12:07, marc marc  > > wrote:
> >
> > I think it would be better to continue the current club=scout
> > system and add precision with
> > scouts=Scouts|Guiding|Patro|Chiro or any other tag to describe the
> > "upstream" organisation/variant.
> >
> >
> > That's a nice neat solution +1
> -1
> I think
> club=youth
> youth=scout/* is a better approach ...
> >
> > Naturally though, not all that list of "youth organizations" would 
> > come under Scouts!
> 
> So put scouts under youth organisations .. logical.

I've been re-reading this thread in order to find a solution.  It's not clear 
to me yet how to proceed forward.

From what I read, quite some people are not against the usage of club=youth as 
is. I might just keep using club=youth, although the wiki is against it.

On the other hand, what about using club=youth_organization instead of 
club=youth, to counter the argument that youth is not a special interest group?


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

Re: [Tagging] Drain vs ditch

[Eugene Podshivalov]

>
> пн, 4 февр. 2019 г. в 02:55, Martin Koppenhoefer  >:
> there is established tagging for buried man made waterways (tunnel=culvert
> and man_made=pipeline)

 tunnel=culvert is supposed to be used with waterway=*, isn't it?

Cheers,
Eugene

пн, 4 февр. 2019 г. в 02:55, Martin Koppenhoefer :

>
>
> sent from a phone
>
> > On 3. Feb 2019, at 02:12, Michael Patrick  wrote:
> >
> > and 'drain_open' or some such to distinguish it from subterranean drains
> ( despite being buried, these are actually sometime more visible than the
> ditches on aerial / sat photography ).
>
>
> there is established tagging for buried man made waterways (tunnel=culvert
> and man_made=pipeline)
>
> 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] tree rows vs individual trees

[Markus]

On Sat, 9 Feb 2019 at 20:41, Paul Allen  wrote:
>
> [...] I see individual trees
> and tree rows as alternative ways of dealing with things and plotting 
> individual trees on a
> tree row seems bizarre (a row of individual trees is obviously a tree row, 
> there's no need to
> map both at the same time).

That's my opinion too.

Regards

Markus

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

Re: [Tagging] man_made=storage_tank for open containers?

[Markus]

On Sat, 9 Feb 2019 at 23:44, Warin <61sundow...@gmail.com> wrote:
>
> Perhaps use the tag covered=no to signify an uncovered storage tank?

According to the wiki, covered=no would signify that the storage tank
isn't covered by something else, not that it isn't closed. Therefore
my suggestion with open_top=yes (or maybe just open=yes).

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