Re: [Tagging] Deprecate water=pond?

2020-11-09 Thread Peter Elderson
The problem is that natural and artificial are not neatly separated IRL. In 
Nederland, nature is neatly cut, shaven and shaped. Currently, natural style is 
preferred. "New nature" is the hype, where heavy machinery creates new 
landscapes including ponds, lakes, streams and wetlands. Sea dykes are shaped 
like dunes. Etc. So every pond is made to look natural, and every lake is 
reshaped and maintained. 

We have words for pond ("vijver") and lake ("meer") but very loosely defined, 
and many more terms for other bodies of water. 

I think a clearcut definition would not help at all in this case.

Peter Elderson

> Op 10 nov. 2020 om 06:30 heeft Joseph Eisenberg  
> het volgende geschreven:
> 
> 
> The tag water=pond was added with a large number of other types of "water=*" 
> in 2011, but it has a poorly defined description. 
> 
> "A pond: a body of standing water, man-made in most cases, that is usually 
> smaller than a lake. Salt evaporation ponds should be tagged with 
> landuse=salt_pond, open-air swimming pools — with leisure=swimming_pool."
> 
> So it might be artificial, like a landuse=reservoir or water=reservoir, but 
> smallish. Or it might be natural like a water=lake, but smallish. However, 
> nothing on the water=lake page defines a lower limit for the size of a lake.
> 
> This is a shame, because all the other values of water=* are clearly defined 
> as only natural, or only artificial, and waterway=* features are also clearly 
> divided. Furthermore, the original lags landuse=reservoir and landuse=basin 
> were also clearly artificial, while lakes were natural.
> 
> But the biggest problem is that there is no way to define a lower size for a 
> lake or reservoir, or an upper size for a pond. And the size of the area is 
> easier available from the geometry of the feature, so it doesn't need to be 
> mentioned in the tag. 
> 
> I think the best option is to deprecate water=pond and suggest using 
> water=lake for natural lakes, even small ones, and use water=reservoir or 
> water=basin (or landuse=reservoir or =basin if you prefer) for the artificial 
> ones. 
> 
> -- Joseph Eisenberg
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Deprecate water=pond?

2020-11-09 Thread Alessandro Sarretta

Hi,

I don't agree with the deprecation of water=pond. I find it perfect for 
small body of water like the ones you can see here for cows watering: 
https://www.openstreetmap.org/way/301144562


Ale

On 10/11/20 06:26, Joseph Eisenberg wrote:
The tag water=pond was added with a large number of other types of 
"water=*" in 2011, but it has a poorly defined description.


"A pond : a body of standing 
water, man-made in most cases, that is usually smaller than a lake. 
Salt evaporation ponds should be tagged with landuse 
=salt_pond 
, 
open-air swimming pools — with leisure 
=swimming_pool 
."


So it might be artificial, like a landuse=reservoir or 
water=reservoir, but smallish. Or it might be natural like a 
water=lake, but smallish. However, nothing on the water=lake page 
defines a lower limit for the size of a lake.


This is a shame, because all the other values of water=* are clearly 
defined as only natural, or only artificial, and waterway=* features 
are also clearly divided. Furthermore, the original lags 
landuse=reservoir and landuse=basin were also clearly artificial, 
while lakes were natural.


But the biggest problem is that there is no way to define a lower size 
for a lake or reservoir, or an upper size for a pond. And the size of 
the area is easier available from the geometry of the feature, so it 
doesn't need to be mentioned in the tag.


I think the best option is to deprecate water=pond and suggest using 
water=lake for natural lakes, even small ones, and use water=reservoir 
or water=basin (or landuse=reservoir or =basin if you prefer) for the 
artificial ones.


-- Joseph Eisenberg

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

--
--

Alessandro Sarretta

skype/twitter: alesarrett
Web: ilsarrett.wordpress.com 

Research information:

 * Google scholar profile
   
 * ORCID 
 * Research Gate 
 * Impactstory 

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


Re: [Tagging] Deprecate water=pond?

2020-11-09 Thread Brian M. Sperlongano
I normally use the name of the body of water, e.g. Foo Pond gets water=pond
and Bar Lake gets water=lake.  It's not clear to me that they have a
distinction beyond customary naming, and in my area there are ponds bigger
than lakes, though usually the lakes are larger.  If there is no
distinction beyond size, I agree that these tags are redundant, much in the
way that place=island and place=islet are: the comparative size can be
obtained from the geometry.

On Tue, Nov 10, 2020, 12:30 AM Joseph Eisenberg 
wrote:

