Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-14 Thread Christoph Hormann


> Anders Torger  hat am 14.12.2020 15:49 geschrieben:
> 
> Okay, but why does the OSM-Carto renderer, and all other renderers known 
> to man(?) make multiple text labels then, when it should be a single 
> one? 

OSM-Carto renders labels primarily based on the following constraints:

* due to the requirement of real time updates more complex operations are 
severely restricted.  Clustering features, aggregating the clusters 
geometry-wise and labeling the aggregates are such operations.
* we want the relationship between the data in the database and the rendering 
results to be intuitively understandable for the mapper so they can derive 
useful feedback from the map.  That also limits the complexity of data 
processing we can use.
* like all zoomable interactive maps OSM-Carto has to deal with the problem 
that high quality labeling is zoom level dependent.  At the same time having 
different approaches to labeling at different zoom levels adds a lot of 
complexity to the style - and OSM-Carto is already one of the most complex map 
styles in existence.  Hence compromises are made that look better on some zoom 
levels than on others.

As far as other map styles are concerned - i have said that before: high 
quality cartography is expensive and the bulk of the digital map market is low 
quality and low price - hence requires low costs.  And the willingness to 
engage in strategic investment in methods for high quality cartography in the 
wider OSM ecosystem as well as in the open source GIS sector is so far rather 
small.  

What can you do as a mapper:  Produce an accurate representation of the 
geography that is non-complex in structure, is easy for you to map and maintain 
and that is consistent with how others map things and don't adjust your mapping 
to what you believe is most convenient for data users.

--
Christoph Hormann
https://www.imagico.de/

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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-14 Thread Christoph Hormann


> Anders Torger  hat am 14.12.2020 14:01 geschrieben:
> 
>  
> To make a specific answer to "what additional verifiable local 
> knowledge" this relation is intended to cover, is that the wetland is a 
> single named entity, not multiple entities named the same.

But i already explained that the fact that in OSM we add name tags to parts of 
roads, waterways, wetlands, forests or woods does not mean these are somehow 
separate from other features with the same name tags.  Names of physical 
geography features in OSM are - as explained - local names.  A polygon tagged 
natural=wood + name=foo means that this is an stretch of land covered with 
trees that locally is referred to with the name 'foo'.  If you took a walk on a 
route that crosses such polygon you can correctly say that today's hike took 
you through 'foo'.  However if your walk crossed five natural=wood polygons 
with name=foo you *cannot* say based on this that your walk took you through 
five 'foo' or through five parts of 'foo'.  The splitting of the wood into five 
polygons is part of the data model we use, it does not represent any 
'five-ness' is the verifiable reality.

> "Verifiable" is tricky in terms of names of natural features as we all 
> know, as many of those haven't defined borders. [...]

I think you have a pretty fundamental misunderstanding here.  Name tagging of 
physical features like wetlands in OSM have practically no issue with 
verifiability because the name tag specifies the name locally used for a 
feature that exists independent of the name.  

You however seem to be talking about abstract concepts that constitute 
themselves through the name and that exist only through the fact that it is 
referred to with some name in communication and that are neither tied to 
physical geography features that exist independent of humans (like a forest, 
lake, wetland etc.) or cultural geography features that constitute themselves 
from independently observable human activities (like shops, addresses or bus 
stops for example) beyond mere communication.

Such concepts are not mappable in OSM due to the lack of independent 
verifiability.  The world of such features does not represent a consistent 
independently observable reality.  Human communication as the foundation of 
this world is inherently inconsistent and self-contradicting.  You would end up 
with a Wikipedia-like paradigm of "reliable sources" and a constant struggle 
for cultural dominance and opinion leadership w.r.t. such features in the OSM 
database.

--
Christoph Hormann
https://www.imagico.de/

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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-14 Thread Christoph Hormann


> Anders Torger  hat am 14.12.2020 07:59 geschrieben:
> 
>  
> I'll gladly answer questions, but I think you need to rephrase. I 
> suppose it is some hidden critique in there, but I honestly do not 
> understand the question. It would be better for me if you put words on 
> the critique instead of wrapping it in a question.

There is no critique in there, i have not formed an opinion on the concept, i 
like to understand the reasoning behind this.  Hence the question.

The premise is that in OSM we record verifiable local knowledge about the 
geography of the world.  And we try to record that in a form that is most 
efficient for the mapper.  Hence the question what additional verifiable 
knowledge you intend to record with the additional data structures you propose 
to create that is not yet in what we already record today.

--
Christoph Hormann
https://www.imagico.de/

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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-13 Thread Christoph Hormann


> Anders Torger  hat am 13.12.2020 20:08 geschrieben:
> 
> [...] I think to actually have them all 
> tied together in a unit is still a good idea, [...]

That does not answer my question.

-- 
Christoph Hormann 
https://www.imagico.de/

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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-13 Thread Christoph Hormann


> Anders Torger  hat am 13.12.2020 15:28 geschrieben:
> 
> So what I've settled for (for now) is as follows:
> - same name on each part (the only way to get the data useful *today*)
> - a new relation with all parts as members (role unset), type=natural, 
> natural=wetland, name=

I am trying to understand what the issue is with the recommendation for mapping 
you have received from multiple sides here.

So what exactly is the verifiable knowledge that is supposed to be represented 
by your new relation type that is not already recorded in the mapping of 
physical features?

-- 
Christoph Hormann 
http://www.imagico.de/

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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-12 Thread Christoph Hormann


> Anders Torger  hat am 12.12.2020 12:23 geschrieben:
> 
> Sorry, I realize I have a followup question. Is this really the right 
> way?
> 
> There's a difference from the Rhine example. With rivers all the 
> separate parts are tied together with a parent relation of the type 
> waterway, and the parts have roles like "main_stream".

No, waterway relations are like route relations for roads, they are purely 
optional and have nothing to do with the local naming of physical features.

My strong advise is not to make this more complicated than it is and especially 
not cargo cult some complex data model in the hope that data users will turn 
this into something meaningful - they won't.

-- 
Christoph Hormann 
http://www.imagico.de/

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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-11 Thread Christoph Hormann


> Anders Torger  hat am 11.12.2020 17:07 geschrieben:
> 
> The least bad way I've come up with is to just name all polygons 
> belonging to the same wetlands the same,

That is widely considered to be the correct way.  It is established practice 
that mapping things like forest, wetland, farmland etc. can be split to 
differentiate tagging (like leaf_type, wetland type, crop etc.).  The name tag 
is then applied to all components.  Same as for waterways or roads where you 
can also split and apply the name to the components.

This also matches the general concept in OSM that names are typically local 
properties and only locally verifiable.  The Rhine river is called Rhein in 
Koblenz but Rhin in Strasbourg and Rijn in Rotterdam.

-- 
Christoph Hormann 
http://www.imagico.de/

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


Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

2020-11-24 Thread Christoph Hormann


> walker.t.brad...@gmail.com hat am 24.11.2020 12:19 geschrieben:
> 
> Is there a wiki page with a "wish-list" of things, with approximate costs 
> where developers could post?  There is likely a disconnect between those 
> willing to pay, and those who could actually scrounge up the money.  Thus, 
> once consensus on what changes are needed has been achieved, we can scrounge 
> for money?

There is certainly a deficit in comprehensive communication of the big tasks 
that are currently not being addressed in and around OSM-Carto.  Part of the 
reason for that is that most OSM-Carto maintainers are doing their work there 
as a hobby and are not very interested in paid OSM-Carto work specifically.  
That also means someone paying a developer for implementing something for 
OSM-Carto does not guarantee you that this will make it into OSM-Carto.  The 
maintainers still reserve the right to review changes for their suitability for 
the project.  See also

https://www.openstreetmap.org/user/imagico/diary/393808

where i previously discussed this being an issue for financing of OSM-Carto 
work.

But lets not beat around the bush too much - here from the top of my head a 
quick list of tasks that could be beneficial for improving the quality of the 
style:

* data preprocessing for low zoom level rendering of waterbodies and landcover. 
 I have done some work on that, some of it was already in production use on 
openstreetmapdata.com, not all of it is currently open source but there is 
extensive writeup on my blog and website.
* importance rating features based on their context.  This includes the widely 
discussed bay and strait rendering matter but also things like airports, 
populated places, peaks etc.
* boundary relation preprocessing.  This includes things like topologically 
consistent line simplification, topological simplification, unification of 
different forms of coastal boundary representation.
* aggregation and importance rating of highway and railway networks based on 
connectivity functions for higher quality low zoom rendering.  There is quite a 
lot of pre-existing work on the aggregation part but much of this does not 
scale or is robust enough for use on a global level of course.
* redesigning the POI and label layers of OSM-Carto for consistent 
prioritization.  There are multiple different levels of radicalism at which 
this could be approached.  This is the most important technical todo within 
OSM-Carto IMO that does not have direct use also beyond that style.

Regarding the volume of work required for these - that depends a lot on how 
you'd define the scope of work in each of the cases.  In those cases where no 
or very little pre-existing work exists it is probably wise to start with a 
proof-of-concept development before actually planning and working on a 
production ready implementation.

-- 
Christoph Hormann 
http://www.imagico.de/

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


Re: [Tagging] coastline v. water

2020-11-24 Thread Christoph Hormann
 - which naturally grow as OSM grows in 
ambitions - and the abilities and engagement in the non-mapping part of the 
community to develop and satisfy similar ambitions in cartographic quality 
without outsourcing the hard part of that work to the mappers.  Too many people 
have followed the illusion for too long that the large corporate OSM data users 
will provide the necessary support in that field while it turns out 
(non-surprisingly in my eyes) that they have neither an interest in above 
average cartographic quality nor in substantially sharing methods and 
competency in the little work they do in that domain.

-- 
Christoph Hormann 
http://www.imagico.de/

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


Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

2020-11-24 Thread Christoph Hormann


> Dave F via Tagging  hat am 24.11.2020 01:24 
> geschrieben:
> 
> Yes, but the demand was still made & 

So what?  Someone (an individual, not 'OSM-Carto' as a whole) made a suggestion 
(and not a demand) that turned out to not be such a good idea and therefore did 
not achieve consensus.

> the solution of writing competent 
> code to enable the proposal was never implemented, 
> so your point is?

I am not sure what you mean here.  One of the problem of tagging boundaries on 
ways and one of the main reason why the idea did not reach consensus is that it 
does not solve any of the rendering problems w.r.t. boundaries in substance.

Code for processing OSM boundary data for cartographic applications exists.  
Not all of it is open source and much of it is just rough implementations not 
robust enough for routine use.  And there are of course very different 
cartographic problems to solve w.r.t. boundary rendering.  Why is nothing in 
that direction in OSM-Carto right now?  Because no one so far has invested the 
volunteer time to do so an no one has invested the money to pay someone 
qualified to do so either.  And a large number of people consider the status 
quo as good enough.  "The good enough is an enemy of the great" is a very 
common pattern in map style development.

-- 
Christoph Hormann 
http://www.imagico.de/

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


Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

2020-11-22 Thread Christoph Hormann


> Mateusz Konieczny via Tagging  hat am 22.11.2020 
> 20:49 geschrieben:
> 
> > https://lists.openstreetmap.org/pipermail/tagging/2018-March/035347.html
> Yes, long time ago there was a problematic idea that was abandoned.

Exactly.  It also shows how we in OSM traditionally make decisions about 
tagging.  An idea to change tagging practice was suggested - on an open channel 
for everyone to read and comment on without hurdles and with an archive that 
allows us now to read up on things years later.  It was discussed and arguments 
and reasoning were provided both for and against the idea and based on that we 
reached consensus that it was a bad idea and it was abandoned.

-- 
Christoph Hormann 
http://www.imagico.de/

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


Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

2020-11-22 Thread Christoph Hormann


> Dave F via Tagging  hat am 22.11.2020 17:08 
> geschrieben:
> 
> [...] OSM-carto demanding boundaries on ways

???

I am smelling fake news here.

-- 
Christoph Hormann 
http://www.imagico.de/

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


Re: [Tagging] coastline v. water

2020-11-18 Thread Christoph Hormann
> Eric H. Christensen via Tagging  hat am 18.11.2020 
> 21:19 geschrieben:
> 
> [...]

First: the matter has been discussed at length previously so i would advise 
anyone who wants to form an opinion on the matter to read up on past discussion 
where essentially everything relevant has been said already.  Most relevant 
links:

https://lists.openstreetmap.org/pipermail/tagging/2020-July/054405.html
and resulting discussion:
https://lists.openstreetmap.org/pipermail/tagging/2020-August/thread.html#54434

https://wiki.openstreetmap.org/wiki/Proposed_Features/Coastline-River_transit_placement

Second:

> 
> Now, some of the feedback that has been presented[2] is that because it is 
> tidal it is part of the sea.  [...]

As you can read in the proposal linked above the range of tidal influence forms 
the upper limit of the range practical coastline mapping in areas with 
significant tidal range but as it is in practical mapping not the universally 
used limit.

Third:

While this is ultimately not relevant because the delineation of tags in OSM 
should be based on verifiable criteria obviously i have never seen any map that 
displays ocean water and inland waterbodies in differentiated form that shows 
the Chesapeake Bay as inland water.

Classical examples with differentiated rendering are TPC/ONC (caution: links go 
to large images):

http://legacy.lib.utexas.edu/maps/tpc/americas-pacific-index.html
http://legacy.lib.utexas.edu/maps/onc/txu-pclmaps-oclc-8322829_g_21.jpg

-- 
Christoph Hormann 
http://www.imagico.de/

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


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

2020-11-07 Thread Christoph Hormann
I wanted to quickly comment on two things where a misleading narrative seems to 
be represented in the discussion here so far.

The first one is the idea that OSM community cartography is being held back by 
the lack of computing power.  It is not.  The resources that would be required 
to run various data preprocessings that have from time to time been considered 
in map style development are absolutely negligible compared to the ressources 
used by the OSMF for rendering and tile delivery.

The problem is process development and maintainance.  I have - together with 
Jochen - from 2015 to 2019 operated openstreetmapdata.com where we offered 
various preprocessed OSM data for cartographic applications updated daily and 
we offered to develop additional processes and extend this with additional 
processed data offers in case people were willing to invest in that.  The 
interest in both the existing data sets as well as in developing new ones was 
extremely sparse.

And any such process needs aintenance obviously - the costs of which by far 
exceed those of the computing infrastructure.

I have during that time and since then done quite a bit of customized 
cartographic data processing for map producers but none of them was ever 
interested in actually financing open source process development in that 
domain.  Hence the work i have done there stays proprietary technology.

The bottom line is neither in the hobbyist OSM community nor among commercial 
OSM data users is there a substantial interest in investing in technologically 
advancing quality in automated rule based cartography based on generic geodata 
like in OSM.  The bays and straits Frederik discusses are a good example.  Both 
mappers and corporate data users seem much more keen in crowd sourcing the 
drawing of labeling polygons to the cheap labor of the mapping community than 
to invest into development and maintenance of open source processes to derive 
importance rating and labeling geometries from bay and strait nodes and 
coastline data.  The irony is that compared to some other problems of automated 
cartography based on OSM data (river networks just to mention one) this is not 
even close to rocket science.  With a 10-20k investment you could achieve quite 
a lot in this field (which is already now far less than the sum of work hours 
at minimum wage invested by mappers into drawing and maintaining labeling 
polygons).  This is just an example of course - there are many other fields.

The second thing i want to comment on is the yet again resurfacing story that 
OSM is falling behind compared to  - in this case government mapping.  And 
therefore we all quickly need to throw overboard all values and traditions of 
the project and urgently become more like .

Such calls are universally based on a lack of understanding of what 
OpenStreetMap is and how OSM became what it is today.  Yes, OpenStreetMap has 
deficits it needs to improve on (i discussed one of them above) but throwing 
overboard valuable lessons learned from the past and throwing ourselves at what 
seems to be the hype of the day is not going to solve anything.  Focusing on 
what OSM is good at and what has made and makes it successful as a social 
project, the cooperative collection of verifiable local geographic knowledge, 
is the key.  That requires a certain technological, communicative and yes, also 
cartographic context and to be and stay avant-garde in that context.  But 
trying to imitate for example what government mapping agencies do (who are 
universally still pretty much stuck in mere 1:1 digitalization of traditional 
pre-digital processes), or on other fronts:  what big corporate map producers 
do for cost efficient production of mediocre maps for social media platform 
customers who don't care a bit about cartographic quality, is definitely not a 
long term winning strategy to do that.

-- 
Christoph Hormann 
http://www.imagico.de/

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


Re: [Tagging] Rio de la Plata edit war

2020-08-07 Thread Christoph Hormann
On Friday 07 August 2020, Colin Smale wrote:
>
> The word "ocean" is already subjective... [...]

Oh please.  Not again another attempt to deflect into a discussion of 
language semantics when i am clearly not talking about the word ocean 
but about the abstract physical and language independent concept of the 
world ocean as the main reservoir of the global water cycle.

