Re: [Tagging] tree rows vs individual trees

[Christian Müller]

> On 9. Feb 2019, at 22:46, Martin Koppenhoefer  wrote:
> 
> > On 9. Feb 2019, at 15:23, Tom Pfeifer  wrote:
> > 
> > IMHO this violates the one object - one OSM element principle.
> 
> 
> IMHO it doesn’t. One tag describes a tree row, the other individual trees. It 
> doesn’t matter that it is the same trees.
> Mapping a residential area doesn’t prevent you from mapping single houses.
> 
> You could also map individual trees in a forest and have natural=tree inside 
> a landuse=forest, although this is not usually done in OSM.


I'd support dropping tree_row as a way,
if the individual trees are mapped. In
the latter case, tree_row is a relation
of the individual items.

A renderer could then decide by styling
theme, if it computes a line between the
extremal points of that relation _or_
the individually mapped trees.


The problem with the combined approach now
is that mappers are not disciplined enough
to include each tree node in tree_row's way.

Which means a simple filter
  if (tree_row) then ignore_render(child(tree_row)) end
will mostly not work, and doing
nearby calculation for this will
be very costly, as there are still
a lot of trees around (knock on wood).


Greetings

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

Re: [Tagging] Mountain Ranges

[Joseph Eisenberg]

> Not all land forms are 'natural' by the common meaning of the word.

Ok, but all mountain ranges are certainly natural, by any sense of the word.

If you would like to change natural=peak, =saddle, =ridge, =cliff etc to a
new “landform” key, that should be a separate proposal which includes all
of the landforms. It doesn’t make sense to invent a new key with only one
value.

> For me I'd just map the spine as a way.

I agree, and I think this should be the recommendation in the proposal.
While some people will choose to use the tag with other geometries, the
central ridge of a mountain range is sufficient to define the extent of the
name, and it is verifiable.

Mountain massifs without a main ridge, such as some isolated volcanic
ranges, should just be mapped as a node for now.

> If a node then some may want a relation - the node as the lable, and
other nodes that are peaks of the range, ways that are ridges of the range
.. and so on.

A complex relation that includes nodes and closed ways isn’t going to be
useful. I do t know of any tools that are able to make sense of such a
thing.

If you want to show that certain peaks and saddle is part of a mountain
range, the main way should connect them.

And if there are smaller side ridges, they can also be selected as part of
the mountain range as long as they share one node with the
natural=mountain_range way
On Sun, Feb 10, 2019 at 8:14 AM Warin <61sundow...@gmail.com> wrote:

> On 09/02/19 11:22, Joseph Eisenberg wrote:
>
> Thanks for working on this. I had been meaning to reopen the proposal.
>
> No need to introduce a new key. natural=mountain_range is fine, and has
> been in use.
>
>
> For me the key 'natural' is not good. It has a common meaning that goes
> against the OSM definition.
>
> Not all land forms are 'natural' by the common meaning of the word.
> So I'd rather use a word that says what it is without any confusion - a
> land form.
>
>
> > To map:
> > - as a node - centred on the area
> > - a simple open way along hte
> spine of the range
>
> Yes, both of these are good. If a way is used it should follow the
> natural=ridge ways.
>
>
> Not all part of a range have ridges - some have plateaus.
>
> A natural=mountain_range will probably consist of several ridges which
> meet at natural=saddle points.
>
> > a closed way on the area of the range or a relation
> > consisting of ways forming a closed area of the range.
>
> These will be quite hard to define. Do you go all the way down into the
> valley or plains till the land is flat? Or only surround the higher
> elevations?
>
>
> Some have already been mapped that way. I don't know of the source/method
> of determination.
>
>
> I’d recommend sticking with a linear way or node.
>
>
> If a node then some may want a relation - the node as the lable, and other
> nodes that are peaks of the range, ways that are ridges of the range .. and
> so on.
> If a way some may want a relation - the ways as the spine, nodes as peaks
> .. and possibly some ways as side ridges ...
>
> ???
> I don't know.
>
> For me I'd just map the spine as a way.
>
>
> On Sat, Feb 9, 2019 at 8:25 AM Warin <61sundow...@gmail.com> wrote:
>
>> Hi,
>>
>>
>> There appear to be 2 competing tags for use with mountain ranges.
>> Neither have any wiki documentation!
>>
>>
>> A) place=region, region=mountain_range
>>
>> Mostly relations with outer ways only.
>>
>>
>> B) natural=mountain_range
>>
>> Again as relations - with outer ways and at least some with nodes
>> representing peaks within the mountain range.
>>
>>
>> -
>>
>> So .. to combine them into one and standardise the format?
>>
>> Introducing
>>
>> C) landform=mountain_range
>>
>>
>> To map as a node - centred on the area, a simple open way along hte
>> spine of the range, a closed way on the area of the range or a relation
>> consisting of ways forming a closed are of the range.
>>
>>
>> No entry of peaks, ridges etc as these will change with new entries, and
>> can be forund by searching inside the area if the area is mapped.
>>
>> -
>>
>> The new tag can run with the older tags so they will still exist while
>> the new tag establishes itself.
>>
>>
>> Well, what do you think?
>>
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Micronations