> The tag water=pond was added with a large number of other types of
> "water=*" in 2011, but it has a poorly defined description.
>
> "A pond : a body of standing water,
> man-made in most cases, that is usually smaller than a lake. Salt
> evaporation ponds should be tagged with landuse
> =salt_pond
> , open-air
> swimming pools — with leisure
> =swimming_pool
> ."
>
> So it might be artificial, like a landuse=reservoir or water=reservoir,
> but smallish. Or it might be natural like a water=lake, but smallish.
> However, nothing on the water=lake page defines a lower limit for the size
> of a lake.
>
> This is a shame, because all the other values of water=* are clearly
> defined as only natural, or only artificial, and waterway=* features are
> also clearly divided. Furthermore, the original lags landuse=reservoir and
> landuse=basin were also clearly artificial, while lakes were natural.
>
> But the biggest problem is that there is no way to define a lower size for
> a lake or reservoir, or an upper size for a pond. And the size of the area
> is easier available from the geometry of the feature, so it doesn't need to
> be mentioned in the tag.
>
> I think the best option is to deprecate water=pond and suggest using
> water=lake for natural lakes, even small ones, and use water=reservoir or
> water=basin (or landuse=reservoir or =basin if you prefer) for the
> artificial ones.
>
> -- Joseph Eisenberg
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Deprecate water=pond?

2020-11-09 Thread Graeme Fitzpatrick
On Tue, 10 Nov 2020 at 15:30, Joseph Eisenberg 
wrote:

>
> I think the best option is to deprecate water=pond and suggest using
> water=lake for natural lakes, even small ones,
>

No, I don't agree, sorry.

Same as the difference between rivers & streams, there is a difference
between lakes & ponds (actually due to teh depth, not teh size!), so we
should keep them both.

Thanks

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


[Tagging] Deprecate water=pond?

2020-11-09 Thread Joseph Eisenberg
The tag water=pond was added with a large number of other types of
"water=*" in 2011, but it has a poorly defined description.

"A pond : a body of standing water,
man-made in most cases, that is usually smaller than a lake. Salt
evaporation ponds should be tagged with landuse
=salt_pond
, open-air
swimming pools — with leisure
=swimming_pool
."

So it might be artificial, like a landuse=reservoir or water=reservoir, but
smallish. Or it might be natural like a water=lake, but smallish. However,
nothing on the water=lake page defines a lower limit for the size of a lake.

This is a shame, because all the other values of water=* are clearly
defined as only natural, or only artificial, and waterway=* features are
also clearly divided. Furthermore, the original lags landuse=reservoir and
landuse=basin were also clearly artificial, while lakes were natural.

But the biggest problem is that there is no way to define a lower size for
a lake or reservoir, or an upper size for a pond. And the size of the area
is easier available from the geometry of the feature, so it doesn't need to
be mentioned in the tag.

I think the best option is to deprecate water=pond and suggest using
water=lake for natural lakes, even small ones, and use water=reservoir or
water=basin (or landuse=reservoir or =basin if you prefer) for the
artificial ones.

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


Re: [Tagging] Power line going underground

2020-11-09 Thread Tod Fitch
I’ve added those tags. JOSM still complains but if it fits the power line 
schema better I guess having some editor warnings is okay.

Thank you!

> On Nov 9, 2020, at 11:25 AM, Hidde Wieringa  wrote:
> 
> Hello,
> 
> You could use "line_management=transition" (and according to the wiki also 
> "location:transition=yes"). See for more examples the wiki 
> https://wiki.openstreetmap.org/wiki/Tag%3Aline_management%3Dtransition with 
> similar entries as the photo you posted.
> 
> Whether this suppresses the warning in JOSM, I do not know.
> 
> Kind regards,
> Hidde
> 
> 
> 
> On 09-11-2020 18:40, Tod Fitch wrote:
>> There are a number of places where an above ground power line transitions to 
>> below ground. I am not equipped to guess where the line runs once it goes 
>> below ground so I stop mapping at the last power pole.  However the 
>> validation in JOSM flags this with a warning and I hate warnings on my 
>> edits. Is there some tag to put on the last power pole to indicate this is 
>> not an issue? I don’t see tagging for this situation described in the wiki.
>> 
>> See
>> https://cloud.fitchfamily.org/index.php/s/k23qn2ERyqo4a3w
>>  for an example of this.
>> 
>> 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



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


Re: [Tagging] Basic cartography features missing, why?

2020-11-09 Thread stevea
On Nov 9, 2020, at 6:22 PM, Graeme Fitzpatrick  wrote:
> Yes, long, but not (yet!) tedious, at least to me! :-), as I both agree, & 
> disagree, with some of the points raised.
> 
> Looking forward to the result of the discussions you both may have.