The distinction between a river and the world ocean is real and a 
fundamental aspect of our scientific understanding of the geography of 
this planet.  That digital maps have - based on the precedent set by 
Google - almost universally ignored this fact does not change it.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Rio de la Plata edit war

2020-08-07 Thread Christoph Hormann

I concur with a lot of your observations and like you i had essentially 
given up on the idea of the coastline representing meaningful 
information in the long term.  But considering this is a very sad 
conclusion which essentially means OpenStreetMap failing in its primary 
goal in the single most fundamental mapping task of the planet, namely 
the distinction between ocean and land, i am trying my best here to 
work towards a consensus - no matter how slim the chances are from my 
perspective.

> 1) We should establish an agreed "OSM Coastline position", which I
> suggest would approximate to the position of the coastline on 1
> January 2020.
>
> 2) Any edit which moved the position of the coastline by more than
> 20Km from the established position should be classed as vandalism,
> unless such movement had previously been agreed by the community.

That is a practically feasible approach but it would form a major 
beachhead in abolishing the principle of verifiablility in 
OpenStreetMap in favor of adopting the major consensus narrative of the 
OSM community as the reality to map rather than the intersubjectively 
verifiable reality.

To put it bluntly:  In your scenario if the OSM community agreed on 
ignoring the physical reality mapping of the coastline could depart 
arbitrarily far from said physical reality.

We de facto already have the situation that if edits are contested the 
status quo is the fallback.  And more strongly formalizing that in case 
of the coastline could be a good idea.  But to forgo having a 
verifiable definition of the coastline tag supported by consensus is 
not a good idea IMO.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Rio de la Plata edit war

2020-08-06 Thread Christoph Hormann

Muralito,

it would be very useful if you could address the request i have made 
several times now.  I will not engage in a discussion on the other 
lines you mean to open here because it is non-productive from my 
perspective.  It could take us hours to determine the smallest common 
denominator on cultural and cartographic subjects and it would still be 
highly doubtful if a discussion on that fields would lead to any 
productive outcome.  So if you are interested in establishing a 
consensus on this matter please try to follow my request.

If there is anyone else from the local community who would be willing to 
formulate a generic set of rules based on physical geography criteria 
about the natural=coastline placement that reflects your local view as 
i have explained please do so - even if you do so in Spanish that would 
be very helpful.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Rio de la Plata edit war

2020-08-04 Thread Christoph Hormann
On Tuesday 04 August 2020, Kevin Kenny wrote:
>
> The Hudson definitely reverses flow. One of its names among the First
> Peoples translates to 'the river flows both ways.'  The division in
> the flow lies less in the fraction of the tidal cycle than the speed
> of the current. It flows 'upstream' for half the time, 'downstream'
> for half, but the downstream current is considerably swifter.

Note the proposal is a draft and does not necessarily represent the 
ultimate wisdom on everything written there.  I am not an expert on 
tidal dynamics of rivers so it is well possible that some adjustments 
in the details are advisable.  Defining the lower limit in the tidal 
case through water flow volume rather than duration seems prudent (and 
also better matching the logic for the non-tidal case) - i chose 
duration mostly because it is practically easier for the mapper to 
observe.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Rio de la Plata edit war

2020-08-04 Thread Christoph Hormann
On Tuesday 04 August 2020, Kevin Kenny wrote:
>
> A water polygon remains a water polygon whether its boundary is
> `natural=coastilne`, `waterway=river`, `natural=water` or whatever.
> Nobody is arguing over the physical extent of surface water coverage.

I am sorry that i cannot make you see my point.  That however does not 
affect its validity.  Just for clarity i will repeat the core argument:

Basic conceptual separation between different fields of mapping is 
absolutely essential for OpenStreetMap to function.  We therefore 
cannot seriously consider mixing the mapping of physical extent of 
surface water cover on this planet (predominantly done with ways tagged 
natural=coastline) with culturally defined elements of the geography 
(that is using the same tag on ways to represent something not defined 
by physical geography criteria).

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Rio de la Plata edit war

2020-08-04 Thread Christoph Hormann
On Tuesday 04 August 2020, Kevin Kenny wrote:
>
> Moreover, I'm somewhat puzzled at Christoph's insistence that
> 'natural=coastline' have a strict physical definition, and dismiss
> local understanding as merely political and cultural. In almost all
> other aspects of OSM, the understanding of the locals is what
> governs. That understanding is, ipso facto, cultural - but we dismiss
> it at our peril. Ignoring local understanding is a path to
> irrelevance.

I am not saying that OSM should only record physical geography.  I am 
saying that natural=coastline is a physical geography tag and should be 
defined based on physical geography criteria.  If there is no consensus 
about this we can end the discussion because if we cannot even agree on 
basic conceptual separation on that level (i.e. that we separate the 
mapping of the physical extent of surface water cover on this planet 
from culturally defined elements of the geography) we can close up shop 
right away.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Rio de la Plata edit war

2020-08-04 Thread Christoph Hormann
On Tuesday 04 August 2020, mural...@montevideo.com.uy wrote:
>
> It's all about semantics.

No, physical geography is not.

> How could I answer your question if you are not able to define what
> you mean by natural=coastline?

I am able to explain how i would define natural=coastline and i have 
already done so.  What i am interested in is how you define 
natural=coastline based on verifiable physical geography criteria.

> We must first agree on what features 
> we call it coastline, and then I can explain where I think it should
> be drawn.

But you already explained where you think the coastline should be 
drawn - what i would like to understand is why, in generic terms and 
based on verifiable physical geography criteria.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Rio de la Plata edit war

2020-08-04 Thread Christoph Hormann
On Tuesday 04 August 2020, Adam Franco wrote:
> It seems to me that the main underlying conflict is that (at least in
> the default Carto rendering on openstreetmap.org a few years ago) the
> Rio Plata was getting rendered as land at low-zooms and South America
> simply looks wrong when such a large water area is rendered as land.
>
> https://github.com/gravitystorm/openstreetmap-carto/issues/1604 is a
> very long issue thread [...]

That is old history.

OSM-Carto does not distinguish between rendering of riverbank polygons 
and rendering of the water polygons created from the coastline data.  
The only difference at the moment is that a (cartographically 
counterproductive) way_area filtering is applied to the riverbank and 
natural=water polygons.  That has been reduced significantly earlier 
this year in

https://github.com/gravitystorm/openstreetmap-carto/pull/4060

but still distorts rendering to some extent.  It however is not relevant 
for large riverbank polygons like we discuss here.

As i have said earlier in this discussion it would be highly desirable 
for consistent mapping if we would actually distinguish different 
waterbody classes in rendering.  A change for that has been suggested 
last October:

https://github.com/gravitystorm/openstreetmap-carto/pull/3930

was already merged but then reverted due to opposition from one of the 
maintainers.  There is a new suggestion to implement this:

https://github.com/gravitystorm/openstreetmap-carto/pull/4128

but it seems still contested.  Getting this change merged and released 
would go a long way towards mappers developing consensus on coastline 
placement since it would provide feedback on the coastline position 
without favoring a particular placement.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Rio de la Plata edit war

2020-08-04 Thread Christoph Hormann
On Tuesday 04 August 2020, mural...@montevideo.com.uy wrote:
>
> I linked several scientific studies that clearly shows and are
> verifiable geographic evidence that this is not an oceanic coast, its
> a riverbank [...]

I am not going to start a discussion here on the semantics of terms 
like 'ocean', 'riverbank', 'coast' or similar which are inherently 
culture specific and political.

So i repeat my request:

could you formulate a generic rule for coastline placement similar to 
what i formulated in

https://wiki.openstreetmap.org/wiki/Proposed_Features/Coastline-River_transit_placement

that 

(a) allows for the coastline placement you favor in case of the Rio de 
la Plata
(b) is based on verifiable physical geography criteria that can 
practically be checked by mappers and
(c) that is compatible to most of the current coastline placements at 
river mouths around the world?

If you can do that we can try to have a productive discussion without 
delving into the swamp of politics and cultural differences and maybe 
can find a consensus position that everyone can be satisfied with.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Rio de la Plata edit war

2020-08-04 Thread Christoph Hormann
On Tuesday 04 August 2020, Martin Koppenhoefer wrote:
>
> Christoph, I guess it could be seen from looking at the email headers
> or when reading in a threaded view, but for the convenience of
> everybody I’d ask you to add a bit of context to your contributions
> here (in particular to whom you reply)

Sorry - i sometimes forget that there are people who seriously read 
mailing lists in a non-threaded view.

That mail was in reply to muralito's detailed comments in reply to 
Frederik:

> As with any terms in OSM context, we should'nt literaly translate the
> terms betwen languages because we can incurr in errors. Sometimes
> also between dialects of the same language the same word have
> different meanings. In this case, "coastline" should'nt be translated
> to spanish as "costa". Acording to RAE.es (official institution for
> the spanish language), it defines "costa" as "Orilla del mar, de un
> río, de un lago, etc., y tierra que está cerca de ella". Translated,
> in spanish "costa" does not mean only seashore ("Orilla de mar"), it
> could be a river bank ("Orilla de río"), lake shore ("Orilla de
> lago". So that any city or comunity defines itself as "costa" or
> "costera", or "SHORE" or any other term, is not related to the OSM
> coastline definition. It is also different from the definition of
> "coast" from Oxford Dictionary (6th edition that i have in hand),
> which refers to the land besides the ocean or the sea.
>
> In some cases, like this, the wikipedia article lacks the accuracy to
> define river. The river starts in Paralelo Hito Punta Gorda and ends
> in the line between Punta del Este and Punta Rasa.
>
> Here in Uruguay we have two "coast", the oceanic coast
> (natural=coastline) which begins in Punta del Este and goes to the
> border with Brazil. The other "coast" is the river, which is why
> Montevideo, Buenos Aires, etc, are known as "ciudad ribereña"
> (riverside city). The oceanic coast in the Argentina side, also
> starts in Punta Rasa. Those two different coast are very different
> All this facts are clearly visible and verifiable being here. Just
> like other thing they are not visible in aerial imagery [3].
>
> The motivation to not map as coastline are not political, but
> technical. The political issues were solved at least 60 years ago,
> with scientific consensus. [1][2] There is no other place where the
> coastline could be placed. There has been, and there is wide
> consensus in both local communities (i cannot say absolute consensus
> without checking). The limit of Rio de la Plata is historically
> recognized by politics and scientists. The legal, or official
> definition is settled at least 60 years ago, by political means
> (binational protocols, UN international treaty, IHO definitions), y
> scientific studies. Also newer/modern scientific studies and papers,
> based on salinity, batimetry, water flows, sediments, mathematical
> models, etc. confirms what the old scientific studies and political
> have agreed that the limit of the ocean is between Punta del Este and
> Punta Rasa, so there should be no discussion here. Besides this, in
> 2016 the UN extended the sovereignty rights of Uruguay in the
> continental platform for 350 nautical miles [11], but this is another
> issue and is not mapped yet. And speaking about politics, both navies
> pursues industrial fishing pirates, mostly from Asia.
>
> This is just a very width river, with a basin size like India, or 10
> times Germany, it obviously brings a very large amount o fresh water,
> which influences the salinity of the ocean waters several tenths of
> km inner into the ocean from Punta Rasa or Punta del Este.
>
> According to some people, mapping the coastline where I think where
> it should be, and where it was since the river was mapped at least 6
> years ago, that kind of mapping, maybe some renders create artifacts
> because they consider this as inner water and not ocean. I see no
> problem in that, because in the aerial photo [3] the colour of the
> river is like any other river, and not like an ocean. For example, i
> linked two videos showing the clearly the difference between Rio de
> la Plata and Atlantic Ocean [9][10]
>
> If you choose to map this riverbank as coastline, is just mapping for
> convenience (for convenience of the renderer), to see the world map
> as you prefer to see it, but it is not modelling the world as it is.
>
> By the way, the problem in january 2020 with the rendering toolchain
> fails were not caused for moving the coastline to the ocean/river
> limit, as it was there for several years, but were caused by a
> changeset which changed the tagging of the riverbank as coastline.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Rio de la Plata edit war

2020-08-04 Thread Christoph Hormann

Almost all of the arguments you bring up here are cultural or political 
in nature.  Discussing those will lead us nowhere.  Hence my suggestion 
to you in the other mail to consider this exclusively from the physical 
geographic perspective.

The only point i could identify in your writing that is not 
cultural/political in nature is the claim that the Rio de la Plata was 
first mapped 6 years ago when the riverbank polygon was created.  That 
is not true.  The Rio de la Plata was mapped long before - first 
significant parts started in 2011 already, by end 2012 the mapping was 
complete:

https://overpass-turbo.eu/s/WK9

and it stayed tagged as natural=coastline until you changed that in:

https://www.openstreetmap.org/changeset/20290034

After that there were countless attempts to move up the coastline 
closure again - all of which however were soon reverted.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Rio de la Plata edit war

2020-08-04 Thread Christoph Hormann
On Monday 03 August 2020, mural...@montevideo.com.uy wrote:
>
> i will try.
>
>
> in my last mail i'm questioning the coastline placement in several
> rivers. so,
> -what are we mapping the coastline for?
> -what we want from the "coastline"?
> -what questions are we going to answer, or could we answer, with that
> modeling of the coastline/world? (or we just draw it for the
> renderer)

In general in OSM

* we are not mapping for a specific purpose, we are documenting local 
knowledge about the verifiable geography of the world.
* what individual tags mean and how they are to be used is decided by 
the mappers using them - but not individually on a case-by-case basis 
but collectively by all the mappers of OSM together.

The problem we have here is that there seems to be a fairly massive 
discrepancy between what some local mappers in the region seem to view 
natural=coastline to mean and what mappers in other parts of the world 
have in mind there.  My request for you to formulate a universal rule 
is meant to gauge that difference and evaluate options for a consensus.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Have our tagging voting rules changed recently?

2020-08-04 Thread Christoph Hormann
On Tuesday 04 August 2020, Frederik Ramm wrote:
> Hi,
>
> looking at the "bare_soil" proposal I was surprised to read:
>
> "Any opposition vote without reason or suggestion will not be counted
> in the voting process."
>
> Is that something that we have added by consensus?

I don't think so - but i also think the question is a bit besides the 
point here.

The thing is the whole idea of proposal voting was originally meant as a 
standardized way to gauge if consensus has been achieved on a tagging 
question. Consensus does not require unanimity but it requires 
dissenting voices not being ignored and being integrated into to 
consensus position, to find the position that enjoys broadest possible 
support.  For that it is of course needed that dissenting voices do not 
just express their dislike per se but explain why they oppose the idea.

Unfortunately the proposal process is often used these days as a mere 
supermajority vote where the majority can push their uncompromising 
position against critique - no matter how well founded and well argued 
that critique might be.

That is one of the main reasons why i typically do not vote in tagging 
proposals.  If i criticize a tagging idea i usually have well founded 
reasons for that.  I require these to be either addressed or being 
convinced with arguments to change my opinion.  If that does not happen 
and a supermajority of voters can decide to ignore objections without 
engaging in a discussion on the merits and convincing me and other 
critical voices i am not going to legitimize the process with my 
participation.

It might actually be better to introduce the opposite rule - that 
yes-votes need to explain why they are willing to dismiss sustained 
critical voices in the discussion.  That would at least avoid people 
voting yes out of group-think, political allegiance or as a personal 
favor without having contemplated the merit of the proposal and of 
voices opposing it.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Rio de la Plata edit war

2020-08-03 Thread Christoph Hormann
On Monday 03 August 2020, mural...@montevideo.com.uy wrote:
>
> The scientific view, and what can be experienced or observed here is
> that the coastline ends in Punta del Este. And the line to Punta Rasa
> is a good average of the limit. Where should be put the coasline if
> not here?

Hello muralito,

could you formulate a generic rule for coastline placement similar to 
what i formulated in

https://wiki.openstreetmap.org/wiki/Proposed_Features/Coastline-River_transit_placement

that 

(a) allows for the coastline placement you favor in case of the Rio de 
la Plata
(b) is based on verifiable physical geography criteria that can 
practically be checked by mappers and
(c) that is compatible to most of the current coastline placements at 
river mouths around the world?

If you can more easily and more precisely formulate such rule in Spanish 
that would be fine - i am sure we could manage to translate.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Rio de la Plata edit war

2020-08-02 Thread Christoph Hormann
On Sunday 02 August 2020, Martin Koppenhoefer wrote:
> >
> > If you consider that incorrect you also have to ask yourself if you
> > draw the same conclusion for natural=bay and natural=strait
> > polygons:
>
> didn’t you argue some time ago that natural=bay should only be placed
> as nodes because polygons were generally unverifiable? Maybe I’m
> remembering wrong...

That is a different matter - i don't think Paul based his objection on 
verifiability concerns.

As i demonstrated with my examples people map the tidal section of 
rivers outside the coastline both as riverbank polygons and bays.  
Discouraging the former would likely lead to people moving to the 
latter.

Also keep in mind that the non-timely coastline updates have also lead 
people to start mapping more with water polygons and less with 
coastline - because the coastline changes failed to show up in the map. 
See for example:

https://www.openstreetmap.org/relation/2805665

Hence the Rio de la Plata matter turned into kind of a self aggravating 
problem.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Rio de la Plata edit war

2020-08-02 Thread Christoph Hormann
On Sunday 02 August 2020, Paul Norman via Tagging wrote:
>
> I would consider an area mapped as water both with natural=coastline
> and waterway=riverbank or natural=water in error. I haven't seen any
> cases where this is done.

It is long term established practice at the Elbe and Weser in Germany:

https://www.openstreetmap.org/way/57390762
https://www.openstreetmap.org/way/250290462

https://www.openstreetmap.org/relation/3352832
https://www.openstreetmap.org/way/28115705

If you consider that incorrect you also have to ask yourself if you draw 
the same conclusion for natural=bay and natural=strait polygons:

https://www.openstreetmap.org/relation/1675626
https://www.openstreetmap.org/relation/9072799

Even though the overall range of positions is not that large the 
specific placement of the coastline closure is often not done with a 
lot of consideration.  That would certainly very much improve if we had 
visual feedback on the water differentiation in OSM-Carto:

https://github.com/gravitystorm/openstreetmap-carto/pull/4128

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Rio de la Plata edit war

2020-08-01 Thread Christoph Hormann
On Friday 31 July 2020, Andy Townsend wrote:
>
> For what it's worth, neither extreme position looks the best answer
> to me - looking at the salinity change between river to ocean at
> https://www.sciencedirect.com/science/article/pii/S0307904X07000716
> (see
> https://www.sciencedirect.com/science/article/pii/S0307904X07000716
> for the key picture) and looking at
> https://de.wikipedia.org/wiki/Datei:Rio_de_la_Plata_BA_2.JPG suggests
> a location some way between the two.  Despite the NASA photo it looks
> like there isn't a "step change" in salinity - and of course values
> will fluctuate based on winds and tides etc.

Surface salinity is not a good universal measure for the transit between 
the riverine and the maritime domain because

a) depending on the threshold you would exclude large maritime areas 
like the Baltic Sea, Hudson Bay or the Sea of Azov.
b) at the mouth of a river salinity often varies significantly between 
the surface layer and deeper water because saltwater is heavier.