[Graeme Fitzpatrick]

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

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

Re: [Tagging] Mountain Ranges

[Warin]

On 09/02/19 11:22, Joseph Eisenberg wrote:

Thanks for working on this. I had been meaning to reopen the proposal.

No need to introduce a new key. natural=mountain_range is fine, and 
has been in use.


For me the key 'natural' is not good. It has a common meaning that goes 
against the OSM definition.


Not all land forms are 'natural' by the common meaning of the word.
So I'd rather use a word that says what it is without any confusion - a 
land form.




> To map:
> - as a node - centred on the area
> - a simple open way along hte
spine of the range

Yes, both of these are good. If a way is used it should follow the 
natural=ridge ways.


Not all part of a range have ridges - some have plateaus.
A natural=mountain_range will probably consist of several ridges which 
meet at natural=saddle points.


> a closed way on the area of the range or a relation
> consisting of ways forming a closed area of the range.

These will be quite hard to define. Do you go all the way down into 
the valley or plains till the land is flat? Or only surround the 
higher elevations?


Some have already been mapped that way. I don't know of the 
source/method of determination.


I’d recommend sticking with a linear way or node.


If a node then some may want a relation - the node as the lable, and 
other nodes that are peaks of the range, ways that are ridges of the 
range .. and so on.
If a way some may want a relation - the ways as the spine, nodes as 
peaks .. and possibly some ways as side ridges ...


???
I don't know.

For me I'd just map the spine as a way.


On Sat, Feb 9, 2019 at 8:25 AM Warin <61sundow...@gmail.com 
> wrote:


Hi,


There appear to be 2 competing tags for use with mountain ranges.
Neither have any wiki documentation!


A) place=region, region=mountain_range

Mostly relations with outer ways only.


B) natural=mountain_range

Again as relations - with outer ways and at least some with nodes
representing peaks within the mountain range.


-

So .. to combine them into one and standardise the format?

Introducing

C) landform=mountain_range


To map as a node - centred on the area, a simple open way along hte
spine of the range, a closed way on the area of the range or a
relation
consisting of ways forming a closed are of the range.


No entry of peaks, ridges etc as these will change with new
entries, and
can be forund by searching inside the area if the area is mapped.

-

The new tag can run with the older tags so they will still exist
while
the new tag establishes itself.


Well, what do you think?



___
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] Micronations

[Richard]

On Sat, Feb 09, 2019 at 09:29:58PM +0100, Sergio Manzi wrote:
> True, but I'm quite sure it is more difficult to fake Google Maps: some time 
> ago I had to register an entry in Google Maps and I went through a quite 
> secure mechanism that involved Google sending back to the registered address 
> a postcard (yes, a piece of paper) with a confirmation code printed on it 
> that I had to use to confirm the entry. I don't know if they still use that 
> mechanism. If yes, it is admirable.
> 
> The BBC article too talks about a verification process. A SNAFU at the 
> school's principal office?
> 
> Again, my uttermost concern is how to evitate to fall into a "fake maps" era, 
> after the "fake news" one...