I appreciate that, Graeme.  As Anders gets back to me and we continue to hash 
out what I hope are understandings, with his permission I'll re-post those 
"results" back up here.  I HOPED that this wasn't too tedious, thanks for 
letting me know that being wordy is (sometimes) worth it.

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


Re: [Tagging] Basic cartography features missing, why?

2020-11-09 Thread Graeme Fitzpatrick
On Tue, 10 Nov 2020 at 06:06, stevea  wrote:

> let's take that off-list.  Those would be appropriate to discuss ON list,
> it's true, and maybe you publish the RESULTS of our off-list discussion
> here after we've emailed each other.  But I feel we have spent a great deal
> of time (and passion!) here on this list and it's getting tedious for other
> readers.  This thread is LONG!
>

Yes, long, but not (yet!) tedious, at least to me! :-), as I both agree, &
disagree, with some of the points raised.

Looking forward to the result of the discussions you both may have.

Thanks

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


Re: [Tagging] Power line going underground

2020-11-09 Thread Mateusz Konieczny via Tagging
You can suggest not complaining in such case by creating a JOSM issue:

see instructions at 
https://josm.openstreetmap.de/newticket


Nov 9, 2020, 21:50 by t...@fitchfamily.org:

> I’ve added those tags. JOSM still complains but if it fits the power line 
> schema better I guess having some editor warnings is okay.
>
> Thank you!
>
>> On Nov 9, 2020, at 11:25 AM, Hidde Wieringa  wrote:
>>
>> Hello,
>>
>> You could use "line_management=transition" (and according to the wiki also 
>> "location:transition=yes"). See for more examples the wiki 
>> https://wiki.openstreetmap.org/wiki/Tag%3Aline_management%3Dtransition with 
>> similar entries as the photo you posted.
>>
>> Whether this suppresses the warning in JOSM, I do not know.
>>
>> Kind regards,
>> Hidde
>>
>>
>>
>> On 09-11-2020 18:40, Tod Fitch wrote:
>>
>>> There are a number of places where an above ground power line transitions 
>>> to below ground. I am not equipped to guess where the line runs once it 
>>> goes below ground so I stop mapping at the last power pole.  However the 
>>> validation in JOSM flags this with a warning and I hate warnings on my 
>>> edits. Is there some tag to put on the last power pole to indicate this is 
>>> not an issue? I don’t see tagging for this situation described in the wiki.
>>>
>>> See
>>> https://cloud.fitchfamily.org/index.php/s/k23qn2ERyqo4a3w
>>>  for an example of this.
>>>
>>> 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] religious bias - Feature Proposal - Voting - (Chapel of rest)

2020-11-09 Thread ET Commands



Date: Mon, 9 Nov 2020 10:34:06 +0100
From: Tom Pfeifer 
To: "Tag discussion, strategy and related tools"

Subject: Re: [Tagging] religous bias - Feature Proposal - Voting -
(Chapel of rest)


I appreciate amenity=place_of_mourning.

tom



What's wrong with funeral_home?  I've seen that term used several times 
in this discussion, and it's religion-agnostic.


Mark


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


[Tagging] Power line going underground

2020-11-09 Thread Tod Fitch
There are a number of places where an above ground power line transitions to 
below ground. I am not equipped to guess where the line runs once it goes below 
ground so I stop mapping at the last power pole.  However the validation in 
JOSM flags this with a warning and I hate warnings on my edits. Is there some 
tag to put on the last power pole to indicate this is not an issue? I don’t see 
tagging for this situation described in the wiki.

See https://cloud.fitchfamily.org/index.php/s/k23qn2ERyqo4a3w for an example of 
this.

Thanks!




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


Re: [Tagging] Basic cartography features missing, why?

2020-11-09 Thread Martin Koppenhoefer
Am Mo., 9. Nov. 2020 um 13:15 Uhr schrieb Anders Torger :

> A question, is this database only intended for very large polygons, or
> also rather small?
>


at the moment, the polygons are all rather small, but the intention is to
get regions of all sizes, where they exist. As long as it is not so many,
they could all go into the same file, but I think we will sooner or later
have to break this up into several files, both by continents (or more
generically, by location) and by size/map scale (you won't use very small
and very big polygons in the same map anyway). On the other hand, splitting
information according to intended map scale will lead to duplicate
information across scales and grow the required maintenance effort, so I am
reluctant to make this step as long as it can be avoided. This part is
still work in progress and will also depend on the number of external
contributions.

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