Suspended particles are also often not a good measure because we are 
usually talking about very fine particles that stay suspended for a 
long time and in shallow water currents can re-suspend silt from the 
bottom as well.  The presence of suspended particles is therefore an 
indication of a lack of large volume dilution of the water in the area, 
not of the dominance of river water over sea water in general.  See for 
example

http://maps.imagico.de/#map=7/32.361/122.212=en=sat=10

where strongly visible turbidity reaches up to more than 50km from the 
shore into the open sea.

As i wrote in my old proposal on the transit placement looking at the 
cross section of the river and the resulting average water flow 
velocity due to discharge gives you a relatively good idea about the 
situation.  In case of the Rio de la Plata you have an average 
discharge of 22000m^3/s.  At the claimed baseline you have an average 
water depth of about 20m and a width of more than 200km that is an 
average waterflow velocity of 6mm/s.  At Montevideo with a width of 
about 100km and a depth of about 8m you get an average velocity of 
3cm/s.  That is still smaller than typical coastal currents induced by 
tides and wind (which the paper you cited confirms).  But you are not 
that far off any more and around where the average water depth is about 
5m you will have reached the lower limit my proposal suggests.

I still think the people best qualified to make the assessment where 
exactly the transit is best placed are those with local knowledge, who 
have first hand knowledge of the effects of waves, tides and currents 
on the shore over the course of the year as long as their perspective 
is not dominated by political considerations (i.e. they are able to 
look at this purely from a physical geography perspective).

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] How to map "piers" on land?

2020-07-28 Thread Christoph Hormann
On Tuesday 28 July 2020, Matthew Woehlke wrote:
> Please see https://www.openstreetmap.org/way/651244930. This is a
> pier with a platform on land that extends into the water. Carto cuts
> off the part that is on land.
>
> Is this a carto bug or should the part that is on land be tagged
> differently? (I wonder about the current behavior, because pier
> structures almost never end exactly at the waterline...)

OSM-Carto renders piers before landuse=military.  That is why you don't 
see it in this case.  That is intentional.

There has been discussion to re-design the rendering of piers to be more 
distinct, possibly more like a footway bridge:

https://github.com/gravitystorm/openstreetmap-carto/issues/2652
https://github.com/gravitystorm/openstreetmap-carto/issues/3459

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Feature Proposal - Voting - (Ground: natural=bare_soil)

2020-07-24 Thread Christoph Hormann
On Friday 24 July 2020, Paul Allen wrote:
>
> I take it that means you're not in favour of my idea of rendering all
> parts of the world not covered by a tagged area with the label "Here
> there be dragons."  I think that would be cool, especially if
> somebody comes up with a good dragon icon.

You can pick one of the following two answers:

1) We already render them in a distinct color:

https://github.com/gravitystorm/openstreetmap-carto/blob/master/style/style.mss

Rendering features with a distinct symbol or pattern in addition if that 
symbol does not transport any additional information is something we 
typically try to avoid.

2) There are no parts of the Earth that are not covered by a mapped area 
since the global coastline divides the Earth surface into land (on the 
left of the coastline) and ocean (on the right of the coastline).

;-)

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Feature Proposal - Voting - (Ground: natural=bare_soil)

2020-07-24 Thread Christoph Hormann
On Friday 24 July 2020, Michael Montani wrote:
>
> The voting for natural=bare_soil has begun and can be found
> here<https://wiki.openstreetmap.org/wiki/Proposed_features/Ground#Vot
>ing>. It will temptatively close August 7th, given enough support.

It is unfortunate that the suggestion to not aim for introducing an 
umbrella tag was not taken into account.

The proposal as is lacks clarity of what it actually suggests and how 
this new tag delienates against existing tags.  It also lacks 
comprehensive practical guidance for the mapper how to identify and 
delineate features with this tag based on real world on-the-ground 
examples.

What you essentially attempt to introduce here is a *residual* tag to 
turn the open OSM tagging system consisting of tags that positively 
identify specific real world features into a closed land cover 
classification system modeled after countless such systems (some of 
which you cited).  

In OSM we generally think that using an open tagging system where the 
tags are narrowly defined in what the positively mean in a locally 
verifiable fashion is better for representing the global geography in 
all its diversity and to document local knowledge of people than a 
closed classification system that assigns the class with the lowest 
mismatch in a classification developed from a specific culturally 
narrow perspective to every point of the earth surface.

Side note:  Measuring percentage of ground cover in an arid/semiarid 
context is usually not practically verifiable on the ground, in 
particular in areas with strong seasonality.  Examples:

https://commons.wikimedia.org/wiki/File:Somewhere_in_Kazakhstan_(20160402_072251_1PS)_(28754128301).jpg
https://commons.wikimedia.org/wiki/File:Lake_turkana.jpg
https://commons.wikimedia.org/wiki/File:Landschaft_AnysbergPICT1454.JPG

We definitely do not want such areas to be engrossed in some 
generic 'unvegetated or sparsely vegetated area' classification.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Riverbanks

2020-07-21 Thread Christoph Hormann


> Tomas Straupis  hat am 21. Juli 2020 um 15:21 
> geschrieben:
> 
>   IT considers wider/higher-level things like stability, quality of
> the final product, documentation, usability etc. etc. IT expertise is
> gained by years of doing work on IT (coding is NOT IT expertise).
> 
>   Only coders/nerds are interested in things like "making sql slightly
> easier to write in some cases". 

Err, no.

I think you are quite on point that preferences for changing established 
tagging here exist due to misguided motivation but that is not due to some 
programmer nerd vs IT expert perspective but due to some programmers, mappers 
and IT experts likewise only looking at OSM through the narrow view of their 
short term use case and that use case for many not including any need for 
differentiating waterbodies.  In that mindset the idea of simplifying life *for 
everyone* by tagging every waterbody natural=water and degrading additional 
differentiation to a supplemental tag makes sense and the traditional 
differentiation in primary tagging we have is of no value and no benefit for 
anyone.

The way to address this problem is to explain why the traditional tagging is 
beneficial.  It is because it requires the mapper to always differentiate 
between standing water (natural=water) and flowing water (waterway=riverbank) - 
a distinction that is rarely a problem for a mapper with local knowledge.  That 
we have traditionally made this distinction in the primary tag could give OSM a 
huge advantage over other data sources which don't make such a distinction.  
There are quite a lot of use cases (both cartographic and analytic) where this 
distinction when made consistently is of high value.

-- 
Christoph Hormann 
http://www.imagico.de/

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


Re: [Tagging] Feature Proposal - RFC - (Ground)

2020-07-14 Thread Christoph Hormann


> Joseph Eisenberg  hat am 13. Juli 2020 um 22:34 
> geschrieben:
> 
> https://www.flickr.com/photos/chrishunkeler/32097822997
> 

I think this is a great example why more specific tags are advisable to use in 
OSM than a generic bare ground tag.

What this picture shows is commonly known as desert pavement:

https://en.wikipedia.org/wiki/Desert_pavement

Apart from varying in size distribution and density as well as material of the 
stones these form a fairly characteristic surface that can and should be mapped 
distinctly.  As size of the larger stones strongly affects navigability, 
specifying that would be a valuable supplemental tag.

-- 
Christoph Hormann 
http://www.imagico.de/

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


Re: [Tagging] Feature Proposal - RFC - (Ground)

2020-07-10 Thread Christoph Hormann

Independent of what i already said in

https://lists.openstreetmap.org/pipermail/tagging/2020-July/053795.html

i am always wary of tags lacking any examples for on-the-ground mapping or a 
practically locally verifiable definition.  And defining a tag negatively 
trough the lack of something (vegetation) rather than positively through 
something that can be positively observed is problematic.  We have had this 
problem with natural=desert already (which some had defined equally though the 
absence of vegetation).

Overall as it stands this does not seem likely to become a successful and 
meaningful tag.  Maybe you can show some on-the-ground examples of areas you 
think this tag is suitable and needed for and get input from the wider 
community how they would suggest to characterize and tag such areas.

-- 
Christoph Hormann 
http://www.imagico.de/

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


Re: [Tagging] Are we mapping ground on OSM?

2020-07-05 Thread Christoph Hormann

Generally speaking you touch a field where established tagging in OSM has gaps. 
 A few notes on that:

We have established and usually quite consistently used tags for a number of 
fairly specific natural or semi-natural non-vegetated surfaces - 
natural=bare_rock, natural=scree, natural=shingle, natural=sand and natural=mud 
and more specifically in coastal environments natural=beach, natural=shoal, 
natural=reef and natural=wetland + wetland=tidalflat.  It would therefore be 
rather counterproductive to introduce a new umbrella tag engrossing those like 
natural=bare_ground.

We have missing tags for bare ground of fine or undifferentiated material.  
natural=till has occasionally been suggested for undifferentiated glacial 
debris.  For any new tag a verifiable definition would be the main problem.

Dry lakebeds are unfortunately tagged quite inconsistently in OSM.  The 
following variants are the most common in my experience:

* natural=wetland - this is almost universally wrong since most dry or 
intermittent lakes only feature a water saturated but not water covered ground 
for a very short time of the year and are otherwise water covered 
(natural=water) or dry.  That disqualifies them as wetlands.
* natural=mud - usually wrong for the same reasons.
* natural=wetland + water=lake + intermittent=yes (and possibly salt=yes) - 
this is usually right in case there is regular or at least frequent verifiable 
water cover.

We lack a suitable tag for dry lakes with no verifiable presence of water 
(where there is either no present day water cover or so sporadic or incomplete 
that it is not practically verifiable).  There are a lot of options for tags 
for these but most of them have their quirks.

Generally mapping bare ground beyond the specific established tags mentioned 
earlier is often hard without local knowledge.  Imagery taken during dry season 
will often read like bare ground while there is often fairly extensive plant 
growth (like natural=grassland) that dries up and looks indistinguishable from 
bare ground even on high resolution imagery.

-- 
Christoph Hormann 
http://www.imagico.de/

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


Re: [Tagging] "Feature Proposal - RFC - Qanat"

2020-06-20 Thread Christoph Hormann


> Paul Allen  hat am 20. Juni 2020 um 15:46 geschrieben:
> Erm, nope, I didn't say that.  I said that if British English has a name
> for something
> then we should use it.  I didn't say that we should force square pegs into
> round holes.  To me it isn't whether it's called a qanat or an
> Undergroundwatertransfersystemfedfromawellandwithverticalmaintenanceshafts
> (as it might be named in some languages) but what it actually is.

Then we are in agreement i think.

-- 
Christoph Hormann 
http://www.imagico.de/

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


Re: [Tagging] "Feature Proposal - RFC - Qanat"

2020-06-20 Thread Christoph Hormann
> loan words.  Qanat IS a word that appears in English dictionaries and it IS
> the British English name for such structures.

That might be the case here - but only because English speakers have started 
communicating about this kind of thing using that term quite a long time ago.  
This is not the case for elements of the geography outside of English speaking 
countries that English speakers have no broad awareness of (of which there are 
plenty).

> We should definitely map things that do not physically occur in
> English-speaking parts of the world.  But we should use the British English
> name (which may or may not have been derived from the local name) to tag
> them.

That would mean giving up on the goal of creating the best map of the world 
through collection of local knowledge of the geography and replacing it with 
the goal of creating a map of the world as it is perceived my English speakers.

-- 
Christoph Hormann
Imagico.de Geovisualisierungen
http://services.imagico.de

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


Re: [Tagging] "Feature Proposal - RFC - Qanat"

2020-06-20 Thread Christoph Hormann

I think this is a good idea.  Both in the sense of establishing a distinct 
tagging for it that does not engross qanats with other types of underground 
waterways and in the sense of using a non-English and non-European term where 
the most descriptive and clear term comes from a non-European language.  We 
have other cases of such tags in OSM but still in a proposal process which is 
dominantly discussed in English this is rare and kind of a litmus test for how 
culturally diverse tagging in OSM can be and if the cultural geography of 
non-European regions can be mapped in the classifications used locally just as 
we are used to doing it in Europe and North America.

Most existing uses of man_made=qanat by the way are in combination with 
waterway=canal.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] leisure=common

2020-05-04 Thread Christoph Hormann
On Monday 04 May 2020, severin.menard via Tagging wrote:
>
> With this approach we would need to create a lot of new tags, eg for
> highways. Primary, secondary and tertiary are hierarchy based and
> does not mean the same reality everywhere, This is why
> https://wiki.openstreetmap.org/wiki/Highway_Tag_Africa has been
> created. When you travel, roads, hospitals, schools, bakeries do not
> look the same but broadly intend to provide similar services.
> "publicly-accessible land worldwide" is the definition in the wiki
> for leisure=common and IMO it fits well for defining those kinds of
> pieces of lands you cannot miss on imagery and whose status/functions
> are not as precise as for parks, recreation grounds, etc.

Note there are real world features which are semantically very similar 
despite looking very different - imagine a soccer field in central 
Europe with green grass, one in subtropical Africa with bare ground, 
one in Greenland with artificial turf and one on a glacier in the 
Antarctic with compacted snow, all tagged leisure=pitch.  But there are 
also features which at a quick look have semantic similarities (public 
spaces in this case) but where this smallest common denominator is too 
broad for it to have much practical meaning and there are tons of 
features all over the world that fit that definition but for which 
there are many different existing and more precise tags.

We from our European/North American often without thinking try to apply 
our cultural perspective and classification to environments physically 
and culturally very different from our own.  We currently have almost 
zero tags with somewhat broader use in the OSM database that were 
invented outside of Europe and North America (counting Russia as Europe 
here - the Russian community is relatively active in establishing new 
tags).  That is not normal and indicates a serious inbalance.

I think - like often in tagging discussion - that too much focus is put 
on what tag to use and too little focus on what you actually want to 
map.  And i don't mean what object physically to map on the ground but 
what semantic aspect of it you want to map.  The problem here - and 
that already became clear with the initial post by Jean-Marc - is that 
there are a multitude of aspects that define these locations.  It would 
be appropriate to tag these aspects as such and not try to identify a 
specific combination of characteristics from a type locality and then 
try to apply this to other locations.  That is not very useful, in 
particular for cultural geography features - no matter if it is a new 
tag or it it locally re-purposes an existing tag.

So my suggestion how to proceed here:

* take a good look at the area you want to map things in.
* identify what specifically you want to map.
* formulate in an abstract form (i.e. not definition via examples) and 
avoiding weasel words like 'generally' 'typically' or 'usually' the 
common and verifiable aspects of what you want to map.  Such aspects 
can be physical (in case of areas of land:  state of the ground, what 
kind of objects are located on it etc.) or cultural (like what function 
the feature has for the locals, how it is used by humans etc.)
* look for existing tags that already indicate things you have 
formulated.  Invent new tags when needed.  Clarify documentation of 
existing tags when needed.

The third step - formulating your classification in abstract form 
*before* you assess if existing tags are suitable - is key here.

-- 
Christoph Hormann
http://www.imagico.de/

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


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

2020-03-25 Thread Christoph Hormann
On Wednesday 25 March 2020, Jyri-Petteri Paloposki wrote:
>
> I slightly disagree with this one. IMO a name in a foreign language
> would be admissible if it is recognised by native speakers of the
> language either back home or in the local community OR if the name is
> otherwise regarded correct by mainstream media or a language
> authority.

Yes, that line of reasoning is fairly widespread among mappers - 
considering secondary sources of information as valid sources of 
information for OSM and not requiring local verifiability but settling 
for compatibility with the major consensus narrative of the mapper's 
culture.

I have written in more detail about the problems of this idea some time 
ago in

http://blog.imagico.de/verifiability-and-the-wikipediarization-of-openstreetmap/

-- 
Christoph Hormann
http://www.imagico.de/

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


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

2020-03-25 Thread Christoph Hormann
On Wednesday 25 March 2020, Frederik Ramm wrote:
>
> In my opinion, a name:xx tag should only be added if you can
> demonstrate that people natively speaking the living language xx are
> actually using this name for this entity. 

In terms of our traditional values and principles active use of the name 
is not the necessary criterion, it is verifiable local knowledge.  Like 
with any kind of names practical verification of names would be 
possible by inquiring about the name to people locally.  This 
essentially means the following practical requirements:

* there being a sufficient number of people present locally that 
speak/write the language in question.  Those don't have to be people 
living there, it can also be visitors.
* these people knowing the name in said language - being able to look it 
up on some external source does not count, that is wikipedia 
verifiability, not OSM verifiability.
* these people largely consistently agreeing on the same name.

Example:

La tour Eiffel:

https://www.openstreetmap.org/way/5013364

has a verifiable name:de, name:en, name:ru and probably quite a few 
other languages as you could go there (normally, not right now of 
course) and inquire people there about the name in those languages and 
(a) would find people who can tell it from their own knowledge and (b) 
these names largely match.

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

I don't think that is the main problem here.  There are certainly people 
whose main mapping activity is to add name translations from external 
data sources but that is not really the issue here as far as i can see.

It seems to me the problem is more that we have meanwhile a significant 
fraction of mappers who reject OSMs traditional value of local 
verifiability and map according to other principles (in particular the 
usefulness principle - that anything that is useful for certain data 
users can and should be added to the OSM database).  My estimate would 
be that this applies to at least about 25-30 percent of the active 
mappers - possibly significantly more especially if you include 
participants in organized mapping activities.

So the problem we are struggling with here is IMO not specific to name 
tagging but more about a fairly fundamental division within the OSM 
community about the basic premise of the project.  

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] URL tracking parameters

2020-02-25 Thread Christoph Hormann
On Tuesday 25 February 2020, Richard Fairhurst wrote:
>
> But more broadly, we value data for its correctness, not for its
> provenance (assuming licence-compatible). You are inventing a
> suspected rationale ("an advertising campaign") on the part of the
> contributor; judging them by your own standards which aren't the
> agreed/stated values of OSM anywhere I can see; and concluding that
> the data should be deleted. That's... a stretch?

Not necessarily.  OSM - like almost any other social cooperation on the 
internet - is strongly based on reputation of its contributors.  I 
can't check every contribution of any contributor in even a small area 
but i can look at the contributor's history of contributions and their 
background as a contributor (their reputation so to speak) to assess 
how trustworthy they are.

And yes, this is unfair in the way that i will make assumptions on a 
newcomer corporate mappers based on my (bad) experience with other 
corporate mappers from the past.  That's collatoral damage inevitable 
to maintain a functioning system of social cooperation in the presence 
of a large volume of organized activities.  You can blame it on the 
corporations/organizations that have lobbied successfully against more 
meaningful regulation of said activities.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-07 Thread Christoph Hormann
On Friday 07 February 2020, Peter Elderson wrote:
> E.g. if a solution would be to tag hedge areas as natural=hedge
> or landcover=hedge, then the change path would be for the renderer to
> temporarily render the old AND the new tagging, so mappers can edit
> the old tagging to the new tagging.

We always try to avoid that because it never works towards a more 
consistent tagging but only perpetualizes the use of both tags as 
synonyms because mappers get feedback that both tags are correct.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-07 Thread Christoph Hormann
On Friday 07 February 2020, Marc Gemis wrote:
>
> I still do not understand why area=yes is a bad tag.

I never said it was.  I said area=yes currently has one *and only one* 
meaning - to indicate a closed way is a polygon.  Since this is such a 
fundamental low level distinction in the OSM data model - comparable in 
a way to the type=* tag on relations - overloading this tag with 
additional meanings would be ill-advised and there is visibly no 
consensus among mappers for such an additional meaning.

> I have little hope that you will revert the change and take a
> different approach.

That is not up to me.  I have given my assessment to what options have a 
chance for achieving consensus among maintainers.  For a simple revert 
of PR 3844 this is unlikely.  Same for any change that interprets 
area=yes beyond the current established meaning for the fundamental 
polygon vs. line string decision for closed ways.

I currently tend towards a broader solution of dropping rendering of all 
barrier tags on polygons.  I originally was under the impression that 
use of barrier tags as a secondary tag for landuse polygons etc. was 
consensus among mappers based on the fairly large use numbers for that 
(>350k) but it quite clearly isn't.  So it would make a lot of sense 
for OSM-Carto to stop indicating this is valid tagging.  This would 
open a path for the various solutions already discussed - like 
introducing a new tagging scheme for indicating a polygon to 
be 'enclosed by a barrier' or by strictly adhering to 'one feature, one 
OSM element' without implicit tagging of barriers.  As indicated 
before - it would in principle, if any such solution finds support by 
mappers, in the long term be possible to interpret barrier tags on 
polygons as 2d barriers again but it might be a better idea - as Joseph 
indicated - to use a different tag than for linear barriers to avoid 
confusion.  Using the same tag for 1d and 2d representations always 
bears the potential for problems (like leisure=track for example).

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-06 Thread Christoph Hormann
On Thursday 06 February 2020, Marc Gemis wrote:
> > And please keep in mind that - as i mentioned - barrier=hedge is
> > not the dominant tag for mapping hedges with polygons in the first
> > place - as i have shown with various links earlier.
>
> I only clicked on a few of your examples and had to figure out which
> areas you meant. But they were outside of urban areas.

Yes, the vast majority of hedges that are currently mapped in OSM with 
polygons are in rural areas.

> As Paul Allen pointed out earlier none of your alternatives (forest,
> scrub) are a good match for those.

If you say so.  That is not a discussion i currently have an opinion on.  
Wooden plants in an urban environment for decorative purpose or as 
barriers for pedestrians come in a wide range of forms, especially if 
you consider different parts of earth in different climate zones.  I 
would not consider existing tags to be wrong for most of them but as 
already said a more specific verifiable characterization would 
certainly not hurt.

> And I want to end with a quote from {1]
>
> "My approach to this matter has been – from the beginning of my
> contributions to OSM-Carto – to regard the role and task of the
> project as mapper support without active steering."
>
> My feeling is that in this case that principle has been broken (I am
> not going to repeat the arguments given here by the others in this
> thread)

Your feeling is wrong, possibly due to you misunderstanding the concept 
of mapper support.  Mapper support does not mean doing what the loudest 
mappers want you to do.  There are tons of nonsensical or 
non-verifiable tags loudly promoted by mappers.  Rendering such in 
OSM-Carto would not be mapper support, it would be sabotage.  Mapper 
support in style design primarily means - as i like to phrase it - 
supporting mappers in consistent use of tags.

The irony here is that - as i mentioned in another mail - OSM-Carto is 
to a significant extent responsible for encouraging mappers to use this 
ambiguous tagging and we now get criticized for trying to fix this 
counterproductive incentive.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Christoph Hormann
On Wednesday 05 February 2020, Andy Townsend wrote:
>
> What would help make the data clearer (regardless of this
> discussion).  For example, https://overpass-turbo.eu/s/QqU is where
> the same object is used to represent both an amenity and a hedge in
> most of England and Wales.  There are only 12 polygons in that list -
> not beyond the bounds of manual fixing.  A similar query covering
> most of The Netherlands https://overpass-turbo.eu/s/QqV gets only 2
> polygons.  Looking for combinations of "landuse" will get more, but
> not that many more: 44 https://overpass-turbo.eu/s/QqW .

There are currently at least about 10k ways with barrier=hedge and a 
landuse=* or leisure=* tag - most of which are probably closed ways 
(though i have not checked).

And please keep in mind that - as i mentioned - barrier=hedge is not the 
dominant tag for mapping hedges with polygons in the first place - as i 
have shown with various links earlier.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Christoph Hormann
On Wednesday 05 February 2020, Paul Allen wrote:
>
> > disagreement about the meaning of certain tagging to in case of
> > doubt opt for not rendering something compared to rendering
> > something in a potentially misleading way.  That would mean
> > following Paul's
>
> Ummm, wasn't me.  I don't recall seeing another Paul post on this on
> the tagging list, but I don't always pay full attention to the
> identities of posters.

Oh, sorry - i meant Paul Norman on the OSM-Carto issue tracker.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Christoph Hormann

Not replying to anyone in particular but it seems there is a lot of 
dysfunctional communication here due to people focusing on something 
very specific without making up their mind (or at least not 
communicating their view) on the overall subject of the semantics of 
barrier mapping.

Therefore i would like to suggest everyone who presents their opinion on 
the matter here to - for clarity of everyone else - state what they 
think the semantics of barrier mapping are supposed to be.  That means 
assigning to each of the mapping scenarios in the following a meaning 
(either 'invalid', '1d barrier' or '2d barrier'):

closed way, barrier=fence
closed way, barrier=fence, area=yes
closed way, barrier=fence, leisure=playground
closed way, barrier=fence, leisure=playground, area=yes

multipolygon, barrier=fence
multipolygon, barrier=fence, area=yes
multipolygon, barrier=fence, leisure=playground
multipolygon, barrier=fence, leisure=playground, area=yes

closed way, barrier=hedge
closed way, barrier=hedge, area=yes
closed way, barrier=hedge, leisure=playground
closed way, barrier=hedge, leisure=playground, area=yes

multipolygon, barrier=hedge
multipolygon, barrier=hedge, area=yes
multipolygon, barrier=hedge, leisure=playground
multipolygon, barrier=hedge, leisure=playground, area=yes

closed way, barrier=ditch, waterway=ditch
closed way, barrier=ditch, waterway=ditch, area=yes
closed way, barrier=ditch, waterway=ditch, leisure=playground
closed way, barrier=ditch, waterway=ditch, leisure=playground, area=yes


-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Christoph Hormann
On Wednesday 05 February 2020, Jeroen Hoek wrote:
> > But that is not in any way sustainable and it would be highly
> > confusing for mappers because the conditions resulting in this
> > rendering would be unique and could not be derived from any general
> > principles.
>
> I understand the reasoning, but what mappers see now is:
> > You thought you could map hedges as areas using `area=yes`, the
> > wiki told you that, and you've seen it done like that everywhere,
> > but it was wrong, there is no way to map hedges as areas, and all
> > those hedges you and your fellow mapper mapped are now tens of
> > thousands of errors on the map.
>
> That is, to put it mildly, quite confusing, not to mention
> disheartening.

I understand and agree (not on there being no way to map hedges with 
polygons though - i have commented on that already) and although as you 
mentioned this is not fully the fault of osm-carto (you mentioned the 
wiki, editors are another culprit) osm-carto previously communicating 
to mappers this to be correct tagging has a huge part in creating this 
confusion.  But having made an error in the past does not mean we need 
to carry it indefinitely into the future.

I am generally inclined to follow the principle in case there is 
disagreement about the meaning of certain tagging to in case of doubt 
opt for not rendering something compared to rendering something in a 
potentially misleading way.  That would mean following Paul's 
suggestion here and dropping rendering of barrier=* on polygons all 
together.

Do you think this would be an improvement compared to the current 
rendering?

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Christoph Hormann
On Wednesday 05 February 2020, Andy Townsend wrote:
> [...]
>
> Basically it's saying "if something is mapped as a brewery and also
> as tourist attraction, remove the tourist attraction tags prior to
> rendering so the renderer renders it as a brewery, not a tourist
> attraction".
>
> Obviously a decision has to be made which of the two tags to render
> if either potentially could - either by layer order or by explicitly
> ensuring that one does and one doesn't, which I've done here.

But that is not the problem here - barriers are rendered after the 
landcover layer both in the past and now.

There is no technical difficulty in doing what Jeroen wants to do by 
re-adding a separate area-barriers layer with something like 

(SELECT way,
barrier
  FROM planet_osm_polygon
  WHERE (barrier IN ('hedge')
AND tags->'area' IN ('yes')
AND osm_id > 0
AND building IS NULL
) AS area_barriers

and adding a condition to the polygon subquery of the barriers layer 
along the lines of

NOT (barrier IN ('hedge')
  AND tags->'area' IN ('yes')
  AND osm_id > 0)

- in other words:  Special casing exactly the situation in question to 
be treated as an exception.  But that is not in any way sustainable and 
it would be highly confusing for mappers because the conditions 
resulting in this rendering would be unique and could not be derived 
from any general principles.  Mappers would rightfully ask:

* why does turning a closed way tagged barrier=hedge + area=yes into a 
multipolygon releation (for adding an interior ring) change rendering?
* why does removing the unnecessary area=yes from a closed way tagged 
barrier=hedge + area=yes + leisure=playground change the rendering?

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Christoph Hormann
On Wednesday 05 February 2020, Andy Townsend wrote:
> > As explained there the only feasible alternative would be to stop
> > rendering barrier tags on polygon features universally.
>
> No, it's not the only alternative - another would be "where there are
> conflicting tags, decide which one to render". 

I don't quite understand, you will have to elaborate.

> There may be good 
> reasons for not doing that, but to claim this is the "only feasible
> alternative" doesn't seem correct to me.

With "only feasible alternative" i means the only alternative that has 
even a remote chance for consensus among the maintainers.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Christoph Hormann
On Wednesday 05 February 2020, Jeroen Hoek wrote:
> > the semantic ambiguity of the > 350k cases where barrier tags are
> > currently used as a secondary tag on landuse/leisure/etc. polygons
> > to incidate the polygon is enclosed by a linear barrier.
>
> The PR specifically removes the filled rendering from `barrier=hedge`
> mapped with `area=yes` from 36665 hedges.

No, it does not, the PR removes the fill rendering of all *polygons* 
tagged barrier=hedge.  This includes closed ways with barrier=hedge and 
area=yes, closed ways with barrier=hedge and a different tag implying a 
polygon and also multipolygons.  I explained the way the renderer 
interprets the data in the PR discussion.  Understanding this and 
understanding the current meaning of the area=yes tag is *essential* 
for understanding the reasoning behind this change.

What you essentially want is for barrier=hedge on polygons to have a 
different meaning depending on the presence of area=yes.  Given the 
very specific and highly significant technical meaning of area=* 
overloading it with additional more specialized meanings w.r.t. 
specific tags seems a very bad idea to me.

> A hedge is not the same as bushes or trees.

I never claimed it to be.  What i did say is that what is mapped with 
barrier=hedge on polygons with a different meaning than 'this polygon 
is enclosed by a hedge' is elsewhere predominantly mapped with 
natural=scrub/wood or landuse=forest.  I demonstrated this with links 
to various places.

Introducing a secondary tag to natural=scrub/wood and landuse=forest 
(like barrier=yes) indicating that it is impassible without difficulty 
would be a good idea and i would support rendering such in OSM-Carto as 
a variation of the rendering we currently have for those if it is being 
used consistently by mappers.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Christoph Hormann
On Wednesday 05 February 2020, Andy Townsend wrote:
>
> It doesn't sound like a tagging issue to me; I'd suggest that the
> renderer that made this change did so in error.  Is using a different
> renderer an option until it is fixed (perhaps the Humanitarian tiles
> linked from openstreetmap.org)?

The change in rendering is intentional.  Is has been explained in:

https://github.com/gravitystorm/openstreetmap-carto/pull/3844

As explained there the only feasible alternative would be to stop 
rendering barrier tags on polygon features universally.

I know that for a mapper who has used this kind of tagging in the past 
unaware of its inherent ambiguity it seems weird that this is ambiguous 
tagging because in isolation it seems clear what it means.  But within 
the overall data model and overall consistency in tagging 
interpretation it is.

If there is a consensus in the community about it the following approach 
would in theory allow ultimately re-introducing the rendering some are 
missing now:

1) remove all rendering of barrier tags on polygons
2) mappers in a concerted effort resolving the semantic ambiguity of the 
>350k cases where barrier tags are currently used as a secondary tag on 
landuse/leisure/etc. polygons to incidate the polygon is enclosed by a 
linear barrier.
3) (re-)introducing the rendering of barrier polygons with a fill where 
this is consistently used tagging.