if it is about something like https://en.wikipedia.org/wiki/Liberland there
should be methods to "map" this in OSM. Perhap Opencarto could have a special 
fill pattern with lions/hic sunt leones?

Richard

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

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

[Warin]

On 09/02/19 10:19, Clifford Snow wrote:
I did create new thread about including other features in wastewater 
treatment facilities. Unfortunately I have been side track on other 
issues, not necessarily OSM issue, but life in general.


I do plan to continue exploring how to tag the various features in 
wastewater treatment facilities in the near future.


To the question of "Are storage tanks covered" It might depend on what 
they are used for. I assumed most were covered.


Perhaps use the tag covered=no to signify an uncovered storage tank?


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

Re: [Tagging] edit war about deletion of proposal

[Richard]

On Tue, Feb 05, 2019 at 11:44:13PM +0100, Sergio Manzi wrote:
> done!

oh well.. now they moved it into some users namespace.

I guess we need category:humor ?

Richard

___
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 9. Feb 2019, at 15:23, Tom Pfeifer  wrote:
> 
> IMHO this violates the one object - one OSM element principle.


IMHO it doesn’t. One tag describes a tree row, the other individual trees. It 
doesn’t matter that it is the same trees.
Mapping a residential area doesn’t prevent you from mapping single houses.

You could also map individual trees in a forest and have natural=tree inside a 
landuse=forest, although this is not usually done in OSM.


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

Re: [Tagging] Micronations

[OSMDoudou]

People in search of mapping fictive worlds should consider OpenGeofiction: 
https://opengeofiction.net/#map=11/-20.1066/22.4554___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Micronations

[Sergio Manzi]

True, but I'm quite sure it is more difficult to fake Google Maps: some time 
ago I had to register an entry in Google Maps and I went through a quite secure 
mechanism that involved Google sending back to the registered address a 
postcard (yes, a piece of paper) with a confirmation code printed on it that I 
had to use to confirm the entry. I don't know if they still use that mechanism. 
If yes, it is admirable.

The BBC article too talks about a verification process. A SNAFU at the school's 
principal office?

Again, my uttermost concern is how to evitate to fall into a "fake maps" era, 
after the "fake news" one...

Sergio


On 2019-02-09 21:16, Paul Allen wrote:
> On Sat, 9 Feb 2019 at 19:48, Sergio Manzi mailto:s...@smz.it>> 
> wrote:
>
> But, yes, "there is /something/ out there": Google too report the 
> existence of a "Pitchfork Union" POI [1] [2].
>
>
> Google is not immune from vandalism.  As this recent report by the BBC shows:
> https://www.bbc.co.uk/news/uk-england-humber-47118901  And while the name of 
> the nearby
> chip shop seems suspicious, it is apparently correct.
>
> -- 
> Paul
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


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

Re: [Tagging] Micronations

[Paul Allen]

On Sat, 9 Feb 2019 at 19:48, Sergio Manzi  wrote:

But, yes, "there is *something* out there": Google too report the existence
> of a "Pitchfork Union" POI [1] [2].
>

Google is not immune from vandalism.  As this recent report by the BBC
shows:
https://www.bbc.co.uk/news/uk-england-humber-47118901  And while the name
of the nearby
chip shop seems suspicious, it is apparently correct.

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

Re: [Tagging] Micronations

[Sergio Manzi]

The thing is quite obviously fruit of immagination, creativity, and/or 
delusion: there surely isn't out there such a concoction of toll booths (/many 
of them/), bunkers, town halls, dams, towers, campgrounds, etc.

The creator's name too, "landhahaha", is also an hint for a probable vandalism.

But, yes, "there is /something/ out there": Google too report the existence of 
a "Pitchfork Union" POI [1] [2].  I really don't know what that could be. My 
bet is on some kind of elaborate prank, maybe even something funny, but again 
I'm ready to bet that those detailed micronation's features are not to be found 
on the ground.

And that concerns me a lot, because it is really hard not thinking what 
implications events like this can have on the reliable availability of OSM 
data/services.

Sergio