Re: [Tagging] Basic cartography features missing, why?

2020-11-09 Thread Martin Koppenhoefer
sorry, of course I meant "rather large", in the first sentence
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Basic cartography features missing, why?

2020-11-09 Thread Paul Allen
On Mon, 9 Nov 2020 at 20:06, stevea  wrote:

>
> For example, you complain that natural=peninsula doesn't render.  So?
> That's not a problem with OSM, it is you assuming that a particular
> renderer is going to display the semiotics you believe it should, when it
> likely does not (exactly as you believe it should).  That doesn't mean OSM
> has "basic cartography features missing," it means you are expecting
> something from a particular renderer it likely doesn't perform or deliver
> as you expect.
>

This is one reason different countries have set up their own renderers
with cartographic styles that align better with the expectations in those
countries.  There even seems to be a Swedish version, although
whenever I've tried it over the past few days it times out.  See
https://openstreetmap.se/

In principle it would be possible to use that, or even your own private
renderer, to develop a cartographic style that does what you want
(provided the objects you are interested in, such as peninsulas,
exist in the database).  If you can achieve something there that the
standard renderer does not offer, you could even submit your
new features to the standard renderer.  Some of your changes might
conflict with other goals but, where there are no conflicts, submitting
working code to do X has a far better chance of happening (and happening
relatively quickly) than adding another wish to an already-long list.

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


Re: [Tagging] Basic cartography features missing, why?

2020-11-09 Thread stevea
On Nov 9, 2020, at 12:59 AM, Anders Torger  wrote:
> Hello Steve, I admire your passion.

Thank you, that is a word both used about me in this project by others and one 
I use myself.  Most apt; some of us in OSM are almost "rabidly" passionate!

> This is my perspective: there are many projects to contribute to, I have 
> multiple interests, I have a limited amount of hours to contribute. I have 
> worked in many high risk ventures, and seen at least 10 years of my work 
> life's production has just disappeared in projects that did not make it. I 
> have experienced work-related burnout once in my life, 16 years ago, and I 
> still have not recovered 100% probably never will, so I need to be careful 
> before I bit over something too large.

Burnout happens.  Thanks for sharing that, it offers perspective and potential 
danger of what can happen if we are not careful to manage our time and risk, 
even in OSM.  I myself have suffered burnout in OSM, where I have to back away 
from it for a bit and do other things.  But I do always seem to come back to 
OSM, it is both rewarding and relaxing, an awesome combination.

> So I make a "due diligence" of projects before I commit. For OSM I actually 
> started before looking into it, fixing roads so the route planner I used for 
> sharing my bike rides would actually work. But this year I've been thinking 
> about stepping up the game, considering mapping, not programming (that's a 
> whole different level of brain activity).

For "sharing bike rides," some of my compatriots / associates in the world of 
mapping and biking find that RideWithGPS (.com) provides the needed services; 
check it out.  (I'm not a member nor do I get anything for saying that, it's 
simply a recommendation I can make as people I know say that it works and I've 
used it and tend to agree).  I don't know if it works in Sweden, maybe, maybe 
not.

Coding is different than mapping, that's for sure.  Both are cerebral tasks, 
there are different left-brain / right-brain mixes in each of them in different 
ways (brain hemispheres).

> Then I first started with testing if OSM feature set was currently capable of 
> generating maps to a similar level I'm used to from the real maps I've been 
> using all my life. It was not in some important key aspects, and I was a bit 
> surprised of the type of features that was lacking as I consider them central 
> for good cartography. So I started investigate how these could be added, 
> first simply by reporting them as bugs, with an initial suggestion how they 
> might be fixed. But long story short, I've come to realize that it's a 
> multi-year process, and the interest of having these "basic" cartography 
> features is weaker than I expected. I've also investigated import status in 
> Sweden, why the situation is like it is despite five years of good data being 
> available which could significantly improve the baseline. The result of that 
> investigation is that we don't have much if any organization locally, and 
> it's technically hard to make imports, those that have tried have got less 
> than optimal and/or only partial results. I've also looked at community 
> statistics. There are about 50 active mappers in Sweden. Despite me being 
> rather casual mapper, I was recently placed top 15. And we have the 
> competition from easy access of high quality maps. This is a tricky situation 
> for any project.