Note (2) would be a massive endeavour without precedent in OSM history 
and regarding (3) it should be noted that barrier=hedge is currently 
not the dominant method of mapping strips of trees or bushes with 
polygons, see for example:

https://www.openstreetmap.org/#map=15/50.4774/5.2980
https://www.openstreetmap.org/#map=15/51.5144/5.7404
https://www.openstreetmap.org/#map=15/48.8437/6.2252
https://www.openstreetmap.org/#map=14/52.8414/8.4571
https://www.openstreetmap.org/#map=15/53.9644/11.0538
https://www.openstreetmap.org/#map=14/51.9532/-0.1199
https://www.openstreetmap.org/#map=13/44.8335/40.0695

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Active volcanoes

2020-01-24 Thread Christoph Hormann
On Friday 24 January 2020, Cascafico Giovanni wrote:
> So "active" is ment in geological time... rather wide for OSM :-)

No, the tag does not have a consistent meaning, it simply means some 
mapper has at some point subjectively considered this feature to be an 
active volcano.

> How to tag its recent activity, ie for touristic purposes?

OSM in general does not map historic features or events.  You should map 
what is at present verifiable to observe.  If there are fumarolic 
activites, hot springs etc. you can map these using appropriate tags 
(geological=volcanic_fumarole, natural=hot_spring etc.).

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Active volcanoes

2020-01-24 Thread Christoph Hormann
On Friday 24 January 2020, Cascafico Giovanni wrote:
>
> Which is the criteria to tag volcanoes as volcano:status=active?

That tag is practically non-verifiable and therefore does not really 
belong in OSM.  But since everyone is free to add any tags they want in 
OSM such tags of course exist.

Reason for the lack of verifiability is that what an active volcano is 
in almost all uses of this term does not depend on the current state of 
the volcano but on its history - most commonly during the holocene (10k 
years) or during historic times.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Rio de la Plata edit war

2020-01-13 Thread Christoph Hormann
On Monday 13 January 2020, Frederik Ramm wrote:
>
> According to Wikipedia, the International Hydrographic Organization
> defines the eastern boundary of the Río de la Plata as "a line
> joining Punta del Este, Uruguay and Cabo San Antonio, Argentina",
> which is what has been the case in OSM until now:

That is a straw man argument that has been floated already at the very 
beginning when a riverbank polygon was first created for that (which 
was later than when the Río de la Plata was originally mapped by the 
way - just to clarify that).

The IHO specifies an (obviously subjective and non-verifiable) set of 
limits of *oceans and seas*.  If anyone wants to use this as an 
argument that would make the Río de la Plata a marginal sea of the 
Atlantic Ocean and therefore to be placed outside the coastline.  So 
using the IHO as a source (in lieu of the verifiable geography in a 
Wikipedia-like fashion so to speak) kind of defeats the basic argument 
for the Río de la Plata to not be a maritime waterbody.

> This current representation in OSM leads to a few strange situations
> especially in toolchains/map styles that use different colours for
> inland water and oceans, or that draw sea depths, or just highlight
> the coastline. Buenos Aires, according to OSM, is currently not a
> coastal city.

The main reason why the current mapping is vigorously maintained by some 
local mappers is political in nature.  Argentina and Uruguay want to 
claim this area as internal waters (and the administrative boundaries 
are mapped accordingly) but not every other nation accepts this claim.  
Presenting the Río de la Plata as a non-maritime waterbody in as many 
maps and data sets as possible would support such claim.

My own solution as a data user to this has been to simply maintain a 
coastline cheatfile which marks this as a special case and moves the 
Río de la Plata polygon into the ocean polygon data.  This is 
unfortunate but way simpler than trying to fight against a widespread 
politically motivated conviction.  See also:

https://wiki.openstreetmap.org/wiki/Tag:maritime=yes

> I'm not so clear about how to interpret the wiki page myself when it
> comes to river mouths. There's a clarifying proposal here
> https://wiki.openstreetmap.org/wiki/Proposed_Features/Coastline-River
>_transit_placement but this is still at the proposal stage.

The IMO logical approach to placing the closing segment of the coastline 
at a river mouth according to the spirit of the OpenStreetMap project 
is to place it where for the verifiable view of humans the maritime 
domain ends and the riverine domain starts.  This is largely an 
ecological question.  Coastline and riverbanks are physical geography 
features so their position is to be defined by physically observable 
characteristics rather than politically defined limits.  Like so often 
(for example in case of the line between scrubland and woodland) this 
is often not a clearly visible sharp line but a transit.  There are 
however clearly observable limits to the extent of this transit.  The 
proposal cited tries to specify those.

Back when i drafted the proposal there was very little interest in the 
subject except by those who were opposed to it for political reasons.  
Therefore i did not pursue it further.  But anyone is welcome to take 
it up again.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Relation for place archipelago with members place island

2019-12-14 Thread Christoph Hormann
On Saturday 14 December 2019, Warin wrote:
>
> I think this is ok. But is there a better way?
>
> The particular relation is 55737 the Schouten Islands.

You mean

https://www.openstreetmap.org/relation/557367

That looks correct, archipelagos are normal multipolygon relations.  
Building them from the same coastline ways that are used to map the 
individual islands is the established method for mapping them.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Draft proposal for Key:aerodrome

2019-09-10 Thread Christoph Hormann
On Tuesday 10 September 2019, Joseph Eisenberg wrote:
> I've started a new proposal for Key:aerodrome.
>
> See
> https://wiki.openstreetmap.org/wiki/Proposed_features/Key:aerodrome

The problem with this kind of tag is that while it can be in principle a 
verifiable tag - provided that the suggested values are clearly defined 
this way it is still an aggregate score designed for usefulness for 
certain data users rather than for good mappability.

An example:

In Germany civil airfields are classified by law 
into "Verkehrslandeplätze", "Sonderlandeplätze" 
and "Segelfluggelände".  "Verkehrslandeplätze" is pretty much the same 
as aerodrome=general_aviation - i.e. can be used by pilots without 
prior permission by the operator.  However "Sonderlandeplätze" is not 
the same as aerodrome=private - there are SLP that qualify as 
aerodrome=commercial because they have regular commercial flights.

In short:  Many of your suggested values are based on properties that 
are independent of each other.  It would be more useful for the data 
user and easier to map for the mapper to document these separately.

Specifically i see:

* presence and nature of regular passenger flight service
* openness to public from the air
* access restrictions on the ground
* presence of services for airplanes
* surface and length of the runway

And not in the proposal but a useful property:

* restrictions to certain types of planes (like non-motorized gliders)

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Populated settlement classification

2019-09-07 Thread Christoph Hormann
On Saturday 07 September 2019, Iago Casabiell wrote:
> I'm new to the mailing list, so first I'm sorry if I miss any step in
> a proposal for the wiki.
>
> I generated a proposal for the classification criteria of populated
> settlements here:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Populated_settl
>ements_classification .

Welcome to the mailing list.

The problem i see with what you are trying to do is that a proposal is 
generally about a new tagging idea or an idea to change existing 
tagging.  And it is not really a good idea to draft a tagging concept 
from the beginning to have different meanings in different parts of the 
world.  This has happened in some cases, in particular with roads 
classification 
(https://wiki.openstreetmap.org/wiki/Highway:International_equivalence) 
but it is generally best for everyone to try avoiding that and use tags 
that have a globally consistent meaning.

In other words:  If you want to document existing regional differences 
in populated place tagging that is most welcome but that does not 
require or even call for a proposal.  If you want to change populated 
place tagging to differ from country to country OTOH i would consider 
that simply a bad idea.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Feature Proposal - RFC - Dehesa

2019-08-30 Thread Christoph Hormann
On Friday 30 August 2019, Diego Cruz wrote:
>
> I have recently proposed a new tag in the Wiki, because none of the
> existing landuse tags seem to match it. A dehesa is a type of land
> that combines a forest with either fields or pasturelands (or both)
> at the same time. It is extensively used in the Iberian Peninsula,
> both in Spain and Portugal. Please see the details in my proposal
> below:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Dehesa

This is certainly a valid idea for inventing a new tag and it is good 
that you open up discussion early.  Let me take this as an example for 
two things that have in the past been decisive on the broader success 
of tags:

* local verifiability.  The primary definition of your tag is for areas 
in a certain region that are in the cultural tradition of that region 
called a certain way.  You try to list a few verifiable criteria what 
not to use the tag for - but these are one sided criteria.  Because 
natural=wood does not rule out use as pasture (and neither does 
landuse=orchard, which is also used for cork oak plantations), 
landuse=farmland does not rule out the presence of trees or the use as 
pasture and many savannas (for which we have no specific tag at the 
moment) are created by human influence.  A good tag is one where a 
local observer, even a casual one like a traveler quickly coming 
through, can without much difficulty determine locally if the tag 
applies or not.

* generic meaning.  As already mentioned you draft this as a region 
specific tag although agroforestry is a practice that exists in many 
different parts of the world in different forms.  Such tag will either 
stay a local speciality tag without much chance for being interpreted 
by global data users and possibly mirrored by other region specific 
tags with similar but slightly different meaning or it will morph into 
a broad umbrella tag - for example for any kind of 'area with trees 
that does not really qualify as wood/forest'.  Well known examples for 
such tags are natural=fell and landuse=village_green.

There are three potential tagging concepts i could imagine could be 
derived from your idea that would seem more promising in that regard:

* a tag for agroforestry landuse.  This of course would only be locally 
verifiable if there is active agricultural use.  That would only 
qualify those dehesas that are actively used for agriculture as such.  
And it would say very little about the physical appearance and 
ecological characteristics of an area.

* establishing a generic tagging concept for secondary characteristics 
of areas - like use of orchards as pasture, underbrush in a forest or 
scattered trees on a meadow.  This could be quite easily implemented 
using natural:secondary=*, landuse:secondary=* etc.  Dehesas would 
under such scheme be something like

- landuse=farmland + landuse:secondary=orchard
- landuse=meadow + landuse:secondary=orchard
- landuse=orchard + landuse:secondary=meadow

* creating one or more region specific secondary tags for exising 
primary tags like landuse=farmland or landuse=orchard for documenting 
the region specific ecological characteristics of the area.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] [OSM-talk] Document personal tags in Proposed_features/ space, User: space, or Tag:/Key: space?

2019-08-16 Thread Christoph Hormann

The problem about proposal pages is that they can be infinitely 
theoretical, non-verifiable or outright insane.  So telling a mapper 
who is thinking about inventing a new tag to search the proposals if 
there is one that already covers what they want to do is not 
practicable.  Because even if there is a proposal that deals with the 
same kind of situation the mapper is confronted with that does not mean 
the proposal contains a practicable idea of how to tag this.

The advisable approach to making tag documentation on the wiki better 
usable is IMO not to further blur the line between documentation of the 
de facto meaning of tags by humans and all the other uses of the wiki 
(like proposals, automatically assembled data etc.) but more strictly 
separating them.  If you (theoretically - it would probably be a lot of 
work to do this practically) take all tagging documentation from the 
wiki no matter where it is and remove everything that is not strictly 
documenting the de facto meaning of tags in the OSM database the result 
would be a pretty compact body of documentation.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Definition of a Beach

2019-08-15 Thread Christoph Hormann
On Thursday 15 August 2019, ael wrote:
>
> I was going to comment that a beach has to meet the water at the same
> level. That is maybe sort of implied above? As opposed to a cliff or
> even wall.

The beach being composed of loose material and being formed by water 
waves implies the beach and the water level intersect and the slope 
being limited.

> I am not sure that a beach is required to have a "significant" slope.

The slope necessarily forms if loose material is being deposited and 
shaped by waves.  As Josef said if the slope is very small the waves 
will not be the dominating force shaping the coast any more and tidal 
currents will be the force shaping the area.  How steep and how wide 
the slope is depends on the relationship of tides, waves and grain size 
of the material.

There are of course also borderline cases to and combinations with other 
coastal land forms like spits, longshore bars etc.  There might also be 
artificial beach nourishment measures that modify the profile.  So 
beaches will not necessarily have a continuous slope everywhere.  But a 
slope on which waves break and water washes up and down with each wave 
is a defining element of a beach.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] [OSM-talk] Document personal tags in Proposed_features/ space, User: space, or Tag:/Key: space?

2019-08-15 Thread Christoph Hormann
On Thursday 15 August 2019, Joseph Eisenberg wrote:
>
> In contrast, the current text of the wiki page "Any tags you like
> suggests creating a new tag for bird nests (as an example) with
> Key:endangered_nest=Siberian_flying_squirrel - besides suggesting
> using non-standard capitalization in the value, this suggests
> creating a new Key: / Tag: page directly, rather than using
> User:username/ or Proposed_features/.
>
> Is this a good idea?  Occasionally new wiki pages are created in
> these standard spaces for tags with only a few uses or no uses in the
> database.

Yes, IMO it is not only acceptable to document newly invented tags but 
also advisable to do so.  Note however inventing tags in this context 
means actively using them, not theoretical inventions along the lines 
of "I would like mappers to tag things this way therefore i document 
the tag as if it was being used".  Elaborate tagging schemes should be 
discussed before being used and not be invented ad hoc by individual 
mappers.

The reason is - as you mentioned - the "Any tags you like" principle.  
It means you can and should invent new tags for *things no tag exists 
for so far*.  To allow mappers to determine if there is already an 
existing tag for a certain type of feature tags have to be documented.  
Or looking at things the other way round:  If inventing new tags is 
encouraged but it is discouraged to document them in a way that can be 
easily found by other mappers that would massively emphasize tag 
proliferation since mappers will repeatedly invent new and different 
tags for certain things because they are unaware that another mapper 
has already invented a tag for this.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Definition of a Beach

2019-08-15 Thread Christoph Hormann
On Thursday 15 August 2019, Warin wrote:
> What is a beach?
>
> [...]

The question you actually wanted to ask i think is what does 
natural=beach mean in OSM.  This distinction between the meaning of a 
tag in OSM and the meaning of the terms used for key and value in 
English language is very important to keep in mind, in particular for 
native English speakers.

I had a thorough look at use of natural=beach in OSM back when i changed 
rendering in OSM-Carto and came to the conclusion that use of this is 
actually reasonably close to the core scientific definition of beaches, 
namely a wave formed accumulation of loose material at the shore of a 
waterbody.

See also

http://blog.imagico.de/reefs-and-beaches-in-the-openstreetmap-standard-style/

There are a number of notable exceptions from this

* natural=beach is also used for human made artificial beaches where 
sand does not occur naturally.  This is obvious since this is often 
hard to distinguish for the casual observer without in depth research.
* some use of natural=beach for rocky shores exists but it is minimal.
* sometimes use of natural=beach extents on costal dunes which are not 
water formed and therefore not part of the actual beach.
* in particular in the UK there is some atypical use of the tag - based 
on historic practice and use of OS data as a source apparently - of 
using natural=beach for what is indicated as 'Sand' in OS maps and 
wetland=tidalflat (or historically natural=mud) for what OS maps show 
as 'Mud'.  This is distinctly different from elsewhere in particular 
since it uses natural=beach for sand based tidal flats - like here

https://www.openstreetmap.org/way/67573161

How can you identify a beach on the ground:

* there are waves breaking, at least at some times, at the water line.
* ground has a significant slope so waves roll up the beach and water 
flows back in the typical fashion leaving a fairly smooth surface.
* the ground material grain size is somewhere between fine sand and 
medium sized stones - small enough to be moved by the waves when they 
are strong and large enough not to be suspended in and carried away by 
the water as the waves break.
* there are no tidal channels forming in the loose material since these 
are indicative of a tide dominated situation and not a wave dominated 
one - such cases would be suited to map with natural=wetland + 
wetland=tidalflat.

Where there is considerable variation is if and how the tidal part of a 
beach is mapped.  Mainly the following variants exist:

* mapping only the part of the beach above the high water line leading 
to a very narrow beach.
* the tidal part of the beach being mapped as or included in a tidal 
flat.
* the beach crossing the coastline and including the tidal part.
* the coastline being placed not at the high water mark but below, 
usually whereever the imagery used shows the water edge and ending the 
beach at this line.

This would be good to clear up and establish a well defined and 
intuitively usable mapping scheme.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] New page "Approval status" for "de facto", "in use", "approved" etc

2019-07-28 Thread Christoph Hormann

There are many tags with status 'de facto' indicated that do not meet at 
least some of your criteria:

landuse=meadow
landuse=forest
natural=wood
place=square
waterway=drain