[1] 
https://www.google.com/maps/place/Pitchfork+Union/@38.0057611,-87.6230528,17.47z/data=!4m13!1m7!3m6!1s0x8871d5133156772d:0xb52e4939112ac99d!2sEvansville,+IN,+USA!3b1!8m2!3d37.9715592!4d-87.5710898!3m4!1s0x8871d3a41e3edbcb:0x36d89880f9e4b0c6!8m2!3d38.0055153!4d-87.6223733?hl=en

[2] 
https://www.google.com/maps/@38.0053737,-87.6226287,3a,75y,90t/data=!3m8!1e1!3m6!1sAF1QipNc0Cno_lNKO_O8oyna_8ihGVTkuy_RQoo1oceA!2e10!3e11!6shttps:%2F%2Flh5.googleusercontent.com%2Fp%2FAF1QipNc0Cno_lNKO_O8oyna_8ihGVTkuy_RQoo1oceA%3Dw203-h100-k-no-pi2.3155072-ya316.65625-ro1.7720242-fo100!7i5376!8i2688?hl=en


On 2019-02-09 18:28, ael via Tagging wrote:
> On Sat, Feb 09, 2019 at 06:20:11PM +1100, Warin wrote:
>> On 09/02/19 16:18, Mark Wagner wrote:
>>> On Sat, 9 Feb 2019 10:54:16 +1000
>>> Graeme Fitzpatrick  wrote:
>>>
 https://www.openstreetmap.org/way/653287455#map=15/38.0034/-87.6183
>> In this case they have been mapped as a 'residential area' with that name ...
>> The basic question is ... is that area residential?
> But note the user name: it does suggest vandalism.
>
> ael
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


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

Re: [Tagging] Micronations

[Simon Poole]

May I point out that this discussion is patently silly? 

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.

Am 9. Februar 2019 18:28:35 MEZ schrieb ael via Tagging 
:
>On Sat, Feb 09, 2019 at 06:20:11PM +1100, Warin wrote:
>> On 09/02/19 16:18, Mark Wagner wrote:
>> > On Sat, 9 Feb 2019 10:54:16 +1000
>> > Graeme Fitzpatrick  wrote:
>> > 
>> > >
>https://www.openstreetmap.org/way/653287455#map=15/38.0034/-87.6183
>> 
>> In this case they have been mapped as a 'residential area' with that
>name ...
>> The basic question is ... is that area residential?
>
>But note the user name: it does suggest vandalism.
>
>ael
>
>
>___
>Tagging mailing list
>Tagging@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/tagging

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit Kaiten Mail gesendet.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tree rows vs individual trees

[Paul Allen]

On Sat, 9 Feb 2019 at 19:19, John Sturdy  wrote:

> I think it's also comparable to mapping the pylons of a power line and the
> line itself.
>

I would say otherwise.  Power lines are strung between pylons.  Often, the
only clue the
line is there is the pylons.  Any time the line changes direction there
MUST be a pylon.
It's possible to miss a pylon or two along the way of a power line if the
line itself is
visoble.  The pylons are separated by large distances.

Tree rows are different.  One-dimensional woods.  It might be possible to
map individual
trees, but it would be tedious.  Trying to map individual trees
algorithmically by giving a
typical spacing would give misleading results and put more load on the
renderer.  Tree
rows are a shorthand for tediously mapping a lot of individual trees.  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).

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

Re: [Tagging] tree rows vs individual trees

[Tom Pfeifer]

On 09.02.2019 20:15, Tobias Knerr wrote:

Because the two feature types exist at different levels of abstraction
(a tree is *part* of a tree row), I do not see this as a violation of
one feature, one element.

Instead, I consider it comparable to mapping building:part areas within
a building=residential outline within a landuse=residential, or mapping
amenity=parking_space areas within an amenity=parking.


On 09.02.2019 20:14, John Sturdy wrote:
> I think it's also comparable to mapping the pylons of a power line and the 
line itself.

I would not consider those analogies applicable.

Both pylon and line exist, and both building:part and building are tangible 
objects.

The tree_row, on the other hand, is a virtual collection of trees, and forming a row is just in the 
perspective of the observer. There is nothing tangible between the trees, once the individual, 
tangible trunks are mapped.