Anders, I (for the third time) have gone back and read your "list of nine" 
things an earlier message of yours in this thread states are "limitations" and 
I'd like to ease your frustrations about those.  I'm not quite sure whether we 
should be doing this to the wider list, so perhaps we take it off-list, as you 
have specific concerns that I'm not convinced will benefit the entirety of the 
tagging discussion list.  But briefly, you seem to have both specific concerns 
about "mapping limitations / cartographic features missing" and what might be 
called broader OSM-wide concerns about the project as a whole 
(professionalization, imports...).  I feel I could more easily help you with 
the specifics of "limitations," (as I don't believe you are really as limited 
in mapping as you believe you are).  So, let's take that discussion off-list.

For example, you complain that natural=peninsula doesn't render.  So?  That's 
not a problem with OSM, it is you assuming that a particular renderer is going 
to display the semiotics you believe it should, when it likely does not 
(exactly as you believe it should).  That doesn't mean OSM has "basic 
cartography features missing," it means you are expecting something from a 
particular renderer it likely doesn't perform or deliver as you expect.  That's 
all — not that OSM is broken.  And I still don't understand what your complaint 
is about "tagging and naming areas 'on the ground' does not seem to be 
developed much at all."  I'm tempted to say "nonsense," as I certainly don't 
have this problem (nor do 

Re: [Tagging] Power line going underground

2020-11-09 Thread Hidde Wieringa

Hello,

You could use "line_management=transition" (and according to the wiki 
also "location:transition=yes"). See for more examples the wiki 
https://wiki.openstreetmap.org/wiki/Tag%3Aline_management%3Dtransition 
with similar entries as the photo you posted.


Whether this suppresses the warning in JOSM, I do not know.

Kind regards,
/Hidde/


On 09-11-2020 18:40, Tod Fitch wrote:

There are a number of places where an above ground power line transitions to 
below ground. I am not equipped to guess where the line runs once it goes below 
ground so I stop mapping at the last power pole.  However the validation in 
JOSM flags this with a warning and I hate warnings on my edits. Is there some 
tag to put on the last power pole to indicate this is not an issue? I don’t see 
tagging for this situation described in the wiki.

See https://cloud.fitchfamily.org/index.php/s/k23qn2ERyqo4a3w for an example of 
this.

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] Feature Proposal - Voting - Special Economic Zone

2020-11-09 Thread Brian M. Sperlongano
The proposal for boundary=special_economic_zone is now open for voting.

Thank you to those that have offered comments and feedback on this
proposal.  Community input has been incorporated into the current version
of the proposal.

Voting link:
https://wiki.openstreetmap.org/wiki/Proposed_features/Special_economic_zone#Voting
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Proposal for admission=* tag

2020-11-09 Thread Janko Mihelić
Okay, it took a while, but I revised the wiki of the proposal. I removed
the possibility of tagging without relations, and added a table with
examples of tagging.

https://wiki.openstreetmap.org/wiki/Proposed_features/Admission#Additional_relation_tags

Send your opinions.

uto, 27. lis 2020. u 00:18 Martin Koppenhoefer 
napisao je:

> to avoid a lot of relations, I think we should have 2 functions (or pois
> within the feature):
> 1.
> place where you can buy the tickets, and
> 2.
> place where the tickets are checked
>
> this could also be the same place (e.g. ticket office where you have to
> pass through in order to enter the POI).
> Of places to get the ticket there are at least 3 kind: a machine issuing
> tickets, a person where you can buy tickets, or a place where you can get
> tickets which you already reserved or bought before.
>
> All the simpler cases (ticket office within or at the perimeter of the
> POI), we do not really need a relation, a specific tag would be sufficient.
> Sometimes it could be a property of "entrance=*" or barrier=gate objects
>
> 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] Basic cartography features missing, why?

2020-11-09 Thread Anders Torger

A question, is this database only intended for very large polygons, or
also rather small? 


From my mapping perspective here in Sweden fuzzy polygons exist down to

say ~1 km size (generally speaking names of hills, valleys, peninsulas
etc). In fact the most I run into is in the 2 - 10 km size. I also come
across many bays and straits of similar sizes, those can be defined (and
rendered) in OSM already today, but I now understand that many don't
like that they exist, so maybe those should be managed in this type of
separate database too? 


On 2020-11-09 10:08, Martin Koppenhoefer wrote:

Am Mo., 9. Nov. 2020 um 09:37 Uhr schrieb Mateusz Konieczny via Tagging : 

In short: technically CC0 may be used, but it would be confusing as ODBL would still 
apply anyway. 

See https://wiki.osmfoundation.org/wiki/Licence/Licence_Compatibility#CC0 

"CC0 licenced material is in general compatible, however the license only extends 
to material the licensor actually has rights in and specifically avoids making a 
statement on the status of any third party material included." 