and there are tags with status 'in use' indicated that at least meet 
some of the criteria:

highway=turning_circle
information=guidepost
landuse=grass
man_made=cutline
place=archipelago
water=lake
waterway=riverbank

IMO if those criteria are significant (which i don't doubt as far as 
they can be objectively determined) it is much more useful to document 
how far a tag meets these criteria individually than to determine an 
aggregate score of some sort from them and a categorization based on 
that.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] New page "Approval status" for "de facto", "in use", "approved" etc

2019-07-28 Thread Christoph Hormann
On Sunday 28 July 2019, Joseph Eisenberg wrote:
>
> Christoph, do you have any ideas about how we could be more inclusive
> and make it easier for mappers from other countries to create and
> document new tags?

I think emphasizing and reaffirming the fact that the wiki is to 
document the de facto use and meaning of tags and openly documenting 
and explaining contradictions, ambiguities and regional differences in 
tagging rather than hiding them to present a subjectively desired 
reality of tagging would be a good approach.

If the wiki documents the de facto use and meaning of tags that would 
automatically give different language versions of the documentation 
equal standing because all of them aim to document the same thing.  If 
however the wiki aims to document the supposed meaning of tags there 
will inevitably be a struggle for opinion leadership on what this 
supposed meaning is to be and this struggle will inevitably be 
dominated by the English language.

What i specifically think is not a good idea is intermixing the formal 
status of a proposal in the proposal process 
('draft', 'proposed', 'voting', 'approved' and 'rejected') with either 
objective and verifiable classifications of the actual use of tags and 
subjective recommendations if a certain tag should or should not be 
used.

> I hoped that by better defining the "de facto" status and defining a
> clear way that a tag can be promoted to this value (which currently
> is honored with a green highlighting, just like "approved"), there
> could be an objective and fair way for "in use" tags to be added to
> Map Features without going through the Proposal process.

I don't think there is a reasonable verifiable way to define a 
sub-classification among tags that are widely accepted to be used with 
a certain meaning but that have never successfully gone through a 
proposal process.  If there was a way to do this it would probably be 
possible to automatically determine this and show such status in 
taginfo (although if that involves the historic development that might 
be technically challenging).

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] New page "Approval status" for "de facto", "in use", "approved" etc

2019-07-28 Thread Christoph Hormann
On Saturday 27 July 2019, Joseph Eisenberg wrote:
> Please take a minute to review the new page
> https://wiki.openstreetmap.org/wiki/Approval_status
>
> [...]

A bit of a general remark here - the OSM wiki has for quite some time 
been torn between being an attempt to document the established mapping 
practice (i.e. what tags actually mean based on how they are used) and 
being a way to tell mappers what tags are supposed to mean in the 
opinion of those editing the wiki.

The way you present this status concept is in support of the latter - in 
particular your use of the term "recommended" on status values that do 
not represent a formal proposal status (that 
is 'draft', 'proposed', 'voting', 'approved' and 'rejected') ultimately 
means recommended by those who have dominance over editing the wiki.

You should keep in mind that this whole concept of meta-classification 
of tags into a set of classes - as attractive as it might be to allow a 
simplistic understanding of tagging in OSM and management of the 
complexity of tagging by a small group of people on the wiki - is going 
to inevitably fail because it tries to trivialize the complexity of the 
geography (which we try to document in tagging) and the social 
dimension of very different people looking at this geography from 
different sides.  The only way to properly document the status of a tag 
is IMO through a verbalized description - which is the essence of what 
tag documentation on the wiki traditionally was centered around.

Also keep in mind that most of concept this idea of tag 'status' is 
based on massively discriminating against languages other than English.  
For the proposal process this is obvious but this also applies to many 
of the other ideas of status.  In contrast to the verbalized 
documentation of tags - which can exist in any language or set of 
languages independent of each others the idea of a tag status is that 
of a single status defined by authority over the global OSM community.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] My ban by user Woodpeck = Frederik Ramm

2019-06-25 Thread Christoph Hormann
On Tuesday 25 June 2019, Ulrich Lamm wrote:
> Ten hours ago, user Woodpeck = Frederik Ramm has banned me for TEN
> YAERS! For what?
> For mapping courses of water.
> Before, he had blocked me or using database data.
> [...]

For competeness of information and for everyone to properly assess this, 
the block history of user ulamm:

https://www.openstreetmap.org/user/ulamm/blocks

And the OSMF ban policy describing the procedures regarding such 
actions:

https://wiki.osmfoundation.org/wiki/Ban_Policy

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Verifiability of geometry

2019-06-17 Thread Christoph Hormann
On Sunday 16 June 2019, Daniel Koc4� wrote:
>
> To have interpretation is not a logical error and I didn't claim
> that. But lack of objective support makes it just your opinion. It
> would be really bad if you would contradict yourself, but still it's
> just a weak point worth showing.

OpenStreetMap is fundamentally based on the existence of a single, 
verifiable reality.  The truthfulness of a statement in that reality is 
not a matter of majority opinion but a question if it can be 
demonstrated to be true or false.

> Your strait definition for example does not contain logically
> fallacy, but is just unrelated to reality, as I have shown, which is
> still OK for philosophy, but bad for mapping, which is about actually
> representing the world outside. I think this is exactly disadvantage
> for the project.

You have shown nothing w.r.t. my statement about straits with what you 
wrote.  This can be easily shown through you not being able to 
verifiably state the length of the straits i am talking about.

What is the length of the Bering Strait for example?

> I have shown you a positive proposition of proper solving the problem
> of the example object. You have not shown that is logically wrong, so
> I guess it should enough for you, if you follow your own rules of
> proving, so here you lack some consistency.
>
> But what worries me more is that you just not even commented why this
> would be a bad thing for reasons other than logic.

I am sorry but we can't really have a productive discussion here if you 
keep ignoring past discussions and their results.  The statement that i 
have not commented on why your ideas for how OSM should work are bad is 
preposterous.  Both Joseph and me have explained in detail on github 
why the status quo in rendering is a bad idea and has no long term 
future.  I have discussed the fundamental concept of verifiability at 
length on my blog:

http://blog.imagico.de/verifiability-and-the-wikipediarization-of-openstreetmap/

and in discussions on the wiki, in diary entries and on mailing lists.

> For some reason you claim that changing the type of geometry in the
> world of geometry into another type of geometry is OK. I wonder if
> you would change the name into some other name in the database?

You seem to have a fundamental misunderstanding here - with the choice 
of how something is modeled in the OSM database mappers do not make a 
statement about the geographic reality and this is therefore not 
subject to verifiability.  The geometry itself (the coordinates of the 
nodes and how they are arranged in ways and relations) however is.

And i agree with Joseph that this is not the best place for such 
discussion.  Given the abstract nature of the topic and how it concerns 
the very foundations of the project i would even say mailing lists with 
spontaneous comments and a natural tendency for tunnel vision on the 
current discussion thread are not really a good medium to handle this 
kind of topic.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Verifiability of geometry

2019-06-16 Thread Christoph Hormann
On Sunday 16 June 2019, Daniel Koc4� wrote:
>
> Christoph (imagico) has proposed there a set of example rules that he
> believes are self evident and invited to challenge them if someone
> disagrees, so here I am:

Not quite - this is just a collection of statements regarding matters 
where you claim i did not provide answers to or where you repeatedly 
bring up arguments based on assumptions that have been refuted in the 
past already (like the persistent idea that any two-dimensional entity 
should best be modeled in OSM with a polygon).  It is neither meant to 
be an exhaustive framework of principles nor are they necessarily 
useful as practical rules.

All of these are not new statements - they are not literal quotes but i 
have made them in previous discussions in similar form (here, on the 
wiki, on github or elsewhere).

You have stated disagreement with several of these statements but you 
have not challenged them in any way by pointing out a logical error or 
by arguing why the suggested approach how mappers should decide on how 
to map things is of disadvantage to them or to the project as a whole.

With challenging my statements i mean providing evidence for them to be 
false.

I would suggest to you not to concentrate on your spontaneous emotional 
reaction of dislike to views like mine that differ from your own but to 
consider what objective arguments you have that support your position 
and what long term consequences this would have.  You have made clear 
on a lot of occasions that you reject the concept of verifiability as a 
guiding principle for mapping decisions but so far the only reason for 
this you have ever given is essentially because it is inconvenient and 
it prevents the addition of data to OSM you would like to see added.  
Given that the reasons why we have and should keep the verifiability 
principle have been discussed really extensively this all seems frankly 
a bit opportunistic.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] A modest proposal to increase the usefulness of the tagging list

2019-06-02 Thread Christoph Hormann
On Sunday 02 June 2019, Simon Poole wrote:
>
> - not posting more than 30 times per month (the 30 comes from the WMF
> mailing lists, where it seems to work quite well)
>
> - not more than one proposal per person per month
>
> - not more than 4 new proposals per month in total

Note there have been in the past opinions that documenting a new tag 
without creating a proposal is not desirable (see 
the "motorcycle:scale" thread earlier this year).  If you combine that 
with the limitation of the number of proposals that can be made you 
would essentially limit our base principle of "Any tags you like".

In other words:  Any rate limitation to the proposal process would IMO 
need to go with a clear agreement that the proposal process is optional 
for creating a new tag.

In the past i usually preferred the wiki for bringing up and discussing 
questions related to specific tags especially because it allowed for 
more selective participation in discussion.  But the introduction of 
bot edits into the wiki to me largely burnt the whole thing.  A clear 
agreement that the tagging documentation part of the wiki is humans 
only without using mechanical tools would therefore also help a 
lot. ;-)

My own observation regarding the tagging list is that endless threads 
are much more annoying than the overall number of new subjects opened.  
So having as a guiding principle the rule not to post more than two or 
three replies on the same subject could be useful.  It would encourage 
everyone to contemplate their replies more thoroughly and not engage in 
back-and forth two person dialogs - for which this kind of mailing list 
with a large number of subscribers is not really the ideal place.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] In defence of OSM Carto (was: Re: Irrigation: ditches, canals and drains)

2019-05-31 Thread Christoph Hormann
On Friday 31 May 2019, Andy Townsend wrote:
>
> I suspect that the OSM Carto style would be open to pull requests
> that looked at the sub-tags of canals etc. if it could be done in a
> way that wasn't over-complicated - look at OSM Carto's handling of
> leaf type for a possible way forward.

Indeed.  There is discussion on this happening in:

https://github.com/gravitystorm/openstreetmap-carto/issues/3354

The important thing is to look at the data and to do it world wide and 
to avoid wishful thinking along the lines of "this tag looks like it 
could be useful to differentiate rendering so let's just assume is is 
actually used in the a way it would be helpful".

leaf_type is easy because it represents a simple and well defined 
biological fact.  Characterizing canals as human built structures in a 
similarly clear way is much harder.

> A bigger problem is the lack of granularity of rendering width at
> various zoom levels (see for example
> https://www.openstreetmap.org/#map=13/54.1856/-0.8334 ,
> https://www.openstreetmap.org/#map=14/54.1850/-0.8258 and compare
> with
> https://map.atownsend.org.uk/maps/map/map.html#zoom=14=54.18504
>on=-0.80956 ).

Yes.  As mentioned in 

https://github.com/gravitystorm/openstreetmap-carto/issues/3354#issuecomment-496449087

the whole waterway line with stepping across zoom levels is full of 
fairly strange historic artefacts and not really well thought through.  
Combined with removing minor waterways from z13 waterways are quite a 
mess now.

And more generally speaking creating a map style that does an equally 
decent job at representing all kinds of geographic settings around the 
world as it is the stated aim of OSM-Carto is inevitably a constant 
uphill battle because the vast majority of mappers and developers in 
OSM simply are from urban environments in Europe and North America 
which brings an inherent bias with it.  How well OSM-Carto manages to 
fulfill its function to create a map for the whole OSM community to a 
large extent depends on how well we manage to compensate for this 
inherent bias.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Difference between barrier=embankment and man_made=embankment?

2019-05-29 Thread Christoph Hormann
On Wednesday 29 May 2019, Paul Allen wrote:
>
> How the terms are used may vary from country to country.  OSM tags do
> not necessarily
> correspond closely to technical and/or common usage.  Meanings may
> differ for
> features like embankments depending upon context (railway embankment,
> fortification,
> levee, etc.).

This might not have been clear from my statement but this is not based 
on a particular local situation in Germany but comes from looking at 
data worldwide.

man_made=embankment is almost exclusively used for one-sided artificial 
slopes - prominently supported by OSM-Carto rendering it this way.

barrier=embankment is in the relatively small volume of use mostly used 
for symmetric structures with slopes on both sides.

And current tagging documentation does not provide a clear suggestion 
how to tag such - if with embankment=yes as a standalone tag or with 
man_made=embankment + embankment=both or embankment=two_sided.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] solving iD conflict

2019-05-24 Thread Christoph Hormann
On Friday 24 May 2019, Kevin Kenny wrote:
>
> Unless you intend to produce further evidence (to which I would
> listen), I consider the insinuation that the iD developers have a
> financial conflict of interest to be highly inappropriate. [...]

Please don't put words into my mouth here - i have said what i said and 
not what you have read into that.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] solving iD conflict

2019-05-24 Thread Christoph Hormann
On Friday 24 May 2019, Mateusz Konieczny wrote:
>
> Is there some editor capable of working in-browser that can be
> considered as better than iD that was refused without a good reason?
> There is Potlatch 2, but relying on Flash immediately makes it worse
> (even assuming that interface and design is better than in iD).

Note i am not talking about the editor as a software product but about 
the presets and validation rules here.  

> Or is there some explicit or implicit announcement that iD will be
> kept as default even in case of something better (like forked iD with
> some changes to presets and validation rules)?

That is obviously a hen-and-egg problem - no one will likely develop 
alternative presets for iD if it is clear that you would have to fight 
a successfull uphill battle against the full inertia of the OSMF to get 
them on the website.

It does not really matter if you consider it unfair or not (and using 
this term was therefore probably a poor choice).  It is not about what 
is fair from a moral perspective, it is about what is a responsible 
choice for ensuring a healthy competitive situation and a good variety 
of editing choices being available to mappers in the long term.  The 
OSMF would have the choice to open the competitive situation for the 
default editor and components of it like presets on osm.org even if at 
the moment there are no direct alternative ready for use.

For the map layers being offered on osm.org we already have a policy:

https://wiki.openstreetmap.org/wiki/Featured_tile_layers/Guidelines_for_new_tile_layers

It would be well possible if in analogy to that we had policies for 
editors or editor components like presets or validation rules.  Having 
a clear regulatory framework that defines what conditions you have to 
fulfill is very helpful in encouraging people taking the initiative to 
start such a project.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] solving iD conflict

2019-05-24 Thread Christoph Hormann
On Friday 24 May 2019, Kevin Kenny wrote:
> On 5/24/19 6:04 AM, Christoph Hormann wrote:
> > This is evidently something that is becoming more and more
> > important as OSM grows as a project and it becomes increasingly
> > difficult for a single person to be knowledgable about every aspect
> > of it.
>
> In the din of voices here, how does one assess who is most qualified
> to make such decisions?

Through arguments and reasoning and through critical evaluation of 
opinions and decisions.

You should not assume just because people articulate all kinds of 
strange views and opinions on these channels that are evidently flawed 
that the discourse on a whole is pointless.

If you engage in discussions in the OSM community for a longer time you 
will learn which people on what subjects tend to have views and ideas 
that in the long term hold up to critical assessment and usually turn 
out to be correct.  Likewise you also learn which people might have an 
interesting perspective on things but frequently draw the wrong 
conclusions.  This helps a lot - but is of course no replacement for 
critical evaluation of ideas on a case-by-case bases.  Everyone can 
make errors in judgement - even experts in their respective fields.

Also allowing the articulation of highly opinionated and unqualified 
ideas is a necesssity in a community that wants to be open and be able 
to develop and adjust the a changing environment.  Because many 
innnovative ideas start as something that is universally considered to 
be a bad idea (or even offensive or toxic as some like to call it).

> Beware of elevating, 'I disagree with this decision,' to, 'the people
> who made this decision were irresponsible. If they had consulted a
> competent authority, they would not have made it.' In this forum, it
> risks being interpreted as an arrogant belief that you are the only
> truly competent authority, unless you accompany it with a proposal
> for constituting a governing body.

I think you got the wrong impression here that i advocate the creation 
of formal authorities based on some codified system of qualifications.

In my opinion the only practical way to effectively select qualified 
people to making decisions is through competition - in arguments and 
reasoning in the process leading up to the decisions and between 
different decisions and those making them afterwards.  What i criticize 
in case of iD presets and validations is not primarily that iD 
developers make decisions the way they do (which i do but which i also 
consider to be their legitimate decision) but that the OSMF endorses 
this as the default way of editing OSM online via the website giving it 
an unfair advantage over any competing system of presets and 
validation.  That adds on top of the pre-existing advantage of being 
financially backed in a significant way (by paying developers) by 
multiple (and in parts still anonymous) financiers.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] solving iD conflict (was: pointlessly inflamatory title)