Thus the tree_row is a simplification, because the mapper was not able to map 
the trees.

Otherwise I could just arbitrarily connect some trees in a park and declare it 
a row.

tom

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

Re: [Tagging] tree rows vs individual trees

[John Sturdy]

I think it's also comparable to mapping the pylons of a power line and the
line itself.


On Sat, Feb 9, 2019 at 7:16 PM Tobias Knerr  wrote:

> On 09.02.19 15:23, Tom Pfeifer wrote:
> > "Tree rows ... This approach can also be combined with individually
> > mapped trees for further details."
> [...]
> > IMHO this violates the one object - one OSM element principle. Either I
> > choose the coarser approach to map a way for the row, or I refine it to
> > individual trees, but should not use the row anymore.
>
> Because the two feature types exist at different levels of abstraction
> (a tree is *part* of a tree row), I do not see this as a violation of
> one feature, one element.
>
> Instead, I consider it comparable to mapping building:part areas within
> a building=residential outline within a landuse=residential, or mapping
> amenity=parking_space areas within an amenity=parking.
>
> > If a renderer wants to cluster any trees that can be done
> algorithmically.
>
> Writing an algorithm to reconstruct tree rows from individual tree nodes
> is probably possible, but it's more complex than what OSM renderers
> usually bother with – even for features that are much more significant
> than tree rows. Checking whether a tree node is part of a tree_row way,
> on the other hand, is far easier and only requires relatively standard
> OSM tooling. So the latter seems like the more practical solution to me.
>
> Tobias
>
>
>
> ___
> 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

[Tobias Knerr]

On 09.02.19 15:23, Tom Pfeifer wrote:
> "Tree rows ... This approach can also be combined with individually
> mapped trees for further details."
[...]
> IMHO this violates the one object - one OSM element principle. Either I
> choose the coarser approach to map a way for the row, or I refine it to
> individual trees, but should not use the row anymore.

Because the two feature types exist at different levels of abstraction
(a tree is *part* of a tree row), I do not see this as a violation of
one feature, one element.

Instead, I consider it comparable to mapping building:part areas within
a building=residential outline within a landuse=residential, or mapping
amenity=parking_space areas within an amenity=parking.

> If a renderer wants to cluster any trees that can be done algorithmically.

Writing an algorithm to reconstruct tree rows from individual tree nodes
is probably possible, but it's more complex than what OSM renderers
usually bother with – even for features that are much more significant
than tree rows. Checking whether a tree node is part of a tree_row way,
on the other hand, is far easier and only requires relatively standard
OSM tooling. So the latter seems like the more practical solution to me.

Tobias



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

Re: [Tagging] tree rows vs individual trees

[Colin Smale]

On 2019-02-09 15:23, Tom Pfeifer wrote:

> On the natural=tree page I stumbled over the phrase:
> 
> "Tree rows ... This approach can also be combined with individually mapped 
> trees for further details."
> 
> On natural=tree_row I found it was part of the 2010 proposal which said:
> "if individual trees in a tree row are mapped, the tree nodes should be part 
> of the tree row way. Usually, however, it's not necessary to map the 
> individual trees in a tree row."
> 
> In the discussion this was reasoned with:
> "...connecting the trees with a way allows renderers to generalize the tree 
> row into a single entity, rather than showing each tree separately"
> 
> IMHO this violates the one object - one OSM element principle. Either I 
> choose the coarser approach to map a way for the row, or I refine it to 
> individual trees, but should not use the row anymore.
> 
> If a renderer wants to cluster any trees that can be done algorithmically.

In the same way that a highway can be deduced from the constituent
nodes?___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Micronations

[ael via Tagging]

On Sat, Feb 09, 2019 at 06:20:11PM +1100, Warin wrote:
> On 09/02/19 16:18, Mark Wagner wrote:
> > On Sat, 9 Feb 2019 10:54:16 +1000
> > Graeme Fitzpatrick  wrote:
> > 
> > > https://www.openstreetmap.org/way/653287455#map=15/38.0034/-87.6183
> 
> In this case they have been mapped as a 'residential area' with that name ...
> The basic question is ... is that area residential?

But note the user name: it does suggest vandalism.