So you could license this as CC0, but it does not mean that other limitations are 
not applying (limited extraction of just some shapes from OpenStreetMap may 
be doable without triggering ODBL - see 
https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Substantial_-_Guideline 
but such project would likely quickly pass it).


For the avoidance of doubt, there is currently no data from OpenStreetMap in OpenGeographyRegions, and there will not be in the future, so that the data can be used without limitations. My intention is using it together with OSM data, but of course you can use it with whichever data you want. 

These regions, although it would be legally possible, should not be imported in OSM either, because they are in medium and large scale resolution and not suitable by their nature (not well defined on small scales, fuzzy boundaries, etc.). 

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] Basic cartography features missing, why?

2020-11-09 Thread Yves via Tagging


Le 9 novembre 2020 10:08:42 GMT+01:00, Martin Koppenhoefer 
 a écrit :
>Am Mo., 9. Nov. 2020 um 09:37 Uhr schrieb Mateusz Konieczny via Tagging <
>tagging@openstreetmap.org>:
>
>> In short: technically CC0 may be used, but it would be confusing as ODBL
>> would still
>> apply anyway.
>>
>> See https://wiki.osmfoundation.org/wiki/Licence/Licence_Compatibility#CC0
>>
>> "CC0 licenced material is in general compatible, however the license only
>> extends
>> to material the licensor actually has rights in and specifically avoids
>> making a
>> statement on the status of any third party material included."
>>
>> So you could license this as CC0, but it does not mean that other
>> limitations are
>> not applying (limited extraction of just some shapes from OpenStreetMap may
>> be doable without triggering ODBL - see
>>
>> https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Substantial_-_Guideline
>> but such project would likely quickly pass it).
>>
>
>
>For the avoidance of doubt, there is currently no data from OpenStreetMap
>in OpenGeographyRegions, and there will not be in the future, so that the
>data can be used without limitations. My intention is using it together
>with OSM data, but of course you can use it with whichever data you want.
>
>These regions, although it would be legally possible, should not be
>imported in OSM either, because they are in medium and large scale
>resolution and not suitable by their nature (not well defined on small
>scales, fuzzy boundaries, etc.).
>
>Cheers
>Martin

Ah, I thought this could be used to host extremely big fuzzy MPs that we 
otherwise do not welcome in OSM. 
Yves 

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


Re: [Tagging] religous bias - Feature Proposal - Voting - (Chapel of rest)

2020-11-09 Thread Tom Pfeifer

I appreciate amenity=place_of_mourning.

tom

On 09.11.2020 10:15, woll...@posteo.de wrote:
OK, so I haven't really done all the counting, but my impression is that amenity=place_of_mourning 
has quite some fans while most of the others are at least able to swallow it.


Unless anyone explains me that I got that wrong, I think I'll move the proposal 
there then.

Am 05.11.2020 09:43 schrieb woll...@posteo.de:

Thanks for all the interventions.

To avoid that the discussion becomes inconclusive again, could
everybody rate the following "favourable", "acceptable" or
"unfavourable"?

amenity=mourning
amenity=place_of_mourning
amenity=mourning_room
amenity=viewing_arrangements
amenity=deceased_viewing

Am 04.11.2020 11:17 schrieb woll...@posteo.de:

Dear all,

As there have been no more comments for some time on this proposal,
I've set it to voting. Please have a look and vote:

Chapel of rest: a room or building where families and friends can come
and view someone who has died before their funeral

Proposal page:
https://wiki.openstreetmap.org/wiki/Proposed_features/Chapel_of_rest

Discussion page:
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Chapel_of_rest

Thanks!

Vollis


___
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] religous bias - Feature Proposal - Voting - (Chapel of rest)

2020-11-09 Thread wolle68
OK, so I haven't really done all the counting, but my impression is that 
amenity=place_of_mourning has quite some fans while most of the others 
are at least able to swallow it.


Unless anyone explains me that I got that wrong, I think I'll move the 
proposal there then.


Am 05.11.2020 09:43 schrieb woll...@posteo.de:

Thanks for all the interventions.

To avoid that the discussion becomes inconclusive again, could
everybody rate the following "favourable", "acceptable" or
"unfavourable"?

amenity=mourning
amenity=place_of_mourning
amenity=mourning_room
amenity=viewing_arrangements
amenity=deceased_viewing

Am 04.11.2020 11:17 schrieb woll...@posteo.de:

Dear all,

As there have been no more comments for some time on this proposal,
I've set it to voting. Please have a look and vote:

Chapel of rest: a room or building where families and friends can come
and view someone who has died before their funeral

Proposal page:
https://wiki.openstreetmap.org/wiki/Proposed_features/Chapel_of_rest