2019-05-24 Thread Christoph Hormann
On Friday 24 May 2019, Kevin Kenny wrote:
> > In general, our project isn't a top-down strictly managed project
> > with a controlled decision-making process. This means that many
> > things have to be discussed over and over, and the community
> > generally doesn't speak with one voice. But this also gives us some
> > resilience; there's no one "tag central command" that someone could
> > take over and dictate what we are to do.
>
> I think at the root of the complaints in this thread is the idea -
> justified or not - that the maintainers of iD are attempting to
> arrogate that role unto themselves.

Note there is not really much in terms of 'justified or not' - we have a 
clear statement here:

https://github.com/openstreetmap/iD/issues/6409#issuecomment-495231649

that without any significant amount of reading between the lines 
communicates dividing the OSM community into a relevant and irrelevant 
part by an authoritive decision that does not have to justify itself 
against anyone.

> To the extent that they are, it is probably because the discussion
> forums on tagging - at least, this list - are too cacophonous to
> inform their decisions about what tags to present in iD.  Where
> consensus fails here - as, in my experience, it almost always does
> for any question that isn't answerable by tagging that was well
> established years before I got here - the iD developers are really
> faced with the decision: implement some arbitrary choice that makes
> sense to them, or do nothing about helping iD users to map the
> feature in question.

The fact that decisions are made is not the problem here.  If you are in 
a decision making position in any kind of project within a diverse 
community like OSM you are inevitably making decisions in situations 
where there are varying opinions.  This basic fact is not what people 
have issues with in case of iD presets and validation (at least not 
more in this case than in any other).  

The problem is if as you describe it people "implement some arbitrary 
choice that makes sense to them" and this "makes sense to them" is not 
based on a qualified in depth look at the whole situation and all its 
angles but from a narrow filter bubble where indeed (as linked to 
above) things might appear clear and simple while with consideration of 
the broader reality they are not.

I have come to the conclusion that it is quite definitely not bad 
intentions that lead to this approach but simply being overwhelmed by 
the complexity of the situation.  The iD developers are foremost 
software developers.  They are certainly highly qualified in software 
development and several people here have expressed appreciation for 
their work in this field (and i agree with that).  But that does not 
provide the background and experience in OSM mapping and global 
geography to make qualified decisions on tagging questions.  Trying to 
solve this by "dumbing down" questions and ignoring perspectives on 
them you don't understand is not a solution.

One of the key qualifications for any decision making position is IMO 
the ability to recognize when you lack the background to make a 
qualified decision and the ability and willingness in those fields to 
yield decision making to others who are more qualified.

This is evidently something that is becoming more and more important as 
OSM grows as a project and it becomes increasingly difficult for a 
single person to be knowledgable about every aspect of it.


-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Maritime=yes for marine river estuaries?

2019-05-09 Thread Christoph Hormann
On Thursday 09 May 2019, Joseph Eisenberg wrote:
> I discovered that maritime=yes has been used about 100 to 150 times
> to tag areas of river estuaries that should be considered part of the
> marine environment.
>
> [...]

I introduced this tag for this purpose to indicate water polygons where 
mappers insist on closing the coastline outside of them even though 
they ecologically belong to the maritime domain and would be placed on 
the wet side of the coastline according to

https://wiki.openstreetmap.org/wiki/Proposed_Features/Coastline-River_transit_placement

By far the largest example of this is

https://www.openstreetmap.org/relation/3474227

But there are countless other cases both with and without the maritime 
tag.  I have essentially stopped trying to maintain this information 
within OSM and use either heuristics based on the geometries or 
external data to draw the line between maritime and inland water areas.

This is immensely sad for OSMs ability to record even the most basic 
information about the physical geography of Earth.  But it is not 
really right to just blame mappers for this because the vast majority 
of data users also just don't care.

> But I wonder if it wouldn't be better to make a different tag for the
> usage on marine rivers and estuaries? This would make it possible to
> keep the tag marine=yes defined for use on administrative boundaries
> only.

I see no need for that since there are no collisions between the two - 
maritime boundaries are never geometrically identical to water 
polygons.  The tag maritime=yes is exactly fitting here - this is to 
indicate a water polygon ecologically belongs to the maritime domain.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] RFC - Feature Proposal - area of steps for pedestrians.

2019-05-04 Thread Christoph Hormann
On Saturday 04 May 2019, Tobias Knerr wrote:
>
> Here's the raw data if you'd like to examine it:
> http://tobias-knerr.de/upload/Step%20Polygon%203D%20Examples/
> Please excuse the sloppy mapping, those are just intended as tests.

Thanks.  I guess that means your approach relies on a one-to-one 
relationship between linear ways and polygons - or at least on the 
polygon outline being intersected by the linear ways exactly twice.

> While you correctly point out several further limitations, I think
> it's important to keep in mind that this isn't an attempt to define a
> data model that works for everything. It's about finding a sweet spot
> that works for a sufficiently large class of steps to be worth it and
> is still relatively simple.

What would likely happen with your approach is once there are data users 
using it mappers would start splitting any stairs that are not 
supported by the algorithm artificially into parts small and simple 
enough for the algorithm to deal with and you'd end up with data 
modeled for the specific requirements and limitations of the algorithm 
rather than for mapping-efficient documentation of the nature of the 
stairs.

> As for that data model that works for (almost) everything, I believe
> that will have to be drawing a way across the edge of each step.
> [...]

That would essentially be giving up on mapping the stairs as an overall 
feature and modeling the steps individually instead.  For data users 
that need only individual steps in the end anyway this would be 
convenient but for any data users who want to interpret the steps as a 
whole this is a bad idea - likewise for the mapper who does not want to 
mechanically draw step after step.

Circular concentric steps for example like this:

https://www.designdiffusion.com/en/2018/10/15/japan-plaza-cofufun-designed-by-nendo-for-the-local-community/

you could model with:

* one circular way per step.
* a number of sector polygons and centerline ways suitable for your 
algorithm.
* a single node and tags for step count, height, inner radius and outer 
radius.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] RFC - Feature Proposal - area of steps for pedestrians.

2019-05-03 Thread Christoph Hormann
On Friday 03 May 2019, Tobias Knerr wrote:
>
> So I finally got around to building that prototype to test my idea.
> The code only needs a highway=step way and an area:highway polygon as
> input, and produces sensible results for common shapes of straight
> stairways. I'm pretty happy with the results:
>
> http://tobias-knerr.de/upload/Step%20Polygon%203D%20Examples.png

That illustration does not show the original data so it does not tell 
very much.

What you are doing is probably non-problematic as long as the upper and 
lower limit are at least roughly equidistant and the sides are strait.  
But it will likely fail with most other shapes.  In particular for 
stairs that are longer than wide and where the sides are more complex 
in shape than the upper and lower limit this is likely to fail.

Like for example classic curved stairs:

https://www.alamy.com/stock-photo-one-of-the-curved-stone-staircases-at-picton-castle-near-haverfordwest-58935307.html

In general I would advise against defining the validity of a mapping 
through some algorithm correctly interpreting it.  This is both awkward 
in principle and it would have the effect of declaring a distiction 
between 'legal' real world stairs and ones that might exist but are not 
allowed to exist because the algorithm can't deal with them.

But in general testing the suitability of a data model by testing its 
usability in practical interpretation is a good approach.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Verifiability wiki page: "Geometry" section added

2019-04-28 Thread Christoph Hormann
On Sunday 28 April 2019, Christoph Hormann wrote:
> [...]
>
> Seriously?
>
> Because one polygon is not a verifiable representation of a certain
> feature you want to replace it with - drumroll - two polygons?

I am sorry if that came across more dismissive than necessary - i was 
just quite taken aback by the suggestion which from my perspective 
pretty much flies into the face of the idea of verifiability.

But i understand the underlying thought process and see that it is not 
trivial at all why this makes very little sense and goes in the 
opposite direction of what might make sense.  And entertaining the idea 
for a moment and considering why you might think this helps but why it 
ultimately does not is a useful approach.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Verifiability wiki page: "Geometry" section added

2019-04-28 Thread Christoph Hormann
On Sunday 28 April 2019, Joseph Eisenberg wrote:
>
> Is this first line a clear definition, or can it be improved?
>
> "Linear ways and areas can be non-verifiable if the geometry cannot
> be demonstrated to be true or false by another mapper."

While that is a correct statement it also applies to nodes and tags and 
does not add any additional information to what is already stated in 
the text before, namely:

> At the core, "verifiability" is that everything you do can be 
demonstrated to be true or false

What would be useful additional information on the verifiability of 
geometries is the distinction between the ability to verifiably 
localize something and the ability to precisely measure its location.  
However i am kind of inclined to agree not to overburden the 
explanation of the basic concept of verifiability with that much 
detail.  And of course the suggestion that proper and precise 
documentation helps applies to recording of geometries as well - not 
only to tags.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Verifiability wiki page: "Geometry" section added

2019-04-28 Thread Christoph Hormann
On Sunday 28 April 2019, Tobias Knerr wrote:
>
> Yes, it's often not possible to agree on a precise border for these
> features. But nevertheless, there are typically areas that are
> definitely part of them, and other areas there are definitely not
> part of them.

I'd like to emphasize once more that verifiability has absolutely 
nothing to do with mapping precision or measurement errors.

It is the nature of every geographic feature (in the sense of something 
with at least limited localizability) that you can specify locations 
that are definitely not part of it.  That does not mean you can create 
a verifiable polygon geometry for them.

OTOH just because the only information source you have for example about 
a lake is a poor quality GPS track from a walk around it does not mean 
you cannot map that lake with a polygon based on that information.  
Because the problem here is not your limited ability to localize the 
shore of the lake but the ability to precisely measure it.

Getting this difference is key to understanding the essence of 
verifiability on OSM.

> The above is verifiable geographic information, so it ought not be
> off-limits for OSM.

So you think "The Amazon Rainforest" should be mappable with a polygon 
in OSM because you can make a verifiable statement that it does not 
extend to Asia?

> [...] One could
> imagine, for example, a relation containing two polygons for the
> feature's "minimum" and "maximum" extent (describing the parts of the
> world that are verifiably part of/not part of the feature), with a
> grey area of uncertainty in between.

Seriously?

Because one polygon is not a verifiable representation of a certain 
feature you want to replace it with - drumroll - two polygons?

The idea of developing new data objects for selectively documenting 
verifiable information of objects with limited localizability is not 
necessarily bad but the aim of this would need to be to allow limiting 
the recorded information to exactly what can verifiably be said about a 
feature, not to add more non-verifiable data to disguise the 
non-verifiable nature of the whole thing.  I have thought about this 
quite a bit and came to the conclusion that the answer to this is 
usually that using a node rarely misses any verifiable information that 
cannot most efficiently be recorded in the form of tags or that is not 
already recorded implicitly in the form of other features that are on 
their own much better verifiable.

> With your recommended solution of placing a node "near the center of
> the feature", capturing this useful knowledge is not possible. It
> also doesn't make logical sense to me: If it were indeed impossible
> to verifiably establish even an approximate boundary of the feature,
> how can we verifiably establish the feature's center?

I have had this discussion plenty of times in the past - the 
verifiability of a node localizing a feature is much easier to achieve 
(through a clear rule where to place the node) and demonstrate than for 
a polygon.  Verifiability of a node location means nothing more than 
that qualified independent placements of the node converge to a single 
location.  This is a completely scale independent condition - it can be 
fullfilled with a standard derivation of less than a meter (for 
something like a power=pole) but might also be many kilometers.  For a 
polygon that is not the case.

I don't really like the extension Joseph wrote on the Verifiability page 
but not because i disagree with the general idea but because for my 
taste it is too much *definition by example* which is a poor way of 
communicating the concept in general.  Examples are useful and needed 
to clarify the meaning (and they have been used as such on that page 
for a long time) but they are no replacement for formulating the 
general abstract idea behind verifiability in a compact form that is 
not tied to specific examples.  Andy's idea of creating subpages 
explaining how to practically apply verifiability to tags and 
geometries is probably the right approach.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Feature Proposal - RFC - Tag:natural=mesa and Tag:natural=butte

2019-04-26 Thread Christoph Hormann
On Friday 26 April 2019, Joseph Eisenberg wrote:
> I have created 2 proposal pages for natural=mesa and natural=butte
>
> A mesa is defined as "A flat-topped elevated landform surrounded by
> cliffs". A mesa may also be known as a table or tableland, potrero or
> tepui. See http://en.wikipedia.org/wiki/en:mesa
>
> A butte is defined as "a hill with a flat top surrounded by cliffs."
> The width of the flat top is less than the relative height of the
> hill. See http://en.wikipedia.org/wiki/en:butte
>
> [...]

As i understand it a butte is not generally assumed to be flat topped in 
common language use, the key elements here are height larger than width 
and cliffs on all sides.

For mesas i already mentioned the fairly precise criterion that the 
elevation variance along the top (or more precisely the derivation from 
flatness - some amount of tilt in geology is fairly common) needs to be 
significantly smaller than the overall height of the structure.  
Combined with a firm requirement for cliffs on all sides this would 
make a fairly precise definition.

In general for a successful tag explaining precisely and in detail how 
the mapper can distinguish features the tag should be used for from 
ones it should not be used for is key.  Referring vaguely to Wikipedia 
for details is not going to work, the actual meaning of the tag will 
deviate from the Wikipedia description.

It should also be mentioned that these tags are not meant to be a 
substitute for locally mapping the actual cliffs - which while by 
definition surrounding the whole structure can be staggered of course.

For natural=plateau i don't see a chance of this becoming a meaningful 
tag.  Too much inherent vagueness in the very idea.  If you'd try to 
define it more precisely it would almost certainly be advisable to use 
a different tag that is not misleading the mapper to have a much 
broader scope.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Stop the large feature madness (was: Tag for a plateau or tableland?)

2019-04-20 Thread Christoph Hormann
On Saturday 20 April 2019, Kevin Kenny wrote:
>
> I apologize for the unfortunate phrasing, and assure you that it was
> intended to be a succinct characterization of your position regarding
> indefinite boundaries, not of your personality or politics.

Thanks, i appreciate that.

When i present and argue for a position here this is not intended to 
suppress or dismiss dissenting voices, i try to convince with arguments 
which also means i emphatically present arguments that i think have 
merit.  But i also try to find convincing arguments to change my 
position.  I think it helps concentrating on the arguments and not so 
much on the people who make them.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Stop the large feature madness (was: Tag for a plateau or tableland?)

2019-04-19 Thread Christoph Hormann
On Friday 19 April 2019, Kevin Kenny wrote:
> > It is interesting that the idea that large size abstract concepts
> > projected onto arbitrarily delineated parts of the physical
> > geography by cultural convention like bays, peninsulas, linear
> > rivers and plateaus might not be suitable for being recorded in OSM
> > is by several people in this discussion reinterpreted as - and i am
> > only slightly exaggerating here - that mappers may only record
> > things after they have personally touched every centimeter of them.
>
> The fact that as many people 'reinterpreted' your words suggests that
> it might behoove you to review them.

I do that all the time, usually also preemptively, which is why i tend 
to formulate carefully to avoid misunderstandings.  In this case i 
think i have explained my idea clearly enough to Graeme - if not he is 
of course welcome to ask for further clarification.

Being accused of being radically intolerant and other things kind of 
limits my interest in this discussion with you.  I can see why you 
reject the idea there are things that should not be part of the OSM 
database despite them being part of the geographic reality as you see 
it and i also see why you have a general preference for representing 
these things in the OSM database with polygons.  But i also see very 
good reasons why you should change your position on that - some of 
which i explained in my comments here.  I could be wrong about this of 
course.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Stop the large feature madness (was: Tag for a plateau or tableland?)

2019-04-19 Thread Christoph Hormann
On Friday 19 April 2019, Graeme Fitzpatrick wrote:
> > But as already hinted i am not sure if the Drake Passage is
> > something i would consider mappable in OSM based on local
> > knowledge.
>
> But, without wishing to sound facetious, how do we then have
> coastlines for Eurasia, Greenland & Antarctica mapped?
>
> *Nobody* has "local knowledge" of the full coastline of any of them,
> & for Greenland & Antarctica, what is mapped - the ice cap, which is
> constantly moving, or the deep underlying rock? Should we erase them
> off the map as they're not "verifiable"?

It is interesting that the idea that large size abstract concepts 
projected onto arbitrarily delineated parts of the physical geography  
by cultural convention like bays, peninsulas, linear rivers and 
plateaus might not be suitable for being recorded in OSM is by several 
people in this discussion reinterpreted as - and i am only slightly 
exaggerating here - that mappers may only record things after they have 
personally touched every centimeter of them.

That does not make much sense of course.  Physical presence near a 
certain geographic setting can help you immensely to acquire local 
knowledge of it but it is neither a guarantee for doing so nor a 
prerequisite for mapping things.  And as said in the past verifiability 
based on local knowledge does not require everything in the database to 
be independently verified by several mappers with local knowledge.  It 
just requires the possibility to do so.

When mapping the coastline of Greenland or the Antarctic you have 
several independently recorded image sources available (not what you 
find in Bing & co. though - that is all the same 20 year old stuff) 
where you can localize the coastline on and there are also quite a few 
people mapping in OSM who have visited these areas.  This is definitely 
not a problem of lack of local verifiability.  In cases of doubt (which 
there might be, in particular if sea ice is present on images) we can 
look together at the images to resolve the situation or we can consult 
people with local knowledge.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Stop the large feature madness (was: Tag for a plateau or tableland?)

2019-04-18 Thread Christoph Hormann
On Thursday 18 April 2019, Kevin Kenny wrote:
> > And how do you verifiably determine if two things are part of the
> > same physical object?  For example: [examples snipped]
>
> I'm all for a rule of, 'if in doubt, split,' possibly paired with
> creating a new relation to carry the grouping.  You seem to favour a
> rule of 'never join,' which is perverse for the common case where
> there is broad consensus about object identity.

As mentioned in terms of physical geography the only cases where there 
is broad consensus on the identity of large size features and if and 
how to represent them in the OSM are lakes and islands.  For most other 
things mapped mostly with polygons, in particular stuff rendered 
typically with a color fill, it is widely accepted that polygons are 
split and most mappers prefer small and easy to handle divisions.  Many 
mapping conventions we have even require this - for example if part of 
a forest is needleleaved, part is mixed, you have to split it to 
represent this fact in the data.

Even for lakes we have cases where this applies by the way.  Lake 
Balkhash is a lake of which part is freshwater and part is saltwater 
which is mapped separately despite the name applying to both parts:

https://www.openstreetmap.org/relation/35904
https://www.openstreetmap.org/relation/3367363

If you consider this a bad idea that's fine.  But it stems from the 
fundamental idea of mapping local geographic knowledge.  For locals at 
the eastern part this is locally Lake Balkhash and it is saltwater.  
For locals at the western part this is also Lake Balkhash and it is 
freshwater.  And that is perfectly fine and nothing should require 
these mappers to settle for a uniform but locally inaccurate 
representation of the geography.

> > I distinguish between names and labels.  Labels are graphical
> > representations of names or other strings in map renderings.  The
> > OSM database should not contain labels, it should contain names.
>
> On this, we agree. To what object should the name, 'Jamaica Bay' be
> assigned? How can such an object be constructed? The locals can
> clearly define its extents, except for very small indefinite
> boundaries over narrow entrances and exits. What should be done to
> give that object, which unquestionably is observable in the field as
> an entity distinct from the ocean, existence in OSM?

I respect your desire to find a consensus for how to represent this 
particular feature but this doesn't really have much to do with the 
subject here, that is to what extent we can and should map large size 
concepts in OSM.  Jamaica Bay is beyond any doubt small enough to be 
mapped under the rule of thumb i proposed so discussing this is IMO not 
a matter of if it should be mapped but only potentially what is the 
best way to map it recording all verifiable knowledge of it in an 
efficient way.  I would like to separate that discussion from the 
subject here.  IIRC in our previous discussion on this i made a 
principal point that creating a polygon is unnecessary even here but i 
don't think i really objected to using one.

> We have that at one extreme, a case where almost all the boundaries
> are indefinite.  Nevertheless, the Drake Passage has some sort of
> existence.

Yes.  Leaving aside for the moment the question if something like the 
Drake Passage should be represented in OSM - the Drake Passage is a 
great example for a strait where no geometric information is required 
beyond a node to fully represent the feature in its spatial 
characteristics.

The Drake Passage is the passage/strait between Cape Horn (the southern 
end of South America) and the Antarctic.  As a prototype of a strait 
between two convex land masses it has no length but only a width.  It 
is perfectly documented with a node placed half way from Cape Horn to 
the closest point in the Antarctic (on the South Shetland Islands).

But as already hinted i am not sure if the Drake Passage is something i 
would consider mappable in OSM based on local knowledge.  Of course as 
long as it was mapped with a simple node it did not really bother 
anyone - you could as a mapper or data user simply ignore it.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Stop the large feature madness

2019-04-18 Thread Christoph Hormann
On Thursday 18 April 2019, marc marc wrote:
> > What if there is disagreement?
>
> it's not related to large feature, it's a issue with all
> source=local knownledge changeset (or no source at all).

No, the concept of verifiability defines a clear path for resolving 
disagreement - you verify the information on the ground and if there is 
still disagreement it is by definition something that is not verifiable 
(because several mappers evaluating the situation independently do not 
consistently come to the same results).

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Stop the large feature madness (was: Tag for a plateau or tableland?)

2019-04-18 Thread Christoph Hormann
On Thursday 18 April 2019, Kevin Kenny wrote:
>
> And therefore the Amazon, the Nile, or the Mississippi ought not to
> be named in such a way that a large-scale map can show the names?

Map producers are obviously free to show labels however they want.  They 
don't need mappers to hand curate dedicated labeling objects for that.  
Ironically the waterway relations we have are not really of much use if 
you want to label rivers in a map.

> Essentially, you're making the statement here that if local mappers
> pool their knowledge to realize that the river in Alexandria is the
> same river in Aswan, that's a mere social convention and has no place
> on the map.

How should they determine that based on local knowledge?  What if there 
is disagreement?  Is 

https://www.openstreetmap.org/way/83015625

the same river as

https://www.openstreetmap.org/way/4769426

or

https://www.openstreetmap.org/way/174752117

or

https://www.openstreetmap.org/way/234008385

What if the local mappers do not speak the same language?  Do those who 
speak English automatically get to overrule those who don't?

> > Everything else in physical geography is typically mapped locally
> > piece by piece like the rivers and creating large features - while
> > done by some mappers for the purpose of label painting - is
> > generally disliked by most mappers because it is very hard to work
> > with these and represents no additional meaningful information.
>
> That's where we disagree. The additional information is that the
> multiple features represent the same physical object.

And how do you verifiably determine if two things are part of the same 
physical object?  For example:

https://www.openstreetmap.org/way/335279145
https://www.openstreetmap.org/way/301691395

which a map producer might want to label the Amazon Rain Forest.

Or these two:

https://www.openstreetmap.org/relation/5567277
https://www.openstreetmap.org/way/470015023

which another map producer might want to label the Eurasian Taiga.

> Please avoid the term "label painting." What you call "label
> painting" is the entirely reasonable desire to have recognized, named
> objects appear on the map with their names.

I distinguish between names and labels.  Labels are graphical 
representations of names or other strings in map renderings.  The OSM 
database should not contain labels, it should contain names.

This:

https://www.openstreetmap.org/relation/9359806

is not a named representation of a verifiable element of the geography, 
it is a labeling geometry.  Creating such is not mapping, it is label 
drawing or label painting.  It is neither meant nor suited to do 
anything other than performing a relatively simple label placement.

Note by speaking of "label painting" i do not intend to assign one sided 
blame to mappers for doing so.  In most cases this is as much the fault 
of map designers encouraging this as it is of mappers to respond to 
this incentive.

> The "hard to work with" argument is what I said is a technological
> limitation.

With "hard to work with" i was referring to work for the mapper in 
maintanance, editing and also just dealing with the object being in the 
way when editing other things.  That is not a technological limitation.

When you talked about technological limitations you were referring to 
problems of data users.

> Now, I could imagine that if the world were other than as it is,
> another culture might insist that the main stem of the river was the
> Missouri, rather than the upper MIssissippi, leading to disagreement
> about the boundaries. That disagreement could be very ugly if the
> cultures were, say, continually embroiled in political conflict about
> other matters. In that case, making a single decision about the
> boundaries might conceivably be imperialistic.

I am glad you understand the problem.  If you now look at examples 
outside the United States (where if i may say so the originally 
different cultures have been largely "homogenized" a long time ago) you 
will realize that the situation is often not that simple in other parts 
of the world.  The fact that people from more than a hundred countries 
from all over the world with very different cultures, world views and 
languages in OSM work together in collecting local knowledge despite in 
many cases not even being able to verbally communicate with each other 
is quite remarkable.  But this amazing cross cultural cooperation 
hinges on on the local verifiability of those things people map.  
Adding large scale concepts to the database that are not verifiable 
based on local knowledge means throwing a wrench into the gears of this 
amazing machine.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Stop the large feature madness

2019-04-18 Thread Christoph Hormann
On Thursday 18 April 2019, Warin wrote:
>
> There are also 'points' and 'heads' to name a few other landforms
> missing in OSM.

While i have an understanding of what a mesa and a butte are i have no 
idea how you define a 'point' or 'head' so no comment on that.

> To say that they should not be mapped is to deny there existence.

No, to say some things should not be mapped acknowledges that OSM is 
about recording verifiable local knowledge and not "everything that 
exists" - whatever that means.

> It is not unusual to look for these things .. OSM failure to map them
> leads to other sources being used.

Exactly.  We need to establish that there are things outside the scope 
of OSM for which you need other projects to collect data about them.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Stop the large feature madness (was: Tag for a plateau or tableland?)

2019-04-18 Thread Christoph Hormann
On Thursday 18 April 2019, Kevin Kenny wrote:
>
> I doubt very much that you're saying what you intended here.
>
> It comes across as saying, for instance, that lakes too big to map on
> the ground in a single day should not be mapped, or should not be
> named. I think that making large waterbodies disappear would be
> ridiculous.

You apparently misunderstood what i said.  My 'surveyable in a single 
day by a single mapper' rule of thumb refers to mapping something as a 
single feature.  A river several thousand kilometers long for example.  
The river is locally still a verifiable element of the geography and 
can be mapped - piece by piece as it is generally established practice 
in OSM.  But if you create a feature for the whole river extending over 
thousands of kilometers that is not something you do based on local 
knowledge, that is based on social conventions you have read up in a 
book, on wikipedia or elsewhere.

As far as physical geography is concerned (so i leave out boundary and 
route relations here - which are a different thing) we have essentially 
only two types of feature that are generally accepted to be mapped with 
large relations:  lakes and islands.  Both of these were not always 
mapped this way - large lakes were for a long time mapped only 
locally - like the coastline.  Both of these are technically 
unnecessary to be mapped this way (there is no actual information 
transported in assembling the ways into an MP relation) because their 
geometry derives non-ambiguously from the locally mapped water 
outlines.  The decision to create MPs none the less mostly comes from 
the desire to have consistency with smaller features (which are 
obviously locally verifiable as a whole).

Everything else in physical geography is typically mapped locally piece 
by piece like the rivers and creating large features - while done by 
some mappers for the purpose of label painting - is generally disliked 
by most mappers because it is very hard to work with these and 
represents no additional meaningful information.

> Moreover, if you've mapped something on the ground, what difference
> does it make how long it took?

It is a rule of thumb.  The rule itself has no meaning on its own, it is 
designed to make it easy to determine a reasonable limit.

> I understand that there are fairly severe technological issues at
> present, where a plethora of enormous multipolygons breaks some of
> the software tools.

My argument is not a technological one, it is a social one.  Mapping 
only things verifiable based on local knowledge in OSM is essential for 
the social cohesion of the project across many different cultures world 
wide without creating an imperialistic dominance of some cultures over 
others.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Stop the large feature madness (was: Tag for a plateau or tableland?)

2019-04-17 Thread Christoph Hormann
On Wednesday 17 April 2019, Joseph Eisenberg wrote:
>
> I believe many people are using natural=peak to add the name of
> plateaus / mesas / tablelands.

Yes, that is definitely the case for buttes and small mesas - but then 
again these are features that can be verifiably mapped based on local 
knowledge.  However using a generic natural=plateau tag which is then 
inevitably used by some mappers to cargo cult polygons around just 
about any area of land elevated in some way relative to its surrounding 
is not a good idea.

I see nothing wrong with creating natural=butte and natural=mesa with 
appropriately tight definitions:  Both being surrounded on all sides by 
cliffs or very steep slopes, buttes with a height larger than width and 
mesas with a flat top (i.e. height variation across the top being 
significantly smaller than the total height).

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Stop the large feature madness (was: Tag for a plateau or tableland?)

2019-04-17 Thread Christoph Hormann
On Wednesday 17 April 2019, Frederik Ramm wrote:
> [...]
>
> The way OSM usually works is someone stumbles over something in
> reality, with a discernible name or property, and adds it to OSM. We
> are, first and foremost, surveyors.
>
> The larger a feature becomes, the less suitable OSM is for mapping
> it. And in the case of the several large-scale objects I have
> mentioned, most contributors don't even have surveying in mind, but
> just writing down existing conventions.

Indeed.  We should always keep in mind that OSM is fundamentally about 
collecting local knowledge of the geography.  'local' is key here.  If 
you try to map some geometry for the Altiplano or the Tibet Plateau 
that is not local knowledge.

As a rule of thumb i'd say something that can at least coarsely be 
surveyed on the ground by a single mapper during a single day is 
usually suitable to be mapped as a distinct named feature, provided it 
is otherwise verifiable of course.  For larger things mapping should 
focus on locally mapping locally surveyable constituent parts or 
aspects of the feature but i would be very careful with creating 
features for them as a whole because this very often drifts from the 
OSM idea of mapping local knowledge to a Wikipedia-like recording of 
social conventions.

Some of the things Joseph mentioned (like buttes) are certainly mappable 
in OSM under this rule - but i'd suggest creating specific well defined 
tags with a precise and tight definition for them and not a generic tag 
for any elevated region.

In any case i think the most valuable thing to map of any of such is the 
constituent elements and aspects of it like natural=cliff, 
natural=arete, natural=peak, natural=bare_rock, natural=scree etc.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Avoid using place=locality - find more specific tags instead

2019-04-16 Thread Christoph Hormann
On Tuesday 16 April 2019, Dave Swarthout wrote:
>
> @MarKus: Regarding the tagging of islands or lake groups (clusters),
> I've already begun to use the type=group tag and hope that someone
> will push OSM-Carto to render such relations in the future.

On a general note:  It is very unlikely that software developers are 
going to open the can of worms of interpreting relations that have 
other relations as members.  Especially for tools that need to deal 
with differential data updates like osm2pgsql.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Subtag for place=locality?

2019-04-16 Thread Christoph Hormann
On Tuesday 16 April 2019, Mark Wagner wrote:
>
> There's a "place=locality" near me called "Seven Mile Airstrip". 
> Now, that's an interesting choice of names for the place, because
> there's no evidence that it was ever used for aviation.  The best
> guess I've seen for where the name came from is that it was intended
> as an auxiliary runway for Spokane Army Air Depot during World War
> II, and after construction was canceled, the name stuck around.
>
> What tag would you recommend for "thing people believe is the
> abandoned construction site for a runway that was never built"?

The crux about about abandoned:* is that it is usually only verifiable 
as long as physical remains are present.  I don't know this particular 
situation but it looks like that is not the case here.  The question 
you need to ask yourself is what the name currently refers to and tag 
accordingly.  Is it the name of a section of a road ("drive east along 
Seven Mile Airstrip"), the name of a neighborhood or parts of it ("i 
live in Seven Mile Airstrip"), the name of some kind of common area 
("lets have a barbecue tonight at Seven Mile Airstrip"), some patch of 
wilderness ("i went hunting yesterday and shot a rabbit at Seven Mile 
Airstrip").  If you can clearly give the named feature some kind of 
classification of what it is that could also apply to other similar 
places with different name elsewhere you should use or create a tag 
indicating that.  Only if that is not the case you might use the 
generic place=locality - but only if it is actually a verifiably 
locatable place and not just a name you have heard from your 
grandfather to apply to a place around here somewhere but you can't 
really specifiy what it refers to now.

If you look into the database you can find place=locality being used for 
a lot of very different things most of which you could clearly classify 
more precisely.  A tag like place=locality will likely always exist in 
OSM - even if this one is deprecated an alternative would be invented.  
But it should be used as sparsely as possible to make the data as 
meaningful as possible.

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [Tagging] Subtag for place=locality?

2019-04-15 Thread Christoph Hormann

place=locality is currently used as a generic tag for anything with a 
name for which no established more precise tag exists.

This kind of contradicts the idea of OSM which would normally suggest to 
invent a new tag then for the type of feature you have.  Subtagging the 
generic tag to make it less generic would kind of take this to a whole 
new level.  You could take this even further and suggest tagging 
everything in OSM something like 'feature=thing' and then 
differentiating only through 'thing=*'.

Long story short - to better differentiate what is currently tagged 
place=locality the way to go is IMO to create more specific top level 
tags (or use existing ones like the mentioned "disused:/abandonded:").

-- 
Christoph Hormann
http://www.imagico.de/

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


  1   2   3   4   >