ael


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

Re: [Tagging] tree rows vs individual trees

[Jarek Piórkowski]

On Sat, 9 Feb 2019 at 09:23, Tom Pfeifer  wrote:
> IMHO this violates the one object - one OSM element principle. Either I 
> choose the coarser approach
> to map a way for the row, or I refine it to individual trees, but should not 
> use the row anymore.

Hello,

My interpretation would be that a tree row and individual trees might
well be separate features, in the same way that several individual
building=university ways make up an amenity=university way or
relation, or individual buildings for an amenity=hospital.

(I previously saw this discussed in German in
https://www.openstreetmap.org/note/1159696 but it didn't end up
decisive)

--Jarek

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

[Tagging] tree rows vs individual trees

[Tom Pfeifer]

On the natural=tree page I stumbled over the phrase:

"Tree rows ... This approach can also be combined with individually mapped trees for 
further details."

On natural=tree_row I found it was part of the 2010 proposal which said:
"if individual trees in a tree row are mapped, the tree nodes should be part of the tree row way. 
Usually, however, it's not necessary to map the individual trees in a tree row."


In the discussion this was reasoned with:
"...connecting the trees with a way allows renderers to generalize the tree row into a single 
entity, rather than showing each tree separately"


IMHO this violates the one object - one OSM element principle. Either I choose the coarser approach 
to map a way for the row, or I refine it to individual trees, but should not use the row anymore.


If a renderer wants to cluster any trees that can be done algorithmically.

I suggest to remove the idea that tree and tree_row could be combined,
or even declare it should not be done.

tom

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

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

[Markus]

Thanks for your messages and the hint to The Mail Archive!

On Sat, 9 Feb 2019 at 02:05, Graeme Fitzpatrick  wrote:
>
> Are you storing solids or liquids?
>
> For solids, bunker_silo (which I have never before heard them referred to 
> as!) may work? 
> https://wiki.openstreetmap.org/wiki/Tag%3Aman_made%3Dbunker_silo

Liquid manure ... so man_made=bunker_silo doesn't work.

Afaik, liquid manure is either stored in

1. open basins/pits/lagoons
(https://c8.alamy.com/comp/FYGKGG/slurry-pit-on-cheshire-farm-FYGKGG.jpg)
2. partially or fully covered pits
(http://croomconcrete.co.uk/wp-content/gallery/buildundergroundtab/building-a-large-underground-slurry-tank.jpg)
3. open containers above ground
(http://img.agriexpo.online/images_ag/photo-g/170326-11371047.jpg)
4. closed containers/tanks above ground
(https://www.swarmhub.co.uk/wp-content/uploads/2018/07/Slurry-Storage-option-1-e1540222548914-1024x489.jpg)

For 4., man_made=storage_tank + content=manure seems fine, but there
appears to be no standard tag combination for the other three.

3. looks very similar to 4., therefore man_made=storage_tank +
content=manure + open_top=yes or similar doesn't seem to be
far-fetched. But i were also fine with a new tag, e.g.
man_made=open_container (which possibly could also be used at
wastewater treatment plants).

For 1. and 2. i was thinking of using man_made=basin + content=manure
(+ underground=yes). Or do you have any other ideas?

Btw, i've found building=slurry_tank with 11,250 uses:

https://wiki.openstreetmap.org/wiki/Tag:building%3Dslurry_tank

I've randomly looked at 30 building=slurry_tank objects on aerial
imagery: only 3 were closed containers, the rest were open. I expect
something to have at least walls and a roof to be called a building
(what building=* is used for). If we find a tag for open containers, i
suggest to replace/deprecate building=slurry_tank.

Regards

Markus

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

Re: [Tagging] Micronations

[Martin Koppenhoefer]

sent from a phone

> On 9. Feb 2019, at 06:18, Mark Wagner  wrote:
> 
> My usual approach to micronations and fictional countries is to delete
> them, warn the user about mapping things that don't exist (yes, it's a
> form of vandalism), and point them at https://opengeofiction.net/


micronations do exist, you might not recognize them as countries or generally 
sovereign entities, but „something“ is there that can be mapped.

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