Discussion page:
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Chapel_of_rest

Thanks!

Vollis


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


Re: [Tagging] Basic cartography features missing, why?

2020-11-09 Thread Martin Koppenhoefer
Am Mo., 9. Nov. 2020 um 09:37 Uhr schrieb Mateusz Konieczny via Tagging <
tagging@openstreetmap.org>:

> In short: technically CC0 may be used, but it would be confusing as ODBL
> would still
> apply anyway.
>
> See https://wiki.osmfoundation.org/wiki/Licence/Licence_Compatibility#CC0
>
> "CC0 licenced material is in general compatible, however the license only
> extends
> to material the licensor actually has rights in and specifically avoids
> making a
> statement on the status of any third party material included."
>
> So you could license this as CC0, but it does not mean that other
> limitations are
> not applying (limited extraction of just some shapes from OpenStreetMap may
> be doable without triggering ODBL - see
>
> https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Substantial_-_Guideline
> but such project would likely quickly pass it).
>


For the avoidance of doubt, there is currently no data from OpenStreetMap
in OpenGeographyRegions, and there will not be in the future, so that the
data can be used without limitations. My intention is using it together
with OSM data, but of course you can use it with whichever data you want.

These regions, although it would be legally possible, should not be
imported in OSM either, because they are in medium and large scale
resolution and not suitable by their nature (not well defined on small
scales, fuzzy boundaries, etc.).

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


Re: [Tagging] Basic cartography features missing, why?

2020-11-09 Thread Anders Torger

Hello Steve,

I admire your passion.

This is my perspective: there are many projects to contribute to, I have 
multiple interests, I have a limited amount of hours to contribute. I 
have worked in many high risk ventures, and seen at least 10 years of my 
work life's production has just disappeared in projects that did not 
make it. I have experienced work-related burnout once in my life, 16 
years ago, and I still have not recovered 100% probably never will, so I 
need to be careful before I bit over something too large.


