Re: [Tagging] Highway classification in Antarctica
> Fernando Trebien hat am 25.04.2024 geschrieben: > > Are such parameters absolute, or would we get a better > map if we adapt them to local realities? That is exactly one of the points i was trying to make. You can try to create a better map from map styles that are not only not optimized for the Antarctic but where also, for the most part, the Antarctic did not receive any consideration in map design. Or you can try to record semantically meaningful information about the geographic reality. Doing both at the same time is unlikely going to work. Even more clear in that regard is the use of secondary tags like snowmobile=yes, ice_road=yes, surface=ice. These are evidently factually wrong. > What is OSM's parameter to judge existence? To be clear - as far as i can see no one has doubted that research stations, supply routes and traces of overland traverses on the polar plateau are verifiable information that can and should be recorded in OpenStreetMap. The question at hand is how to tag these so that the data in OSM documents in a well defined way what is and what is not known about the features in question. -- Christoph Hormann https://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Highway classification in Antarctica
I wanted to add some cautionary advice here. Mapping in the Antarctic in OSM is to a much larger part than on other continents fueled by 'imagined' things. I am not talking about stuff here individually made up by mappers but more institutionally conjured ideas, projections and to some extent also political propaganda. The percentage of things mapped in the Antarctic in recent years that is based on secondary sources (government/institutional publications, wikipedia etc.) without any verification based on primary sources (local observations, satellite/aerial imagery, ground photos) is rather high - in a way that in the long term would become a serious problem for OpenStreetMap. Having looked at a lot of satellite imagery from the Antarctic over the years i can clearly say that a lot of claims that are being made about 'roads' in the Antarctic - in OSM or in Wikipedia - do not hold up in scrutiny against primary source evidence. And in such cases you'd have to ask yourself: Do you want OSM to represent the observable reality on the ground or do you want it to reflect the major consensus narrative of a certain cultural sphere. As a basic definition a route of navigation on land has two requirements to qualify as a road/path in OSM: * it is physically manifested in some form, at least during those periods when it is used (in case of seasonal roads on seasonally dry/frozen lakes/rivers for example). * it is used in the physically manifested form with some level of regularity and permanency. Two examples from outside the Antarctic that would probably not qualify: https://mc.bbbike.org/mc/?lon=10.713939=17.952688=13=3=bing-satellite=mapnik=nokia-satellite https://mc.bbbike.org/mc/?lon=14.069293=22.547244=17=3=bing-satellite=mapnik=nokia-satellite The first simply lacks a physical manifestation (because the ground is too dynamically re-shaped by wind and the route used is too variable in its exact course). The second visibly demonstrates that no single physically manifested track is commonly used by the different users of the route. Both of these are evidently verifiable routes of navigation (a bit like ferry routes) - but, by established meaning of the road tags in OSM, not roads (though of course mappers are free to map them as such - as evidenced by the examples). Looking concretely at long distance supply routes in the Antarctic - those are largely quite comparable to the linked to cases outside the Antarctic - except that most of them are much more sparsely used for very specific purposes (supply of a specific remote location with certain goods that are impossible or much less cost efficient to transport via airplane). By established conventions of functional road tagging in OSM these would almost all be service roads (no through-traffic to other destinations than the ones the route ends at). The level of physical manifestation varies a lot depending on local snow and wind conditions and type and frequency of use. Some routes that have likely not been used for many years are clearly visible in images while others (some of which are claimed to be used with high frequency on Wikipedia and elsewhere) have clearly no physical manifestation. In general, it is unlikely that mappers at large can be convinced to refrain from inflating tagging in the Antarctic to compensate for the variable scale of the Mercator projection or to reproduce certain subjective believes of importance. This applies to both routes of navigation and populated places. The solution would be to create distinct tagging to account for the concrete features that exist and are practically verifiable specifically to be used in parallel with the subjectively inflated (and therefore semantically meaningless) mainstream tags. In this specific case that would be tagging of routes of land navigation with sporadic use and permanently/regularly populated places that are not settlements in the sense that people individually settle there for a longer time, but that might still fulfill some of the functions settlements have elsewhere. The criteria for such tagging should be chosen for practical verifiability based on available primary sources. -- 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?
> 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?
> 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?
> 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?
> 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?
> 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?
> 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?
> 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
> 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
- 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
> 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
> 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
> 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
> 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?
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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
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?
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)
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)
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
> 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)
> 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)
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?
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"
> 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"
> 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"
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
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?
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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?
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
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
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
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
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
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
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
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
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)
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?
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
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
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
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)
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?
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.
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.
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
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
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
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
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?)
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?)
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?)
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?)
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
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?)
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
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?)
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?)
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?)
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
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