So I make a "due diligence" of projects before I commit. For OSM I 
actually started before looking into it, fixing roads so the route 
planner I used for sharing my bike rides would actually work. But this 
year I've been thinking about stepping up the game, considering mapping, 
not programming (that's a whole different level of brain activity).


Then I first started with testing if OSM feature set was currently 
capable of generating maps to a similar level I'm used to from the real 
maps I've been using all my life. It was not in some important key 
aspects, and I was a bit surprised of the type of features that was 
lacking as I consider them central for good cartography. So I started 
investigate how these could be added, first simply by reporting them as 
bugs, with an initial suggestion how they might be fixed. But long story 
short, I've come to realize that it's a multi-year process, and the 
interest of having these "basic" cartography features is weaker than I 
expected. I've also investigated import status in Sweden, why the 
situation is like it is despite five years of good data being available 
which could significantly improve the baseline. The result of that 
investigation is that we don't have much if any organization locally, 
and it's technically hard to make imports, those that have tried have 
got less than optimal and/or only partial results. I've also looked at 
community statistics. There are about 50 active mappers in Sweden. 
Despite me being rather casual mapper, I was recently placed top 15. And 
we have the competition from easy access of high quality maps. This is a 
tricky situation for any project.


It seems like due to the limited maturity locally, I need to go in full 
time and become an OSM champion, and that is what you tell me as well. 
Indeed I think I have the competence (or rather have the basic skill set 
so I can build it), but unfortunately not the capacity, and if I need to 
spend a lot of time I prefer projects with more programming and less 
politics. It's natural that large communities have lots of politics, so 
I tend to prefer smaller projects, or alternatively large ones with 
clear roadmaps and well-defined sub-tasks to engage in (my Linux kernel 
work belongs to the latter).


If I wait for the project to move on its own here locally, I consider it 
to be a substantial risk that nothing will happen, but who knows, 
hopefully someone has the skill, time, passion and capacity to engage. 
It also seems like cartography to the level I expect is not a key 
priority within the majority of the project, and to me personally that 
takes away a big part of the joy of mapping. I don't just want to make a 
geodata database, I want to see beautiful useful maps. Of course all 
want that, but there are many different views on what makes up useful 
maps. To me the generalization shortcomings are just too large, and have 
been that for a long time.


About overall maturity, I don't think 16 years runtime makes a project 
automatically mature. Another perfectly realistic scenario is that the a 
project outgrows the initial processes making it stagnant in certain 
aspects which causes various functionality gaps that wouldn't be 
expected of a project of this age. It's my assessment that this is 
exactly the current situation with OSM. No assessment is perfect and 
100% complete, but for my own purposes I've got enough of those 
indications to come to that conclusion. This doesn't mean that it cannot 
change, but it's not something I can do. The only thing I can do is to 
report what I see and then the rest of the community can do whatever 
they like with it.


In all, for me probably the wisest thing to do is to step back and 
continue my casual contributions as needed for my bike routes, and keep 
and eye and see what happens with OSM at large and locally in Sweden, 
but not engage in detailed cartography until it can be represented well.


Regarding suggesting things, I think I have made plenty of suggestions, 
both in terms of how features could possibly be implemented, and how 
priorities could be changed etc, and many of these are just the same as 
many others have suggested in one way or another. Of course, I cannot 
expect these to be implemented just like that, and obviously many think 
that these suggestions are outright poor ideas, perhaps the majority of 
the community. I don't know. This is just a view of some random guy 
making a due 

Re: [Tagging] Basic cartography features missing, why?

2020-11-09 Thread Mateusz Konieczny via Tagging



Nov 8, 2020, 17:44 by jayands...@gmail.com:

>>> And there should be several specialized layers: general car navigation map, 
>>> sport map for hiking/cycling/skiing, transportation. All of that would be 
>>> possible with vector tiles which are less computationally demanding to 
>>> create.
>>>
>> We already have multiple map styles.
>>
>
> What they mean is that the current map styles run by other providers will not 
> be necessary if we switch to vector tiles. 
>
(1) Only if all people will agree what and how should be included in vector 
tiles.
Due to conflicts between quality and tile size and performance on client and 
different
needs unification is simply impossible and will not happen and should not be 
expected to
happen

For example: hiking trails map vs pipeline map vs focus on small tile size - 
all of that
have completely different needs.

(2) This is nitpicking, but remember that big benefit of vector tiles is that 
you can have own
map style allowing some (limited, not full) changes how map is rendered. 

So number of map styles would increase, not reduce as vector tiles are more 
widely available.

And vector tiles served from OSMF servers would not mean that commercial 
hosting by
companies would become unnecessary - if you meant that by
"current map styles run by other providers will not be necessary"___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Basic cartography features missing, why?

2020-11-09 Thread Mateusz Konieczny via Tagging
Warning: I am not a lawyer

In short: technically CC0 may be used, but it would be confusing as ODBL would 
still
apply anyway.

See https://wiki.osmfoundation.org/wiki/Licence/Licence_Compatibility#CC0

"CC0 licenced material is in general compatible, however the license only 
extends
to material the licensor actually has rights in and specifically avoids making a
statement on the status of any third party material included."

So you could license this as CC0, but it does not mean that other limitations 
are
not applying (limited extraction of just some shapes from OpenStreetMap may
be doable without triggering ODBL - see
https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Substantial_-_Guideline
but such project would likely quickly pass it).

In the same way as Wikidata is CC0 but not importable into OpenStreetMap
as they include location data systematically copied from various sources,
for example Google Maps.

Nov 8, 2020, 10:10 by tagging@openstreetmap.org:

> Good initiative Martin, at first sight I'll make two comments :
> * CC0 doesn't allow to derive data from OSM
> * as geometries are fuzzy in nature, there should be a way to accept several 
> geometries for a same entity, be it only to avoid long discussions on 
> boundaries
> Yves 
>
> Le 8 novembre 2020 09:47:04 GMT+01:00, Martin Koppenhoefer 
>  a écrit :
>
>>
>>
>> sent from a phone
>>
>>
>>> On 8. Nov 2020, at 09:24, Mateusz Konieczny via Tagging 
>>>  wrote:
>>>
>>> I really like an idea of separate database/layer for such fuzzy objects.
>>>
>>
>>
>> I have started a project to collect such fuzzy objects. Data is stored in a 
>> git repo in Geojson representation. Pull requests welcome.
>> https://github.com/dieterdreist/OpenGeographyRegions
>>
>> Cheers Martin 
>>
>>

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


Re: [Tagging] Basic cartography features missing, why?

2020-11-09 Thread Mateusz Konieczny via Tagging
Nov 8, 2020, 14:00 by tomasstrau...@gmail.com:

> 2020-11-08, sk, 09:46 Mateusz Konieczny via Tagging rašė:
>
>> (and it is from person who put a lot of effort into tagging improvements, 
>> wikifiddling,
>> deprecating some unwanted values, deduplication and validator-related work 
>> and has
>> some experience from data consumer side)
>>
>
> That is a lie, as you're supporter of harmful duplication of water schema :-D
>
Fact that I do not agree in 100% with Tomas Straupis does not invalidate 
anything 
of what you quoted.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging